Qwen 4 泄露：SGLang 对 Qwen4Exp 预填充进行分片，TTFT 提速 18%，每块 GPU 省回 1 GiB

今天凌晨 UTC 03:47（2026 年 10 月 8 日），SGLang 仓库中开出了一个拉取请求，它承诺了一样 Qwen 4 的任何公告至今都未能给出的东西：一个数字。它的标题是feat(qwen4-exp): enable LayerNorm sequence parallelism for GR and PLE，并且在四块 H20 GPU 上以 FP8 运行开放权重的Qwen3.8-Flash-Next检查点时，其作者报告称：在 32K 输入下首 token 时延降低 17.7–18.4%，在 235K 输入下降低 14.6–14.7%，每块 GPU 峰值内存回收约 1 GB，输入吞吐量最多提升 22%。Qwen 4本身——即厂商在 2026 年 9 月 22 日杭州云栖大会上点名却并未发布的那个家族——仍未发布，没有权重、没有标识符，也没有价格。如今唯一实例化 Qwen4Exp 架构的模型是 2026 年 8 月 26 日发布的 Qwen3.8-Flash-Next，而它托管的同门兄弟Qwen3.8-Flash才是 API 调用者真正能够触及的版本。因此，请把下文当作它本来的样子来读：一位工程师的成对测量数据，附在一个公开、草稿状态、尚未合并的拉取请求上，讨论的是一个尚不存在的模型家族的推理服务边界。

先说来源，因为这是一篇爆料性质的内容，而这层区分确有实际作用。线索是 sgl-project/sglang#43048，由 GitHub 账号 shiyang814-cpu于 2026-10-08 03:47 UTC 提交，最后触及时间为 03:55 UTC，目前仍标记为 draft，没有记录到批准审查，也没有合并。它改动了六个文件——两个测试文件、Qwen4Exp 模型文件、LayerNorm-SP 模块、一个层边界工厂和一个参数组钩子——共 +345、−50 行。下文的每一项性能数据都来自该 PR 描述，是作者自己做的 OFF/ON 配对测量，尚未被任何人复现。分支顶端该修订版本上的三次 CI 运行均被标记为失败。这里没有任何已交付的能力。

拉取请求实际改变了什么

序列并行不是模型改动，也不是新增能力。它只是把少数层做算术运算的位置重新接线。它的血统可以追溯到 Megatron 风格的序列并行——也就是 arXiv:2205.05198 里的那个技巧——而 SGLang 已经内置了它：该模块自己的 docstring 就解释了它所复用的机制：在纯张量并行下，行并行的 all_reduce在代数上等价于reduce_scatter后接一次all_gather。因为这两个集合通信操作搬运的字节数与它们所替代的那单个 all_reduce完全相同，所以按这种方式拆分操作完全不会带来额外的通信量。它换来的是让归一化和残差区域运行在 序列分片的激活上——每个张量并行 rank 持有 1/tp的 token 行——从而削减了长上下文 prefill 需要一直保活的瞬时激活内存。

这个特定拉取请求所做的是，将那条现有路径从它经过验证的架构扩展到 Qwen4Exp 架构。在预填充期间，Gated Residual 和 Per-Layer Embedding 激活会在 TP 组内沿 token 维度保持分片。在 attention、GDN、QSA 以及 Mixture-of-Experts 块运行之前，完整的 token 行会被 all-gather 回来，现有的全行张量并行计算会在共享回退背后保持不变地运行，随后 reduce-scatter 会汇总部分贡献并恢复每个 rank 的分片。解码阶段完全不会触及这条新路径。该功能通过已经存在的选项 — --enable-layernorm-sp — 来启用，无需 Qwen4Exp 专用标志；并且在缺少该标志时，代码的行为与之前完全一样。

为什么 Qwen4Exp 才是所需的架构

