进阶战场

把一台插了八张卡的机器变成集群里可调度的 GPU 节点，比装个驱动复杂得多。

• →用 GPU Operator 完成驱动、容器运行时与设备插件的全套部署
• →验证 Pod 真正拿到了 GPU，并确认拓扑与 NUMA 亲和
• →排查「有卡但调度不上去」的常见原因

默认调度器一个一个放 Pod，分布式训练要么全起要么别起 —— 这就是要换调度器的原因。

• →解释 gang scheduling 解决的死锁问题，以及默认调度器为什么做不到
• →对比 Volcano、Kueue 与 scheduler-plugins 的定位与组合方式
• →为多团队共享的 GPU 集群设计队列与配额

平台交付给算法团队的不是节点，是「提交一个作业」和「上线一个模型」这两个动作。

• →说清训练作业与推理服务对集群的不同要求
• →选择合适的编排方式跑起一个多机多卡训练作业
• →部署一个 LLM 推理服务，并说明扩缩容的难点在哪

「每个团队一套集群」和「所有团队一套集群」之间，还有一整排折中方案。

• →在命名空间隔离、虚拟集群、独立集群之间给出选型理由
• →说清虚拟集群方案各自把控制面放在哪、代价是什么
• →为多租户平台设计配额、隔离与计费的落点

「我们要 100 张卡的集群」到底需要几台机器、控制面多大、能跑多少 Pod —— 这一节把账算出来。

• →从节点规格推出真正可分配的 CPU、内存与 Pod 数
• →按集群规模选出控制面规格与 etcd 配置
• →识别第一个撞上的限制：CPU、内存、Pod 密度还是 IP 段

几十台的时候一切正常，几百台之后 list 一次 Pod 就能把控制面拖垮。

• →定位 apiserver 压力来源：谁在 list、谁在 watch
• →用 APF（API Priority and Fairness）保住关键请求
• →说出官方规模上限的几条硬约束，以及逼近时的表现

把排查过程固化成 SOP，把每次事故变成一条检查项 —— 这是运维团队唯一的复利。

• →为常见告警写出可直接执行的处置 SOP
• →建立变更窗口、双人复核与回滚检查清单
• →主持一次不追责的故障复盘并产出改进项