章节导航第 14 章 / 共 16 章

第 14 章第四部分：推理与部署

服务部署与系统架构

从单机到万卡集群——构建高可用、低延迟的 LLM 推理服务

最后更新：2026年10月16日部署服务架构负载均衡 GPU 集群成本优化

LLM 服务的独特挑战

部署 LLM 不同于传统的 ML serving。核心差异：

维度	传统 ML 服务	LLM 服务
延迟模式	固定延迟	流式输出（首 token 延迟 + 逐 token 延迟）
请求时长	毫秒级	秒到分钟级
资源占用	KB 级	GB 级（KV Cache）
负载特征	均匀	长尾分布（输出长度差异巨大）
GPU 利用率	容易达 80%+	不优化只有 10-30%

系统架构全景

一个生产级 LLM 推理系统通常包含以下层次：

┌─────────────────────────────────────────────────┐
│                    客户端层                        │
│         Web / Mobile / API Clients              │
└───────────────────┬─────────────────────────────┘
                    │
┌───────────────────▼─────────────────────────────┐
│                  网关层 (Gateway)                  │
│   速率限制 │ 认证鉴权 │ 请求路由 │ 流量控制       │
└───────────────────┬─────────────────────────────┘
                    │
┌───────────────────▼─────────────────────────────┐
│                调度层 (Scheduler)                  │
│   请求队列 │ 优先级管理 │ 模型路由 │ 负载均衡      │
└───────────────────┬─────────────────────────────┘
                    │
┌───────────────────▼─────────────────────────────┐
│                推理层 (Inference Engine)           │
│   vLLM / TRT-LLM / SGLang                       │
│   Batching │ KV Cache │ 量化 │ 并行策略          │
└───────────────────┬─────────────────────────────┘
                    │
┌───────────────────▼─────────────────────────────┐
│               硬件层 (GPU Cluster)                │
│   H100/A100 │ NVLink │ InfiniBand │ 存储        │
└─────────────────────────────────────────────────┘

关键指标

延迟指标

指标	定义	典型目标
TTFT (Time to First Token)	从请求到首个 token	<500ms
TPOT (Time Per Output Token)	相邻输出 token 间隔	<50ms
E2E Latency	请求到完整响应	取决于长度
P99 Latency	99 分位延迟	<3x 中位数

吞吐量指标

指标	定义	说明
QPS	每秒处理请求数	整体容量
Tokens/s	每秒生成 token 数	更精确的度量
并发数	同时处理的请求数	与 KV Cache 显存相关

成本指标

$\text{成本效率} = \frac{\text{Tokens/s}}{\text{GPU 数量} \times \text{GPU 单价}}$

或者更直观的：每百万 token 的美元成本。

负载均衡与调度

请求特征

LLM 请求有极大的异质性：

请求 A: 输入 50 tokens, 输出 20 tokens   → 轻量
请求 B: 输入 8000 tokens, 输出 2000 tokens → 重量
请求 C: 输入 100 tokens, 输出 5000 tokens  → 生成密集

传统的 round-robin 或最少连接数策略不适用。更好的方法：

Token-Aware 负载均衡

根据预估的 token 处理量（而非请求数）来分配：

$\text{Load}_i = \sum_{r \in \text{active}(i)} (\text{input\_len}_r + \text{estimated\_output\_len}_r)$

将新请求分配给 $\text{Load}$ 最小的 worker。

优先级队列

不同的请求可能有不同的优先级：

高优先级: 付费 API 用户 → 保证 SLA
中优先级: 免费 API 用户 → Best effort
低优先级: 批处理任务    → 填充空闲 GPU

实现方式：多级队列 + 抢占（preemption）。低优先级请求可以被中断，保存 KV Cache 到 CPU 内存，让高优先级请求先执行。vLLM 支持请求级别的抢占。

抢占之后会发生什么，vLLM 0.31.0 把答案改了。 本节此前只写到”保存 KV Cache 到 CPU 内存”，没有写被抢占的请求如何回到队列。v0.31.0（2026-10-05）重做了等待队列：已持有 KV block 的请求优先被调度（#58947）。直接后果是——被抢占的请求因为已经持有 KV block，在重新排队时会被优先捞回，抢占不再是”从头再来”。这让优先级队列的代价结构发生了变化：抢占低优先级请求的成本，从”重做这部分计算”降为”稍后继续”，因此可以更激进地使用抢占而不惩罚吞吐。

同一版本还补了一个运维旋钮：--max-num-active-seqs（#56758）把 RUNNING 准入与 max_num_seqs 解耦——此前两者共用一个阈值，现在可以给”并发上限”（防 OOM / 防显存打满）与”准入上限”（控制排队深度）分别设值。对”想限并发但不想拒请求”的场景，这是官方给出的解法。

模型并行部署

Tensor Parallelism (TP)

将单个模型的权重矩阵切分到多张 GPU：

TP=2 部署:
GPU 0: 权重的前半部分    GPU 1: 权重的后半部分
        ↓                        ↓
    部分计算                   部分计算
        └──── AllReduce ────────┘
                  ↓
              完整结果

特点：

需要高带宽互连（NVLink，~900 GB/s）
减少单卡显存占用
增加通信开销（每层两次 AllReduce）
适合同一节点内的 GPU

Pipeline Parallelism (PP)

将模型的不同层放在不同 GPU 上：

PP=2 部署:
GPU 0: Layer 0-39    GPU 1: Layer 40-79
         │                    │
     前 40 层计算  ──→    后 40 层计算

特点：

节点间通信量小（只传 hidden states）
可用较低带宽的网络（InfiniBand，~400 Gb/s）
有”气泡”（pipeline bubble）问题
适合跨节点部署

混合并行

生产环境通常组合使用：

