Qwen4Exp 批次分片采样：深入 vLLM PR #61018，以及它对 Qwen 4 的说明

vLLM 拉取请求 #61018 中最能说明问题的数字是一个损失：1.5%。这是作者对自己这次改动给出的上限——在平均 42 毫秒的一步中大约节省 0.6 到 0.8 毫秒，而且是在一台他并不拥有的机器上、在一个他完全无法运行的补丁中测得的。这篇拉取请求题为“[模型] Qwen4Exp：支持批分片采样（compute_logits_local）”，于 2026-10-10 由贡献者 kimseunghyun-kr提交，向两个文件添加了三行模型代码，使 Qwen4Exp 架构能够采用 vLLM 在 8 月发布的采样路径。它是一份草稿。它包含 14 行模型代码外加 57 行测试。但它仍然值得仔细阅读，因为那三行代码所掩盖的东西是：Qwen4Exp 是 Qwen3.8-Flash-Next 内部的架构，而 Qwen3.8-Flash-Next 是该厂商于 2026-08-24 发布的 1250 亿参数开放权重模型，号称“将支撑 Qwen4 的架构的实验性预览”——而该架构纯文本部分中的一个双路径 bug，正是那种你只有通过观察服务层而非发布博文才能了解到的细节。

为了在表述框架上做到毫不含糊，因为这一点在这里很重要：Qwen 4 本身尚未发布。在 2026-09-22 的云栖大会（Apsara conference）上，该厂商公布了四个 Qwen 4 层级——Qwen 4 Max、Flash、Plus 和 27B——但没有发布其中任何一个的权重、标识符、价格、上下文长度或基准测试。以下内容没有一项构成发布。这是针对单个草稿拉取请求的、截至目前我们所知情况的梳理，其中凡是带有数字的内容，要么是你可以核实的时间戳，要么是贡献者自己键入其 PR 正文里的数字，要么是从公开模型配置文件中读出的值。

用一段话说明什么是批次分片采样

张量并行将模型的权重分散到多块 GPU 上；词表投影是整个堆栈中最宽的单个张量，因此每个 rank 通常只计算自己那部分词表切片——随后所有 rank 进行 all-gather，于是每个 rank 最终都持有该批次中每个请求的完整 logits。分片采样则将这种交换方式反转过来。它不再在各 rank 之间复制词表，而是对批次进行分片：每个 rank 采样一部分请求，各 rank 之间通过 all-to-all 交换词表切片。vLLM 自己的 CLI 文档直白地描述了这个标志——"每个 rank 采样批次的一部分，而不是每个 rank 都采样全部"——并说明了各项约束：--enable-batch-sharded-sampling 默认为 False，要求 tensor_parallel_size 大于 1、至少具有 tensor_parallel_size 个最大序列数，以及一个非负的 max_logprobs。该文档的最后一句正是这个 pull request 所依附的钩子："模型通过实现 compute_logits_local 来选择启用。"

这个功能本身并不新鲜。vLLM 已将其作为 PR #50465——"[Model Runner V2] batch-sharded sample"，作者 Giancarlo Delfin——于 2026-08-24 合并，与 Qwen3.8-Flash-Next 权重上线是同一天。当时的动机是内存和延迟：完整物化目标 logits 的开销约为 批大小 ×（投机 token 数 + 1）× 词表大小，而分片可将这一分配量按张量并行度成比例削减，同时让采样器的 top-k 和 top-p 计算并行运行。这是使其得以实现的一步，而非终点：该 PR 自身的文本就把分片的 draft-logits 列为未来工作。

为什么三行代码就是整个活儿

这才是真正的缺陷，而且它很妙，因为从代码外部根本看不见。vLLM 的 Qwen4Exp 实现以两个类的形式提供。Qwen4ExpForConditionalGeneration 是视觉语言包装器——一个加装到语言模型上的 Qwen3-VL 视觉塔——而 Qwen4ExpForCausalLM 是纯文本路径。该包装器继承 compute_logits_local，来源是 Qwen3_5ForConditionalGeneration，后者将调用向下转发到 language_model.compute_logits_local。但该包装器所指向的语言模型类从未定义该方法。

