用 Dynamo 部署预填充与解码分离推理

把大模型推理拆到两组 GPU 上，吞吐就会更高吗？这篇 NVIDIA Dynamo 部署指南给出的答案有条件：大模型、长输入和 RDMA 网络更适合拆分；它展示的 4B 模型配置搜索，反而选中了不拆分的方案。

对自建模型服务的程序员，最有用的是这套决策顺序：先根据延迟目标比较架构，再部署，最后压测。不过，原文提供了配置预测和启动日志，没有给出最终压测结果，不能把整篇都当成性能实测报告。

为什么把读提示词和生成答案拆开

NVIDIA Dynamo 是面向多节点、多 GPU 环境的开源推理框架。原文讨论的分离式服务（disaggregated serving），把一次推理分成两段。

Prefill 处理输入提示词，生成后续推理需要的 KV cache，可以理解为模型读完输入后保留的中间计算结果。Decode 接过这些缓存，逐个生成输出 token。

两段的优化目标不同。Prefill 希望尽快完成输入处理，降低首 token 延迟 TTFT；Decode 希望在较高并发和较大 batch 下持续生成，提高 token 吞吐。拆开后，两组 worker 可以分别扩容，采用不同的张量并行度 TP。

请求先进入 Frontend，PrefillRouter 根据 KV cache 亲和性选择 prefill worker；处理完毕后，通过 NIXL 把缓存交给 decode worker。这里的关键成本是搬运缓存，网络因此成为架构的一部分。

原文建议优先考虑分离式服务的条件包括：模型达到 32B+、输入长度 ISL 通常超过 4000 tokens、输入明显长于输出 OSL，以及拥有 InfiniBand 或 RoCE 等 RDMA 网络。它声称，大模型长上下文负载的吞吐最高可达到聚合式服务的 1.7 倍。

对于小于 10B 的模型、ISL/OSL 在 2:1 到 10:1 之间的负载，或更重视部署简单、通信延迟的团队，原文更倾向聚合式服务。这些是选型提示，文章没有提供覆盖这些边界的完整对照实验。

拆分是否划算，要看分阶段优化省下的时间，能否覆盖 KV cache 传输成本。

配置搜索为什么给 4B 模型选了聚合式

AIConfigurator 的作用，是先比较配置，再决定架构。它模拟聚合式和分离式方案，搜索张量并行、流水线并行 PP 等组合，筛掉不满足 TTFT、每 token 输出时间 TPOT 目标的结果，再按每 GPU 吞吐排序，生成部署文件。

运行它需要 Python 3.10+。安装使用 pip3 install aiconfigurator，通过 aiconfigurator version 查看版本，通过 aiconfigurator cli default --help 查看参数。

下面这条命令保留了原文的完整搜索条件，用来比较同一模型、硬件和延迟约束下的配置：

$ aiconfigurator cli default \
  --hf_id nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1 \
  --system h200_sxm \
  --total_gpus 4 \
  --isl 4000 \
  --osl 500 \
  --ttft 600 \
  --tpot 16.67 \
  --backend vllm \
  --backend_version 0.12.0 \
  --save_dir ./results_vllm

重点看 --ttft 600 和 --tpot 16.67：它搜索的是满足延迟约束后的吞吐最优配置。模型是 4B，硬件是 4 张 H200，输入 4000 tokens、输出 500 tokens，后端固定为 vLLM 0.12.0。

结果中，聚合式每 GPU 吞吐为 3785.20 tokens/s，分离式为 3067.51 tokens/s，前者约高 23%。日志里的 disagg 0.81x better 容易误读，结合数值，它表示分离式吞吐约为聚合式的 0.81 倍。

聚合式最优配置使用 4 个副本，每个副本 tp1pp1、batch size 为 64，总并发 256。预测总吞吐为 15,140.82 tokens/s，每用户速度为 61.41 tokens/s，TTFT 为 395.88ms，TPOT 为 16.28ms，请求延迟为 8521.26ms。

分离式最优方案的并发为 208，每用户速度为 63.99 tokens/s，表中 prefill TTFT 为 111.33ms，请求延迟为 7909.20ms。它说明不同指标可能指向不同选择：首 token 更快的方案，每 GPU 吞吐未必最高。

这些数字来自 AIConfigurator 的预测输出。文章接下来仍部署分离式方案，明确是为了演示流程，并非证明它适合这个 4B 模型。

部署跑通以后，还缺哪一步证明