4 节点 × 8 GPU 部署 (70B 模型):
  - TP=4 (节点内 NVLink)
  - PP=2 (跨节点 InfiniBand)
  - 剩余 GPU 做 replicas

前缀缓存（Prefix Caching）

很多 LLM 请求共享相同的前缀：

系统提示 (所有请求相同):
  "你是一个有帮助的 AI 助手，请用中文回答。"

多轮对话 (前几轮相同):
  "[用户第1轮] ... [助手第1轮] ... [用户第2轮] ..."
  └──────────── 这部分已经计算过 ──────────────┘

前缀缓存（也叫 prompt caching）将共享前缀的 KV Cache 缓存起来复用：

SGLang 的 RadixAttention：用 Radix Tree 管理前缀共享
vLLM 的 Automatic Prefix Caching：自动检测和复用
OpenAI / Anthropic / DeepSeek 的 API 都支持 prompt caching，可节省 50-90% 的 prefill 成本

推理引擎格局（2026）

2026 年，推理引擎从 vLLM 一家独大演变为 5+ 引擎并存的格局。Hugging Face 已将 TGI 转为维护模式，推荐 vLLM 或 SGLang。NVIDIA Dynamo 以引擎无关的模块化设计切入，llm-d 则在云原生多硬件方向拓展，选择时需根据部署场景和硬件环境综合评估。

引擎	特色	适用场景	吞吐量参考（H100）
vLLM	广泛硬件支持、PagedAttention、高并发；0.26.0 新增分层 KV 卸载（CPU+对象存储）、INT4/NVFP4/MXFP4 量化路径、day-one Inkling MoE 系列支持；0.28.0 起分层 KV 卸载延伸到磁盘层并支持树外 L2 管理器，Model Runner V2 支持 E/P/D 分离；0.30.0（2026-09-22）为当前版本	通用 API 服务、多硬件环境	~12,500 tok/s
SGLang	RadixAttention、原生结构化输出、prefix 密集优化；0.5.16 UnifiedRadixTree 默认前缀缓存 + DSpark 置信度驱动投机解码（~383 tok/s，仍成立）；v0.5.21（2026-10-02）为当前版本（779 PRs / 227 贡献者；0.5.20 为 2026-09-18）。v0.5.22（tag 2026-10-15）已切出但 release notes 未发布，特性一律以 v0.5.21 为准	Agent（函数调用）、结构化输出、多轮对话	~16,200 tok/s（prefix-heavy 下超 vLLM 6.4x）
TensorRT-LLM	NVIDIA 深度优化、Medusa 投机解码；v1.4.0rc0（2026-10-14）为当前版本，仍处 RC 序列——1.3 的 RC 序列已随 rc29（2026-09-29）结束，进入 1.4 RC	纯 NVIDIA 环境、极致性能	因优化级别而异
NVIDIA Dynamo	模块化推理框架，引擎无关设计（支持 TRT-LLM/vLLM/SGLang），核心组件 Planner/Smart Router/Distributed KV Cache Manager。v1.5.1（2026-10-07）为当前版本；v1.5.0 GA 于 2026-09-21（v1.4.0 stable 2026-08-15 / v1.4.1 08-22 / v1.4.2 08-29）。v1.6.0 仅有 `dev.1/dev.2` 预发布，尚未 GA	多引擎混合部署、分离式推理	取决于底层引擎
llm-d	开源社区框架，支持 TPU+GPU 混合分离式推理 + GKE Inference Gateway；v1.0.0-rc.1（tag 2026-10-14）——1.0 里程碑；v0.10.0（release 2026-09-29）；v0.9.0（2026-08-28）新增 FMA P2P 权重传输、P2P KV cache sharing、KEDA 原生扩缩	云原生多硬件环境、混合推理	取决于配置

截至 2026-10-16（vLLM v0.31.0 / SGLang v0.5.21 / TensorRT-LLM v1.4.0rc0 / NVIDIA Dynamo v1.5.1 / llm-d v1.0.0-rc.1）。另：vLLM v0.32.0rc0/rc1/rc2（10-09~10-15） 已在 RC；SGLang v0.5.22 tag 已切（10-15）但 notes 未发布；Dynamo v1.6.0 仅 dev 预发布，未 GA；llm-d v1.0 / v1.0.0-rc / v1.0.0-rc.1 三个 tag 均于 2026-10-14 出现，release notes 尚未发布，故不推测 v1.0 新增了什么。SGLang 0.5.16 将 UnifiedRadixTree 设为默认前缀缓存，对 Agent 场景的 system prompt 复用至关重要。vLLM 0.26.0 移除了 TeleChat/Persimmon/Fuyu 等旧架构，保持模型支持的精简。

📌 关于版本号的读法（两条）：

其零（2026-10-16 补）：版本锚点要 releases（或 releases.atom）与 tags 两个端点一起看。 llm-d 的 v1.0.0-rc.1 就是只存在于 tags、在 releases 里还查不到的里程碑——只查 releases 会漏掉刚切出来的版本；只查 tags 又拿不到日期与 release notes（SGLang v0.5.22 属于后一种）。 其一，版本号一律回 GitHub releases.atom 确认，不要依赖搜索引擎快照。 本轮（2026-09-26）实测：搜索引擎对 vLLM 只回到 0.28.0–0.29.0 区间，只有 releases.atom 给出了 v0.30.0——滞后一到两个版本是这个领域的常态，而非偶发。

其二，推理引擎的版本节奏已进入”每月 1–2 个 minor”的区间（vLLM 在 2026-09 一个自然月内发了 0.29.0 与 0.30.0，SGLang 同期发 0.5.20）。本书中的版本号必然滞后于你读到它的那一天，请以各项目 GitHub Releases 页为准；本书的价值在于选型维度与架构判断，不在版本号本身。

vLLM 的连续两版（2026-08）把分离能力推进到了混合架构与异构拓扑：