这件事对 Qwen4Exp 特别重要、而非对每个模型都同等重要，原因就在该架构自身的设计之中。Qwen3.8-Flash-Next 会对所有 token 行应用门控残差投影，且是在每一个解码器层中——该配置声明了四条残差流，并在 48 层上采用 320 的瓶颈秩——而逐层嵌入（Per-Layer Embedding）在此基础上又额外增加了一次逐 token 行复制的投影。在张量并行下，这两种操作都会在每个 rank 上被完全相同地复制，因为它们自身并不携带可强制切分的、按 TP 分片的权重矩阵。对其 token 维度进行分片可以直接消除这部分被复制的工作，而正如该 PR 的动机部分所言，这一切是在保留现有张量并行布局以及注意力、GDN/QSA 和 MoE 的归约语义的前提下实现的——正是这一点让该改动称得上安全，而非只是巧妙。

值得直白地说清楚，这对读者意味着什么。这个 PR 有意思的地方不在于 SGLang 正在变得更快，而在于 Qwen4 架构带有随token 数量而非参数量扩展的逐层成本，而这些成本恰恰会在长 prefill 上咬人。那是一种设计指纹，也是规格表从来不会提及的东西。

测量的差值

作者基准测试固定一种配置并切换该标志：四块 NVIDIA H20 GPU、Qwen3.8-Flash-Next-FP8、张量并行 4 与专家并行 4、分块预填充大小 8192、FlashInfer 线性注意力预填充与解码后端、OFF 和 ON 使用相同的服务器配置、交替进行 OFF → ON → OFF → ON 服务重启，以及带有预热请求的固定 token 输入。下文的每个数字均来自该设置，且未经审计：

• 32K 输入，批大小 1 — TTFT 提升 17.72–18.36%，端到端延迟约 16%，输入吞吐量约 20%

• 235K 输入，批大小 1 — TTFT 提升 14.63–14.71%，端到端延迟约 14%，输入吞吐量约 17%

• 32K 输入，批大小为 4 —— TTFT 提升 18.74%，端到端延迟 18.14%，输入吞吐量 22.14%

• 峰值内存 — 每块 GPU 降低约 1.0 GiB

• 解码，批大小 1 —— 每个输出 token 的时间基本不变

最后一行最值得读两遍，而作者对其原因直言不讳：这项优化仅对预填充启用，因此单流解码无法从中获益。批大小为 4 时每 token 耗时的改进，如果出现，反映的是并发长预填充带来的调度延迟减少，而不是解码内核变得更快。如果你原本希望这是一个吞吐量提升的故事，那并不是——它关乎首 token 延迟和内存，而这两个约束决定了一个 235K token 的请求究竟能否被服务。

他们必须先修复的布局错误

这个拉取请求中最具信息量的部分并不是加速比表格，而是关于PLE物理行布局的那一节，因为它揭示了Qwen4Exp服务栈至今仍然搞错的地方。

Per-Layer Embedding 在固定的物理 CUDA-graph 桶上运行，而该桶中可能只有一段前缀行保存真实 token。因此，填充需要在序列被分片之前应用，而不是之后。在 235K token 请求的最后一个分块中，作者给出的数字是：在 TP 4 下，8,192 行的物理桶内处理了 5,624 个 token，而唯一正确的布局是 rank 0 持有 2,048 个有效行，rank 1 持有 2,048 个有效行，rank 2 持有 1,528 个有效行加 520 个填充行，rank 3 持有 2,048 个填充行。先对 5,624 个已处理行进行分片——这种显而易见的实现——会在全局连续的有效范围之间插入填充，并破坏结果。作者记录称，一次真实的 235K OFF/ON 测试只产生了相同的 16-token 贪心输出，在该布局被修复之后

那是一个小细节，却影响重大。SGLang 中的 PLE 路径是最近才加入的，新到这种形态的 token 排序 bug 仍然可被触发，而发现它的人当时正在编写序列并行扩展。针对这一架构的 Day-zero 推理服务支持尚未完成；它正由贡献者们在公开场合积极构建，一次一个布局。

你付出的代价：约束条件

一个只对某些部署有帮助的标志，只有在你知道是哪些部署时才有用。PR 明确说明了它的要求，而不符合这些要求的配置会在参数验证期间失败，而不是静默降级：

• 张量并行大小必须大于 1——单 GPU 部署毫无益处，因为没有 rank 可供分片

• 专家并行大小必须等于张量并行大小

• 流水线并行大小必须等于 1

• 必须禁用数据并行注意力

• 投机解码必须禁用

