分布式推理与 NVIDIA Dynamo：并行化、prefill/decode 分离、KV 缓存迁移

状态：草稿（2026-10-05，横幅于 2026-10-07 更新）。 本文内容经官方文档核实，文中数据依然基于文档。直接在单张 GPU 环境下安装 Dynamo 并实测（前端成本、感知 KV 的路由、单卡上的 prefill/decode 分离）的内容在 第 24 篇中单独说明。两台不同 GPU 服务器之间（1GbE 级别网络）的分离式服务也在第 24 篇第 4.5 节进行了测量，而 NVLink 和 RDMA 环境仍然属于 未实测 。 请先阅读文末的“核实版本与日期”和“未核实项”。 编写规则：以实测数据为基础，未能测出的内容标注为“未实测”。

目录

• 摘要
• 1. 拆分模型的四种方法
• 2. prefill/decode 分离：为什么这样做，付出了什么代价
• 3. KV 缓存通过什么路径迁移
• 4. Dynamo v1.5.0 的架构
• 5. 与 llm-d、vLLM、SGLang 的定位差异
• 6. 分离有利的场景与有害的场景
• 7. 亲自尝试
• 外部依据：论文与官方资料核实的内容
• 8. 面试可能遇到的问题
• 9. 常见误解
• 参考资料（实际打开查阅过的）
• 核实版本与日期、未核实项

摘要

由于大模型无法装入单张 GPU，必须将权重分配到多张 GPU 上。由于每种分配方式（张量、流水线、专家、数据并行）的通信量和延迟差异很大，因此节点内部倾向于使用高带宽方式，节点之间倾向于使用通信较少的方式。此外，prefill（提示词处理）和 decode（生成 Token）的资源特性不同，分离资源池可以避免相互干扰，但代价是必须迁移 KV 缓存。NVIDIA Dynamo 是在推理引擎之上协调这种分离、感知 KV 的路由以及自动扩缩容的层。

读完本文后在面试中能够解释的内容

1. 张量、流水线、专家和数据并行分别划分了什么内容以及会引发什么通信，节点内部和节点之间做出选择的原因。
2. 通过 KV 缓存大小计算来解释 prefill/decode 分离的动机与代价，以及划分受益工作负载与受损工作负载的标准。
3. Dynamo v1.5.0 的组件如何处理单个请求，与 llm-d、vLLM、SGLang 的区别。

作者的定位。 我目前在普通以太网（1~2.5GbE 级别）环境中进行实验，没有 RDMA、InfiniBand、NVLink 的经验。本文是阅读官方文档和论文后的总结，直接测量过的数据仅有 LMCache 实验这一个。

1. 拆分模型的四种方法

通信量可通过 Narayanan 等人（2021）论文中的公式来估算。PP 在相邻段之间按每个微批次发送 b·s·h 个元素（批次、序列长度、隐藏维度的乘积）。在训练基准下，TP 在每层中每个设备收发 8·b·s·h·(t−1)/t 个元素，因为前向和反向传播各有两次 all-reduce。由于推理中没有反向传播，因此只保留前向传播的分量即为 4·b·s·h·(t−1)/t （作者推导）。

用于说明的示例（非实测）。 如果使用 TP=8 对 Qwen3-32B（隐藏层 5120，64 层）进行 8,000 个 Token 提示词的 prefill 并以 bf16 计算，则每层每个设备通过 all-reduce 传输约 287MB，整个 64 层约为 18GB。在同一请求中，跨越一个 PP 边界的数据约为 82MB。

因此，论文总结建议：TP 应在服务器内的 GPU 数量范围内使用，超出部分应通过 PP 增加（Takeaway #1，训练背景）。vLLM 文档也建议将 TP 设置为每个节点的 GPU 数量，将 PP 设置为节点数量，并指出在没有 NVLink 的 GPU（如 L40S 等）上 PP 更好。带宽差异从规格上也能看出。NVIDIA 将 NVLink 第 4 代标示为每张 GPU 900GB/s，第 5 代为 1,800GB/s（双向总和），而一张 ConnectX-7 为 400Gb/s（每个方向约 50GB/s）。DeepSeek-V3 报告中的 H800 集群采用的是 NVLink 160GB/s 对比 InfiniBand 50GB/s。