0.27.0（2026-08-10）：混合模型的 P/D 分离——NIXL P/D for hybrid MLA+SSM、异构 P/D block size、MoRIIO 异构 TP↔DP prefill/decode 读路由；Rust 前端 gRPC 控制平面（健康上报 / 中止 / 服务与模型发现 / KV 事件源）；vllm-bench 并入 CLI。
0.28.0（2026-08-26）：Model Runner V2 成熟（E/P/D 分离、权重卸载、多层 MTP KV cache、thinking_token_budget）；分层 KV 卸载新增磁盘层，并通过 module_path 支持树外 L2 管理器与分层指标；DeepSeek-V4 稀疏 MLA 端到端支持 plain decode/MTP/DSpark 投机解码；新默认值 max_num_batched_tokens 8192→16384、Mamba 默认开启前缀缓存、Blackwell CUDA graph 捕获默认 1024。
⚠️ 破坏性变更：0.28.0 起 bitsandbytes 移到树外插件、Transformers 升至 5.15.0；0.27.0 起引入新版 PyTorch/Triton 依赖。这两个大版本都需要重建环境，不能就地升级。📌 具体的 PyTorch / Triton 版本号建议在上游 release notes 二次确认后再写进生产变更单。

分离粒度支持（选引擎时的新评价维度）：vLLM = 混合架构 P/D + 异构 TP/DP（0.27+）、E/P/D（0.28+ Model Runner V2）；SGLang = EPD 三级 + 异构 TP（GPU Staging Buffer）。

NVIDIA Dynamo 的能力边界（回源 NVIDIA 官方兼容性矩阵，快照 v1.5.0）：vLLM 后端覆盖最广——15 项中支持 14 项（Disaggregated Serving / KV-Aware Routing / SLA-Based Planner / KV Block Manager（⚠️ v1.5.0 起已弃用，目标 v1.6.0 移除） / Multimodal image+video，audio 为实验性 / Request Migration / Cancellation / LoRA 动态加载+适配器亲和路由 / Tool Calling / Eagle3 投机解码 / GPU Memory Service）；SGLang 与 TRT-LLM 各 9/15。已知限制：Shadow Engine Failover 仅软件进程级故障转移，无 KV cache 复用、无硬件容错。另：frontend 与 worker 支持 N-2 窗口的混合版本运行，但该保证不覆盖 worker 间直连协议（如 prefill→decode 通信）。

v1.5.0（GitHub release 2026-09-21；“GA 2026-09-18”一说未获证实，现已按 release 时间核定为 09-21）是一个”大改”版本——658 merged PRs / 123 贡献者 / 43 项破坏性变更（按 release notes「Breaking Changes」顶层条目自数，原文未给总数）/ 12 known issues（与 Known Issues 小节 12 条一致）。对上面这张矩阵有三处直接改写：

🔴 KV Block Manager（KVBM）已弃用，目标在 v1.6.0 移除。 它是 Dynamo 早期宣传的核心组件之一，也是这份矩阵里”vLLM 后端支持 14/15”的组成部分。

📌 KVBM 的弃用值得单独提醒：能力矩阵是快照，弃用是过程。矩阵把 KVBM 算作”支持项”，在 v1.5.0 之后会误导选型——按本节内容去选组件的读者，会选到一个即将被移除的东西。引用任何框架的能力矩阵时，都要一并查它的 deprecations ledger（弃用清单），否则”支持”两个字是静态的、而项目是动态的。

这条判据需要再扩展一格：矩阵只回答”支持什么”，还有三类清单回答”现在还能怎么用”，三类都要查。

清单类型	回答什么	本章实例
① deprecations ledger（已有）	什么即将被移除	KVBM 目标 v1.6.0 移除
② 输入限制	支持，但接受什么样的输入	Dynamo v1.5.1（2026-10-07）首次对客户端提供的多模态输入设界：内联 `data:` URL 大小、远程媒体下载、图像尺寸、base64 音频，跨 SGLang / TRT-LLM / vLLM / vLLM-Omni 四条路径统一执行
③ 破坏性变更	升级时需要什么动作	见下

所以矩阵里 “multimodal image+video（audio 实验性）” 这一格的完整读法应当是：“支持”不等于”接受任意输入”——能力矩阵描述的是模态，release notes 描述的是边界，两者必须一起读。

v1.5.1 的两条破坏性变更都需要升级时动作（均与”媒体抓取”这条侧信道有关）：

Egress Proxy Opt-In（#14474）：通过环境 HTTP 代理抓取请求媒体的 worker 必须显式设 DYN_MM_TRUST_EGRESS_PROXY=1，否则策略检查过的媒体抓取会被拒绝——因为代理会在 Dynamo 的地址检查之外解析目标地址（即 SSRF 防护被绕过）。NO_PROXY 直连不受影响；DYN_MM_ALLOW_INTERNAL=1 下不检查。
SGLang Diffusion 本地引用（#14435）：传给图像/视频生成 worker 的本地 input_reference 现在需要 DYN_MM_LOCAL_PATH 指定允许目录，此前接受任意本地路径。

🔁 同族取向，值得并置：vLLM 0.31.0 把 per-request 的 mm_processor_kwargs / media_io_kwargs 改为默认拒绝，须显式设 --trust-request-mm-kwargs（#58830）。两个引擎在同一个月做了同一类动作：把多模态输入的默认策略从”接受”改成”拒绝”。 这与本书反复出现的 fail-closed 取向一致，只是这次发生在多模态入口，而不是权限层——说明该取向正在从”权限设计原则”下沉为”默认配置默认值”。

同版本另有一批移除类破坏性变更，升级前须自查：tokenizer_mode="slow" 移除（#58545）；quantization="fp8" 的在线量化改为 fp8_per_tensor 简写（#53585）、Quark 静默在线量化移除（#51800）；AllSpark INT8 W8A16 后端移除（#58001）；--enable-mamba-fine-grained-prefix-cache 改名（#57382）。

