Qwen 4 QSA 迎来解码上下文并行：深入解读 vLLM 针对 Qwen3.8-Flash-Next 的草稿 PR

2026-09-29，vLLM 仓库中出现了一个标题为“[Model][DCP] Support Qwen4Exp QSA”的草稿拉取请求；对于它所描述的模型，这个请求给出了整个月里任何人公布过的最具体的服务性能数字：在四块 GPU 上对 Qwen3.8-Flash-Next 进行的成对运行显示，KV token 容量从 9,759,529 增至 17,603,636，最大并发数从 37.23× 增至 67.15×，首 token 时间从 1,869 ms 降至 767 ms。Qwen3.8-Flash-Next 是开放权重、1250 亿参数的混合专家（MoE）预览模型，其 Hugging Face 模型卡将其描述为“Qwen4 架构的预览版”；该拉取请求为这一架构赖以构建的稀疏注意力路径加入了解码上下文并行。Qwen4 本身——厂商在 2026-09-22 云栖大会上公布的 Qwen4 Max、Flash、Plus 和 27B 档位——仍未发布，没有权重、没有标识符、没有价格，也没有日期。所以，请按它的本来面目来理解：不是发布，不是基准测试，而是一件工程产物，它告诉你 Qwen4 的服务能力边界在该系列尚未问世之前正如何被拓宽。

这是一篇“截至目前我们所知”的报道，信源的重要性比往常更高。该拉取请求是一份草稿，处于开放状态，尚未合并——vllm-project/vllm#59279，由 NVIDIA 软件工程师 Sungsoo Ha 于 2026-09-29 提交，至今仍处于草稿状态。下文中的每一个数字都是作者自己的配对测量结果，报告在 PR 正文中，取自同一工作的较早修订版本。此处没有任何内容经过独立审计，也没有任何内容进入正式发布，而作者附上的注意事项足够重要，因此下文为其单独设了一节。

拉取请求实际改变了什么

解码上下文并行——DCP——是一种推理服务技术，而不是对模型的改动。DCP 不是让一个 GPU 组持有整个 KV 缓存，而是把该缓存拆分到各个 rank 上，因此每个 rank 只读取自己那一片上下文，而注意力结果则在最后跨 rank 合并。关键在于容量：缓存被分区后，同一硬件上的部署可以承载多得多的并发长上下文流量，而这正是当每个请求都携带 25 万个 token 时最要命的约束。

复杂之处在于，Qwen Sparse Attention——QSA——并不是一个普通的注意力层。正如 Qwen3.8-Flash-Next 模型卡所说明的，一个轻量级索引器会以 4 的压缩比将键压缩成微块，对它们评分，并保留最佳的 512 个块，大约 2,048 个 token 位置，而最终的 softmax 和值聚合仍然在未压缩的 K 和 V 上运行。这意味着 QSA 比 KV 缓存携带更多状态：有主缓存，还有索引器维护的选择器缓存和侧缓存。vLLM 中的通用 DCP 实现对这些一无所知。

根据其描述，#59279 的作用是让 DCP 了解 QSA 特有的部分：

• 每个 rank 读取主 KV 缓存中属于自己的那部分，而 QSA 的选择器与侧缓存则在各 rank 之间保持复制，而非分片。

拆分读取后，注意力结果会跨 rank 进行合并。

• 选择器和主 KV 缓存被保存在同一个缓存组中，因此它们不会彼此偏离。

• 合成 V2 批次被禁止写入 QSA 侧缓存。

最后那对细节才是有意思的部分，如果你在意的是正确性而不是吞吐量。一个分片注意力缓存如果悄悄与复制型选择器不一致，属于那种不会崩溃、而是在长上下文下表现为精度缓慢衰减的 bug；而这项改动明确要求让两者保持同步。作者还说明使用了 AI 辅助，并将 Codex 署名为共同作者——这一点值得直说，因为在这样形态的草稿 PR 中，问清谁写了什么是一个合理的问题。

成对的数字，以及它们的获取方式

该测试计划足够具体、可供核查，这也是其结果值得引用的原因。两组均在四块 GPU 上以张量并行度 4 并启用专家并行来服务 Qwen/Qwen3.8-Flash-Next-FP8，参数为 --gpu-memory-utilization 0.90，并开启前缀缓存。两组之间唯一的差异在于 --decode-context-parallel-size：DCP=1 时省略，DCP=2 时设为 2，并在两组之间重启，使基准测试从冷缓存开始。负载为 128 个用户下持续 900 秒的 AgentX 256k trace；准确率采用 EvalScope 的 GSM8K 加上已检入的 MRCR 评估器，每组运行六次，并丢弃重启后的首次运行结果。

所报告的吞吐量差值，DCP=2 相对于 DCP=1：

• KV 令牌 — 9,759,529 对比 17,603,636，缓存容量提升至 1.80 倍。