由于 EP 将 Token 发送到拥有专家的 GPU 并取回结果，因此每层都会发生 all-to-all。DeepSeek-V3 将路由限制在最多 4 个节点的范围内以减少 InfiniBand 流量，并将部署单元设为 prefill 32 GPU（EP32）、decode 320 GPU（EP320）。在 vLLM 中，启用 --enable-expert-parallel 后，EP 大小将变为 TP × DP ，并建议在 prefill 中将通信后端设为 deepep_high_throughput，在 decode 中设为 deepep_low_latency 。

 [노드 A: TP=4]                          [노드 B: TP=4]
 GPU0 GPU1 GPU2 GPU3 -- PP 경계 --> GPU4 GPU5 GPU6 GPU7
  └ NVLink all-reduce ┘  (활성화 텐서,    └ NVLink all-reduce ┘
    층마다, 지연 민감       점대점, RDMA)      층마다, 지연 민감

2. prefill/decode 分离：为什么这样做，付出了什么代价

动机。 Dynamo 文档将 prefill 描述为计算密集型，decode 描述为内存密集型，因此可以为 decode 分配更大的 TP，为 prefill 分配更小的 TP。SGLang 文档解释说，如果在一个引擎中混合，新的 prefill 会打断正在进行的 decode，从而延迟 Token 生成。vLLM 文档将其理由解释为可以分别调整 TTFT（首个 Token 生成时间）和 ITL（Token 间延迟）并控制尾部 ITL，同时明确指出分离并不能提高吞吐量。在论文方面，DistServe 报告称在聊天机器人中，请求率是 vLLM 的 2.0~4.6 倍（相比 DeepSpeed-MII 为 1.6~7.4 倍），在摘要任务中对 SLO 的满足度严格高达 12.6 倍（这是不同应用和对比对象的最大值，并非在一种配置下同时获得的值）；Splitwise 主张相比现有集群，吞吐量提升 1.4 倍且成本降低 20%，或者在相同功耗下提升 2.35 倍（集群规模的收益不是实测结果，而是模拟器结果）。这两者都是在 70B 到 175B 级别模型和快速连接（NVLink 内部部署、InfiniBand 200/400Gbps）的论文条件下得出的值。正文中的数据已在下文“外部依据”中进行了直接核实。

代价：必须迁移 KV 缓存。 每个 Token 的 KV 大小为 2(K와 V) × 층 수 × KV 헤드 수 × 헤드 차원 × 바이트 수 。根据 Qwen3-32B 的 config.json（64层，KV 头 8，头维度 128，bf16）计算，每个 Token 为 256KiB，8,000 个 Token 约为 2.1GB。

作者的实测。 这是在 8GB 级别笔记本 GPU 上使用 vLLM+LMCache 运行 Qwen2.5-1.5B 的实验。每个文档 4,864 个 Token（0.13GB）的 KV 从 CPU 内存加载到 GPU 大约花了 8~9ms，而重新计算相同的 5 千个 Token 大约花了 560ms。该模型的每个 Token KV 为 28KiB，因此 4,864 个 Token 变为 0.13GiB，与日志中的 0.1299 相符。不过，这是单节点内从 CPU 到 GPU 的迁移，而不是网络传输，且为并发 1、模型 1.5B、合成文档、单次测量。可以得出的结论仅限于“迁移往往比重新计算成本更低”这一方向，要在网络段成立，带宽必须像上表那样提供支撑。

Dynamo 文档集指出，如果通过 TCP 迁移 KV，TTFT 约为 98 秒，如果是 RDMA 则为 200~500ms。这两个数值的性质不同。98 秒是 Llama-3.1-8B、输入 8,000 个 Token、在 AWS p5.48xlarge 上当 EFA Pod 的 NIXL 静默降级到 UCX 的慢速路径时 测得的值（文档指导将 NIXL 后端指定为 LIBFABRIC 作为解决方案），而 200~500ms 是文档标注的“基于规格的期望值”。在相同条件的 EFA 下实际测得的 KV 传输附加开销为 37ms。因此，不应将“TCP 是 98 秒，RDMA 是 0.5 秒”作为通用对比来理解（见下文“外部依据”）。

