大規(guī)模異構(gòu) GPU 資源碎片治理基于拓撲親和與 Binpack 算法的調(diào)度優(yōu)化在管理上百節(jié)點、包含 A100、H800、L40 及國產(chǎn)異構(gòu)加速卡的混合算力集群時最令人頭疼的問題往往不是算力絕對總量的不足而是“顯存碎片化”與“拓撲不匹配”。經(jīng)常出現(xiàn)的情況是集群總空閑顯存高達上千 GB但當一個需要 8 卡 NVLink 全互聯(lián)的 70B 大模型任務(wù)提交上來時卻沒有任何一臺物理機能夠滿足連續(xù)的 8 卡拓撲需求。原因在于之前的零散小任務(wù)隨意分布在各個節(jié)點上把原本連續(xù)的 NUMA / NVLink 節(jié)點打得支離破碎。為了解決異構(gòu)算力碎片化問題我們自研并落地了基于 Kube-Scheduler 框架的拓撲感知裝箱Binpack調(diào)度插件。graph TD subgraph 待調(diào)度任務(wù)隊列 TaskA[70B分布式推理 申請8卡互聯(lián)] TaskB[LoRA微調(diào) 申請2卡] TaskC[Embedding 單卡切片] end Scheduler[拓撲感知調(diào)度器] TaskA -- Scheduler TaskB -- Scheduler TaskC -- Scheduler subgraph 節(jié)點拓撲與打分決策 Scheduler -- Filter[拓撲過濾器: 校驗NVLink/PCIe Switch連通性] Filter -- Score[Binpack 打分器: 優(yōu)先填充已有碎片節(jié)點] Score -- BestFit[選定最佳節(jié)點: 保留完整整機給大任務(wù)] end BestFit -- Node1[節(jié)點 1: 已滿載] BestFit -- Node2[節(jié)點 2: 填充輕量任務(wù)] BestFit -- Node3[節(jié)點 3: 預(yù)留完整 8 卡拓撲]1. 物理拓撲感知從單卡數(shù)量到通信帶寬矩陣在傳統(tǒng)的 Kubernetes 默認調(diào)度器中GPU 只是一個無差別的標量資源如nvidia.com/gpu: 2。調(diào)度器只要看到節(jié)點剩余 GPU 數(shù)量大于等于 2就會把 Pod 調(diào)度過去。但在真實硬件中卡 0 和卡 1 可能通過高速 NVLink 直連帶寬達到 600GB/s而卡 0 和卡 7 可能跨越了 CPU NUMA 節(jié)點通信只能走高延遲的 PCIe 總線帶寬驟降至 32GB/s。如果讓分布式張量并行Tensor Parallel跨越 NUMA 節(jié)點運行模型推理延遲會直接增加 3 倍以上。我們在調(diào)度插件中維護了節(jié)點硬件的物理拓撲掩碼Topology Maskpackage scheduler import ( context fmt v1 k8s.io/api/core/v1 k8s.io/kubernetes/pkg/scheduler/framework ) type GPUTopologyPlugin struct { handle framework.Handle } const PluginName GPUTopologyBinpack func (p *GPUTopologyPlugin) Name() string { return PluginName } // Filter 階段不僅檢查卡數(shù)更校驗是否存在滿足通信帶寬的連續(xù)卡組合 func (p *GPUTopologyPlugin) Filter(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeInfo *framework.NodeInfo) *framework.Status { reqGPUs : getRequestedGPUs(pod) if reqGPUs 1 { return framework.NewStatus(framework.Success) } node : nodeInfo.Node() topologyData, exists : node.Annotations[topology.gpu.internal/matrix] if !exists { return framework.NewStatus(framework.Unschedulable, 節(jié)點缺少 GPU 拓撲元數(shù)據(jù)) } if !hasContiguousTopology(topologyData, reqGPUs) { return framework.NewStatus(framework.Unschedulable, fmt.Sprintf(節(jié)點無滿足帶寬的 %d 卡連續(xù)拓撲, reqGPUs)) } return framework.NewStatus(framework.Success) } // Score 階段采用 Binpack 策略傾向于將碎任務(wù)擠入同一個 NUMA 節(jié)點盡量空出整機 func (p *GPUTopologyPlugin) Score(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeName string) (int64, *framework.Status) { nodeInfo, err : p.handle.SnapshotSharedLister().NodeInfos().Get(nodeName) if err ! nil { return 0, framework.NewStatus(framework.Error, err.Error()) } usedGPUs, totalGPUs : getNodeGPUUsage(nodeInfo) if totalGPUs 0 { return 0, framework.NewStatus(framework.Success) } // 計算裝箱分數(shù)已有使用率越高打分越高加速填滿單機 utilization : float64(usedGPUs) / float64(totalGPUs) score : int64(utilization * 100) return score, framework.NewStatus(framework.Success) }2. 碎片主動整理與低優(yōu)先級任務(wù)搶占靜態(tài)調(diào)度只能保證任務(wù)入場時的合理性但隨著不同任務(wù)生命周期的異步結(jié)束集群不可避免地會再次產(chǎn)生碎片。為了動態(tài)消除碎片平臺引入了周期性碎片整理與智能重排控制器apiVersion: config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration leaderElection: leaderElect: true profiles: - schedulerName: gpu-topology-scheduler plugins: filter: enabled: - name: GPUTopologyBinpack score: enabled: - name: GPUTopologyBinpack weight: 100 reserve: enabled: - name: GPUTopologyBinpack控制器每隔 15 分鐘掃描一次全集群。當發(fā)現(xiàn)某臺 8 卡機器上只運行了一個單卡低優(yōu)先級批處理任務(wù)而其他節(jié)點有能力容納該任務(wù)時控制器會自動向該任務(wù)發(fā)送安全遷移信號優(yōu)雅終止并在另一節(jié)點重建從而將整臺 8 卡機器釋放出來為后續(xù)的高優(yōu)先級大模型任務(wù)保留黃金算力槽位。3. 生產(chǎn)調(diào)優(yōu)成效與避坑總結(jié)通過拓撲感知與裝箱調(diào)度的結(jié)合我們在生產(chǎn)環(huán)境中取得了顯著的收益集群整卡可用率提升8 卡連通任務(wù)的調(diào)度成功率從 61% 提升至 94%消除了“有空閑卡卻調(diào)不動大任務(wù)”的窘境。算力裝箱率顯著提高在混合運行微調(diào)、輕量推理與批量計算的集群中整體算力碎片率下降了近 40%。避免過早調(diào)度鎖定在 Score 階段必須同時結(jié)合 CPU、內(nèi)存與 RDMA 網(wǎng)絡(luò)的分配情況防止因 GPU 綁定成功但宿主機網(wǎng)絡(luò)帶寬打滿造成的性能次生災(zāi)害。