• 最大并发数——37.23× 对比 67.15×，以及 1.80×。

• 每秒请求数 — 1.69 对比 2.30，1.36 倍。

• 输入令牌/秒 — 128,730 vs 179,702，1.40×。

• 首个 token 耗时 — 1,869 毫秒 vs 767 毫秒，低 2.44 倍。

• 令牌间延迟 — 43.48 ms 对比 26.27 ms，降低至 1.66 分之一。

• 稳态下前缀缓存命中率——67.85% 对 88.98%，提升了 21.1 个百分点。

准确率（以预热后各次运行的均值 ± 样本标准差报告）基本持平：在 DCP=1 时，MRCR 聚合值为 0.8630 ± 0.0005，而 DCP=2 时为 0.8697 ± 0.0153；GSM8K 则为 0.9788 ± 0.0020 对 0.9790 ± 0.0016。2-needle 和 4-needle 的 MRCR 样本在两组中分别固定为 0.9960 和 0.9906，因此所有运行间波动都来自 8-needle 样本——而且有一次 DCP=2 聚合运行得分为 0.8970，其余四次则介于 0.8620 和 0.8632 之间。这是真实的离散，不是可以挥手带过的噪声，而且它被写进了 PR，而不是被粉饰过去。

这些数字所无法确立的

这个注意事项写在 PR 文本中，而且绝非小事。配对的 AgentX 与准确率结果是在 较早的 QSA DCP 修订版本上测得的，使用的是基于提交 3df4ae153eb 的 vLLM nightly。拉取请求中的最终干净提交包含后续的 QSA 本地化内核修复，并已通过有针对性的 B200 验证——但完整的 AgentX 和准确率评估尚未在该确切源代码上重复进行。换句话说：吞吐量说法和实际交付的 diff 并不是同一个产物，作者本人也这么说。

除此之外，通常的严谨要求依然适用，而且在这里尤其必须严格执行。这些数字来自单一配置、单一贡献者、单一四 GPU 环境。它们与厂商关系密切，而非中立：框架贡献者衡量框架改动是正常且有用的，但这并不是独立审计，也没有第三方复现过该运行。目前没有任何已发布的 vLLM 版本包含这项更改，因为该更改尚未合并。而且 DCP=2 是对某一特定形状的两路切分——这些增量并不预示 DCP=4 或 DCP=8 会有怎样的表现，PR 中也没有任何内容这样声称。

为什么一篇关于未发布架构的 serving PR 仍然值得你花时间

显而易见的反对意见是：标题中的模型并不存在，那为什么还要在意？因为被调优的并不是 Qwen 4，而是 Qwen3.8-Flash-Next，而这个模型确实存在——阿里巴巴于 2026-08-24 发布了它，它是一个 125B 参数的 MoE，激活参数为 6B，拥有一个 510 亿参数的 n-gram 嵌入表，一个用于推测解码的 4B MTP 头，48 层按三个 Gated DeltaNet 块后接一个 QSA 块的方式重复十二次排列，512 个专家，其中 10 个路由专家和 1 个共享专家处于激活状态，原生上下文为 262,144 个 token，模型卡称其可扩展至 1,000,000。它是以开放权重形式提供的 Qwen4 架构参考实现，而 QSA——这个拉取请求正在教 DCP 对其进行分片的微块稀疏注意力——是它最独特的部分。

这些数字所描述的是：当你不再把 262K 上下文看作必须由单个 GPU 组整体承载的东西时，会发生什么。KV token 容量与并发度提升 1.80×，这不过是将缓存一分为二后的算术结果，也是这份清单里最不令人意外的一项。更值得关注的是延迟方面的数字：在相同提供负载下，首 token 时间降低 2.44×，token 间延迟降低 1.66×，同时稳态前缀缓存命中率还提升了 21 个百分点。这说明 DCP 路径并非以延迟为代价来换取容量——在这组配对运行中，它两者兼得。对于任何要用超长系统提示词来服务 agent 流量的人而言，这正是那种真正重要的变化形态，因为长上下文下的前缀缓存行为，往往正是长上下文吞吐量悄然崩塌的地方。

而这并不是一个孤立的补丁。同一周还产生了一批 Qwen4Exp 引擎工作：#59214 为 B200 形状添加 SM100 低延迟解码 GEMM 方案，#59010 为 Hopper 上的 QSA 路径添加 SM90 原生稀疏预填充内核，#58977 涵盖 BF16 INC PLE 嵌入，而 #58961——真正已合并的那个，于 2026-09-28——修复了一个被 QSA 键视图一直保持存活的 profiling KV 缓存。放在一起看，它们构成了 Qwen4 架构的服务轮廓：该架构正公开地、在运行时中被构建，早在该系列发布前数月。如果你正在为 Qwen 4 做规划，有用的信号不是发布日期——并不存在发布日期——而是内核和缓存布局已经就你必须如何服务它所作的假设。

