Qwen4-Exp QSA 登陆华为昇腾：深入解析 SGLang 可选启用的 CANN prefill PR

2026-09-30，一位贡献者提交了 SGLang 拉取请求 #41855，标题为“[NPU] 为 Qwen4-Exp QSA 预填充添加可选的 CANN 稀疏注意力”，而有趣之处不在算术，而在硬件。Qwen4Exp 架构现在为华为 Ascend 910C 加速器提供了一条手写的稀疏注意力路径，位于一个默认关闭的开关之后，且在一个尚未合并的草稿拉取请求中——而该架构名称所属的模型 Qwen4-Exp，从未以任何形式发布。唯一以开放权重承载这一架构的检查点仍然是 Qwen3.8-Flash-Next，即厂商于 2026-08-24 在 Hugging Face 上发布的 1250 亿参数专家混合预览版，其模型卡实际上将其架构声明为qwen4_exp。Qwen 4 本身——厂商于 2026-09-22 在云栖大会上公布的 Max、Flash、Plus 和 27B 各档——仍然没有权重、没有标识符、没有价格，也没有日期。因此，这是一篇关于工程产物、而非发布的“截至目前我们所知”的文章：又一家厂商的服务栈悄然认定，一个尚未发布的架构值得提前支持。

拉取请求实际添加了什么

这一改动有意做得很小，也有意收得很窄。五个文件，一次提交，与提交 b87a241 的主分支相比新增 +355 行，带有 SGLang npu 标签。作者 w1ida，一开始就说明了意图：为 Qwen4-Exp QSA 的 eager prefill 提供一条可选的 CANN 主注意力路径，构建在 torch_npu.npu_sparse_flash_attention 之上，同时索引器、Top-K 选择、token 预算和 KV-cache 内容都完全保持原样。

