8 月 6 日，vLLM 团队发文报告了 Qwen3.5 在分离式（disaggregated，P/D）服务下的性能进展：在 GB200 NVL72 集群上，单卡总吞吐突破了 25,000 token/秒。这篇文章来自社区对 Qwen3.5 分离式推理路径的持续贡献，重点介绍了背后的三项关键优化、可复现的配置，以及要跑到这个数字你需要注意的实践细节。

Qwen3.5 发布于 2026 年初，至今仍是客户使用最广的模型之一。它的新颖之处在于混合注意力架构——同时包含完整的全注意力层和 Gated Delta Network（GDN）层。这给分离式服务带来了额外挑战，也带来了独有的优化空间。

一脸三处：Qwen3.5 的优化难题

Qwen3.5 的混合架构把优化拆成了两个截然不同的问题：一是在 Blackwell 上加速 GDN 计算，二是在 prefill 和 decode 工作节点之间正确迁移异构的注意力/GDN 状态。

vLLM 官方的 NIXL 分离式路线图，由社区通过 SSM（状态空间模型）支持一路驱动而来。文章特别强调了三项对 Qwen3.5 性能最关键的贡献，下面逐一展开。

优化一：Blackwell 优化的 GDN Prefill 内核

第一个突破口是 FlashInfer 新增的 Blackwell GDN prefill 内核（FlashInfer #3001）。相比此前的 FLA/Triton 实现，这个新内核在 Qwen3.5 的各模型规模、张量并行配置、序列长度和 batch 形态上，性能提升了约 1.02× 到 5.78×。

内核随后通过 vLLM PR #40717 在 prefill 侧启用。在 8×B200 系统跑 Qwen3.5-397B-A17B-NVFP4 上，集成带来的实测收益是：

  • 微基准里 GDN 内核性能最高提升 5.92×
  • pure-prefill 负载（ISL/OSL = 8192/1）端到端 prefill 吞吐提升 1.13×
  • 同类负载的平均 TTFT 降低 12%

在支持它的 Blackwell 配置上，vLLM 会把 GDN 后端设为 auto 时自动选择 FlashInfer 路径；也可以显式指定：

--gdn-prefill-backend flashinfer

优化二：混合缓存与 GDN 状态迁移

混合 SSM-注意力模型的分离式服务，建立在一系列连接器改动之上（见混合 SSM 分离式博客）。其中最必要的先行 PR，是把 HMA 的逻辑块映射到正确的物理显存区域，让 NIXL 只传输各层类型真正属于自己的缓存区域——把需要迁移的描述符从 4,284 个降到 1,650 个，在小规模同节点 H100 上吞吐提升约 7%。

但 Mamba 式状态在布局、大小和传输语义上都和注意力缓存不同，光有 HMA 支持还不够。核心 PR 为混合 SSM-FA 分离式加入双描述符视图和同构 TP 支持，让 prefill 和 decode 工作节点能通过 NIXL 同时迁移全注意力 KV 缓存和 Mamba 式 SSM 状态。相关跟进还包括 Mamba 的 conv 状态不同布局、异构 TP 的三读 conv 状态迁移、以及 N-1 prefill 等。

针对 Qwen3.5，NIXL Connector: GDN support (Qwen3.5)（PR #41869）这把这条路径延伸到了 GDN 层。

优化三：无竞态异步调度

「异步调度（async scheduling）」被证明是冲过 25K token/s/GPU 的关键特性之一。但它一开始根本不能用——KV 块迁移里有两个竞态条件，开着它准确率会直接崩到 0。这两个补丁把竞态修掉了：

  • 修复混合注意力模型在异步调度下的 PD 竞态（#48481）
  • 异步调度 + PD KV 消费者下，把块释放推迟到进行中的步骤结束（#45357）

性能测试：怎么跑出 25K

环境

测量在 NVLink72 互联的 GB200 集群上进行，固定 ISL/OSL = 8192/1024，模型是 Qwen3.5-397B-A17B-NVFP4。性能在固定的 decode 拓扑和常数个 decode 端点上测得：decode 侧用 1 个端点、DEP8（8 卡的数据并行 + 专家并行）；prefill 侧评估了 4 到 8 个端点，每个用固定的 DEP2 拓扑。

复现需要：最新 vLLM vllm/vllm-openai:nightly-d223c90 Docker 镜像、Dynamo 1.2.0.dev20260526、srt-slurm v1.0.32，所有配方都在 srt-slurm-recipes 仓库。

正确性验证

所有服务配置都先跑过标准 GSM8K 数学基准，5 个配置的准确率都是 88%，和聚合的 Qwen3.5 结果一致——保证性能数字是有效的。

