Qwen 4 泄露：SGLang 的主机暂存 PR 展示了 47.7 GiB 的 PLE 表如何装入单块 GPU

那个将决定Qwen 4能否成为你可自行部署的模型的数字，不是它的参数量。而是 47.7 GiB——伴随 Qwen4 架构、独立于权重、并且在模型解码期间必须存放在某处的 n-gram 嵌入表的大小。2026 年 9 月 18 日在 SGLang 仓库中打开的一个标题为[Qwen4-Exp] 为文件支持的 PLE 添加主机暂存的拉取请求，试图阻止那张表决定一台机器在能够运行之前需要多少 RAM。Qwen 4 仍未发布：没有模型卡、没有权重、没有目录条目、没有日期。唯一已发布且实例化了这一架构的模型是 Qwen3.8-Flash-Next，即 2026 年 8 月 26 日发布的开放权重预览版，其配置声明了 model_type=qwen4_exp——正是让这个拉取请求得名的同一个字符串。它的生产版同门模型 Qwen3.8-Flash 才是 API 调用者今天实际能够访问到的版本。本文中关于 Qwen 4 的一切都是从那个预览版和引擎代码推断出来的；这个拉取请求仍处于开放且未合并状态，因此请把这一切当作一个信号，而不是已交付的能力。

信号实际上是什么

拉取请求 sgl-project/sglang#40235尚未启动审查，也未被合并。它停留在单个提交上，由贡献者 Dev-Jahn 开启，将一个名为 task/ple-host-staged 的分支合并到 SGLang 的主线。已有九位代码负责人被请求审查，且全部显示为等待中，因此至少还需要一个批准审查，它才能进入主线。在当前的提交上，有三个 CI 任务——基础 PR 测试、额外 PR 测试以及 AMD ROCm 运行——均处于失败状态。这是一次大型引擎改动在推进过程中的正常状态，也正是为什么这个 PR 有意思的地方不在于它能否落地，而在于 其作者为了论证它不得不去测量什么。该描述包含约 1,400 行新增内容（包括测试），以及一张基准测试表，这是目前任何人就单张 GPU 上运行该架构所公开过的最具体的数据。

为什么这张表就说明了一切

逐层嵌入是这一代模型的结构性异类。普通模型会在最前面放置一个 token 嵌入，而 Qwen4 的设计则携带一张大型 n-gram 表——由二元组和三元组经哈希映射到一个远大于分词器词表的词表中——并在整个堆栈中从该表提供逐层嵌入查找。阿里巴巴自己的预览材料将 n-gram 组件描述为在 125B 参数 MoE 主体之上还有数百亿参数；社区对已发布检查点的拆解则将表文件定为 47.7 GiB。这些数字来自厂商与社区来源，而非独立复现，并且预览版的表与 Qwen 4 最终发布的表之间的确切关系尚不清楚。

无可置疑的是其工程后果。一个必须在每个解码步骤都被查询的 47.7 GiB 侧表，并不是你能悄悄塞进显存某个角落的东西。在 96 GB 的显卡上，它会直接与 KV 缓存竞争；在更小的显卡上，它根本装不下。这就是为什么 SGLang——它在 8 月下旬就为预览版提供了首日支持——在接下来的三周里，围绕这一个数据结构、而不是围绕它周围的模型，产出了一个又一个拉取请求。

在这个 PR 之前，什么是坏的

SGLang 原本已有两种持有这张表的方式，而两者都存在硬伤。

• Pinned会将整张表保存在主机内存中，并从那里读取。它确实可行，速度也快，但它使主机内存需求成为绝对的硬性要求——没有任何更小的版本。

• 基于文件的方案在更早的一个独立 pull request 中加入，它把这张表保存在一个稀疏文件中，并让 gather 内核直接读取该映射，因此由操作系统的页缓存来决定其中有多少常驻内存。问题出在硬件上：这条直接读取路径要求 GPU 报告 cudaDevAttrPageableMemoryAccessUsesHostPageTables —— 也就是该 PR 自己的文本中含糊地称为“GB10 级别”的能力。在不具备这一能力的 GPU 上，文件后端会被直接拒绝，只剩下固定内存这一选项。

