AI 原生开放教材

外观

AI 工程从零到一（中文）源码研读·中文原文 ↗原件 ↓仓库 ↗

分离式 Prefill/Decode —— NVIDIA Dynamo 与 llm-d ​

Prefill 受计算限制；decode 受内存限制。把两者跑在同一块 GPU 上会浪费其中一种资源。分离（disaggregation）把它们拆到分开的池上，并经由 NIXL（RDMA/InfiniBand 或回退到 TCP）在两者之间传输 KV cache。NVIDIA Dynamo（GTC 2025 发布，1.0 GA）位于 vLLM/SGLang/TRT-LLM 之上 —— 它的 Planner Profiler + SLA Planner 自动按比例匹配 prefill:decode 的配比以满足 SLO。NVIDIA 公布的吞吐增益大致在这个区间 —— developer.nvidia.com（2025-06）显示 DeepSeek-R1 MoE 在 GB200 NVL72 + Dynamo 上、在中等延迟制度下约 6 倍的提升，而 Dynamo 产品页（developer.nvidia.com，无日期）宣传 GB300 NVL72 + Dynamo 相比 Hopper 最高 50 倍的 MoE 吞吐。那个"30x"的数字是跨全栈 Blackwell + Dynamo + DeepSeek-R1 报告的社区聚合；我们没找到一个准确说 30x 的单一一手来源，所以把它当方向性说法。llm-d（Red Hat + AWS）是 Kubernetes 原生的：prefill / decode / 路由器作为独立的 Service，按角色分别配 HPA。llm-d 0.5 加了分层 KV offloading、缓存感知 LoRA 路由、UCCL 网络、缩到零。经济性：对多个客户披露做内部汇总，提示在恒定 SLA 下从同机部署切到带 Dynamo 的分离式，能在 200 万美元级的推理开销上节省 30-40%（即每年 60-80 万美元）；那个具体的 $2M→$600-800K 数字是内部综合，不是单一已发布案例 —— 把它当数量级锚点，不是引用出处。短 prompt（<512 token、短输出）不值得那笔传输成本。

类型： Learn 语言： Python（标准库，一个玩具级分离式 vs 同机模拟器） 前置要求： 阶段 17 · 04（推理服务引擎内部机制）、阶段 17 · 08（推理指标） 预计时间： ~75 分钟

学习目标 ​

  • 解释为什么 prefill 和 decode 有不同的最优 GPU 分配，并量化同机下的浪费。
  • 画出分离式架构：prefill 池、decode 池、经 NIXL 的 KV 传输、路由器。
  • 说出分离不划算的条件（短 prompt、短输出）。
  • 区分 NVIDIA Dynamo（栈之上）和 llm-d（Kubernetes 原生），并把每个对应到一个运维场景。

问题背景 ​

你在 8 块 H100 上跑 Llama 3.3 70B。在混合工作负载下（长 prompt + 短输出），GPU 在 decode 期间闲着，因为大部分算力花在了 prefill 上。在另一种工作负载下（短 prompt + 长输出），反过来。同机的 prefill + decode 意味着你对两者都超配。

预算影响：20-40% 的 GPU 时间浪费在错误的资源上。你在买 H100 算力去跑内存受限的 decode，或者在买 H100 HBM 带宽去跑计算受限的 prefill。两者都是昂贵的浪费。

分离把 prefill 和 decode 拆到各按自己瓶颈配尺寸的分开池上。KV cache 经由高带宽互联从 prefill 池传到 decode 池。

核心概念 ​

为什么瓶颈不同 ​

Prefill —— 在一次 forward 里把 transformer 跑过整个输入 prompt。矩阵乘法主导；受计算限制。H100 FP8 给出约 2000 TFLOPS 的有用吞吐。批效率好 —— 一次 forward 处理很多 token。

Decode —— 一次生成一个 token，每次迭代读取整套权重。受内存带宽限制。HBM3 给出约 3 TB/s。批效率只在高并发时好 —— 读权重的开销跨批摊薄。

把它们同机：你买的 GPU 要同时优化两者。H100 两者都擅长，但哪种用法都一样贵。在规模上，你想要 prefill 池在 H100 / 计算重；decode 池在 H200 / 内存重，或者用激进量化。

架构 ​

            ┌──────────────┐
  请求    → │    路由器     │ ───────────────────────┐
            └──────┬───────┘                        │
                   │                                │
                   ▼ (仅 prompt)                    │
            ┌──────────────┐    KV cache    ┌───────▼──────┐
            │  Prefill 池  │ ─── NIXL ────► │  Decode 池   │
            │   (计算)     │                │   (内存)     │
            └──────────────┘                └──────┬───────┘
                                                   │ token
                                                   ▼
                                                 客户端

NIXL 是 NVIDIA 的跨节点传输。可用时用 RDMA/InfiniBand，否则回退到 TCP。传输延迟是真实存在的 —— 对 70B FP8 上一个 4K token prompt 的 KV cache，通常 20-80 ms。这就是为什么短 prompt 不值得分离：传输税超过节省。

Dynamo vs llm-d ​

NVIDIA Dynamo（GTC 2025 发布，1.0 GA）：

  • 作为编排器位于 vLLM、SGLang、TRT-LLM 之上。
  • Planner Profiler 测量工作负载，SLA Planner 自动配置 prefill:decode 配比。
  • Rust 内核，Python 可扩展。
  • 吞吐增益：NVIDIA 报告 DeepSeek-R1 MoE 在 GB200 NVL72 + Dynamo 上、中等延迟制度下 6 倍（developer.nvidia.com，2025-06）；关于全 Blackwell + Dynamo + DeepSeek-R1 栈"最高 30x"的社区报告缺乏单一一手来源，应当作方向性看待。
  • GB300 NVL72 + Dynamo：据 Dynamo 产品页（developer.nvidia.com，无日期），相比 Hopper 最高 50x MoE 吞吐。