3. KV 缓存通过什么路径迁移

传输库是 NIXL（NVIDIA Inference Xfer Library）。它抽象了内存类型（HBM、DRAM、文件、对象存储）并通过插件选择后端。文档提及的后端是 UCX 和 GPUDirect Storage，Dynamo 文档提到它通过 UCX 或 libfabric，而 SGLang 支持 Mooncake 和 NIXL。在节点内部使用 CUDA IPC 通过 NVLink，在节点之间使用 RDMA。

方向是“decode 从 prefill 拉取（pull）”的形式。llm-d 文档如此记载，vLLM 的 NixlConnector 将 prefill 端的 KV 块默认通过 30 秒的租约（lease）进行保留。运营中有四个需要了解的点。首先， NCCL_IB_HCA 等 NCCL 变量不适用于 NixlConnector，必须使用 UCX_TLS, UCX_NET_DEVICES 。其次，根据 Dynamo 文档，即使是同一节点上的不同 Pod，其 NVLink 也被阻止，必须通过网卡（NIC）传输。第三，Kubernetes 中的 /dev/shm 默认值（64MB）不足以初始化 NIXL，文档指导将 sharedMemory 提升至 16Gi。第四，vLLM 文档将 kv_role="kv_both" 标记为即将废弃，并建议使用 kv_producer/kv_consumer 建议使用，但 Dynamo 1.5.0 文档示例仍在使用 kv_both 。

4. Dynamo v1.5.0 的架构

Dynamo 并没有替换引擎，而是在 vLLM、SGLang、TensorRT-LLM 之上协调多个节点。其运行时采用 Rust，扩展采用 Python。

flowchart LR
  C[클라이언트] -->|HTTP 8000| F[Frontend<br/>토큰화·검증]
  F --> R[Router / PrefillRouter]
  R -->|1 prefill 요청| P[Prefill Worker]
  P -->|2 disaggregated_params| R
  R -->|3 decode 요청+메타데이터| D[Decode Worker]
  P -.->|4 KV 전송 NIXL| D
  D -->|5 토큰 스트림| F
  PL[Planner] -.->|복제본 수 조정| P
  PL -.-> D
  DS[(Discovery: K8s 또는 etcd)] -.-> F

• Frontend：兼容 OpenAI 的 HTTP 服务器（端口 8000），负责应用聊天模板、分词、验证和反分词。
• Router：结合前缀已缓存的工作节点和当前负载，选择成本最低的工作节点。成本为 prefill_load_scale × max(0, 활성 prefill 블록 + 신규 프롬프트 블록 − 겹침 크레딧) + 잠재 decode 블록 + 활성 요청 비용 。工作节点发布 KV 创建/删除事件来更新索引，如果收不到事件，则使用 --no-router-kv-events 进入预测模式。文档将此称为“批处理决策”，即使缓存很热的工作节点，如果负载很高也会落选。
• Worker：引擎进程。在分离部署中，通过 --disaggregation-mode prefill|decode 区分角色。
• Planner：以 TTFT、ITL SLA 为目标调整副本数量。目标是 throughput（默认）、 latency, load, sla ，并且可以结合基于吞吐量（默认 180 秒周期）和基于负载（默认 5 秒周期）的策略使用。由于缩容时不会等待正在进行的请求就直接终止工作节点，因此建议设置 min_endpoint 下限。
• 通信平面：发现（Kubernetes 使用 DynamoWorkerMetadata 和 EndpointSlice，裸金属使用 etcd）、请求（默认 TCP，可选 NATS）、事件（默认 ZMQ，可选 NATS）。
• 更改与废弃：KV 块管理器 (KVBM) 计划在 v1.5.0 中废弃，目标是在 v1.6.0 中移除（建议迁移至引擎的 KV 卸载功能）。AIConfigurator 已更名为 AISimulate，Go Endpoint Picker 已被 Rust 版本取代。