最后一项约束是背后有真正决策的那一项。对于每个 token 激活约 6B 参数的稀疏模型，推测解码是少数几个能加速 解码的杠杆之一，而此功能明确关闭了这个杠杆，以换取预填充的收益。如果你的工作负载是长提示、短输出——文档和代码库分析、视频摘要、一次读取的大上下文——这笔取舍显然划算。如果你的工作负载是短提示、长生成，那么你放弃的正是原本在帮助你的东西，换来的却是一个并不适用于你的数字。专家并行等于张量并行的要求是另一个需要注意的点：这意味着 MoE 分片几何结构必须与 TP 几何结构完全对齐，这排除了几种在其他情况下合理的多节点布局。

这对Qwen 4的时间线意味着什么

换个角度看这个 diff，你看到的是一份日历。SGLang 在主分支上的 LayerNorm-SP 模块，如今维护着一份显式白名单，列出该特性已经过验证的架构；截至本文撰写时，这份白名单中恰好只有一条记录——Qwen3ForCausalLM——如果传入该标志，其他任何架构都会在构造阶段被拒绝。因此，把 Qwen4Exp 加入这条路径，并不是对一个成熟抽象做的小修小补；这是 Qwen4 架构第一次被接入一项比它早了好几代的优化。

把这一点同公开记录对照起来，整体图景就是自洽的。厂商于2026-09-22宣布Qwen 4正在训练中，并预告了四个层级名称——Qwen 4 Max、Qwen 4 Flash、Qwen 4 Plus和Qwen 4 27B——却没有为其中任何一个附上规格。共享同一架构的开源权重预览版Qwen3.8-Flash-Next，自2026-08-26起即可下载。自那以后三周里发生的事，正是你在“训练中”与“发布”之间会预期看到的：引擎作者们在磨合运行时，好让首日支持是实打实的，而不是名义上的。一个让某项服务优化能在该架构上生效的拉取请求，于2026-10-08上午开启且仍处于草稿状态，它比任何人抛出的日期都更能说明Qwen 4距离可服务还有多近。它显然也不是发布日期——该标志默认关闭，改动尚未合并，而且它做基准测试的模型是预览版，而非Qwen 4。

你今天可以呼叫的对象

这一切都不改变今天下午实际可用的东西。Qwen3.8-Flash-Next 是真实存在的，其权重已在 Hugging Face 上，你可以自行托管——但它不在我们的目录中，我们也不会假装它在。我们实际提供的层级是qwen/qwen3.8-flash，这个托管版本的同系列模型运行相同的 Qwen4-preview 架构，具备 100 万 token 的上下文窗口，支持文本、图像和视频输入，价格为每百万输入 token 0.15 美元、每百万输出 token 0.47 美元、每百万缓存读取 0.0184 美元。这是按 0% 加价率转嫁的标价，因此当供应商调整价格时，你发票上的数字当天就会随之变动，而不是等到某个中间商重新发布价格表时才变。

这里还有第二个不那么明显的理由，让你需要关注路由层。本文所讲的一切，都围绕一个尚未验证的预览版和一个草稿补丁——这类东西你只想拿来测试，而不愿押上一条生产路径。这正是故障转移的用武之地：把预览版放在与你已经信任的模型相同的密钥之后，观察它在你的流量上的表现，当提供商出现波动或端点不存在时，让请求回落到已知可靠的路径。一个 API 即可接入 200 多个模型，一套凭证，无需再签第二份合同，就能判断一个新架构是否值得你关注。

从这一点看，有两件事值得关注，而这两者我们都无法预测。第一，这个补丁究竟会不会被合并：它是一份草稿，来自一个在该仓库中没有既往历史的贡献者账户，涉及六个文件的改动，却有三轮 CI 运行失败；而且 PLE 行布局工作的反复变动表明作者仍在迭代。第二，白名单会不会扩大——如果 Qwen4Exp 加入 Qwen3ForCausalLM 成为经验证的架构，那么这就不再是泄漏，而会成为 Qwen4 系列模型在长上下文场景下的默认服务方式。在上述任一情况发生之前，请把 18% 当作关于运行时走向的承诺，而不是一个你能租用的数字。