llm-d（Red Hat + AWS，Kubernetes 原生）：

  • prefill / decode / 路由器作为独立的 Kubernetes Service。
  • 按角色配 HPA，用队列深度（prefill）/ KV 利用率（decode）信号。
  • topologyConstraint packDomain: rack 把 prefill+decode 小团打包到同一机架，做高带宽 KV 传输。
  • llm-d 0.5（2026）：分层 KV offloading、缓存感知 LoRA 路由、UCCL 网络、缩到零。

想要一个托管的栈之上编排器就用 Dynamo。想要 Kubernetes 原生原语、并押注 CNCF 生态就用 llm-d。

经济性 ​

内部综合（不是单一已发布案例 —— 数量级锚点）：

  • 同机部署上每年 200 万美元推理开销。
  • 切到带 Dynamo 的分离式。
  • 相同请求量、相同 P99 延迟 SLA。
  • 报告的节省：每年 60-80 万美元（降 30-40%）。
  • 不加新硬件。

我们从多个客户披露综合出这个数字，而不是某个可引用的单一案例；最接近的已发布数据点是 Baseten 用 Dynamo KV 路由实现 2 倍更快 TTFT / 高 61% 吞吐（baseten.co，2025-10），以及 VAST + CoreWeave 在 40-60% KV 命中率下多出 60-130% token/$ 的预测（vastdata.com，2025-12）。节省来自给每个池正确定尺寸；prefill 重的工作负载（带 8K+ 前缀的 RAG）比均衡的受益更多。

何时别分离 ​

  • prompt < 512 token 且输出 < 200 token：传输税盖过收益。
  • 小集群（< 4 GPU）：池子多样性不够。
  • 团队无法运维带按角色扩缩的两个 GPU 池：Dynamo 有帮助但不是轻而易举。
  • 没有 RDMA fabric：TCP 传输税更重。

路由器与阶段 17 · 11 集成 ​

分离式路由器是 KV-cache 感知的（阶段 17 · 11）。一个请求落在持有它前缀的 decode 池上 —— 没匹配的话，它就流过 prefill → decode。命中率和分离相互叠加 —— 缓存感知路由器决定一次新的 prefill 到底是否需要。

Blackwell 上的 MoE 才是真正数字所在 ​

GB300 NVL72 + Dynamo 显示相比 Hopper 基线 50x 的 MoE 吞吐。MoE 专家路由在 prefill 上计算重、在 decode 上内存重（专家缓存），所以分离是双赢。2026 年的前沿模型服务以 MoE 为主导（DeepSeek-V3、未来的 GPT-5 变体）。

你该记住的数字 ​

基准数字会漂移 —— NVIDIA 和推理栈每季度都发新结果。引用前重新核对。

  • DeepSeek-R1 在 GB200 NVL72 + Dynamo 上：中等延迟制度下相比基线约 6x 吞吐（developer.nvidia.com，2025-06）；关于全 Blackwell + Dynamo 栈"最高 30x"的社区说法是没有单一一手来源的方向性聚合。
  • GB300 NVL72 + Dynamo：相比 Hopper 最高 50x MoE 吞吐（developer.nvidia.com，无日期）。
  • 节省锚点（内部综合，非单一案例）：在恒定 SLA 下从 200 万美元年开销里省 60-80 万美元/年。
  • 分离阈值：prompt >512 token + 输出 >200 token。
  • 经 NIXL 的 KV 传输：70B FP8 上 4K prompt 的 KV 为 20-80 ms。
figure
prefill-decode-split

实际使用 ​

code/main.py 模拟同机 vs 分离式服务。报告吞吐、单请求成本和 prompt 长度的交叉点。

拿去用 ​

这一课产出 outputs/skill-disaggregation-decider.md。给定工作负载和集群，决定是否分离。

练习 ​

  1. 跑 code/main.py。prompt 长到多少时分离胜过同机？
  2. 为一个 P99 前缀长度 8K、输出 300 的 RAG 服务设计 prefill 池和 decode 池。
  3. Dynamo vs llm-d：为一个纯 Kubernetes、对 Python 运行时无偏好的团队挑一个。
  4. 算 KV 传输成本：70B FP8 上 4K prefill = 约 500 MB KV。RDMA 100 GB/s 下，传输 = 5 ms。TCP 10 GB/s = 50 ms。哪个对你的 SLA 重要？
  5. MoE 专家路由改变 KV 访问模式。对每个 token 激活不同专家的 MoE，分离表现如何？

关键术语 ​

术语大家嘴上怎么说它实际是什么
分离式服务"拆 prefill/decode"为每个阶段分开的 GPU 池
NIXL"NVIDIA 传输"Dynamo 的跨节点 KV 传输（RDMA/TCP）
NVIDIA Dynamo"编排器"vLLM/SGLang/TRT-LLM 的栈之上协调器
llm-d"Kubernetes 原生"Red Hat + AWS 的 K8s 分离式栈
Planner Profiler"Dynamo 自动配置"测量工作负载，配置池配比
SLA Planner"Dynamo 策略"自动按比例匹配 prefill:decode 以满足 SLO
packDomain: rack"llm-d 拓扑"把 prefill+decode 打包到同机架做快速 KV
UCCL"统一集合通信"llm-d 0.5 用于缩到零的网络层
MoE 专家路由"每 token 一个专家"DeepSeek-V3 模式；分离有帮助

延伸阅读 ​