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

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

本节摘要:Prefill 是计算受限的;decode 是内存受限的。把两者跑在同一块 GPU 上会浪费一种资源。分离式架构(disaggregation)把它们拆到不同池,经 NIXL(RDMA/InfiniBand 或 TCP 回落)在池间传 KV 缓存。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 吞吐。「30 倍」是全栈 Blackwell + Dynamo + DeepSeek-R1 报告的社区聚合;我们没找到单一原始来源精确说 30 倍,故视为方向性主张。llm-d(Red Hat + AWS)是 Kubernetes 原生:prefill / decode / router 作为独立 Service,各带按角色 HPA。llm-d 0.5 加了分层 KV 卸载、缓存感知 LoRA 路由、UCCL 网络、缩到零。经济性:多个客户披露的内部汇总显示,从协同部署切到 Dynamo 分离式(恒定 SLA)在 200 万美元级推理花费上省 3040%(即 6080 万美元/年);具体 200 万→60~80 万是内部合成,非单一公开案例——用作量级锚点,非引用来源。短提示(<512 token、短输出)不划算付传输成本。

对应原课程:Phase 17 · Lesson 17 · 17-disaggregated-prefill-decode(原英文 phases/17-infrastructure-and-production/17-disaggregated-prefill-decode/docs/en.md)。

学习目标

阅读完本节,你应当能够:

1. 解释为什么 prefill 与 decode 有不同最优 GPU 配置,并量化协同部署下的浪费。
2. 画出分离式架构:prefill 池、decode 池、经 NIXL 传 KV、路由器。
3. 说出分离式不划算的条件(短提示、短输出)。
4. 区分 NVIDIA Dynamo(栈之上)与 llm-d(Kubernetes 原生),并把各自对应到运维语境。

一、问题与直觉

你在 8 张 H100 上跑 Llama 3.3 70B。混合工作负载(长提示 + 短输出)下,GPU 在 decode 期间闲置,因为多数算力花在了 prefill。另一种工作负载(短提示 + 长输出)则相反。协同部署 prefill + decode 意味着你对两者都过量配置。

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

分离式把 prefill 与 decode 拆到各自按瓶颈尺寸的池。KV 缓存经高带宽互联从 prefill 池传到 decode 池。

二、核心概念

为什么瓶颈不同

Prefill —— 一次前向把 transformer 跑过整个输入提示。矩阵乘主导;计算受限。H100 FP8 给约 2000 TFLOPS 有用吞吐。批次效率好——一次前向处理多个 token。

Decode —— 一次生成一个 token,每次迭代读全部权重。内存带宽受限。HBM3 给约 3 TB/s。批次效率只在 高并发下好——权重读取在批次间摊销。

协同部署:你买对两者都优化的 GPU。H100 两者都擅长但任一方式都同价。规模化时,你要 prefill 池在 H100/算力重;decode 池在 H200/内存重,或带激进量化。

架构

            ┌──────────────┐
  请求 →    │    Router    │ ───────────────────────┐
            └──────┬───────┘                        │
                   │                                │
                   ▼ (仅提示)                       │
            ┌──────────────┐    KV 缓存    ┌───────▼──────┐
            │ Prefill 池   │ ─── NIXL ────► │ Decode 池    │
            │  (计算)      │                │  (内存)      │
            └──────────────┘                └──────┬───────┘
                                                   │ token
                                                   ▼
                                                 客户端
​

NIXL 是 NVIDIA 的节点间传输。可用时用 RDMA/InfiniBand,否则 TCP 回落。传输延迟是真的——70B FP8 上 4K token 提示的 KV 通常 20~80 ms。这就是为什么短提示不值得分离:传输税超过节省。

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);社区「高达 30 倍」在全 Blackwell + Dynamo + DeepSeek-R1 栈上缺单一原始来源,视为方向性。
• GB300 NVL72 + Dynamo:依 Dynamo 产品页(developer.nvidia.com,未注日期),相对 Hopper 高达 50 倍 MoE 吞吐。

llm-d(Red Hat + AWS,Kubernetes 原生):

• Prefill / decode / router 作为独立 Kubernetes Service。
• 按角色 HPA,prefill 用队列深度、decode 用 KV 利用率信号。
• topologyConstraint packDomain: rack 把 prefill+decode 团伙打包到同机柜,获高带宽 KV 传输。
• llm-d 0.5(2026):分层 KV 卸载、缓存感知 LoRA 路由、UCCL 网络、缩到零。

要托管栈之上编排器用 Dynamo;要 Kubernetes 原生原语、押注 CNCF 生态用 llm-d。

经济性

内部合成(非单一公开案例——量级锚点):

• 200 万美元/年推理花费,协同部署。
• 切到 Dynamo 分离式。
• 同请求量、同 P99 延迟 SLA。
• 报告节省:6080 万美元/年(降 3040%)。
• 无新硬件。

我们从多个客户披露合成此数字,而非单一可引案例;最近公开数据点是 Baseten 用 Dynamo KV 路由的 2 倍 TTFT / 61% 更高吞吐(baseten.co,2025-10),以及 VAST + CoreWeave 在 4060% KV 命中率下多 60130% token/美元的投影(vastdata.com,2025-12)。节省来自每池适度尺寸;prefill 重的工作负载(8K+ 前缀的 RAG)比平衡的获益更多。

何时不要分离

• 提示 <512 token 且输出 <200 token:传输税主导收益。
• 小集群(<4 GPU):池多样性不够。
• 团队运维不了两个带按角色伸缩的 GPU 池:Dynamo 有帮助但非轻易。
• 无 RDMA 织网:TCP 传输税更重。

路由器与第 11 节集成