它用来达到这一点的技巧值得用一段来说明，因为这解释了为什么这是一个布局适配器，而不是一个新的注意力内核。对于已经旋转过的 Q 和 K，该路径将缓存打包为 C = [K, V]，并将查询打包为 Q' = [Q, 0]。乘积 Q' @ C.T 然后等于 Q @ K.T，而由于填充后的查询不贡献任何内容，softmax(scale * Q' @ C.T) @ C 会返回 [P @ K, P @ V] 的堆叠结果——因此 V 那一半可以被切出来。用作者自己的话来说，这是“一种注意力布局嵌入，而不是对模型注意力的改动，也不是低秩 KV 压缩。”每个 KV 头在原生 MLA 布局中成为一个独立的批次，原始 D256 缩放保持不变，并且辅助 RoPE 被置零。

操作细节与数学同样重要：

• 启用方式 — SGLANG_NPU_QSA_NATIVE_PREFILL=1，默认关闭。仅普通ForwardMode.EXTEND 才会启用；解码、推测模式、混合前向和图捕获均仍走现有路径，且图捕获会完全绕过该适配器。

• 硬件与 dtype——BF16，头维度 256，Ascend 910C（Ascend910_93*），已针对 CANN 9.0 和 torch-npu 2.10 进行测试。任何不受支持的 dtype 或形状都会静默回退到参考路径。

• 头形状 —— 支持的本地（Q 头、KV 头）对为（16,2）、（24,2）、（12,1）、（6,1）以及（3,1）。CANN 会直接拒绝 query/KV 比例为 12 的情况 —— 它的 tiler 只接受 2 的幂 —— 因此头数会被按 12→16、6→8 或 3→4 填充，多出的输出则被丢弃。这是整个 PR 中最明显的迹象，表明硬件在设计时并未考虑稀疏注意力的头比例，而适配器只是在吸收这种不匹配，而非让模型为此改变形态。

• 尺寸边界——仅打包被引用的物理缓存范围，上限为 262,144 个 token，作者计算出在两个 KV 头下，打包后的 BF16 K/V 张量至多为 512 MiB。内部的 -1 填充会被检测并路由到回退路径，因为 CANN 要求连续的有效的槽位；完全被掩码的行保留现有的零输出约定。

• 为什么仅限预填充——范围与布局检查会将两个标量拷贝到主机，而临时副本加上原生工作区会占用内存。正是这种同步使得该路径仅限用于 eager 预填充，并在捕获期间保持关闭。

九项通过的测试，以及一个并非来自这个分支的速度数字

正确性证据具体且可复现，这比大多数内核 PR 所能提供的都更多。作者报告在 Ascend 910C（Ascend910_9362）上，使用 CANN 9.0 和 torch-npu 2.10.0，9 项测试在 40.772 秒内全部通过，且无需 checkpoint：以非零随机 BF16 Q/K/V 对照由相同 BF16 输入计算出的 FP32 CPU 参考结果进行验证；宽度为 1/63/64/65/2051 的无序物理槽位；默认与显式 scale；完全掩码的行；全零行；零选择宽度；非连续张量；压缩比为 4 的因果尾部余数 0 至 3；带共享前缀的双请求物理映射；缓存内容复用；以及 1 和 257 个 query 行下的 Flash-Next 局部头形状。

重点用例是一次长预填充：7,810 个查询 token 对 65,536 token 的缓存，每个查询有 2,051 个选中槽位，所有输出均为有限值，并将八个抽样行与 FP32 参考值进行比较。观察到的相对 L2 误差在 head 形状较小的用例中达到 0.209%，在抽样的长预填充行中达到 0.231%，相对于测试门限 atol=0.025、rtol=0.025 以及相对 L2 低于 0.008，并要求空行必须精确为零。该次运行的 NPU 已分配内存峰值标称为 1,042.7 MiB —— 作者将其标注为 PyTorch 分配器指标，而不是板载 HBM，也不是完整模型内存，这正是应当附上的恰当限定说明。

然后还有一个将会被引用、却不该被引用的数字。该 PR 附有一张速度表，显示现有本地注意力路径为每秒 2,270.79 个新 token，而原生打包主注意力为 3,890.06——提升 1.713 倍 / +71.3%，平均首 token 时间从 3.109 秒降至 1.812 秒。作者明确指出，这些是历史原型测量数据，于 2026-09-29 在适配后的 Whittle-Next-26B-A3B 检查点上取得，在 CANN 9.0 下的 910C 上以 TP1、W8A8 权重和 BF16 注意力运行，使用官方 sglang.bench_serving 测试框架，并发为 1，共六个请求，每个请求一个输出 token，并从新 token 吞吐量中排除了 36,096 个缓存前缀 token。它们并非对 PR 中上游分支的基准测试，原始 serving JSON 产物不在检出内容中，而且后来约每秒 5,000 token 的本地结果使用了额外的原生 indexer 和 block4 工作，这些工作明确未归因于本次更改。作者还指出，适配检查点的 indexer 权重是惰性的，其预算与原始版本不同，因此这些都不能作为关于 indexer 正确性或全预算生成质量的证据。

先澄清一下命名问题，因为这会误导任何搜索该检查点的人：基准模型是贡献者自己改编的产物。另外，“Whittle-Next”也是一个由第三方 Hugging Face 账号发布的公开系列名称，该系列包含基于 Qwen3.8 衍生的 MoE 微调模型，其中包括 9 月上传的一个 26B-A3B 变体。它们不是本 PR 所针对的 Qwen4Exp 模型，也不应被解读为支撑 1.713× 这一数字的基准配置。

另外两点注意事项来自作者，而非出自我本人。完整的服务集成、分布式张量并行以及完整的 Qwen3.8-Flash-Next 模型尚未在该分支上得到验证；贡献者表示，在讨论集成与依赖问题期间将其保持为草稿是有意为之，甚至在 PR 正文中询问该适配器应归属于 SGLang 还是单独的 sgl-kernel-npu仓库。CI 也不干净——PR 正文的状态块显示 PR Test (Base)、PR Test (Extra) 以及 AMD ROCm 10 运行均出现失败。上文所述的正确性属于算子级别；PR 中没有任何内容声称在集成栈上取得了端到端的精度或吞吐量结果。

为什么 QSA 是最棘手的部分，用数字来说明

Qwen 稀疏注意力并非传统的注意力层，已发布的配置说明了为何加速器供应商必须为其编写定制路径。从 Qwen3.8-Flash-Next 配置来看：48 层按十二次重复排列，每次重复由三个 Gated DeltaNet 块后接一个全注意力块组成，full_attention_interval 为 4，隐藏大小为 2,560，注意力头维度为 256，24 个查询头对 2 个 KV 头，RoPE 维度为 64。使注意力稀疏的索引器是一种多查询结构：4 个查询头共享 1 个键头，头维度为 128，压缩比为 4，每个查询的预算为 2,048 个选中的微块。

该预算是 PR 保持不变的部分。稀疏块大小保持为 1，稀疏模式保持为 0，注意力模式保持为 2，所选 token 接口保持不变；原生 indexer 和 block4 优化被明确排除在范围之外。因此，这是一个挂在现有选择机制之下的适配器，而非对 QSA 的重新实现——这也正是作者能够可信地声称 KV 缓存内容未发生变化的原因。

模型卡直白地阐述了其设计意图：QSA 并非逐个选择 token，而是在微块（micro-block）层面运作以降低长上下文延迟，而正是这种微块粒度，连同随之而来的复制式选择器状态，恰恰无法干净地映射到任何一家厂商芯片上的通用分页注意力内核之上。

这在 Qwen4Exp 服务化建设中的位置

单独看，某个加速器上的一个草稿 PR 不过是件稀罕事。对照九月的其余时间来看，它就是一个平台的第四或第五块木板，而这个平台正在它所服务的产品家族尚未存在之前，就被公开地拼装起来：

• 开放权重中的架构——Qwen3.8-Flash-Next，2026-08-24，一个总参数 125B、激活参数 6B 的 MoE，配有一个 510 亿参数的 n-gram 嵌入表和一个 4B 的 MTP 头，带有 model_type: qwen4_exp以及架构 Qwen4ExpForConditionalGeneration。

• vLLM 方面——#53909，即添加 HyperConnection、QSA 和 PLE 内核的“qwen4 fuse op”PR，自 2026-08-26 起一直处于开放且未合并状态；#59279，为同一 QSA 路径添加解码上下文并行，是 2026-09-29 开启的草稿；以及 9 月期间落地的 PLE 卸载工作。

• SGLang 侧——#38642 用于 DFlash 隐藏状态捕获，#39548 用于 Ascend 上 Qwen4-Exp PLE 的 CPU 卸载，#40235 为基于文件的 PLE 表添加主机暂存，而现在 #41855 则用于 Ascend 注意力路径。

• NPU 支持工作线——sglang #37570，将 Qwen3.8-Flash-Next 引入 NPU 上的 SGLang，并支持图重放（graph replay）、MTP 和 Triton 内核（创建于 2026-09-02，至今仍处于开启状态，跨 20 个文件新增 +2,590 行），以及配套 Triton 内核的 sgl-kernel-npu #807（创建于 2026-09-17，新增 +4,643 行）。两者均来自同一位贡献者。#41855 是位于这一更大规模启用工作中的注意力层。

有两点观察可供读者采取行动。其一，整个 Ascend Qwen4Exp 的叙事仅建立在极少数人之上——启用 PR 与内核仓库出自同一位作者，而注意力适配器则出自另一位作者。这种集中程度可以较为公允地估计出，Ascend Qwen4Exp 服务距离成为受支持的产品路径、而非一项实验，还有多远。其二，内核瓶颈并非某一厂商独有：2026-08-28 提交的两个 SGLang issue 记录了在 NVIDIA DGX Spark 上的 Qwen4Exp decode，其中 QSA、PLE 和 Gated DeltaNet 的内核耗时占主导；并且其中测得 NVFP4 KV cache 相比 fp8_e4m3 使 decode 回退约 29%。这种架构的注意力层与嵌入层在任何地方都是难点所在。

这不意味着什么

这并不意味着 Qwen 4 已经发布，或者即将发布。阿里巴巴在 2026-09-22 命名的 Qwen 4 系列——Max、Flash、Plus 以及一个 27B 层级——仍然只是一份路线图，没有模型卡、没有权重、没有 API 标识符、没有上下文窗口、没有许可证，也没有价格。一个针对内部架构名称的框架适配器，是朝着有朝一日能很好地服务该系列迈出的一步；它不是朝着该系列存在迈出的一步。

这并不意味着你今天就能运行它。这个 PR 还是草稿，CI 失败，也没有合并日期。即使合并了，这条路径也需要 Ascend 910C、BF16、带 torch-npu 2.10 的 CANN 9.0，以及五种特定本地 head 形状之一，而且它是可选加入的——也就是说，部署必须主动选择它。作者也拒绝声称已进行服务器级验证，而这正是真正能告诉你它在真实批处理下是否站得住脚的部分。

而且这并不意味着 Qwen3.8-Flash-Next 是昇腾上受支持的产品，也不是任何已发布引擎构建中受支持的产品。两个主流开源运行时中的 Qwen4Exp 路径都是尚未合并的拉取请求。目前没有任何已发布的 SGLang 或 vLLM 版本可供你安装并原生支持这一架构——托管端点那种 FastAPI 式的便利，与你自己能运行的 kernel 完全是两回事，而两者之间的差距，正是像这个 PR 这样的贡献所要填补的。

等待时你实际可以拨打什么

如果你关注 Qwen4Exp 的原因是想测试该架构的长上下文表现，而不是它的内核内部实现，那么你该选择的是阿里实际正式提供的那一档。Qwen3.8-Flash——基于 Qwen3.8-Flash-Next 打造的生产线，内置官方工具，支持 1,000,000 token 上下文——已在 OrcaRouter 上线，模型为qwen/qwen3.8-flash：支持文本、图像和视频输入，最大输出 131,072 token，每百万输入 token 0.15 美元、每百万输出 token 0.47 美元，缓存读取为 0.0184 美元。这些都是服务商标价，我方以 0% 加价原样传递，因此供应商的价格或限制一旦变动，公布当天就会同步到你这里。在过去七天的窗口内，实时卡片显示首 token 延迟 p50 为 4,416 毫秒、约每秒 106 个输出 token、错误率 2.68%——这是高吞吐文本档位的画像，而非实验室预览版。

有两点必须坦诚说明，而关于这套架构的姊妹篇文章也同样带有这两点。Qwen3.8-Flash-Next 本身——那个 FP8 预览检查点，也就是你想在本地复现这些内核测量结果所需要的那个东西——并不在我们的产品目录中；对外提供的 Flash 层级是基于它构建的生产部署，而非原始预览产物。而且上文描述的任何 Ascend 或 DCP 工作，都不存在于你现在能调用的任何东西里，因为它们都还没有合并。对外提供的层级确实能给你一种低成本的方法，来判断你的工作负载是否适合这些内核所要解决的问题——面向超长上下文的、长且前缀密集的智能体提示。如果确实如此，那么你在那里观察到的吞吐和缓存行为，也正是 Qwen 4 服务栈会通过调优来保护的同一种行为。

还有一个架构层面的理由，说明不必等待一个没有发布日期的模型家族。无论最终哪一档在 Qwen 4 系列中胜出，切换成本都是一个路由问题，而不是一个集成项目，一个 API 覆盖 200+ 模型的方式，让你在权重落地时无需第二份合同或代码改动就能保留这个选项。故障转移在这里同样重要，而且有具体原因：如果你想基于一个尚未验证的档位进行构建，你会希望请求能回退到稳定的东西上，而不是在你押注的路径出问题的瞬间直接失败。

三个值得直接回答的问题

SGLang #41855 是否意味着 Qwen 4 已经发布，还是可以预览？

不，两方面都不对。该拉取请求针对的是在 Qwen3.8-Flash-Next 中实现的 Qwen4Exp 架构，而 Qwen3.8-Flash-Next 是阿里巴巴于 2026-08-24 发布的。它并不触及 Qwen 4 权重，而且 Qwen 4 没有任何层级存在可供触及的权重。这里要解读的信号，关乎的是一个预览架构的服务容量，而不是该模型家族的可用性。

如果模型卡上写着 qwen4_exp，那就是 Qwen 4 吗？

不——而这正是整个故事里的命名陷阱。qwen4_exp 是内部架构标识符，你在 config.json 中为 Qwen3.8-Flash-Next 及其 FP8 同门型号找到的就是它。“实验性架构”才是关键词：权重已发布，架构是真实存在的，而该模型是对 Qwen 4 系列预计将基于什么构建的一次预览。搜索这个标识符，并在标题中带有 Qwen4Exp 的 SGLang 或 vLLM PR 里找到它，说明的是引擎方面的工作，而不是一次发布。

这是Ascend与NVIDIA的对决吗？

并不尽然。同样的注意力路径在 NVIDIA 一侧也需要一个定制适配器——在 vLLM 中为 QSA 实现解码上下文并行，以及为 Hopper 实现原生稀疏预填充内核——而 DGX Spark 的问题表明，QSA、PLE 和 Gated DeltaNet 的内核耗时同样在当地的解码中占据主导。QSA 的微块索引器及其复制的选择器状态，根本不是通用分页注意力内核所假设的样子。Ascend 对这一模式的贡献在于更严苛的约束：一个仅接受 2 的幂的头比例分块器，这迫使适配器不得不隐藏填充。

值得关注的事

问题不在于它是否会合并。适配器坦承自己只是适配器，正确性测试无需检查点即可复现，作者也标出了集成问题，而不是假装它已成定局。真正值得关注的是，NPU 使能分支与这条注意力路径合并后会发生什么——集成后的分支是否会获得两者都未曾有过的端到端运行：在完整模型上进行真实批处理，而不是只处理局部的头形状张量。1.713× 这个数字才是会流传开来的那个，而它是在不同的构建上、在经适配的检查点上、带着一个不起作用的索引器计算出来的。在完成后的技术栈上实测得到的数字，会比一个历史数字有价值得多。

在那之前，最诚实的总结正是 PR 自己始终恪守的那一份：算术上说得通，开关默认关闭，CI 是红的，而标题里的那个模型仍然不存在。