Kubernetes。 Dynamo Operator 负责协调 CRD。核心是 DynamoGraphDeployment（DGD，由前端和工作节点组成的一套推理图），还包括 DynamoComponentDeployment, DynamoGraphDeploymentRequest（填写模型、硬件、SLA 后进行性能分析以生成 DGD）、 DynamoGraphDeploymentScalingAdapter（集成 HPA/KEDA）等。 DynamoModel 在 v1.5.0 中， nvidia.com/v1beta1 成为了存储版本，在 spec.components 列表中使用 type: frontend|worker|prefill|decode 。对于跨多个节点的工作节点，如果没有 Grove（默认）或 LeaderWorkerSet，Operator 将报错。以下是精简后的文档示例（Qwen3-32B），未经实际应用验证。

apiVersion: nvidia.com/v1beta1
kind: DynamoGraphDeployment
spec:
  components:
  - {name: Frontend, type: frontend}
  - name: VllmPrefillWorker
    type: prefill
    sharedMemorySize: 16Gi
    # args: --model Qwen/Qwen3-32B --disaggregation-mode prefill
    #       --kv-transfer-config '{"kv_connector":"NixlConnector",...}'
  - name: VllmDecodeWorker
    type: decode        # args 는 같고 --disaggregation-mode decode

5. llm-d、vLLM 与 SGLang 的定位差异

这三个项目并非互斥。Dynamo 1.5.0 的发布说明中包含 llm-d 批处理网关示例，且两者都使用 vLLM 和 SGLang 作为模型服务器。未能确认哪一个更快。llm-d 的“最高 70% 吞吐量”（B200, AWS）与 Dynamo 的“TTFT 2 倍”（Baseten）不仅条件不同，而且 测量对象也不同。 70% 是指 prefill/decode 分离的吞吐量（GPT-OSS，输入与输出 1,024 个 Token），而 2 倍不是指分离，而是指 KV 感知路由的 TTFT（Qwen3-Coder 480B，输入约 5 万个 Token，对比随机路由），因此不能将两者并列放置来判断优劣。

6. 分离部署受益与受损的场景

根据 Dynamo 文档， 受益场景包括：长提示词导致 prefill 成本高昂、高并发导致 decode 成为瓶颈、希望分别扩展两个池、以及两个阶段需要不同并行化的大型模型。llm-d 推荐将输入与输出比为 10:1 的长文本作为典型案例。 受损场景包括：小模型、短提示词、低并发且缺乏高速 KV 传输网络的情况，此时聚合（aggregated) 部署更简单且通常更快。文档还警告称，当 decode KV 容量成为瓶颈时，增加 prefill 副本可能会导致总容量下降。

Dynamo 的对应方案是 条件分离（conditional disaggregation，实验性） 。如果路由器扣除 decode 工作节点的 KV 重叠部分后，剩余的有效输入长度小于默认的 2048 个 Token，并且与原始长度相比的比例小于 0.7，则不经过 prefill 工作节点，直接由 decode 工作节点处理 prefill。这针对的是多轮对话等大量重用前缀的情况，vLLM 的双向 KV 传输（prefill 拉取 decode 已有的上一轮 KV）也是基于同样的问题意识。

7. 动手尝试

如果没有 RDMA 和多 GPU 节点，则无法重现分离式服务，可行范围如下：

1. 计算 KV 大小（不改变环境）。 计算模型 config.json 中每个 Token 的 KV。

   python3 -c "import json,sys;c=json.load(open(sys.argv[1]));h=c.get('head_dim',c['hidden_size']//c['num_attention_heads']);print(2*c['num_hidden_layers']*c['num_key_value_heads']*h*2,'bytes/token(2바이트 가정)')" config.json
   