分离式路由器是 KV 缓存感知的(第 11 节)。请求落到持有其前缀的 decode 池——若无匹配,流 prefill → decode。命中率与分离式叠加——缓存感知路由器决定是否需要新 prefill。

MoE on Blackwell 才是真数字所在

GB300 NVL72 + Dynamo 显示相对 Hopper 基线 50 倍 MoE 吞吐。MoE 专家路由在 prefill 上算力重,在 decode 上内存重(专家缓存),所以分离式是双倍赢。2026 前沿模型服务是 MoE 主导(DeepSeek-V3、未来 GPT-5 变体)。

你该记住的数字

基准数字漂移——NVIDIA 与推理栈每季度发更新结果。引用前再核。

• DeepSeek-R1 在 GB200 NVL72 + Dynamo:中等延迟档下相对基线约 6 倍吞吐(developer.nvidia.com,2025-06);社区「高达 30 倍」是方向性聚合,无单一原始来源。
• GB300 NVL72 + Dynamo:相对 Hopper 高达 50 倍 MoE 吞吐(developer.nvidia.com,未注日期)。
• 节省锚点(内部合成,非单一案例):恒定 SLA 下 200 万年花费省 60~80 万/年。
• 分离阈值:提示 >512 token + 输出 >200 token。
• 经 NIXL 的 KV 传输:70B FP8 上 4K 提示 KV 20~80 ms。

三、从零实现:分离式 vs 协同部署模拟器

原课程 code/main.py 模拟协同部署 vs 分离式服务,报告吞吐、每请求成本、提示长度交叉点。下面给最小可读的交叉点判断骨架。

def disaggregation_pays(prompt_tokens, output_tokens,
                        transfer_ms_per_kv, prefill_compute_savings_ms,
                        decode_memory_savings_ms):
    """判断分离式对此请求是否划算。

    返回: (净收益 ms, 是否划算)
    """
    # 分离式节省:prefill 用算力优池 + decode 用内存优池
    savings = prefill_compute_savings_ms + decode_memory_savings_ms
    # 传输税:KV 从 prefill 池搬到 decode 池
    tax = transfer_ms_per_kv
    net = savings - tax
    return round(net, 1), net > 0


# 案例:4K 提示 + 300 输出 vs 256 提示 + 100 输出
for label, p, o in [("长提示长输出", 4000, 300), ("短提示短输出", 256, 100)]:
    # KV 传输税随提示长度增长;节省随提示+输出增长
    tax = (p / 4000) * 50  # 4K 约 50ms
    sav = (p / 4000) * 40 + (o / 300) * 30
    net, ok = disaggregation_pays(p, o, tax, (p/4000)*40, (o/300)*30)
    print(f"{label}: 净 {net}ms, 分离划算={ok}")
​

💡 分离式的阈值很清晰:提示 >512、输出 >200 才划算。短交互越分离越亏——传输税超过节省。先按请求分布算交叉点,再决定是否拆池。

四、框架对比:Dynamo vs llm-d

心法:NVIDIA 栈 + 要编排器 → Dynamo;Kubernetes 优先 + CNCF 押注 → llm-d。两者都基于「prefill 与 decode 拆池」同一原理。

五、可复用产物

本节产出 outputs/skill-disaggregation-decider.md(原课程目录)。给定工作负载与集群,它决定是否分离:

1. 请求分布分析:提示/输出长度分布,算多少比例过分离阈值。
2. 池配比:prefill 池 vs decode 池的 GPU 数与型号(H100 算力 vs H200 带宽)。
3. 传输预算:NIXL/NVLink/IB 的 KV 传输延迟与 SLA 余量。
4. 不分离条件:短交互占比高、小集群、无 RDMA 时的回落。

六、练习

1. 跑通模拟器:运行 code/main.py。在多长提示下分离式胜过协同部署?

2. 池设计:为一个 P99 前缀 8K、输出 300 的 RAG 服务设计 prefill 池与 decode 池。

3. Dynamo vs llm-d:为一个纯 Kubernetes、无 Python 运行时偏好的团队选一个。

4. 传输成本:4K prefill 在 70B FP8 上 = 约 500 MB KV。RDMA 100 GB/s 下传输 5 ms,TCP 10 GB/s 下 50 ms。哪个对你的 SLA 要紧?

5. MoE 专家:MoE 专家路由改变 KV 访问模式。每 token 激活不同专家的 MoE 下,分离式如何表现?

本节要点回顾

1. Prefill 计算受限、decode 内存受限:同 GPU 跑两者浪费一种资源,20~40% GPU 时间浪费。
2. 分离式拆池 + NIXL 传 KV:prefill 池算力优、decode 池带宽优,KV 经 RDMA/IB 传输。
3. NVIDIA Dynamo 是栈之上编排器:Planner Profiler + SLA Planner 自动配 prefill:decode 比。
4. llm-d 是 Kubernetes 原生:prefill/decode/router 独立 Service,按角色 HPA,topology packDomain。
5. Dynamo 在 GB200/GB300 上 6~50 倍:DeepSeek-R1 MoE 中等延迟档 6 倍,GB300 MoE 高达 50 倍。
6. 经济性量级锚点:200 万年花费省 3040%(6080 万),无新硬件,恒定 SLA。
7. 不分离条件:提示 <512 + 输出 <200、小集群 <4 GPU、无 RDMA、团队运维不了两池。
8. 路由器与第 11 节叠加:缓存感知路由决定是否需新 prefill,命中率与分离式复合。
9. MoE 是真数字所在:专家路由 prefill 算力重、decode 内存重,分离式双倍赢,2026 前沿 MoE 主导。

下一节,我们看 vLLM production-stack + LMCache 如何把分离式的 KV 卸载与缓存感知路由组合成一套可自托管的生产服务栈。