因此，这两条路径处于不同的状态。Qwen3.8-Flash-Next 的视觉语言部署可以走分片路径；纯文本部署则不行，因为封装器所委托的方法并不存在。修复办法就是一个方法，在模型文件的 NVIDIA 和 AMD 副本中完全相同：

• 该方法返回 self.logits_processor(self.lm_head, hidden_states, skip_gather=True)——该 rank 自身的词表分片，不进行 gather，也不在任何 rank 上物化完整词表。

• 它遵循了该 PR 所说的"与 Qwen3.5 和 MiniMax M3 相同的三行模式"，这一点值得停下来想一想：同一代码仓库中的另外两个模型系列早已选择加入，Qwen4Exp 只是唯一尚未加入的那一个。

测试文件是最容易检查补丁诚实性的地方，也是最容易看出其局限的地方。它只有 57 行，在 NVIDIA 和 AMD 两个模块上都做了参数化，而且不下载模型。辅助函数用 object.__new__构造该类，用 nn.Identity替换语言模型头，并安装一个假的 logits 处理器，该处理器返回其输入加一，同时记录它是如何被调用的。第一个测试断言输入 4.0 会输出 5.0，并且记录的调用带有 skip_gather=True。第二个测试把语言模型包装进条件生成类，并断言委托确实发生。这是对连接关系的一次真实验证，除此之外什么也没验证——没有内核被执行，没有跨越 rank 边界，涉及的 GPU 数量为零。

这两个事实都写在了 PR 里，而不是被埋没。测试文件自己的文档字符串把 Qwen4Exp 称作“一个仅限 CPU 的微型测试替身”。作者的验证部分指出，他在自己的 macOS 环境上根本无法导入该模型，因为transformers 的构建版本并未附带 Qwen4ExpConfig。CUDA 运行仍悬而未决。端到端基准测试——MLPerf 智能体数据集、20 个并发会话、三个 60 分钟的试验组——同样悬而未决。MTP drafter 自身的 logits 路径被标记为未检查。LoRA 已被上游的标志位拒绝，因此它属于范围之外，而非回归。还有一行披露，该草稿是在 AI 辅助下写成的，而提交 trailer 将 Claude Opus 5.5 列为共同作者——这种披露在如此规模的技术栈中本应是常态，而大多情况下却并非如此。

1.5%的估计值，以及与之相邻的测量值

贡献者的估算是基于一份nsys trace：在 16 个并发会话下，使用 Qwen3.8-Flash-Next-FP8、张量并行度为 8，并在八张 A100-SXM4-40GB 卡上进行专家并行；在 42 毫秒的 step 中约占 1.6 毫秒，经削减后约为其三分之一，端到端增益为 1.5% 到 2%。他的核心要点是这组算术——42 毫秒中的 0.6 到 0.8 毫秒。注意随之而来的限定：42 毫秒是 token 间延迟的数字，因此 1.7% 的削减就是 token 生成时间上 1.7% 的削减，而不是抽象意义上的吞吐量声明。

诚实的比较应以父功能自身已合并的数值为基准，因为这些数值是由拥有该硬件的人端到端测量出来的。在 PR #50465 中发布的 Speed-Bench 2K/2K 运行中，批分片采样将带有 DSpark、使用 7 个推测令牌且并发数为 64 的 DeepSeek V4 从 2.62 请求/秒提升至 2.66 请求/秒——吞吐量提升 1.53%——令牌间延迟中位数下降 3.09%，首令牌时间上升 1.45%。在带有 DSpark、使用 8 个推测令牌的 MiniMax M3 上，请求吞吐量上升 5.38%，TPOT 中位数下降 8.33%，从 15.61 毫秒降至 14.31 毫秒。同一方案还记录了它无济于事的情况：在并发数为 4 到 16 时，运行结果持平到略微为负，其中并发数为 16 的实验组吞吐量下降 0.54%，接受长度下降 1.89%。

