21 集群调度

21.1 调度分层

调度这个词在这个行业里指三件完全不同的事，谈判时必须问清是哪一层：集群编排层决定哪个节点放哪个副本，管资源配额、成组调度、抢占与回填；服务调度层在副本之间分配请求，管路由与负载均衡；引擎调度层在副本内部组批次、做 KV 准入，管延迟分布。这个区分在人才评估上尤其重要：做过万卡训练集群调度的人，熟悉的是第一层；做在线推理调度的人，熟悉的是第三层。两者在 Kubernetes 架构层面有相当程度的重合，但在核心机制上是不同物种。

21.2 编排底座

集群层的事实标准是 Kubernetes 加一个批调度插件。原生调度器为无状态微服务设计，一个一个 Pod 独立放置；AI 负载不是这样：一个推理副本可能要八张卡同时就位才能启动，少一张就全部白等，这叫成组调度（gang scheduling）。开源生态里 Volcano、Apache YuniKorn、Kueue 都在解决这类问题，各自侧重队列与配额、层级公平或批任务生命周期。要注意编排器与服务调度器不在一层：Kubernetes 把 GPU 暴露为扩展资源，决定哪个容器拿到几张卡，但它不理解请求长度、KV 压力、前缀局部性或首字延迟，核两层要分开设计、分开验收。

21.3 扩容反馈

自动扩容不是即时增加容量。新节点要经历供应、镜像、驱动、权重装载、初始化和预热，第 10.4 节的冷启动分段在这里全部生效。缩到零节省空闲资源，却必然引入冷启动；单副本允许过多在途请求，则会在扩容完成前放大尾延迟。这里存在第 11.5 节讲过的反馈：流量上升触发扩容，多个新副本同时拉权重，存储和网络拥塞使冷启动更慢，旧副本队列继续增长，客户端重试又加剧负载。扩容策略必须把装载路径、预热时间、备用容量和主动丢弃放在同一个控制回路里。

21.4 故障分域

推理集群的可用性由最脆弱的共享组件决定，不是由单卡可靠性决定。

最后一行最容易被低估。硬件故障是局部的，软件故障是全局的：一个新版本推上去，所有副本同时出问题。这是灰度发布在推理场景必须严格执行的原因。故障域要用共同依赖来画，不能用地理标签：两套集群共用同一变电站、核心交换机、身份系统或模型仓库，仍可能同时失效；跨区副本依赖同一控制面密钥，也没有形成完整隔离。冗余只有在故障注入和切换演练之后才算能力，没有演练的双路设计只是结构意图。

21.5 观测体系

没有分阶段的指标，就无法定位问题，也就无法承诺 SLA。推理服务的监控与传统 Web 服务不同，关键在于把一次请求的时间拆成可归因的几段：只看端到端延迟，出问题时无法判断是排队、prefill 慢还是 decode 抖动。观测的三层结构与告警动作在第 23.2 节展开，这里先立一条原则：探针要配对使用。就绪探针控制是否接流量，存活探针决定是否重启；错误的存活探针在高负载下会不断重启尚可恢复的实例，把一次过载变成级联故障。核