你今天可以呼叫的对象

如果你想针对这个 PR 所涉及的架构测试长上下文行为，那么该用的模型就是阿里实际提供服务的 Flash 层级。Qwen3.8-Flash——基于 Qwen3.8-Flash-Next 构建的生产部署，具备 1,000,000 token 上下文和 131,072 token 最大输出，接受文本、图像和视频输入——已经上线，而且它是如今真正运行 Qwen4Exp 架构的那个模型的一个端点，以 qwen/qwen3.8-flash 的形式列出，每百万输入 token 0.15 美元、每百万输出 token 0.47 美元，缓存读取为 0.0184 美元。由于这些是供应商标价，在我们这边不加价直接透传，因此该模型的供应商价格或限额若有变动，会在公布当天就传达到你这里。

两个诚实的限定条件。第一，Qwen3.8-Flash-Next 本身——也就是那份拉取请求测试计划中的 FP8 权重，即你要在本地复现上述任何测量结果都需要用到的那份权重——并不在我们的目录中；所服务的 Flash 层级是 QwenCloud 生产线，而非原始预览检查点。如果你想要运行 PR 中的确切配置，那你就得在四块 GPU 上自托管。第二，DCP 这项改动尚未合入，因此今天你在任何地方能调用的东西都没有在运行它。所服务的层级能给你的，是一种用以查明你的工作负载究竟是否契合 DCP 所解决的那个问题的方式：如果你的提示词很长、具有智能体特性且前缀密集，那么 1.80× 的容量提升和前缀缓存差值，就是你应该在自己的调用轨迹中重点关注的数字。

而如果你感兴趣的部分不是某一个模型，而是切换的问题——在 Qwen 4 系列仍未定名的当下，该基于哪一档来构建——那这是路由问题而非服务问题，而 一个 API 接入 200+ 模型 正是让你在该系列最终落地时无需第二份合同或改动代码就能保留这一选项的方式。

值得直接回答的问题

#59279 是否意味着 Qwen 4 已经发布，还是即将发布？

不。这个拉取请求针对的是 Qwen3.8-Flash-Next 中所实现的 Qwen4Exp 架构，而该模型是阿里巴巴于 2026-08-24 发布的。Qwen 4 系列——Max、Flash、Plus 和 27B——于 2026-09-22 在 Apsara 的舞台上被命名，并被列入公司路线图，其后续产品线预计参数规模为 5 万亿到 10 万亿，而它至今仍没有模型卡、没有权重、没有 API 标识符、没有上下文窗口、没有价格，也没有发布日期。一个为预览架构添加并行模式的框架 PR，是朝着把 Qwen 4 服务好迈出的一步。它不是朝着 Qwen 4 存在迈出的一步。

解码上下文并行与张量并行有何不同？

它们切分的是不同的东西，也会以不同的方式失败。张量并行把每一层的权重和计算划分到多个 GPU 上，因此每个 rank 都参与每个 token 的计算，但看到的是完整序列。解码上下文并行切分的是 KV cache本身，因此每个 rank 只持有并读取上下文的一个切片，之后再把各部分的注意力结果合并起来。TP 解决的是装得下模型的问题；DCP 解决的是装得下上下文以及随之而来的并发流量的问题。这一区别正是这个 PR 并非易事的原因：QSA 的选择器和附属缓存不能像主 KV cache 那样简单地分片，因此这项改动必须对其中一个进行分片、对其余的进行复制，然后还要证明两者保持一致。

如果我今天通过托管 API 调用 Qwen3.8-Flash-Next，是否已经能得到这些数字？

不，而且这一差距由三部分组成。这个改动尚未合并，因此没有任何已发布的 vLLM 构建包含它。即便合并了，服务提供商也必须采用该构建，并选择以大于 1 的 DCP 规模运行——这是一种服务端配置，而非默认设置。而且这些实测差值来自该补丁的较早修订版，而非最终提交；作者表示，最终提交目前只经过了针对 B200 的集中验证。请把所报告的差值视为有充分记录的上限，代表该方法在某一种配置下能带来的收益，而不是你本周就能租用的任何端点的规格说明。

悬而未决的问题

值得关注的不是这份具体草案是否会被合并——它很可能会以某种形式合并，因为它新增的针对 QSA 的缓存处理是一个真实缺口，而非偏好问题。值得关注的是，最终提交是否会得到与中间修订版相同的配对评估。一项服务变更，如果其吞吐量声明来自一个构建，而正确性声明来自另一个构建，那么目前它只是一个论证充分的提案，而非实测结果；而 8-needle MRCR 样本上的准确率差异足够大，以至于在已发布源码上重跑会是任何人能就它发布的最有用的一件事。在那之前：方向清晰可辨，账目尚未结清，而开放权重中唯一一个 Qwen4 架构模型仍是 8 月那个。