Dynamo Snapshot 已改为独立 operator。 v1.5.0 把它移到独立的 operator 与 chart（Snapshot v0.1.0），移除了 bundled chart 与 Dynamo Operator 内的 reconciliation，并删除了 DynamoCheckpoint CRD 及其 Helm 值（由 PodSnapshot CRDs 取代，checkpointRef 改指 PodSnapshot）。此前记录的”仅单 GPU 稳定、多 GPU 高度实验性、多节点仍在进行中”这一限制，需按新的 operator 形态重新核实（CRD 都删了，限制的表述方式大概率也变了）。

⚠️ 待核实（2026-09-26）：Snapshot 的单 GPU / 多 GPU / 多节点支持级别，在改为独立 operator 后未见官方以原表述重申。生产使用前请以 v1.5.0 release notes 的 Known Issues 与新的 operator 文档为准。
后端 pin 推进了，但”落后上游”这个结论没有变。 v1.5.0 的 pin 是 vLLM 0.28.0 / SGLang 0.5.18 / TRT-LLM 1.3.0rc25（v1.4.x 时是 0.26.0 / 0.5.16 / 1.3.0rc22，确实推进了两个版本）；而 2026-09-26 上游已经是 vLLM 0.30.0 / SGLang 0.5.20 / TRT-LLM 1.3.0rc28——“引擎无关”成立，但”跑最新引擎”仍然不成立。这是选 Dynamo 时最容易被忽略的隐性成本：你买的是编排层的一致性，代价是引擎层永远慢半拍到一拍。

另有四条结构性变化，不改变矩阵但影响集成方式：Go EPP 被移除（改由 Frontend 镜像内的 Rust EPP 提供）、AIConfigurator 改名为 AISimulate 并作为独立包发布、CRD storage version 升到 nvidia.com/v1beta1（v1alpha1 的 admission webhook 端点被删除）、TLS/mTLS 覆盖 TCP 与 NATS 传输。

两条新增能力对分离式部署特别有用：

KV 索引扩展到 Mooncake 与磁盘层——Dynamo 的 KV 分层从此接上了 Mooncake 生态，不再是只有自己那一层；
Router 的 worker 选择开放为自定义 scoring / picking 策略——路由策略不再只能在内置选项里二选一，可以自己写打分与挑选逻辑。

滚动更新时的 generation 隔离语义。 N-2 混合版本窗口落到 Kubernetes 滚动更新上有一个具体表现：worker spec 变更会创建分代（generation-specific）的 Dynamo runtime namespace——注意这是服务发现作用域，不是 Kubernetes namespace。frontend 监听 deployment 的基础 runtime namespace 前缀，可发现多个重叠 generation，但不允许跨 generation 的 worker 直连；分离式部署中，同一 generation 的 prefill 与 decode worker 共享一个 runtime namespace，与其他 generation 隔离。

工程含义是明确的：滚动更新期间不存在”旧 prefill 给新 decode 传 KV”的中间态，从机制上避免了跨版本 KV 格式不兼容的问题。⚠️ 但原文未直接说明跨 generation 的 KV cache 复用行为（是否可跨代复用、更新窗口内命中率如何变化，均无官方陈述），生产滚动更新前请自行验证。

结构化输出

Agent 时代的推理引擎需要可靠地输出结构化数据（JSON、函数调用参数、正则约束）。实现方式是constrained decoding——在采样时用正则表达式或 JSON Schema 引导 token 选择，确保输出始终符合预定义格式。SGLang 原生集成了高性能 constrained decoding，vLLM 通过 Outlines 集成追赶。这一能力对 Agent 场景（工具调用、多步规划）至关重要。

分离式推理架构（Disaggregated Inference）

传统 LLM 推理将 Prefill（prompt 处理）和 Decode（token 生成）放在同一组 GPU 上执行，但两者的计算特征截然不同：

阶段	计算特征	瓶颈	GPU 利用模式
Prefill	Compute-bound	算力	GPU 计算单元满载
Decode	Memory-bound	显存带宽	大量时间等待数据读取

混合执行导致资源浪费——Prefill 的高算力需求和 Decode 的高带宽需求无法同时最优化。分离式推理将两个阶段拆分为独立的服务池：

┌──────────────┐     ┌───────────────────┐     ┌──────────────┐
│  Prefill Pool │ ──→ │  KV Cache 传输层   │ ──→ │  Decode Pool  │
│  (计算密集型)  │     │  (RDMA/NVLink)    │     │  (带宽密集型)  │
└──────────────┘     └───────────────────┘     └──────────────┘

代表实现：

Mooncake（Moonshot AI，ASPLOS 2025）：将 KV Cache 提升为独立分布式存储层（KVCache-centric 架构），使用 DRAM/SSD/RDMA 构建 Transfer Engine 和 Mooncake Store，吞吐提升可达 525%
DistServe：异构并行分离架构，TTFT 降低 40-50%，decode 吞吐提升 2-3x
NVIDIA 官方方案：2026 年 3 月发布 K8s 分离式推理部署方案，将 Prefill、Decode、Router 拆分为独立 K8s 服务，实现细粒度资源分配

动态 P/D 比例调整

截至 2026-09，上述方案均采用固定的 Prefill/Decode 节点比例，但实际负载在一天内波动剧烈——高峰期 prefill 密集、低峰期 decode 密集，固定比例导致资源浪费或 SLO 违规。DOPD（2026.03）提出实时负载感知的自适应 P/D 比例调整方案：根据当前请求队列长度、prefill/decode 延迟和 KV Cache 命中率，动态调整两类节点的数量配比。实测表明，DOPD 相比固定比例方案实现 P90 TTFT 降低 67.5%、goodput 提升 1.5x、SLO 达成率 >99%。这表明分离式推理的下一步是从”静态分离”走向”动态弹性分离”。