由此产生的缺口并非理论上的。一份针对同一条代码路径另行提交的报告记录了一位使用两块 RTX 3090 的用户：其每个 rank 分到的表份额达到 23.84 GiB，而可用内存为 23.56 GiB——少了 0.28 GiB，同时主机 RAM 还有 188 GiB 空闲。在该配置下，文件后端被硬件检查拒绝，而普通的 CPU offload 标志与 PLE offload 标志结合使用时会报错。少了三百兆字节却还空着一百八十吉字节，恰恰就是这个拉取请求所要消除的那类问题。

有哪些主机暂存更改？

PR 添加的机制是位于文件和设备之间的暂存层。它不再让 GPU 解引用主机页，而是由 CPU 侧组件通过加载器已有的映射读取所需行，并建议内核提前将这些页调入；一个环境变量，SGLANG_QWEN4_PLE_FILE_PREFETCH，如果你想在不使用该建议的情况下进行测量，可以用它关闭此建议。随后每个 PLE 层获得两个包含 8,192 行的固定缓冲区——FP8 下每个约 1.25 MiB——以及一个工作线程。行会先被收集到一个缓冲区，同时另一个缓冲区正被复制到设备，因此收集与传输相互重叠，而不是串行执行。N-gram 标识符在主机上而非设备上进行哈希。图重放前会为每次重放调用一次准备函数，启动线程会等待上一步完成。

最后那个细节就是代价，而 PR 里也直言不讳：相较固定路径，大约每个解码步骤会多出 0.5 到 1 毫秒。其余的一切都是回报。在单块 96 GB 的 RTX PRO 6000 Blackwell、搭配 377 GiB 内存的 AMD EPYC 主机上，使用 CUDA 13.2，并采用 Qwen3.8-Flash-Next 的公开 FP8 与 NVFP4 检查点实测：

• 主机页缓存，FP8 TP4/EP4 —— 固定且无上限时为 71 GB，而 64 GB 上限时为 49 GB，32 GB 时为 15 GB，24 GB 上限时为 6 GB

• 解码延迟，相同运行 — 在绑定并发数为 1 时，每 token 耗时 8.62 ms，而三次设限文件运行分别为 9.16 / 9.20 / 9.12 ms

• 并发 16 — 固定时为 16.54 毫秒，受限时为 17.62 / 17.85 / 17.37 毫秒，即从每秒 893 个 token 降至 827–840

• 预填充吞吐量 — 在 8k 固定时为每秒 620 个 token，而在封顶情况下为 624 / 630 / 631；在 32k 时，为 1,347，相比之下为 1,358 / 1,359 / 1,361

• NVFP4 TP2 —— 在 32 GB 上限下，固定内存为 69 GB，而文件后端为 24 GB；延迟为 8.87 ms 对 9.18 ms

• 单 GPU NVFP4 — 在 64 GB 上限下，固定占用为 69 GB 对比 51 GB，6.44 ms 对比 6.73 ms

• 它所超越的替代方案 —— 在该 GPU 上通过主机内存管理读取同一文件，在并发度为 1 时为 10.8 毫秒，在并发度为 16 时为 46.5 毫秒，PR 将其描述为该并发度下 pinned 延迟的 2.8 倍

准确率方面报告为无异常。在 FP8 TP4 上，八个 256 token 提示的确定性贪心输出在 pinned 路径与 file 路径之间逐 token 完全一致；而在 64 GB 上限下，GSM8K 在 pinned 路径上为 97.6%，在 file 路径上为 98.0%——作者将这相差六道题的差距归因于运行间的波动，而非 offload 路径。所有这些数字都出自拉取请求作者本人，仅在一台机器上测量过一次，且无人复现过。

PR 承认的代价

