第 12 章 — 拆分部署与 Kubernetes

发布于: 2026-05-04 最后更新于: 2026-07-08 版本: 1
第 12 章 — 拆分部署与 Kubernetes

第 12 章 — 拆分部署与 Kubernetes

LLM Primer VI: Scaling AI Systems》章节走读的第十二篇。这一章终于把 prefill 和 decode 拆到不同 GPU 池,并展示那些让 pod 落在互联正确一侧的 Kubernetes 原语。


这一章为什么存在

第 11 章在 engine 和平台之间画了一条干净的线 —— 直到 engine 本身指出 prefill 和 decode 是相反的工作负载。Prefill 是 compute-bound;decode 是 memory-bandwidth-bound。让同一块 GPU 上把它们跑在一起,等于让一块硬件同时做两件相互冲突的事,结果两件都平庸。拆分部署把它们拆到不同 GPU 池,在两池之间搬 KV cache,让每一池按自己的工作负载调优。代价是运营复杂度,以 Kubernetes 原语、pod 拓扑和承载 KV 流量的网络 fabric 来支付。第 12 章走这份复杂度的形状 —— 组件、传输路径,以及承载这一切的 CRD(LeaderWorkerSet、Grove 的 PodCliqueSet、KAI Scheduler)。

一句话:拆分部署把一个平庸的 GPU 池变成两个各自调好的池,代价是把 KV cache —— 每条序列通常几个 GB —— 在严格的 TTFT 预算内通过 NVLink 或 InfiniBand 送过去。

12.1 Prefill 和 decode 想要不同的芯片跑不同的频率

同一块 H100 上,一段长 prefill 确实能到峰值 FLOPs 的 60–80%,而 decode 步在算力上只用 5–15%,却把 HBM 带宽用到 70–90%。用 continuous batching 交错跑是能凑合,但在两处漏水。Prefill 的算力那一次会撞上排队 decode 想要流的同一条 HBM 总线,token 间时间被拉长。卡也只跑一个工作点:按 prefill 调,decode 被带宽勒住;按 decode 调,prefill 被算力勒住。随着 RAG 和 agent 拿下生产流量,prompt 长度从几百 token 涨到几千,这份交错代价也跟着长。拆分给每一阶段各一池。Prefill worker 可以跑在裸 FLOPs 强的卡上(H100 SXM、B200)。Decode worker 可以跑在容量和带宽强的卡上(H200、MI300X)。每一池按自己的工作负载定量 —— 长上下文、短输出流量需要更多 prefill;chat 流量需要更多 decode。

12.2 形状是四个组件加一条 KV 传输路径

一份能工作的拆分部署有四个组件。Prefill worker 接受请求、跑 prefill、吐出第一个 token,并把 KV cache 打包好准备传输。Decode worker 接受进来的 KV cache 及其元数据,把它装进自己的分页 attention 池,再在正在跑的生成上跑 continuous batching。KV cache 路由器 —— 控制平面 —— 维护每个 decode worker 的空闲 KV 容量、batch 满度、网络位置的视图,把每一个 prefill 的产出指到那里,最小化传输成本并均衡负载。前端网关终止用户 HTTP 连接,从 prefill worker 流出第一个 token,然后透明地切换到从 decode worker 流出剩下的。关键约束是 KV 传输:70B GQA 序列 4,096 token 是 1.5–2 GB,要在用户在盯的那 50–100 ms TTFT 预算内从 prefill 节点搬到 decode 节点。节点内 NVLink 900 GB/s、节点间 InfiniBand 400 Gb/s 让数字兜得住 —— 前提是 pod 落在 fabric 的正确一侧。

12.3 LeaderWorkerSet、Grove、KAI 表达这份拓扑

Kubernetes 原来没有"这两种类型的 pod 是同一个逻辑副本"的原语。LeaderWorkerSet(2024 年上游)表达一个多 pod 副本,有 leader(比如 prefill)和 worker(比如 decode);控制器把这组当一个调度单位。NVIDIA Grove 的 PodCliqueSet(2025,NVIDIA AI Enterprise 一部分)再泛化一步,用带类型的 clique(prefill、decode、router),各自有自己的模板和大小,加上一份说明 clique 之间关系的拓扑描述。Grove 把整套连同 clique 内和 clique 间的位置约束一起交给调度器。两种 CRD 单独都不够;都需要一个懂集群物理拓扑的调度器,而默认 Kubernetes 调度器不懂。KAI Scheduler —— 2024 年从 Run:ai 开源 —— 消费 nvidia-smi topo --matrix 和 InfiniBand 子网管理器产出的拓扑图,对候选放置打分。当 Grove 的 clique 要求 nvlinkDomain: required 时,KAI 把放置限制到单一 NVLink 一致域(一块 HGX 底板上八块 GPU 在一个 NVSwitch 下)。当 clique 间拓扑说 sameInfiniBandIsland 时,KAI 把 clique 都留在同一个叶交换机组里,KV 往返延迟保持在 100 μs 以内。

值得记住:没有拓扑感知调度的拆分部署,比不拆更糟。如果 KV 传输走过错的交换机,TTFT 预算会消失在网络抖动里,负责部署的人吃下了拆分的复杂度,却没拿到它的吞吐。

第 12 章为下面铺了什么

第 12 章给部署一张静态图:任一时刻有固定数量的 clique 在跑、在服务流量。真实流量不是静态的 —— chat 助手一天内峰谷 30 倍摇摆,开发者工具周末归零,消费级产品追着太阳走。第 13 章走自动扩缩的故事:为什么标准 HPA 是错的 LLM serving 扩缩器、KEDA 应该按什么信号扩缩、Knative 怎么表达 scale-to-zero,以及是什么把 60–180 秒的冷启动压到用户面向应用能吸收的程度。


下一章 — 第 13 章:自动扩缩与冷启动缓解KEDA、Knative、CRIU、CUDA graph 缓存、NVMe —— 让 scale-to-zero 和真实用户共存的那套栈。

想看完整的全貌?书里这一章包括一份完整 Llama-70B 拆分部署的 LeaderWorkerSet 和 Grove YAML、KAI 拓扑配置块、Python 路由决策函数、请求穿过四组件的端到端追踪,以及多模型多租户 clique 的说明。在 Amazon 上查看 LLM Primer VI →

下田 昌平
下田 昌平
作为株式会社Receipt Roller的CEO兼CTO,目前负责开发电子收据服务以及自动将对话分类并生成行动任务的系统「ACTIONBRIDGE」。从小便接触编程,1996年参与开发测量仪器的相关程序,始终保持着对技术的深刻探索与热情。 在此前的职业生涯中,曾担任日本最大呼叫中心行业企业的子公司——一家研究开发公司的CEO/CTO,领导了多个技术开发项目。目前,我依然活跃在编程的最前沿,持续书写代码。