这个”下一步”在 2026-10 已经部分落地，而且落地的形态和论文设想的不一样。 SGLang v0.5.21（2026-10-02） 的官方 release notes 写明：“PD instances can switch between prefill and decode on the fly, no restart needed”（#28403）——同一组实例可以在 prefill 与 decode 角色之间在线切换，无需重启。

真正的差别在粒度：

方案	调整粒度	代价	状态
DOPD（arXiv:2511.20982）	增减节点数量（扩缩容）	新 Pod 冷启动	研究方案
SGLang v0.5.21（#28403）	同一实例换角色	无冷启动	已发布

两者可以叠加，但后者的意义在于：它把”一天内负载波动”这个问题从扩容问题降级成了调度问题——不再需要为了匹配流量曲线去新建和销毁 Pod。

🔗 与第 12 章的交叉引用：FluidPD（arXiv:2610.06917，“PD 角色可原地改、不重载模型”）与这条是同一方向的独立证据。⚠️ 但两者不要合并叙述：一个是学术原型，一个是已发布的引擎能力，可信度类型不同，保留各自来源。

⚠️ 仍未解决，须实测：角色切换之后已缓存的 KV 属于谁、命中率如何变化，SGLang v0.5.21 的 release notes 未作说明。在拿到自己的实测数据之前，不要写”动态弹性分离已解决”——这与本章对 Dynamo 跨 generation KV 复用问题用过的自律保持一致。

Mooncake 生态扩展

Mooncake 已从 Moonshot AI 的内部项目发展为 PyTorch 生态的核心组件。它已集成 vLLM、SGLang、TensorRT-LLM、LMDeploy 四大推理引擎，并支持 Encode-Prefill-Decode 三级分离（SGLang EPD 模式）——在传统 PD 分离基础上进一步将 prefill 拆分为 encode（token embedding）和 prefill（attention 计算）两个阶段，实现更细粒度的资源调度。此外，TorchSpec 利用 Mooncake 的解耦架构实现推理-训练协同优化，腾讯 FlexKV 则基于 Mooncake 实现分布式 KV Cache 跨集群复用。

分离式推理是 2025-2026 年 LLM 部署最重要的架构变革——它从根本上改变了”一组 GPU 做所有事”的思路。

子阶段分离：分离式推理的第四粒度层。传统 PD 分离将推理拆为 Prefill 和 Decode 两个阶段，Mooncake 的 EPD 模式进一步将 Prefill 拆为 Encode 和 Prefill 两个子阶段。2026 H1 的一个新方向是将 Decode 阶段内进一步拆分——ByteDance MegaScale Infer 将 Decode 分解为注意力（带宽密集）和 FFN（计算密集）两个子阶段，分别使用不同类型 GPU 优化，已部署在近 10,000 GPU 规模。这代表了分离式推理的四层粒度演进：

粒度	拆分方式	代表	阶段
阶段级	P/D 分离	DistServe, Splitwise	2024-2025
子阶段级	EPD 三级分离	Mooncake + SGLang EPD	2025-2026
算子级	注意力/FFN 分离	MegaScale Infer ~10K GPU	2026 H1
架构级 / 异构拓扑级	混合架构（MLA+SSM）的 P/D 分离；prefill 与 decode 使用不同 TP 度；GPU 与 XPU 混合部署 E/P/D	vLLM 0.27 NIXL hybrid P/D + MoRIIO 异构 TP↔DP；llm-d v0.9 E/P/D on GPU+XPU；SGLang 异构 TP（GPU Staging Buffer）	2026 H2

异构 TP 的关键工程手段是 SGLang 的 GPU Staging Buffer——把 KV 头切片到连续缓冲区做批量 RDMA，官方称高并发下比逐 token 切片快 2-5 倍。到这一层，拆分的依据已经不是”请求的哪个阶段”，而是”这段计算在什么拓扑上跑最划算”。

生产案例：Cloudflare 部署 Kimi K2.5

Cloudflare 于 2026 年 4 月在其全球边缘网络上部署了 Kimi K2.5 万亿参数模型，是分离式推理架构在超大规模生产环境的标杆实践：

PD 分离部署：将 Prefill 和 Decode 分布在全球不同边缘节点，Prefill 集中在算力充足的中心节点，Decode 部署在靠近用户的边缘节点，实现”计算集中、推理下沉”
Mooncake Transfer Engine + Store：使用 Mooncake 的 Transfer Engine 实现 KV Cache 跨节点 RDMA 传输，Mooncake Store 将冷 KV Cache 卸载到 SSD，显著降低 decode 节点的显存压力
EAGLE-3 投机解码：在 Agent 场景中，工具调用（function calling）的输出模式具有高度结构性，EAGLE-3 投机解码利用这一特征大幅提升 accept rate，加速工具调用的 token 生成
量化成果：P90 TPOT 从 ~100ms 降至 20-30ms（3x 改善），KV Cache 命中率从 60% 提升至 80%，显著降低重复 prefill 开销
Infire 推理引擎：Cloudflare 自研推理引擎 Infire（Rust 实现），负责请求调度、KV Cache 管理和流式输出，充分发挥 Rust 的零成本抽象和高并发性能

来源：Cloudflare 官方博客，2026.03.19

生产案例：华为云 A3 昇腾 + Mooncake + vLLM-Ascend

Cloudflare Kimi K2.5 案例展示了 NVIDIA 硬件上的分离式推理最佳实践。华为云则验证了 Mooncake 生态在非 NVIDIA 硬件上的可移植性：