2. 测量 KV 加载成本。 像第 2 节的实验那样，在单个临时 Pod 中运行 vLLM 和 LMCache，比较从 CPU 内存加载 KV 的时间和重新计算的时间。结束后删除 Pod。如果节点内存与其它工作负载共享，在调高限制前必须先确认剩余空间。
3. 通过 TCP 运行 NIXL（未验证）。 在各自拥有一张 GPU 的两台服务器上启动 prefill/decode 实例，并将 UCX_TLS 限制为 TCP 系列，观察 TTFT 是否会像上表中的 1GbE 行那样增加的实验。编写本文时未执行此操作，也不保证其正常运行。由于 GPU 可能被其他工作负载占用，因此运行前需要进行检查。外部测量表明，即使在 100Gb/s TCP 下，根据实现的不同，GPU 间传输速度也会从 0.55GB/s (UCX) 降至约 4.8GB/s (UCCL)，因此 1GbE 行的理论线速实际上可能会更慢（参见下文“外部依据”）。（2026-10-07 补充：我们在第 24 篇第 4.5 节中直接测量了两台不同 GPU 服务器之间的情况。在 UCX 默认设置（TCP）下，输入 1,500 个单词的首个 Token 耗时 1.7 秒，3,000 个单词耗时 3.4~3.5 秒，比独立服务（44~172ms）慢了 20 倍以上。在单个 GPU 内将 UCX_TLS 限制为 TCP 系列的变体速度与默认设置相同。）
4. 直接测量的节点间 TCP 吞吐量（计算所需的最低实测值）。 在三个不同的节点对（Pod 网络， iperf3 10 秒）中，单流为 894~902 Mbit/s，四流为 901~912 Mbit/s，均达到 1GbE 级别（约 112 MB/s）。在此网络中传输一个 1.7B 模型、每 Token 114,688 字节、大小为 8,000 Token 的 KV（约 917 MB）需要约 8 秒，而 8GB 级 GPU 重新计算相同输入需要约 1 秒（第 21 篇）。也就是说，“ 小模型与 1GbE 环境下分离服务并不划算”（传输速度比重新计算慢 8 倍）这一第 6 节的表述得到了计算证实。直接连接两个实例的端到端 TTFT 已在第 24 篇第 4.5 节中进行了测量。0.6B 模型（每个 Token 的 KV 大小相同，为 114,688 字节）的 3,000 单词请求以 104 MB/s 的速度在 3.4 秒内传输了 351.75 MB，首个 Token 耗时 3.4~3.5 秒，与计算结果吻合（独立服务为 83~172ms）。

外部依据：通过论文和官方资料确认的内容

由于没有数据中心级设备无法重现分离式服务，本文的所有数据主张均通过查阅第一手资料并结合条件进行了确认。外部数据与我们的环境（小模型、单 GPU、1GbE）条件不同，因此未进行直接对比，仅用于判断方向。

供应商（NVIDIA、AWS、Baseten、llm-d）的数据仅搬运了正文中提到的条件。由于无法打开两个 llm-d README 项的原始博客以及 Megatron-LM 的通信量公式，因此未列出具体数值。

8. 面试可能问到的问题

1. 如果将 70B 模型部署到两个拥有 8 张 GPU 的节点上，应如何设置并行化策略？ 鉴于节点内有 NVLink，TP 设为 8；节点间由于通信较少，PP 设为 2。不过，由于 PP 会产生气泡（Bubble），如果模型能放入单个节点，最好在每个节点保留 TP 副本，并通过 DP 进行扩展。
2. 为什么要做 Prefill/Decode 拆分？什么情况下不拆分？ 其动机是解决计算密集型与内存密集型等资源特征的差异以及相互干扰，从而分别控制 TTFT 和 ITL。由于 KV 传输和 GPU 划分是其代价，因此在短提示词、低并发、慢网络的情况下，采用存算一体（集成）更好。
3. 通过 100GbE 发送 8K 提示词的 KV 需要多长时间？ 每个 Token 的 KV（Qwen3-32B 为 256KiB）约为 2.1GB，若线速为 12.5GB/s，则理论上为 0.17 秒。由于实际耗时更长，因此需要对照 TTFT 目标来决定是否需要 RDMA。
4. KV 感知路由的优点和风险是什么？ 发送到拥有此前缀的 Worker 可以跳过 Prefill 计算从而减少 TTFT，但如果请求过度涌向缓存所在的 Worker，则会形成热点。Dynamo 将缓存信用（Cache Credit）和活跃负载纳入同一个成本公式，其效果可以通过 random|round-robin 与 kv 在同等负载下进行对比来确认。
5. Planner 与 HPA 有何不同？ 它不基于 CPU 或请求数量，而是使用 TTFT、ITL SLA 以及按 Prefill/Decode 区分的信号（队列深度、KV 利用率）来预测流量。由于在缩容（Scale Down）时进行中的请求可能会失败，因此会设置最小副本数的下限。