结果

单卡总吞吐达到 25,000 token/秒。并发从 64 扫到 5120。往下不测 1–32 的低并发，因为文章专注 Pareto 曲线左侧、最大化单卡总吞吐；往上不超 5120，因为那一刻 decode 侧的 KV 缓存容量开始见底——整个测量里 decode 侧被刻意固定在单个 8×GB200 端点。想推更高并发完全可以，只是要在 decode 侧加卡。

指标数值
单卡总吞吐25,000 token/s
并发范围64 – 5120
GSM8K 准确率88%（全部配置一致）
decode 拓扑1 端点 × DEP8
prefill 拓扑4–8 端点 × DEP2

配方与最佳实践

所有配方都以 srtctl run --file <recipe>.yaml 一条命令启动。命名规则是 NxDEP2-1xDEP8（N 个跑 DEP2 的 prefill 端点对一个 DEP8 的 decode 端点），有 4×DEP2 到 8×DEP2 五个基础配置，各带派生变体。几个值得单独拎出来的设置：

  • VLLM_SSM_CONV_STATE_LAYOUT=DS——SSM 模型分离式服务的硬性要求，不设它 conv 状态迁移根本跑不起来
  • --async-scheduling——冲到 25K token/s/GPU 的关键之一，但需要包含上述竞态修复的 vLLM 构建
  • --mamba-ssm-cache-dtype bfloat16——大幅提高 decode 端点的有效 KV 缓存容量
  • --language-model-only——纯文本负载下不只关掉多模态输入，还解锁注意力层里融合的 QK-norm + RoPE + gate 路径
  • --max-num-batched-tokens 16384（prefill 侧）——即 2× ISL。prefill 端点较少时 prefill 成了瓶颈、decode 侧空转，让每个 prefill 步一次批两条完整提示，高并发下约值 +8% 的单卡总吞吐
  • --max-cudagraph-capture-size（decode 侧）——最高两个并发点分别抬到 640（cc=4096）和 768（cc=5120）
  • 前缀缓存关闭——随机数据集上没收益
  • --stream-interval 100——减少高并发的前端开销，但会把流式输出缓冲成 100-token 块，影响实测的每 token 延迟；优化 ITL/TPOT 而非聚合吞吐时要注意

文章还分享了两个很实在的调试技巧：

  • --api-server-count 1：数据并行端点下 vLLM 默认把 API server 数量设为数据并行度，超过一个会为了不报出残缺数字而关掉默认统计日志。强制设为 1 能把日志找回来——每 10 秒（可用 VLLM_LOG_STATS_INTERVAL 调）打印 prompt/生成吞吐和 KV 缓存利用率。没有这些数字，几乎定位不了各配置的瓶颈。
  • 三个环境变量：DYN_LOG=error、DYN_SDK_DISABLE_ANSI_LOGGING=1、VLLM_LOGGING_COLOR=0——大幅减少 Dynamo 的日志量并压制 ANSI 转义序列，否则日志基本没法看。

接下来往哪走

目前测量集中在 Pareto 曲线左侧、压榨单卡总吞吐。下一步计划扫出最大化单用户生成吞吐（Gen TPS per user）的分离式配置——那需要从 DEP 拓扑转向 TEP（张量并行 + 专家并行）或纯 TP，这类拓扑单用户性能更好；增加投入的 GPU 数是另一个预期会见到收益的杠杆。

核心总结

  • 成绩：Qwen3.5 分离式服务在 GB200 NVL72 上做到单卡总吞吐 25,000 token/s，全部配置 GSM8K 88% 准确率
  • 三大优化：Blackwell 优化的 GDN prefill 内核、混合缓存 + GDN 状态迁移、修掉竞态后的异步调度
  • 配方可复现：srtctl run --file <recipe>.yaml 一条命令，5 个 NxDEP2-1×DEP8 基础配置各带变体
  • 细节决定成败：VLLM_SSM_CONV_STATE_LAYOUT=DS 必设、--async-scheduling 要先修竞态、--mamba-ssm-cache-dtype bfloat16 扩容、--api-server-count 1 找回统计日志
  • 下一步：转向 TEP/TP 拓扑，从”压单卡总吞吐”转向”最大化单用户生成吞吐”

这篇文章的价值不只在那个亮眼的 25K 数字，更在于它把分离式服务里那些”关了就没法跑、开了就崩准确率”的隐蔽开关一一摊开说清了。对于要在生产里复现这个吞吐的团队，这些配方和注意事项，比数字本身更值得收藏。

原文：vLLM Reaches 25K Total TPS/GPU on Qwen3.5（vLLM）