平台：A3 昇腾集群（单超节点）
工具链：vLLM-Ascend + Kthena 推理平台 + Mooncake Connector
模型：DeepSeek-R1-Distill-Qwen-1.5B（1P1D 分离）
架构：物理隔离 Prefill 和 Decode 阶段，利用 Mooncake Connector 实现 KV Cache 传输
价值：
- 验证了 Mooncake 生态在国产昇腾硬件上的可行性
- 扩大了 Mooncake 方案的硬件适用性（不再局限于 NVIDIA 生态）
- 为”信创 AI 基础设施”提供了端到端的可参考实现

这一案例与 Cloudflare Kimi K2.5 互补——一个展示超大规模 + NVIDIA 硬件上限，一个展示中等规模 + 国产硬件下限，共同勾勒出 Mooncake 生态在 2026 H1 的部署全谱。

传输层的可移植性：华为云案例证明 Mooncake 可以跑在昇腾整机方案上，而摩尔线程 2026 年的 Mooncake MUSA 预编译 wheel（mooncake-transfer-engine-musa 0.3.12.post1）进一步说明 KV 传输层本身可被第三方 GPU 厂商移植并进入 PyPI 生态——vLLM-MUSA 已将其接入默认分支（复用上游 MooncakeConnector），SGLang 主分支提供 MUSA 平台 + Mooncake PD backend，并在 MTT S5000 + RoCE 上完成单机双卡 PD 分离验证。至此 PD 分离的国产化拼图从”整机适配”下沉到”传输层组件”，与华为云案例（整机方案）是两个不同层次。📌 该段为中等置信度，引用前建议以摩尔线程官方公告或 PyPI 页面二次确认。

Kubernetes 原生路线：LLM-D

分离式推理在 2026 年分化出两条互补的技术路线。Mooncake 走”专用框架路线”——自研 TransferEngine + 独立 KV Store + 专用元数据管理。LLM-D（CNCF 托管，v0.8.1 于 2026-06-26 发布，当前版本 v0.9.0 / 2026-08-28）代表了另一条路线——通过 Kubernetes 原生编排实现分离推理：

核心架构：专用 Prefill Pod 和 Decode Pod 通过 NIXL 协议进行 KV Cache 跨节点传输（握手成本 ~5s/对）
差异化扩缩容：Workload Variant Autoscaler 基于 TTFT/TPOT 指标独立伸缩 Prefill 和 Decode Pod——两者可根据各自瓶颈差异化调整
Wide Expert Parallelism：支持 DeepSeek-R1-0528 在 32×H200/B200 上 16×16 EP 配置
标准集成：与 Kubernetes Gateway API Inference Extension v1（GA） 集成，兼容 Envoy/Istio。InferencePool + Endpoint Picker Extension (EPP) 机制使 KV cache-aware 路由成为 K8s 原生标准能力——基于 KV cache 局部性、当前负载和优先级路由请求，25+ 网关实现方。

v1.0.0-rc.1（tag 2026-10-14）为当前版本锚点；v0.10.0 的 release 发布于 2026-09-29（本章此前记的 09-24 为 tag 口径，此处按 release 时间更正）。以下 v0.9.0（tag 2026-08-17 / 官方公告 2026-08-28）的内容仍按 v0.9 描述

🎯 1.0 里程碑（2026-10-16 补）：本书自 v0.8.1（2026-06-26） 起跟踪 llm-d，v0.9 补上 P2P 权重传输与 P2P KV 复用，v0.10 主打 “operational hardening / production readiness”，到 2026-10-14 打出 v1.0 / v1.0.0-rc / v1.0.0-rc.1 三个 tag——Kubernetes 原生分离式推理这条路线，在本书跟踪的六个月内从 0.8 走到了 1.0。 ⚠️ 但 v1.0.0-rc.1 的 GitHub release notes 本轮未发布（releases/tags/v1.0.0-rc.1 返回 404），因此本书不推测 v1.0 新增了什么，只记录”里程碑已到、内容待官方 release notes”。选型时请以官方公告为准，不要按 1.0 这个数字去假设稳定性承诺。：从”PD 分离”扩展到”异构 + 多模态 + KEDA 原生”。

上表 v0.8.1 的四点仍然成立，v0.9 新增四条，其中两条会改写读者对”分离式推理需要中心化 KV Store”的印象：

冷启动：FMA + ModelExpress P2P 权重传输——一台 pod 从 HuggingFace 拉取权重，其余 pod 经 RDMA 直接从该 pod 的 HBM 获取，绕过磁盘 I/O。这是分离式推理在弹性扩容上的真实瓶颈解法。
去中心化 KV 复用：P2P KV cache sharing——vLLM 实例直接从 peer 的 CPU offload 层拉取已缓存前缀块，无需中心化 KV Store。与 Mooncake Store 的中心化路线形成对照。
可观测性：端到端 OpenTelemetry 追踪贯穿 P/D 传输链（请求到达 → prefill 调度 → KV 传输 → decode 完成），首次可单请求全链路追踪；EPP metrics mTLS。
自动扩缩从 Prometheus Adapter 迁移到 KEDA，EPP 暴露队列深度 / 在途请求数 / KV cache 压力作为 KEDA 信号，支持 SLO 驱动扩缩（旧路径继续保留）。

范围上，v0.9 新增多模态与扩散路由（OpenAI 兼容 /v1/images/generations，面向 vLLM-Omni 等扩散后端）、video 输入的前缀缓存亲和计算、多模态预测延迟——llm-d 不再只服务文本 LLM。硬件侧新增 GB200/GB300 P/D overlays、Intel XPU 宽 EP、ROCm（MoRI connector）、TPU v7 P/D 基准。

在生产性能方面，GPT-OSS-120B 在 8×Prefill + 2×Decode 拓扑上比标准 vLLM 吞吐提升最高 70%（AWS p6-b200 实例）；Llama 3.1 70B 在 4×MI300X 上实现 3× 吞吐、2× TTFT。LLM-D 的 CNCF 托管身份意味着它代表”社区共识”而非”单方方案”——PD 分离正从 Mooncake 的框架级创新走向 Kubernetes 的编排级标准化。