这个模式才是值得记住的。当采样任务繁重、批次较宽——高并发、大量投机 token、top-k 和 top-p 真正发挥作用——时，分片采样才有收益；而当批次小到 all-to-all 纯属额外开销时，它则会带来一点成本。某个模型选择启用后 1.5% 的估计值与此一致，并不矛盾：5.38% 和 8.33% 这两个数字属于不同模型，它们有不同的投机预算，而这个 PR 中的模型有自己的配置、自己的 248,320 token 词表，以及自己的投机解码路径。

这些都没有经过审计。父 PR 的数字是某一位贡献者在单个节点上的成对运行结果；这里的冒烟测试数据是作者并不拥有的硬件上的一份跟踪记录，来自补丁的一个修订版，而他说该修订版只测量了 16 个会话。单一贡献者、单一配置的测量对于判断方向是有用信号，但作为容量规划的依据则很糟糕。这个话题之所以还值得写，原因在于方向，而不是小数点后的数值。

周围的补丁集群对Qwen4Exp有何说明

单个草案 PR 不足以构成一个故事。故事在于，Qwen4Exp 在这批改动落地的那一周已成为一个持续的服务目标，而这一簇补丁中最小的那个，正是让这一模式变得清晰可辨的补丁。在截至 2026-10-10 的七天里，vLLM 承载了来自同一位贡献者及其他人的以下改动：一条用于 Ampere 上稀疏注意力的 FP8 主 KV 缓存路径，在八张 A100 上 KV 容量提升 1.83×，在四张 RTX 3090 上提升 1.87×，在并发 16 时请求量约为 2.7×，代价是单流解码 TPOT 高出约 6%；一个针对张量并行度为 1 且启用专家并行时的 W4A4 MoE 填充问题的修复；一条 AMD 路径，可在遇到不受支持的 AITER FP8 MoE 操作时回退，并以 fp16 提供服务；一个让 PLE 短卷积状态在 align 模式下传递的修复；以及一个在 sm_80 上每个寄存器一次解包四个 e4m3 字节的解码内核。其中之一——对 H200 M=4 合并 QSA LL-GEMM 方案的重新调优——已于 2026-10-09 合并到 main。

把这份清单当作一个整体来看，它传达的信息很具体。Qwen4Exp 架构——即厂商尚未发布的那一个——正在同时针对 Ampere、Hopper、ROCm 和 fp16 回退进行调优，而该项目会为人们真正能下载到的模型提供首日支持。原因并不神秘：Qwen3.8-Flash-Next 是一个真实的、可下载的、被大量使用的模型，而它正是构建在 Qwen 4 将会采用的架构之上。Qwen 4 的权重最终是否真会以这副模样到来，尚属未知，厂商也未置一词；但服务能力边界正在公开地不断拓宽，而这种信息是可以核查的，传闻中的 10 月到 11 月窗口则不然。

一些架构形态也是公开的，任何阅读配置而非公告的人都能看到。Qwen3.8-Flash-Next 的配置列出了 248,320 个 token 的词表、48 层、512 个专家（每个 token 激活 10 个路由专家加 1 个共享专家，专家中间宽度为 640）、隐藏维度 2,560，以及原生上下文 262,144 个 token，并称可扩展至一百万。它是一个混合模型：层类型列表以三个线性注意力块与一个全注意力块交替排列，而全注意力块使用稀疏注意力路径，配有一个单头索引器，将键压缩为四分之一，并保持 2,048 个位置的预算。第 2 层有一个逐层嵌入表，一个词表规模为 2,000 万条的 n-gram 嵌入——也就是本集群中其他补丁正忙于主机暂存的 47.7 GiB 表——以及一个用于推测解码的单层 MTP 头。模型卡自己的总结是“125B 激活 6B，外加 51B n-gram 嵌入和 4B MTP”。248,320 条目的词表正是 logits 投影值得分片的原因。

这对你来说不会改变什么

