异构算力调度：GPU不是供品，资源池化才是硬仗

先扔个场景。某AI团队买了8卡A100服务器，训练任务排队到天亮，推理服务却只吃掉半张卡。另一边，几个CPU节点闲着发呆。老板问：算力不够？运维苦笑：不是不够，是摆得不对。这就是异构算力调度要啃的骨头。不是把CPU、GPU、NPU插满机柜就完事。真正难的是让任务找到合适的资源，让资源别在角落里吃灰。

异构不是把卡插满机柜

CPU、GPU、FPGA、ASIC、NPU，架构差得远。GPU擅长并行计算，CPU擅长逻辑控制，NPU专啃特定算子。你把它们塞进一个池子，调度器面前就不是“几台机器”那么简单。显存、算力类型、卡间互联、NUMA节点、PCIe带宽、RDMA网卡，全得进资源画像。

举个常见的坑。一张GPU卡切MIG，能切成不同形状的实例。任务A只要8GB显存，任务B要40GB，任务C还要跨卡NVLink通信。调度器如果只看“剩余卡数”，很容易把任务C扔到跨机柜的两张卡上。训练速度掉一半。钱烧得心疼。

很多平台大屏很漂亮，利用率曲线也漂亮。实际任务排队排到骂人。为什么？资源标签太粗。GPU型号、显存规格、互联拓扑、驱动版本、CUDA版本，都得进调度视图。少一个标签，调度就可能拍脑袋。异构算力调度的第一层，不是算法，是资源画像。画像不准，后面全歪。

调度器到底在调什么

我习惯分三层看。集群级，决定任务进哪个资源池。看SLA、配额、价格、数据位置。节点级，看NUMA和PCIe拓扑、网卡亲和。设备级，看GPU切分、共享、隔离。三层没打通，就会出现“集群看着有空，任务就是跑不起来”的怪事。

Kubernetes的device plugin能报资源数量，拓扑感知得靠扩展。MIG是硬隔离，切分固定，灵活度差。MPS能共享，故障隔离弱，一个任务崩了可能拖邻居下水。时间片共享对在线推理友好，对训练任务容易抖。选哪种，得看业务。

科研里有些招数挺有意思。Gavel做异构GPU集群调度，考虑不同卡型和任务性能。Pollux把弹性资源分配和批处理大小放一起优化。Gandiva做GPU时空共享。Tiresias做在线调度。论文里的假设到了生产环境，经常被打脸。任务时长分布、抢占成本、故障率，全得重新标定。

说实话，离线训练和在线推理根本不是一类活。训练喜欢整卡、长时间、拓扑稳定。推理喜欢小切片、弹性、快速伸缩。混在一起调度，得有优先级和抢占。抢占别乱来，checkpoint成本高。潮汐调度把离线任务放到夜间，听着美，在线峰值一来照样鸡飞狗跳。调度策略要跟workload的形状走，别拿一个模子套所有任务。

科研成果落地，最怕只抄公式

有团队做异构资源统一抽象，把GPU算力、显存、互联带宽建模成多维向量，用在线学习预测任务性能。听起来高级。落地时采集指标很痛。性能计数器、NVLink利用率、PCIe带宽，采太细开销大，采太粗没意义。还有调度周期。秒级对训练够用，对推理突发不够。毫秒级又容易抖。

折中办法是分层。粗粒度分钟级做放置，细粒度秒级做副本伸缩。跨集群调度更麻烦。数据在A地，算力在B地，网络带宽不够，调度过去就是灾难。所以调度器得算“数据引力”。跨域异构算力调度，先算网络账，再算命。这话糙，理不糙。

几个容易踩的坑

只看利用率，不看排队时长。GPU利用率90%可能是大任务占着，短任务饿死。忽略故障域。共享GPU一个任务OOM，邻居跟着遭殃。配额僵化。按卡数分配额，不如按显存和算力分。缺少可观测。调度决策要能解释，不然业务方天天吵架。能耗和散热也得看。机柜功率摆在那，不是想插满就插满。

有些方案PPT里全是“智能”。一问拓扑标签怎么打，沉默了。一问抢占后checkpoint怎么恢复，又沉默了。异构算力调度不是买个调度器就完事，它是资源治理。标签体系、配额、计费、监控、故障隔离，得一起上。

落地顺序我偏保守。先把资源画像和标签做扎实。再上优先级和抢占。最后才碰智能预测。一上来搞强化学习，数据不够，调参调到怀疑人生。先把那半张闲着的GPU用起来，比啥都实在。