拓撲感知排程
3 秒看懂
拓撲感知排程（Topology-aware Scheduling）是一種根據計算節點間的物理/邏輯連線關係（拓撲）來智慧放置任務的排程策略。在 AI 大型模型分散式訓練這類重通訊場景中，如果不考慮節點之間的“遠近距離”，任務就可能被分散到不同機架甚至不同交換器下，導致網路跳數多、延遲高，拉長訓練時間。拓撲感知排程會把相互通訊密集的任務排程到同一機架、同一交換器、甚至同一臺機器內 NVLink 直連的 GPU 上，讓通訊“抄近路”，顯著縮短作業完成時間。
3 分鐘產業解釋
在 Kubernetes 叢集上跑多卡 AI 訓練或大規模資料分析作業時，Pod 之間通常有巨大的網路通訊需求（例如 AllReduce 集合通訊或引數同步）。原生 Kubernetes 排程器預設根據節點的資源可用情況和 Pod 請求進行負載均衡（如 LeastAllocated 策略），這往往會導致 Pod 分散到不同節點，反而增加了高通訊需求 Pod 之間的網路距離，拉高時延，致使訓練作業“久而不快”。
拓撲感知排程通過以下思路解決此問題：
- 感知物理拓撲：識別節點的分佈層級——同一 NUMA 節點、同一 GPU 直連域（NVLink）、同一機架（Rack）、同一交換器（Tor）等。
- 量化通訊代價：將不同物理連線方式對映為可比較的“通訊分數”，例如 NVLink 直連分數高（通訊優秀），跨 PCIe 或乙太網路分數低。
- 排程決策最佳化：基於分數做成組排程、最佳匹配、反碎片等策略，將一組需要高通訊頻寬的 Pod 放到一起。
阿里雲端 ACK 的“拓撲感知排程”功能和開源專案 HAMi 的 NVIDIA GPU 拓撲感知排程，都是產業落地的代表。前者在 Kubernetes 層面提供了在多拓撲域中自動重試的 Gang 排程能力，解決原生親和排程“一次失敗就卡住”的痛點。後者則深入到單節點內，通過 NVML 動態探測 GPU 間的 NVLink/PCIe 拓撲，將物理連線數字化，讓排程器做出最優的 GPU 組合選擇，兼顧短期效能和長期叢集資源健康度。
15 分鐘專家深入
要理解拓撲感知排程的全貌，需要從兩個層次拆解：
-
節點內 GPU 拓撲感知（單機多卡場景）
- 感知物件：GPU 與 GPU 之間是通過 NVLink 直連、NVSwitch 全互聯，還是僅通過 PCIe 匯流排連線。
- 目標：將多卡訓練任務的一組 GPU 分配在 NVLink 頻寬最高、延遲最低的組合上。例如，8 卡 A100 節點中，某些卡兩兩之間是 NVLink 直連，有些需經過 PCIe Switch 轉發，後者通訊效率會大幅下降。
- 實現方式：裝置外掛（Device Plugin）通過 NVIDIA NVML 庫即時探測 GPU 對之間的連結型別，然後轉化為標準化的“拓撲通訊分數”，排程器基於此分數做匹配。
-
多節點網路拓撲感知（跨機器分散式場景）
- 感知物件：節點在叢集網路中的位置——同一機架、同一聚合交換器、跨層級路由器等。
- 目標：將同屬一個分散式訓練作業的所有節點儘可能放在網路跳數最少、頻寬最大的子域內。
- 實現方式：利用 Kubernetes 節點標籤（如
topology.kubernetes.io/zone、rack、switch）以及自定義拓撲域，通過 Gang 排程保證所有 Pod 同時繫結，並在多個可用拓撲域中重試。
關鍵技術武器：
- Gang Scheduling：要求一個作業的所有 Pod 必須一起獲得資源後才開始執行，避免“部分 Pod 先排程到理想位置，其他 Pod 因資源不足而 Pending，重試時卻無法切換到另一個可用拓撲域”的問題。
- 動態拓撲打分：不再依賴靜態標籤，而是由 Device Plugin 持續將動態探測的拓撲資訊轉化為分數，以反映真實的物理連線優劣。
- 雙模式防碎片策略：對多卡並行任務採用“最佳匹配”（尋找通訊分數最高的 GPU 集合），對單卡獨立任務則採用“最小破壞”（優先使用對鄰近 GPU 通訊破壞最小的空閒卡），防止將可構成高頻寬組合的 GPU 群拆散，維護叢集的長期排程能力。
因此，拓撲感知排程 = 拓撲數字化 + 成組約束 + 分數決策 + 防碎片。
技術原理
本部分以 HAMi（開源方案）針對 NVIDIA GPU 的拓撲感知排程 為核心示例，闡釋從資料採集到排程決策的完整機制。
整體流程：先量化，再決策
┌──────────────────────────────────────────────┐
│ 階段一：拓撲註冊 │
│ Node內 Device Plugin → NVML 探測 → 通訊分數 │
└──────────────────┬───────────────────────────┘
│ 上報（Device 擴充套件資源 + 分數矩陣）
▼
┌──────────────────────────────────────────────┐
│ 階段二：排程決策 │
│ Scheduler → 過濾可用節點 → 根據分數選最優 GPU 組合│
└──────────────────────────────────────────────┘階段一：拓撲註冊——將物理連線數字化
- 資訊探測：每個 GPU 節點上的 Device Plugin 利用 NVIDIA NVML 庫，遍歷所有 GPU 裝置對 (
GPU_i,GPU_j)，獲取它們之間的直連型別（NVLink 或 PCIe），並檢測是否經過 NVSwitch。 - 建模與打分：
- 在記憶體中構造 GPU 連線圖譜。
- 依據預設評分規則將連線型別轉換為數值，例如（來源：[HAMi 解析]）：
SingleNVLINKLink計 100 分，PCIeLink計 10 分（示例性定性表述，實際分數取決於具體實現）。 - 最終形成節點內每對 GPU 的“通訊分數矩陣”，上報給 Kubernetes 排程器。
階段二：排程決策——在拓撲維度上做組合最佳化
-
排程器 Fit 函式擴充套件：HAMi 內建了兩套防碎片排程策略，根據請求型別自動選擇：
- 多卡並行任務（如 4/8 卡訓練）：啟用“最佳匹配”策略。排程器會計算請求 GPU 數量下所有可能組合的總通訊分數（例如所有選中卡兩兩之間分數之和），選擇總分最高的組合。這樣確保任務被分配到的 GPU 之間物理連線最優。
- 單卡獨立任務：啟用“最小破壞”策略。優先使用那些與已佔用 GPU 之間通訊分數較低的空閒卡，避免把可用於未來多卡最優組合的“好卡”提前用掉，降低叢集拓撲資源的碎片化。
-
Gang 排程協同（阿里雲端 ACK 等平台）：
當作業包含多個 Pod 且需跨節點時，通過 PodGroup 標籤宣告一組 Pod 必須同時排程。若第一次選擇的拓撲域無法滿足所有 Pod，排程器不會將部分 Pod 置於 Pending 不去重試，而是在多個不同的拓撲域（可用區、機架）中迴圈重試，直到找到能夠容納整個作業的位置。配置示例（簡化自阿里雲端幫助中心）：
labels: pod-group.scheduling.sigs.k8s.io/name: "tf-smoke-gpu" pod-group.scheduling.sigs.k8s.io/min-available: "3" # 與Pod數一致 annotations: alibabacloud.com/topology-aware-core: "..." # 拓撲約束定義
關鍵引數域
- 拓撲域（Topology Domain）：定義一組在拓撲上被認為“近”的節點集合，如
kubernetes.io/hostname、failure-domain.beta.kubernetes.io/zone、自定義rack等。 - 通訊分數（Communication Score）：反映裝置對之間通訊效率的無量綱數值，由具體實現定義對映規則。分數越高表示頻寬越大、延遲越低。
- 最大偏斜（MaxSkew）：定義 Pod 在拓撲域間分佈的不均勻度上限，值越小分佈越均衡；若目標為將 Pod 全部集中在最小拓撲域，應使用親和排程或 Gang 排程，而不依賴偏斜控制。
注意：此處給出的“100 分”“10 分”等數值參考了開源資料中的示例，各廠商、各版本的具體規則可能不同，僅用於說明分數化思路。
技術演進史
早期：僅靠親和/反親和，缺乏拓撲彈性
- Kubernetes 原生
nodeAffinity/podAffinity可以將 Pod 吸引到具有特定標籤的節點或拓撲域，但存在兩大痛點：- 重試僵化：一旦第一個 Pod 落地，如果該拓撲域資源不足以容納整個作業，部分 Pod 將永遠 Pending，排程器不會自動切換到其它滿足條件的拓撲域。
- 粒度不足：通常只能親和到“可用區”級別，無法進一步細化到機架或 NUMA 節點。
2019‑2021：引入 Topology Manager 和 GPU 拓撲萌芽
- Kubernetes Topology Manager 試圖在 CPU、記憶體、裝置（如 SR‑IOV 網絡卡）之間進行 NUMA 對齊，但初期對 GPU 叢集的成熟度有限。
- NVIDIA 推出 NVLink/NVSwitch 硬體，驅動社群開始關注 GPU 間的通訊拓撲，但排程仍多為靜態、手工配置。
2021‑至今：阿里雲端 ACK、HAMi 等方案成熟
- 阿里雲端 ACK 拓撲感知排程 + Gang 排程：通過
pod-group和拓撲約束 Annotation，支援 Pod 在多個拓撲域中自動重試，解決了“親和失敗即死”的問題。 - HAMi v2.7.0 釋出面向 NVIDIA GPU 的拓撲感知排程（2024‑2025 前後，源自資料時間推斷）：首次將動態探測‑打分‑最佳匹配/最小破壞鏈路完整實現，並作為開源專案被超過 120 家企業/機構採用。
當前，行業正在向 “全棧拓撲感知” 演進：即從單機內 GPU 拓撲到跨機網路結構（RDMA、IB、RoCE）均納入統一的排程分值體系，並結合擁塞控制、集體通訊庫協同，實現端到端的通訊最佳化。
技術路線對比
下表對不感知拓撲的預設排程、基於靜態標籤的拓撲親和，以及兩種典型拓撲感知排程方案進行對比：
| 方案 | 排程粒度 | 動態性 | 防碎片能力 | 多拓撲域重試 | 網路層級支援 | 關鍵實現 |
|---|---|---|---|---|---|---|
| K8s 預設排程（資源負載均衡） | 節點級 | 無 | 差 | 否 | 無 | – |
| 靜態拓撲親和（NodeAffinity） | 常用區/機架（標籤） | 差（標籤固定） | 差 | 否（僅一次機會） | 可手寫標籤 | K8s 原生 nodeAffinity |
| 阿里雲端 ACK 拓撲感知排程 + Gang | 可用區/機架，可自定義 alibabacloud.com/topology-aware-* | 中等（標籤可更新，但非即時探測） | 一般 | 是（自動切換拓撲域） | 機架/交換器 | 擴充套件排程器 + PodGroup |
| HAMi NVIDIA GPU 拓撲感知排程 | 單 GPU 對級別（NVLink vs PCIe） | 高（NVML 動態探測，即時改分） | 優（最佳匹配+最小破壞） | 不直接管理跨節點拓撲域，可與上層排程配合 | 僅節點內 GPU 拓撲 | Device Plugin + 自定義 Fit |
路線選擇要點：
- 若僅需簡單的跨機架親和，原生
nodeAffinity+podAffinity即可，但要注意重試缺陷。 - 若叢集跨節點通訊頻寬對訓練至關重要，且容忍部分 Pod Pending 需要自動恢復，考慮 ACK 式的 Gang + 拓撲域重試方案。
- 若叢集內單節點有多張 GPU，且訓練任務常為多卡並行，強烈建議部署類似 HAMi 的節點內拓撲感知排程，以避免 GPU 組合中的“短板效應”。
上下游
上游
- 硬體拓撲：GPU（NVLink、NVSwitch 代際）、高效能網絡卡（InfiniBand、RoCE）、交換器層級（ToR、Spine、Core）。
- 資源管理系統：Kubernetes（排程器、Device Plugin 架構）、Slurm（傳統 HPC）等。
- 拓撲資訊匯出：NVIDIA NVML、Kubernetes Topology Manager、廠商自定義節點標籤/Annotation。
下游
- 分散式訓練架構：PyTorch DDP、DeepSpeed、Megatron‑LM 等。它們通過 NCCL 通訊庫呼叫底層拓撲最佳化過的 GPU 集合，排程結果直接決定 AllReduce 實際頻寬。
- 作業執行效率：更優的親和擺放可減少單次迭代的通訊時間佔比，提升可擴充套件性和 GPU 利用率。
- 叢集運營成本：通過提高算力利用效率和減少長尾作業，降低單位訓練成本。
關鍵指標
- 有效通訊頻寬：訓練作業實際達到的互聯頻寬與理論峰值的比例。拓撲感知排程應使其趨近於 1。
- 作業完成時間（Job Completion Time, JCT）：啟用拓撲感知後，通常可減少 10%–30% 的通訊尾延時影響（定性估計，具體取決於場景）。
- 拓撲碎片率：因不當分配導致後續多卡任務無法找到最優 GPU 組合的機率。HAMi 等最小破壞策略旨在降低此值。
- 重試成功率：Gang 排程在首次拓撲域失敗後，於其他域成功排程的機率。阿里雲端方案實現了跨域重試，有效提升了成功率。
- 排程延遲：增加拓撲打分和組合最佳化帶來的額外排程計算時間，通常設計目標是遠小於作業生命週期，毫秒級可接受。
供需與市場資料
由於檢索資料未提供具體市場規模，以下為定性分析：
- 需求端：大型模型（引數規模 > 10B）訓練普遍需要數百至數千 GPU，通訊開銷可佔總訓練時間的 30% 以上。雲端服務商和自建叢集的企業對“拓撲感知排程”的訴求極為強烈，因為它是提升算力效率、降低成本的關鍵槓桿之一。
- 供給端：開源社群（HAMi 已有 120+ 企業採用）與頭部雲端廠商（阿里雲端、火山引擎、華為雲端等均有類似功能）形成供給。NVIDIA 自身也在通過 NVML 和 NCCL 提供硬體側的配合。
- 趨勢：隨著 AI 訓練叢集從千卡向萬卡級別擴充套件，網路拓撲感知排程將逐步從“可選最佳化”變為“標配能力”，並可能與擁塞控制、集體通訊庫更深耦合。
代表公司與資本對映
- 阿里雲端：ACK 容器服務提供拓撲感知排程與 Gang 排程，為公共雲端和專有雲端使用者降低 AI 訓練成本。
- HAMi 社群：活躍開源專案，由 15+ 國家 350+ 貢獻者維護，超過 120 家機構採用（來源：CSDN 部落格）。無直接上市/融資對映，但其生態價值體現在被廣泛整合。
- NVIDIA：通過硬體拓撲、NVML 和 NCCL 庫為上層排程提供必要的資料，自身不直接做 K8s 排程器，但通過合作伙伴生態影響行業。
- 其他雲端服務商：各主流雲端廠商均有類似功能或計劃，但具體命名和實現細節各異。
資本對映方面，暫無直接以“拓撲感知排程”為單一業務的公司上市或獲得專門融資，其價值多內嵌於雲端運算或 AI 平台型公司中。
投資邏輯
- 效率即成本：大型模型訓練動輒千萬美元，任何節約通訊時間的軟體最佳化都會直接轉化為顯性成本的節省。拓撲感知排程作為“軟體定義算力”的典型，投入產出比高。
- 雲端廠商競爭壁壘：誰能提供開箱即用的智慧拓撲排程、更低的算力成本，誰就更可能贏得 AI 訓練託管的大客戶。這是一個重要的產品競爭力指標。
- 生態受益：與 GPU 硬體、高速網路方案深度繫結的排程最佳化，會增強相關硬體（如 NVLink 交換器、InfiniBand 介面卡）在叢集採購中的必要性，利好 NVIDIA、Mellanox（NVIDIA 網路部門）等。
- 風險提示：排程策略與具體硬體代際強相關，硬體拓撲變化可能導致原有規則失效，需持續投入適配；開源方案（如 HAMi）的成熟可能降低商業工具的獨有優勢。
常見誤讀糾偏
誤讀 1：拓撲感知排程就是簡單的 podAffinity，上個標籤就好。
事實：原生 podAffinity 無法在多個拓撲域間自動重試，一旦第一次放置失敗就無法自動切換到另一個同樣滿足條件的機架，且粒度粗。真正的拓撲感知排程結合了動態打分、Gang 排程重試和碎片預防，遠不止貼標籤。
誤讀 2：只要解決單節點內 GPU 拓撲就夠了，跨節點網路無所謂。
事實：分散式訓練中 AllReduce 大量資料跨節點傳輸，忽略機架/交換器拓撲可能導致流經 higher‑level 交換器，頻寬驟降。多層次拓撲感知（節點內 + 跨節點）才能全面最佳化。兩者需協同。
誤讀 3：排程分數是固定不變的，一次設定終生有效。
事實：HAMi 的方案證明，拓撲分數可以由 Device Plugin 動態探測並即時更新，以適應硬體變化或髒標籤。靜態打分無法應對 GPU 故障或動態切換連線模式。
學習路徑
- Kubernetes 排程架構基礎：理解排程佇列、Filter/Score 擴充套件點、Device Plugin 機制、Topology Manager。
- GPU 互聯技術：學習 NVLink、NVSwitch、PCIe 的基本原理與頻寬差異，以及 NCCL 通訊庫對拓撲的感知方式。
- 分散式訓練通訊模式：掌握 AllReduce、All‑to‑All、ReduceScatter 等原語，以及它們在 Ring、Tree、Collnet 等演算法下的流量特徵。
- 實踐案例：動手部署 HAMi 或體驗阿里雲端 ACK 的拓撲感知排程 Demo，觀察排程結果對 NCCL 頻寬的影響。
- 深入前沿：研讀 Volta、Ampere、Hopper 等架構的白皮書中關於 NVLink 代際變化的章節，以及 SIG‑scheduling 社群的拓撲相關 KEP 提案。
一句話總結
拓撲感知排程把叢集的物理連線資訊端到端數字化，並注入排程決策，讓 AI 訓練的每個資料包都跑在最短、最快的路徑上，以此將高昂的通訊成本壓到最低。
延伸閱讀與來源
- 阿里雲端 ACK：拓撲感知排程
- HAMi NVIDIA GPU 拓撲感知排程實現詳解（PHP中文網）
- 詳細剖析 HAMi 支援 NVIDIA GPU 拓撲感知的設計與原理（CSDN）
- Kubernetes Topology Manager 官方文件
- NVIDIA NVML 開發者文件
本文涉及的定量示例（如分數值）均源自檢索資料的描述，用於體現原理，不代表特定版本的精確數值。具體實現細節請以各專案最新原始碼和官方文件為準。