9. 常见误解

• "拆分后总是更快。" vLLM 文档指出它不会提高吞吐量。其目的是实现延迟隔离和尾部延迟控制。
• "NCCL_IB_HCA 也适用于 KV 传输。" NixlConnector 使用 UCX，因此需要设置 UCX_NET_DEVICES 。
• "KVBM 是 Dynamo 的核心。" 它将在 v1.5.0 中被弃用。由于它仍保留在 README 的功能表中，请以发行说明（Release Notes）为准。
• "TP 设得越大，速度越快。" 由于每一层都会发生全规约（All-Reduce），一旦跨节点，通信就会成为瓶颈。Dynamo 也不是一个新的引擎，而是引擎之上的协调层。

参考资料（实际打开查阅过的）

• Dynamo v1.5.0 发行说明：https://github.com/ai-dynamo/dynamo/releases/tag/v1.5.0
• Dynamo 仓库 README 与文档（release/1.5.0 docs/fern/pages：架构、拆分服务、KV 感知路由、路由器概念、条件拆分、规划器、Kubernetes 拆分服务·DGD·RDMA·安装、API 参考、术语表）：https://github.com/ai-dynamo/dynamo , https://docs.nvidia.com/dynamo/
• NIXL: https://github.com/ai-dynamo/nixl
• vLLM: https://docs.vllm.ai/en/latest/features/disagg_prefill/ , https://docs.vllm.ai/en/latest/features/nixl_connector_usage/ , https://docs.vllm.ai/en/latest/serving/parallelism_scaling/ , https://docs.vllm.ai/en/latest/serving/expert_parallel_deployment/
• SGLang: https://docs.sglang.ai/advanced_features/pd_disaggregation.html
• llm-d: https://github.com/llm-d/llm-d , https://llm-d.ai/docs/architecture , https://llm-d.ai/docs/well-lit-paths/foundations/pd-disaggregation
• 论文: https://arxiv.org/abs/2104.04473 , https://arxiv.org/abs/2412.19437 , https://arxiv.org/abs/2401.09670 , https://arxiv.org/abs/2311.18677
• NVLink 规格: https://www.nvidia.com/en-us/data-center/nvlink/ , Qwen3-32B config: https://huggingface.co/Qwen/Qwen3-32B/raw/main/config.json

确认的版本与日期，以及未能确认的内容

确认日期为 2026-10-05。通过 GitHub Releases API 确认了 Dynamo v1.5.0（2026-09-21，捆绑引擎 SGLang v0.5.18、TensorRT-LLM v1.3.0rc25、vLLM v0.28.0）、NIXL v1.5.0（2026-09-30）、llm-d v0.10.0（2026-09-29）、vLLM 最新版 v0.30.0 以及 SGLang 最新版 v0.5.21，并且文档网站的 latest 也是 v1.5.0。

未能确认的内容：(1) 部分 Dynamo 文档仍在使用 v1alpha1 和 kv_both 示例的原因。(2) llm-d·Dynamo·SGLang 之间的性能优劣（由于测量对象不同，难以直接进行比较）。(3) 第 7 节第 3 个实验（在两台服务器上通过 TCP 运行 NIXL 来观察 TTFT 的测试）于 2026-10-07 在第 24 篇第 4.5 节中执行（仅在 1GbE 级别链路上，非 RDMA）。(4) 由于无法打开两个 llm-d README 项的原始博客以及 Megatron-LM 论文的通信量公式，故未予记录。98 秒和 200~500ms 的条件（现已确认）、DistServe·Splitwise 正文数值（现已确认）位于“外部依据”中。