Gateway API 的落地证据与粒度演进：阿里云 ACK Gateway with Inference Extension（v1.6.1-apsara.3，2026-08-19）已支持稳定版 InferencePool v1 API、未配置 endpointPickerRef 时自动创建 Endpoint Picker，并新增 InferenceModelRewrite 与 InferenceObjective（模型名改写、流量分配、模型级调度目标）。粒度上，路由已从”KV cache 局部性”细化到”分层缓存感知”——可识别 SGLang HiCache 的 GPU/L1 与 cpu_pinned/L2 分层，把请求导向缓存所处的具体层级。

云厂商采纳（2026-07）：AWS SageMaker HyperPod 于 2026-07-10 正式支持分离式 Prefill-Decode 推理——标志着 PD 分离从框架能力进化为云平台产品特性。配套更新包括本地 NVMe 模型权重加载、Route 53 自动化 DNS 管理和 Pod 级别 IAM 权限。PD 分离正在成为行业默认模式，而非 Mooncake 一家的技术主张。

国产超集群里程碑：曙光 8000（登峰）。2026 年 7 月，中科曙光宣布曙光 8000 正式落成并接入国家超算互联网，这是中国首个全链路国产自研的十万卡级 AI 超集群。核心特点：(1) “超智融合”技术路线——同集群支持从 FP64 科学计算到 INT8 AI 训练，与 NVIDIA 纯 AI 集群定位不同；(2) scaleFabric 类 IB 原生 RDMA 高速网络；(3) 全链路国产自研（芯片-计算-存储-网络-散热-应用-服务）。与华为昇腾超节点（WAIC 2026 展出）、摩尔线程 MTT C256（一层 256 卡全互联）形成国产 AI 超节点集群竞争格局。中国 AI 基础设施建设正从万卡迈入十万卡时代。

推理加速：投机解码（Speculative Decoding）

Decode 阶段的逐 token 生成本质上是串行的，投机解码通过引入一个轻量级 draft 模型来打破这个串行瓶颈：

Draft 阶段：小模型（如 1B）快速生成 K 个候选 token
Verify 阶段：大模型一次性验证这 K 个 token（并行前向传播）
Accept/Reject：按概率接受匹配的 token，在首个不匹配处截断

关键性质：投机解码在数学上保证输出分布与原始大模型完全一致（无质量损失）。

生产框架支持状态：

框架	支持方式	典型加速比
vLLM	Draft model + Eagle/Medusa	1.5-2x（长输出）
SGLang	Draft model；DSpark 置信度驱动投机解码（2026-07-25, ~383 tok/s, accept-len ~5）	1.5-2x（长输出）
TensorRT-LLM	Medusa 多头投机	1.5-2x（长输出）

需要注意：投机解码只加速 Decode 阶段，不影响 Prefill。在输出较短或 draft 模型接受率低的场景，加速效果有限甚至可能增加开销。

多模型管理

生产环境通常需要同时部署多个模型（不同大小、不同版本、不同能力）。

模型路由

根据请求特征自动选择最合适的模型：

def route_request(request):
    if request.requires_reasoning:
        return "deepseek-r1-671b"  # 推理任务用大模型
    elif request.is_simple_qa:
        return "qwen-7b"          # 简单问答用小模型
    elif request.language == "code":
        return "deepseek-coder-33b"  # 代码任务用专用模型
    else:
        return "qwen-72b"         # 默认中等模型

RouteLLM（LMSYS）训练了一个轻量级路由器，根据查询复杂度自动在强模型和弱模型之间路由，在保持 95% 质量的同时减少 50%+ 的成本。

A/B 测试与灰度发布

新模型上线流程：

阶段 1: 影子模式（1% 流量，只记录不返回）
阶段 2: 灰度发布（5% 流量，对比指标）
阶段 3: 逐步放量（5% → 20% → 50% → 100%）
阶段 4: 全量切换

关键监控指标：延迟 P50/P99、用户满意度、错误率、安全指标。

GPU 集群运维

硬件故障应对

大规模 GPU 集群的故障率不可忽视：

故障类型	频率（千卡/天）	影响	应对
GPU 掉卡	~0.1%	单卡不可用	自动驱逐 + 替换
NVLink 降级	~0.05%	通信变慢	降级运行 + 维修
内存 ECC 错误	~0.01%	计算错误	自动重启 + 替换
节点宕机	~0.01%	多卡不可用	请求迁移

应对策略：

健康检查：每分钟探测 GPU 状态、显存、温度
自动故障转移：检测到异常后自动将请求路由到健康节点
冗余部署：N+1 或 N+2 冗余，确保单点故障不影响服务
优雅降级：GPU 不足时，优先保证高优先级请求
把重启代价纳入 SLO（）：故障转移的隐藏成本不是”能不能切走”，而是切过去之后多久能重新服务——而权重加载正是重启的大头。上表四类故障里，「自动驱逐 + 替换」「自动重启 + 替换」两格都隐含一次冷启动，此前本章只写了动作，没写耗时。

vLLM v0.31.0（2026-10-05） 给出两条官方路径：
- vllm preload：新增的 CLI 启动一个权重缓存守护进程，让量化后的权重在引擎重启之间常驻 GPU 显存（#56680），已支持数据并行（#57386）、MTP draft 模型（#57312）、/health 端点（#58552）与就绪等待（#58370）；
- vllm snapshot create/restore（实验性）：用 CRIU 恢复一个已完全初始化好的 TP1 引擎（#51360），比”重新加载权重 + 重建图”更进一步，直接恢复进程状态。
与 §Kubernetes 原生路线里 llm-d 的 FMA + ModelExpress P2P 权重传输（从 peer 的 HBM 拉权重、绕过磁盘 I/O）对比着记：llm-d 解决的是”首次冷启动”，vLLM 解决的是”重复重启”——两者不是竞争关系，而是不同场景：前者优化第一次把权重弄进显存，后者优化第 N 次。