公允地解读这个拉取请求，也要把它拒绝做的事算进去。若干执行模式会在构造时被拒绝，而不是被静默降级；每一次拒绝都会把固定后端列为回退方案：预填充 CUDA 图、数据并行注意力、预填充-解码多路复用路径、双批次重叠、DLLM 解码图，以及紧凑的 ragged 验证图，全都被排除在外。同样重要的是，它没有新增任何标志，也没有新增任何面向用户的开关——暂存路径正是文件后端在以前完全无法使用该后端的硬件上所做的事。而精度运行还带有作者主动说明的一项注意事项：设了上限的运行从未容纳整张表，因为该表有 47.7 GiB，而上限低至 24 GB，所以，针对整张表具有真正平坦且不可预测访问模式的工作负载，并不是本次所测量的内容。

为什么这一点对 Qwen 4 尤其重要

剥去引擎细节，模式便清晰可辨。阿里巴巴于8月26日发布了一份架构预览，并指示开源社区在完整系列发布之前准备好运行时、量化和推理引擎。SGLang 照做了，随后用三周时间提交拉取请求，内容都围绕那个让该架构难以部署的组件。若把它当作一种预测来读，这说的是 Qwen 4 将对你的硬件提出什么要求，而不是它在基准测试上能有什么表现。

这也让时间线问题变得更加尖锐。Qwen 4 尚未发布，而围绕它的9月猜测指向9月22日至24日在杭州举行的阿里巴巴云栖大会——此前几代 Qwen 就是在此发布的。此事尚无任何确认，而从上一轮预览周期来看，其模式是架构预览会比完整系列提前数月，而不是数周。在那场会议前三天开启一个拉取请求，只是一种暗示，仅此而已。

对读者而言，诚实的总结是：Qwen 4 并不存在，Qwen3.8-Flash-Next 存在，而后者会告诉你运行前者需要付出多少成本。如果 47.7 GiB 的表格在有效占用上持续缩小——三周以来的拉取请求表明它正被大力推进——那么 Qwen 4 系列的部署门槛就低于预览版发布当周所暗示的水平。

你今天实际上能用这个做什么

这个 pull request 里的任何内容在 main 分支上都不可用，而且它针对的模型也不是你能通过 API 调用的东西。开放权重的 Qwen3.8-Flash-Next 检查点讲的是自托管的故事：你得自己拉取权重、自己提供服务，而你现在读到的正是基于文件的 PLE 路径。它不在这里被路由。真正被路由的是生产版本——Qwen3.8-Flash，可通过 qwen/qwen3.8-flash 访问，每百万输入 token 收费 0.15 美元、每百万输出 token 收费 0.47 美元，具备 1M token 的上下文，支持文本、图像和视频输入——以及规模更大的 Qwen3.8-Max，收费为 2.00 美元和 6.00 美元。

对正在决定这周该做什么的读者来说，这一区分才是有用的。预览版是你自己运行的研究；已上线版本则是同一架构的生产路径，而它只差一个端点。0% 加价OrcaRouter 正是以这个加价率把供应商的标价原样转嫁出去，因此该端点上的供应商价格变动当天就会体现，而不是等到下一个计费周期；而且密钥上的每个模型都能通过一个兼容 OpenAI 的基础 URL 访问，不必为每个供应商分别签订合同、接入各自的 SDK 和凭证。对于一个如此年轻的架构——引擎层面的工作仍在按周迭代，路线图也尚未公布——跨供应商的自动故障转移是依赖已上线版本的务实做法，无需把生产路径押在单一供应商的可用性上。以上说的都是你今天能调用的模型。至于 Qwen 4，它只字未提，而 Qwen 4 并不在其中。

我们仍然不知道的事

Qwen 4 是否会以相同规模发布同样的表格。那个拉取请求究竟会不会被合并——它有三项失败的 CI 运行，且尚无评审。每步 0.5 到 1 毫秒的开销，在作者的低并发配置之外是否依然成立。以及 Alibaba 是否会在 9 月 22 日的 Apsara 上说什么。就目前的证据而言，关于 Qwen 4，最稳妥的结论不是它得分多少，而是整个行业为了让它适配正在搭建多少配套机制——这本身在模型还没有在任何目录中拥有名字之前，就是一件值得知道的事。