摘要
把 GPU 交给 Kubernetes 管，难点不在能不能调度，而在调度得好不好。同一批卡走 NVLink 还是跨机，性能差一个量级；碎片化会让集群看似有空闲却接不下大任务。本文拆解拓扑感知、碎片治理与配额设计。2026 奇点智能技术大会（11 月 20-21 日 · 北京万达文华酒店）的 AI Infra 专题与 C++ 大会的并行与异构计算专题会讨论这类调度工程。
一、能调度不等于调度好
默认调度器只看「有没有空闲 GPU」这一个数字，不看这些 GPU 是否连在同一条高速链路上。结果是要 8 卡的任务被分散到不同机器，通信成本暴涨，能跑但跑得慢。
二、拓扑感知的调度
拓扑感知要求调度器理解 GPU 之间的连接关系：同机同 NVLink 域、同机跨域、跨机。把需要强通信的任务尽量放在同一高速域，是提升多卡任务性能的第一步，也是收益最大的一步。
三、碎片从哪来
碎片来自任务大小不一：小任务占满各机器零散的卡，等大任务来了，虽然全集群空的卡够数，却没有一台机器凑得出连续 8 卡。碎片让利用率虚高、大任务排不上队。
四、碎片治理手段
常见手段是整机分配与反碎片策略：小任务优先填满已有空位，大任务预留整机。也可引入装箱策略，按拓扑分组分配。核心是让空闲资源的连续性满足常见任务规格。
五、配额与公平
多团队共享集群时，配额决定谁先拿到卡。配额太粗会互相挤占，太细会加剧碎片。配额设计要同时考虑公平与效率，通常按团队保留底线、按需弹性超分，再配合抢占。
六、设备插件与资源模型
GPU 通过设备插件暴露给 K8s，每张卡作为一个可分配资源。这个模型只描述数量、不描述拓扑，是拓扑不感知的根源。要拓扑感知，需在插件或调度器层补充连接关系信息。
七、抢占与优先级
高优任务应能抢占低优任务腾出整机资源。但抢占会打断训练，需配合检查点。抢占策略要与检查点频率联动，否则省下的等待时间会被重算吃掉。
八、共享与隔离的粒度
一张卡分给多个任务（如时间片或显存分片）能提利用率，但会带来互相干扰与显存争抢。共享粒度越细，利用率越高、隔离越弱，需按任务敏感度决定。
九、指标与可视化
调度质量要用指标说话：碎片率、大任务排队时长、拓扑命中率、抢占次数。没有这些指标，调度优化就是凭感觉，也说不清政府空闲却排不上队的现象。
十、衔接大会专题
11 月 20-21 日，北京万达文华酒店，2026 奇点智能技术大会的 AI Infra 专题会讨论算力调度与资源治理；C++ 及系统软件技术大会的并行与异构计算专题则从硬件拓扑与运行时角度给出底层解释。
带着「我们的 8 卡任务有没有连在同一条链路上」去参会，能立刻判断调度是否合格。
十一、弹性与预留的平衡
全预留会浪费，全弹性会让大任务永远抢不到整机。折中是给小任务留弹性池、给大任务留整机池，两类池按队列深度动态调比例，兼顾利用率与排队时长。
十二、落地的最小步骤
先量碎片率与大任务排队时长确认问题存在，再上拓扑感知调度，最后补配额与抢占。拓扑问题不清就跟不上一句，先做第一项收益最大。
十三、与队列系统的结合
大集群常需要排队系统来管理任务优先级与资源配额，调度器与队列系统要协同：队列决定谁先来，调度器决定放到哪。两者脱节会出现高优任务排到队首却分不到合适拓扑的尴尬。
十四、多云与混合集群
跨云与混合集群里，各处的 GPU 型号与拓扑不同，统一调度要考虑异构性。把任务需求与资源特征做匹配，比把所有资源当同质处理更贴近实际，也更能提利用率。
十五、调度的可观测
调度决策要有日志与指标：为什么这个任务被放到这些卡、为什么被推迟。没有可解释的调度记录，资源纠纷与性能问题都无从复盘，优化也失去依据。
十六、成本分摊
多团队共享集群时，成本要能按团队与任务分摊，否则配额管理缺少依据。把资源占用换算成成本并定期出账，能让团队自觉优化资源使用，这比单纯行政管控有效。
十七、多租户隔离
多团队共用集群时，除配额外还要做故障与干扰隔离：一个团队的失控任务不应拖垮他人。结合 cgroup、网络配额与共享粒度的组合隔离，比单纯靠配额更能保证租户间的可预测性。
十八、虚拟化的调度
vGPU 把一张卡切成多份，调度器要理解切分关系，避免把强通信任务分到同一物理卡的不同切片上互相抢。虚拟化提升了密度，却也让拓扑更隐蔽，调度要向上层暴露真实拓扑。
十九、调度器的拓扑打分
把拓扑信息量化为打分函数：同域加分、跨机减分，再按任务通信画像选位。打分模型比硬规则灵活，能处理混合负载，但要可解释，否则排错时无人说得清为何这么排。
二十、能耗与利用率
利用率高不等于能耗优。把能耗纳入调度目标，在空闲节点上做整合与下电，能降成本。但要平衡整合带来的碎片与重启开销，否则省了电却损了效率。
二十一、与大数据调度对比
Spark 等大数据调度重数据本地性，GPU 训练调度重拓扑与连续资源。两者理念相通但目标不同，借鉴数据本地性思路可优化训练数据的就近读取，减少跨节点搬数据。
二十二、推理服务的弹性
推理流量有波峰波谷，弹性伸缩要避免频繁启停带来的冷启动延迟。用预热池与保守缩容策略，让弹性既省成本又不伤尾延迟，是推理调度区别于训练的要点。
二十三、调度与容量预测
用历史任务画像预测各规格任务的需求峰谷，提前预留对应拓扑的连续资源，能把被动排队变主动准备。预测不必精确，方向对了就能显著降低大任务的等待与碎片。
二十四、与成本优化的联动
调度决策应直接挂钩成本：把闲置资源自动降配或释放，把高价资源留给高优任务。调度与成本看板打通后，利用率提升与账单下降能同时发生，而非各管各的。
二十五、故障迁移的代价
节点故障时其上任务要迁移到别处，迁移既要找得出连续资源，又要能恢复状态。迁移代价常被低估，应在调度里预留迁移余量，否则故障时会因无位可去而扩大影响。
补充问答
问：容量要预测吗？
答：用历史画像预测需求峰谷、提前预留连续资源，能把被动排队变主动准备。预测不必精确，方向对就能显著降低大任务等待与碎片。
问：调度怎么降本？
答：决策挂钩成本：闲置资源自动降配释放，高价资源留给高优。调度与成本看板打通，利用率与账单能同时改善，而非各管各的。
问：节点故障影响大吗？
答：故障时任务要迁移，既要找连续资源又要恢复状态，代价常被低估。调度应预留迁移余量，否则无位可去会扩大故障影响面。
问：多租户怎么隔离？
答：除配额外加故障与干扰隔离：cgroup、网络配额、共享粒度组合，比单纯配额更能保证租户间可预测，一个失控任务不拖垮他人。
问：vGPU 怎么调度？
答：调度器要理解切分关系，避免强通信任务分到同一物理卡的不同切片互相抢。虚拟化提升密度却让拓扑更隐蔽，要向上暴露真实拓扑。
问：拓扑怎么打分？
答：量化为打分函数：同域加分、跨机减分，按任务通信画像选位。比硬规则灵活，但要可解释，否则排错说不清为何这么排。
问：调度管能耗吗？
答：利用率高不等于能耗优。把能耗纳入目标，整合空闲节点与下电降本，但要平衡整合带来的碎片与重启开销，否则省电损效率。
问：和 Spark 调度像吗？
答：理念通但目标不同：Spark 重数据本地性，GPU 训练重拓扑与连续资源。借鉴数据本地性可优化训练数据就近读取，少搬跨节点数据。
问：推理怎么弹性？
答：流量有峰谷，频繁启停冷启动伤延迟。用预热池与保守缩容，弹性既省成本又不伤尾延迟，这是推理调度区别于训练的要点。
问：队列和调度怎么配合？
答：队列定优先级与顺序，调度定落点与拓扑。两者要联动，否则会出现高优任务排到队首却拿不到合适拓扑的情况，反而比低优任务更慢。
问：混合集群怎么调？
答：按异构性做需求与资源的匹配，而不是当同质资源处理。统一调度要考虑型号与拓扑差异，否则利用率与任务性能都会受损。
问：调度能解释吗？
答：应留下决策日志与指标：为何这样分配、为何被推迟。可解释的调度才能复盘资源纠纷，也是后续优化的依据，否则只能凭感觉。
问：成本怎么分摊？
答：按团队与任务把资源占用换算成成本并定期出账。透明账单能让团队自觉优化用量，比行政指令更有效，也让配额调整有据可依。
问：默认调度器的问题在哪？
答：它只看空闲 GPU 数量，不看拓扑。要 8 卡的任务可能被分到不同机器，通信成本暴涨。能跑起来，但性能远低于应有的水平。
问：碎片怎么量化？
答：用碎片率与大任务排队时长两个指标。若集群整体空闲卡数够而大任务仍排队，基本可判定是碎片问题，而不是资源真的不足。
问：拓扑感知难做吗？
答：基础版不难：把拓扑信息注入调度决策，优先同高速域分配。难在维护信息的准确性与处理拓扑变化，需要设备插件与调度器配合。
问：共享 GPU 划算吗？
答：提利用率但降低隔离。对延迟敏感的任务共享会互相干扰。按任务敏感度决定：批处理类可共享，在线推理与训练尽量独占。
问：抢占会不会伤训练？
答：会，所以要与检查点联动。抢占前先触发保存，恢复后接着训。检查点太稀则重算多，太密则开销大，频率要按任务时长权衡。
问：小团队要自研调度吗？
答：不必。先用社区方案加拓扑配置，覆盖大部分场景。等确有特殊需求（如超节点亲和）再考虑定制，自研调度器维护成本很高。
大会信息
2026 奇点智能技术大会 + C++ 及系统软件技术大会
时间：2026 年 11 月 20-21 日
地点：中国·北京万达文华酒店
大会报名：免费领取大会PPT资料
立即报名，锁定 Lukasz Kaiser Keynote 与 70+ 场演讲完整资料！