Kubernetes 部署需要提前安装 Dynamo Operator，配置 GPU 资源管理和 DynamoGraphDeployment CRD，并具备 RDMA device plugin。共享模型缓存使用 ReadWriteMany PVC，容量为 100Gi，因此 StorageClass 也必须支持 RWX。

演示清单采用 nvidia.com/v1alpha1，部署 1 个 Frontend、2 个 prefill worker 和 2 个 decode worker，后两组各使用 1 张 GPU。容器镜像为 nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.9.0-cuda13。两个阶段都设置 --tensor-parallel-size 1、--kv-cache-dtype fp8，但 --max-num-seqs 分别为 1 和 1024，体现了各自不同的并发配置。

RDMA 相关配置包括申请 rdma/hca_shared_devices: "1"、添加 IPC_LOCK 能力，以及设置：

• UCX_TLS="rc_x,rc,dc_x,dc,cuda_copy,cuda_ipc"，选择传输方式。
• UCX_RNDV_SCHEME=get_zcopy，配置零拷贝传输。
• UCX_RNDV_THRESH=0，按原文意图让所有消息尺寸使用 rendezvous 机制。

POD_UID 用于 worker 标识，--trust-remote-code 允许执行 Hugging Face 上的自定义模型代码。这些都有具体用途，迁移配置时需要逐项理解。

原文展示了 Pod Running、NIXL 初始化、UCX backend 创建和 KV cache 注册日志，也通过 /v1/chat/completions 完成请求，并查看 dynamo_frontend_requests_total。它们可以证明服务启动和请求成功；仅凭这些输出，还不足以量化 RDMA 的实际传输性能，或证明分离式优于聚合式。

最后需要 AIPerf。通过 pip3 install aiperf 安装后，下面的命令用于初步验证部署：

$ aiperf profile \
  -m nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1 \
  --endpoint-type chat \
  -u http://localhost:8000 \
  --isl 4000 --isl-stddev 0 \
  --osl 500 --osl-stddev 0 \
  --num-requests 800 \
  --concurrency 30 \
  --streaming \
  --extra-inputs "ignore_eos:true" \
  --num-warmup-requests 40 \
  --ui-type simple

要注意 --concurrency 30：配置搜索推荐的是 208，这里主动降低并发以便快速验证。正式检查预测吞吐时，原文建议使用 --concurrency 208、--num-requests 8320，即并发数乘以 40；ignore_eos:true 用来保证生成指定的 500 tokens。

提供的原文到「以 30 并发运行 800 次请求」便结束了，没有附上压测成绩。

我的判断

我赞同先设延迟目标、再比较架构的顺序。同样是聊天服务，有的更在意首字出现速度，有的更在意 GPU 承载能力，不能只拿一个吞吐数字替所有业务做决定。

文章的局限也很明确。1.7 倍提升没有对应的大模型、硬件配置和完整结果；唯一详细展示的 4B 示例支持的是聚合式更高效。32B+、小于 10B、ISL 超过 4000 等条件，更适合作为搜索起点，不能当作固定分界线。

原文还声称，没有 RDMA 时性能下降 40 倍，并举出 TTFT 从约 400ms 增加到 10 秒以上。这里没有完整测试条件，40 倍也无法从给出的近似数值直接核对，应当保留问号。

另一个待核对点是版本：配置搜索指定 vLLM 0.12.0，部署使用 Dynamo runtime 0.9.0-cuda13，文章没有解释镜像内后端版本与模拟条件如何对应。

这是一条可以参考的部署与验证路线，还不是一份足以证明性能收益的完整实验。

对于一般团队，聚合式部署是合理的对照起点。分离式增加了网络、调度和资源管理要求，收益需要用自己的负载测出来。

能拿来做什么

• 自建模型服务前，先统计真实请求的输入、输出长度，并分别确定 TTFT 和 TPOT 目标，再用 AIConfigurator 比较方案，避免只按参数规模选架构。
• 如果当前运行的是 4B 等小模型，先保留聚合式基线。原文自己的预测结果已经说明，拆分可能降低每 GPU 吞吐。
• 给前端或 Node 应用接入自建服务时，可以先通过 /v1/chat/completions 验证请求，再使用带 --streaming 的 AIPerf 压测，分别检查首 token 延迟、生成速度和并发吞吐。
• 如果决定部署分离式服务，就沿用搜索时的模型、后端版本、ISL、OSL 和并发条件进行验证，并检查 RDMA 配置；Pod Running 只是验证流程的一步。