总览
本章节范围：LLM 推理从单机走向集群服务化后的通信形态 — PD 分离 / KV 池化 / Cache-aware 调度 / 长上下文 / Reasoning 长 CoT / 投机解码。 目标读者：做生产 LLM 推理部署、KV cache 跨节点搬运、SLO 驱动的调度策略选型的工程师。
范围与边界
- 包含：推理部署形态 （PD 分离 / colocated / KV 池化 / 投机解码）；主流系统 (DistServe / Mooncake / SGLang PD / NVIDIA Dynamo) 设计与对比；KV cache 跨节点传输的瓶颈分析 (RTT-bound vs BW-bound); Cache-aware 调度算法 (RadixAttention / Conductor / CPD / STAR); Reasoning 长 CoT 对 decode 集群的压力。
- 不包含：各并行策略 (TP/PP/DP/EP/SP/CP) 单次前向通信特征 (见 05-LLM并行通信)；集合通信原语公式 (见 04-集合通信); $\alpha$-$\beta$ 性能模型 (见 06-通信性能建模)。
- 边界一句话：05 章讲"一次前向里的通信"，本章讲"一个请求在系统里的通信"。
名词定义
| 名词 | 定义 |
|---|---|
| 推理服务化 (Inference Serving) | 把 LLM 包装成可在线服务上万并发请求的部署形态，在 SLO （TTFT / TPOT / 吞吐） 和成本间权衡 |
| Prefill | 推理首阶段，对整个 prompt 一次性计算 KV cache 产出首 token; compute-bound，大消息通信 |
| Decode | 推理续生成阶段，每步基于已有 KV cache 生成一个新 token; memory-bandwidth-bound，小消息通信 |
| TTFT (Time To First Token) | 从请求到达至首 token 输出的端到端延迟，由 prefill 时间主导 |
| TPOT (Time Per Output Token) | 续生成阶段的单 token 平均延迟，由 decode 步长主导 |
| KV cache | Attention 中累计的 Key / Value 张量，decode 反复读取的状态，体积与序列长度线性增长 |
| PD 分离 (Prefill-Decode Disaggregation) | 把 prefill 与 decode 部署到独立 GPU 池，跨池迁移 KV cache，避免相互干扰 |
| KV 池化 (KV Pooling) | 把 KV cache 统一放在跨节点共享存储 (DRAM / CXL / SSD) 中，按需调度到 GPU，代表方案 Mooncake |
| Cache-aware Scheduling | 根据请求 prefix 与已存在 KV cache 的命中关系，把请求路由到能复用 cache 的节点 |
| 投机解码 (Speculative Decoding) | 用 draft model 提前生成候选 token, target model 一次性 verify，提升 decode 等效吞吐 |
| Reasoning Model | o1 / o3 / DeepSeek-R1 等通过延长 CoT 生成长度提升推理质量的模型，对 decode 集群压力显著放大 |
| SLO (Service Level Objective) | 推理服务对 TTFT / TPOT 等延迟指标的承诺，是部署决策的硬约束 |
| Goodput | DistServe 定义为"每张 GPU 在满足 SLO attainment 目标 （如 90%） 下可承载的最大请求速率" |
| XpYd | Mooncake 部署比例记号：X 个 prefill 节点 + Y 个 decode 节点 |
| NIXL | NVIDIA Inference Xfer Library, Dynamo 的零拷贝传输底座，统一抽象 RDMA / GDS / S3 |
@tbl-serving-glossary 第 10 章共享名词表
推理为什么要从单机走向服务化
核心问题：单机部署在哪些维度撞墙？服务化引入的新通信负担是什么？
研究阶段的推理通常是"一台机器、一个 prompt、看一遍生成结果"。一旦面向生产，要在同一套硬件上同时服务上万并发请求并保证延迟 SLO，单机部署会在四个维度上同时撞墙：
| 维度 | 单机部署的问题 | 服务化需要解决 |
|---|---|---|
| 吞吐 | 单卡 batch size 受显存限制，请求排队 | continuous batching / 动态合批 |
| 延迟 SLO | TTFT 和 TPOT 由同一组 GPU 竞争资源 | 把 prefill / decode 解耦，分别按 SLO 调度 |
| 显存 | 长上下文 KV cache 一旦超出单卡 HBM 就失败 | 跨节点 KV 池化、PagedAttention、CXL 扩展 |
| 长尾请求 | reasoning model 的 CoT 长度方差极大，少数请求会拖累整批 | 优先级调度、preemption、Chunked Prefill |
@tbl-serving-singlemachine-walls 单机 vs 服务化部署的四维差距
服务化部署的本质：把一个推理请求拆成多种阶段、多种资源、多种通信路径，分别在最适合的硬件上运行。由此引入了三类此前不存在的通信负担：
- KV cache 跨节点搬运 — prefill 与 decode 不在同一组 GPU 上，KV 必须迁移
- 调度信令通信 — cache-aware router / conductor 之类的中心化或 P2P 调度协议
- 投机解码 draft-target 通信 — draft model 与 target model 协同时的候选 token 同步
这些通信负担是本章的核心讨论对象，也是 05-LLM并行通信 不覆盖的内容。
关键挑战清单
核心问题：推理服务化的工程挑战哪些与互联强相关？
推理服务化的工程挑战可以按"硬指标 vs 业务诉求"两个轴铺开：
| 挑战 | 主要影响 | 互联相关性 |
|---|---|---|
| 降 TTFT | prefill 阶段的算力 + 跨节点 CP 通信 | 高 |
| 降 TPOT | decode 阶段的 HBM 带宽 + 小消息 alpha | 中 （小消息延迟敏感） |
| 提吞吐 | continuous batching、PD 解耦使资源专用 | 高 （KV 迁移带宽） |
| 控成本 | prefill / decode GPU 异构、CXL DRAM 扩展 | 高 （跨池带宽决定是否划算） |
| 长上下文 (128K-1M) | KV cache 暴涨、CP / RingAttention 通信 | 极高 （互联是关键） |
| Reasoning 长 CoT | decode 步数从几十增到几千，集群被长尾拖累 | 中 （动态调度 + KV 迁移频次） |
| Prefix Cache 命中 | system prompt / 多轮对话复用 KV 节省 prefill | 高 （cache-aware 调度依赖 KV 索引同步） |
@tbl-serving-challenges 推理服务化的关键挑战及与互联的相关性
挑战相互耦合：长上下文模型让 KV cache 变大、放大 PD 分离的迁移成本；reasoning model 让 decode 队列变长、放大调度算法的重要性。本章子主题之间不是平行而是交织 — 读完单篇只能看清一面，需要在总览这里把整张清单说清楚。
主流范式有哪几种
核心问题：Colocated / PD 分离 / KV 池化 / 投机解码增强是什么关系？怎么叠加？
Colocated 与 PD 分离的二分原理已在 05-LLM并行通信/09-推理部署模式 展开。这里只展开 05-09 未覆盖的两种叠加形态 — KV 池化和投机解码增强：
| 范式 | Prefill / Decode 位置 | KV cache 位置 | 代表实现 |
|---|---|---|---|
| KV 池化 (KV-centric) | 独立 GPU 池 + 共享 KV 存储 | 跨节点 DRAM / CXL / SSD 池 | Mooncake / NVIDIA Dynamo |
| 投机解码增强 | 任一形态 + 独立 draft model | 主链路 + draft 临时状态 | EAGLE / MTP / 分布式投机解码 |
@tbl-serving-paradigms KV 池化与投机解码增强两种叠加范式
这两种范式与 colocated / PD 分离不是替代而是叠加：生产系统 (Mooncake / Dynamo) 通常同时启用 PD 分离 + KV 池化 + 投机解码。它们与 colocated / PD 分离的差别主要在：
- KV cache 的搬运频率与方向：KV 池化按调度命中搬多次 （PD 分离每请求只搬一次）
- 调度算法的复杂度：KV 池化需要全局 cache 索引 + 路由
- 对互联拓扑的要求：KV 池化需要 CXL / RDMA 大池带宽 （PD 分离只需跨池 RDMA）
与 05-LLM 并行通信怎么划边界
核心问题：05 章和 10 章容易混淆，各自的关注层次是什么？
| 维度 | 05-LLM 并行通信 | 09-推理服务化通信 （本章） |
|---|---|---|
| 关注层次 | 单次前向 / 反向中各并行维度 (TP/PP/DP/EP/SP/CP) 产生的通信原语 | 把推理请求拆成多阶段、多集群协同的部署形态 |
| 通信对象 | Activation、梯度、Expert 路由 token | KV cache、调度信令、draft token |
| 时间尺度 | 一次 forward 内 （毫秒级） | 一个请求生命周期 （秒级到分钟级） |
| 通信原语 | AllReduce / AllGather / AllToAll / P2P | RDMA write / KV 迁移 / router RPC |
| 主要问题 | 各并行策略的通信量公式与重叠潜力 | KV 怎么迁移、请求怎么路由、什么时候解耦 |
@tbl-serving-vs-llm-parallel 05-LLM 并行通信 与 09-推理服务化通信 的边界
一句话：05 章讲"一次前向里的通信", 10 章讲"一个请求在系统里的通信"。05 章是基础 （决定单节点跑哪种并行），10 章构建在 05 之上 （决定整个集群怎么协同）。
衔接点是 05-09-推理部署模式 — 该文档在 05 章引入了 prefill / decode 通信不对称和 PD 解耦的基础概念，作为 10 章的入口铺垫。10 章不重复 05-09 的基础内容，而是逐个系统展开实现细节、定量比较和工业实测。
子文档索引
按"原理 → 系统实现 → 通信优化 → 调度 → 长上下文 / reasoning"组织：
- 9.2 Prefill/Decode 分离原理 — PD 分离的调度模型、SLO 拆分 (TTFT / TPOT)、与 colocated 的取舍。
- 9.3 DistServe — OSDI'24 学术原型：Goodput 指标 + 双 Placement 算法 （按节点间带宽分类）。
- 9.4 Mooncake — Moonshot Kimi 的 KV-centric 架构：Conductor + Messenger + 跨节点 KV pool。
- 9.5 SGLang PD — 开源 PD 实现：mini-LB / DP attention / Heterogeneous TP / Mooncake / NIXL backend。
- 9.6 NVIDIA Dynamo — NVIDIA GTC 2025 发布的开源 LLM 推理编排框架：Smart KV Router + 多级 KVBM + NIXL。
- 9.7 KV cache 跨节点传输瓶颈 — KV 迁移到底是 RTT-bound 还是 BW-bound；不同拓扑层次临界点。
- 9.9 Cache-aware 调度 — Prefix cache 命中驱动的路由策略 (RadixAttention / Conductor / CPD / STAR)。
- 9.12 Reasoning 模型推理通信 — 长 CoT 对 decode 集群的压力与动态长度调度。
规划中未发布：08-flowkv （KV 传输流水线优化） / 10-cxl-rack-kv （CXL 机架级 KV 共享） / 11-长上下文推理通信 (CP for 1M token) / 13-投机解码通信 — 这些子主题在本知识域规划中，但尚未撰写。
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 服务化撞墙 | 吞吐 / 延迟 SLO / 显存 / 长尾四维同时撞墙，单机部署不够 |
| 新增三类通信 | KV cache 跨节点搬运 + 调度信令 + 投机解码 draft-target 同步 |
| 主流范式 | colocated / PD 分离 / KV 池化 / 投机解码增强，生产通常同时叠加 |
| 与 05 章边界 | 05 讲一次前向通信，10 讲一个请求在系统里的通信 |
| 挑战相互耦合 | 长上下文放大 PD 分离迁移成本；reasoning 放大调度算法重要性 |