显存管理

70B 模型显存分配（单卡 80GB H100, TP=4）:
  模型权重:     ~35 GB (FP16, TP=4 → 每卡 ~9 GB)
  KV Cache:     ~50 GB (动态分配)
  临时缓冲区:    ~5 GB
  CUDA 开销:    ~2 GB
  可用余量:      ~14 GB (安全边际)

KV Cache 是 LLM 推理中最大的动态显存消耗，管理策略经历了三代演进：

静态分配（早期）：按最大序列长度预留，浪费严重
PagedAttention（vLLM）：将 KV Cache 按”页”动态分配，类似操作系统虚拟内存，显存浪费降低至 <4%
分布式 KV Store（Mooncake 等）：将 KV Cache 从 GPU 显存中解放到 DRAM/SSD，通过 RDMA 实现跨节点 KV Cache 共享和迁移——这是分离式推理架构的基础

实际上这个序列在 2026 年已经变成四级，中间插进了一层本章此前没写的东西：vLLM 自 0.30.0 起引入 HiSparse，在 GPU 显存与 SSD 之间加了一个主机常驻层（pinned host memory）——GPU 压力下把 KV 页溢出到锁页主机内存，未命中的 top-k 由每请求的 GPU 热缓冲供给。0.31.0 又对它做了一轮硬化：MTP 验证行改用 union residency kernel（#59235）、修 FULL graph 下的 MTP 接受率崩溃（#59309）、修 chunked-prefill 抢占活锁（#59494）、KV cache 按 HiSparse 实际分配的组来定大小（#59450），并修了「KV connector + MTP 在 KV 压力下死锁」（#57104）。

修订后的层级序列应写作：GPU 显存 → 主机锁页内存（HiSparse）→ SSD / 对象存储 → 跨节点。

📌 这一级的加入改变了”卸载”这个动作的含义：在只有三级时，“把 KV 卸载到 DRAM/SSD”意味着一次跨设备传输；有了锁页主机内存之后，卸载变成了一个就近的、可回捞的分级，代价与命中率都不同。因此凡看到”卸载到 CPU 内存”的表述（包括本节上文优先级队列里的”保存 KV Cache 到 CPU 内存”），都要问一句：是普通主机内存，还是锁页常驻层——两者的性能语义不是一回事。

此外，KV Cache 复用（跨请求共享前缀的 KV Cache）已成为标准优化——前缀缓存正是这一思路的实现。

成本优化策略

1. Spot/Preemptible Instances

云厂商的抢占式实例通常比按需实例便宜 60-70%。适合：

批处理推理（可以被打断重试）
低优先级请求
非实时场景

2. 混合精度部署

高峰期: FP8/INT8, TP=2 → 高吞吐
低谷期: 释放 GPU → 降低成本

3. 自动扩缩容

# 伪代码: 基于队列深度的扩缩容策略
autoscaler:
  metric: queue_depth_per_gpu
  target: 5  # 每张 GPU 排队 5 个请求
  scale_up:
    threshold: 10
    cooldown: 60s
  scale_down:
    threshold: 2
    cooldown: 300s
  min_replicas: 2
  max_replicas: 32

4. 请求优化

Prompt 压缩：去除冗余的系统提示，使用更简洁的指令
Max tokens 限制：设置合理的最大输出长度
缓存复用：相似请求复用结果（语义缓存）
Early stopping：检测到循环或无意义输出时提前终止

可观测性

关键监控面板

实时指标:
├── QPS（当前/峰值）
├── TTFT P50/P99
├── TPOT P50/P99
├── GPU 利用率（计算/显存）
├── KV Cache 使用率
├── 队列深度
├── 错误率
└── 每秒生成 tokens

告警规则:
├── TTFT P99 > 2s → 告警
├── GPU 利用率 < 20% 持续 10min → 缩容提醒
├── GPU 利用率 > 90% 持续 5min → 扩容告警
├── 错误率 > 1% → 紧急告警
└── KV Cache 使用率 > 90% → 容量告警

分布式追踪

每个请求的完整生命周期追踪：

Request → Gateway (认证, 2ms)
  → Scheduler (排队, 15ms)
  → Engine.prefill (计算, 120ms)
  → Engine.decode (生成 200 tokens, 4000ms)
  → Response streaming
Total: 4137ms, 200 tokens, ~48 tok/s

端到端部署示例

方案一：快速启动（单卡/多卡）

# vLLM 一键部署
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3-70b-instruct \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 8192 \
  --port 8000

方案二：生产环境（Kubernetes）

# 简化的 K8s 部署配置
apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-inference
spec:
  replicas: 4
  template:
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        resources:
          limits:
            nvidia.com/gpu: 4
        env:
        - name: MODEL
          value: "meta-llama/Llama-3-70b-instruct"
        - name: TENSOR_PARALLEL_SIZE
          value: "4"

章节小结

LLM 服务的核心挑战是长尾延迟和资源异质性
TTFT 和 TPOT 是最关键的延迟指标
Token-aware 负载均衡比传统方法更适合 LLM 场景
分离式推理是 2025-2026 年最大的架构变革——Prefill 和 Decode 拆分为独立资源池
投机解码在数学上无损地加速 Decode 阶段 1.5-2x
推理引擎从 vLLM 一家独大变为5+ 引擎并存（vLLM / SGLang / TensorRT-LLM / NVIDIA Dynamo / llm-d）
前缀缓存在多轮对话和共享系统提示场景下效果显著
结构化输出是 Agent 时代推理引擎的核心能力
模型路由可以在保持质量的同时大幅降低成本
可观测性是生产部署的基石——你无法优化你看不到的东西