值得较真，因为如此密集的补丁集群读起来可能像一次正式发布。以上内容没有一项已被合并，而且其中一部分——Ampere FP8 KV cache 相关工作——在 CI 中明确未经验证，因为 vLLM 的 CI 没有 A100。今天你无法安装任何一个已发布的 vLLM 版本，能带上 Qwen4Exp 分片采样这一可选功能。也没有任何独立基准测试衡量过 Qwen3.8-Flash-Next 在这些改动中任意一项之下的服务行为；上文引用的每一个数字都来自 PR 正文，这使其成为贡献者自行报告的、且未经过审计的数据——具体含义是没有任何第三方复现过该次运行。而开启本文的那份 PR 中的头条数字是 1.5%，这在服务栈中是实打实的收益，但并不构成改变模型选型的理由。

会改变决定的，是一次完整、经过审计的服务运行，而这样的运行目前还不存在。Qwen3.8-Flash-Next 确实存在的那些节奏测量数据，完全不属于这些补丁的范畴：该模型在 Artificial Analysis 上的智能指数为 40，远高于同等规模开放权重模型 18 的中位数，而这一数字与这里讨论的一切无关。

你今天可以调用什么，以及路由角度

对于读到这里、想要使用托管模型而不是自己动手插桩的读者来说，接下来这部分就很实用了。Qwen3.8-Flash-Next 并不在 OrcaRouter 的目录中——它不是我们所路由的 205 个模型之一，这里也没有它的托管端点。但它所预览的那个生产版本则在目录中：qwen/qwen3.8-flash，这是 Qwen3.8-Flash 的官方发布版，厂商自家的模型卡称其功能比预览版更丰富，包括默认一百万 token 的上下文以及内置工具，价格为每百万输入 token 0.15 美元、每百万输出 token 0.47 美元，按提供商标价透传，不附加任何加价。若要在同一系列内做规模对比，qwen/qwen3.8-27b 为 0.33 美元和 2.40 美元，而 qwen/qwen3.8-max 为 2.00 美元和 6.00 美元——全都能用一个密钥访问。

对于一篇关于尚未发布的架构的文章来说，有两点比平时更值得关注。第一是切换成本。如果你想在 Qwen 4 问世之前，先在自家流量上校准稀疏注意力模型的体验，你要做的对比就是按标价与 qwen/qwen3.8-flash 比较——而通过路由器来做这件事，意味着你正在测量的模型和你可能回退到的模型都位于同一个端点、同一个 SDK 和同一个密钥之后，无需再签第二份合同。第二是，这个补丁集群中的每一项服务变更都针对自托管的 vLLM。如果你没有跑八张 A100，那么 1.83× 的 KV 容量和 1.5% 的采样提升就只是你读到的东西，而不是你能得到的东西。路由端点则是无需构建步骤就能获得这一切的版本：当某个提供商性能下降时自动故障转移，以及一套路由 DSL，让你在自己确实有硬件可供测量时，能把托管调用与自托管调用放在同一个端点中。

最不该做的一件事，就是把这篇文章当作等待 Qwen 4 的理由。没有日期。没有价格。真正的成品也没有参数量数字——上面那些数字描述的是预览版本，而非最终产品。真正存在的，是一个正在公开筹备的推理服务栈，服务于一种目前只能以预览形式下载的架构。

简短版本

三行代码填补某个模型文件中纯文本路径与视觉-语言路径之间的缺口，本身并不算新闻。这种补丁如果有人有时间审查，很可能会被埋进某个合并提交里；它也很可能被并入更大的改动，或者干脆被关闭——PR 上引用的 vLLM 机器人自己的智能体指南，就指示 AI 辅助贡献者在其工作缺乏显著收益时关闭它，而 1.5% 正是会招来这个疑问的数字。真正让它值得你关注的是它所记录的东西：一张含 2000 万条目的 n-gram 表、一个 512 专家的 MoE 且每个 token 激活十个专家、线性注意力与压缩稀疏注意力的混合架构、一个投机头——所有这一切都在 NVIDIA 和 AMD、从 Ampere 到 Hopper 的硬件上进行调优，而承载它的产品尚未问世。如果你关心 Qwen4 的服务边界，那么 PR 正文正是它当前真实规格所在之处。如果你想今天就调用一个模型，Qwen3.8-Flash 才是真正已经就位的那个。

一个 API 覆盖 200+ 模型，自动故障转移，路由 DSL。探索 OrcaRouter 模型目录