Qwen 4 外洩：SGLang 的 Host-Staging PR 展示 47.7 GiB 的 PLE 表如何裝進單張 GPU

決定你能否自行部署 Qwen 4 的數字，不是它的參數量。而是 47.7 GiB——那張 n-gram 嵌入表的大小；這張表伴隨 Qwen4 架構、與權重分開，而且在模型解碼時必須存在於某處。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 的一切，都是從該預覽版與引擎程式碼推論而來；該提取要求仍開放且未合併，因此請將這一切視為訊號，而非已出貨的能力。

訊號實際上是什麼

Pull Request sgl-project/sglang#40235並不是一次發布，也尚未合併。它停留在單一 commit 上，由貢獻者 Dev-Jahn 開啟，將名為 task/ple-host-staged 的分支合併進 SGLang 的主線。已有九位程式碼擁有者被請求審查，且全部顯示為等待中，因此至少還需要一份核准的審查才能進入主線。三項 CI 工作——基礎 PR 測試、額外 PR 測試，以及 AMD ROCm 執行——在目前開啟的 commit 上失敗。這是一個大型引擎變更進行中的正常狀態，也是為什麼這個 PR 有趣之處不在於它是否會落地，而在於 其作者必須量測什麼才能為它辯護。其說明包含約 1,400 行新增內容（含測試），以及一張基準測試表，那是目前任何人針對在單一 GPU 上執行此架構所發表過最具體的公開資料。

為什麼表格說明了一切

逐層嵌入（Per-Layer Embeddings）是這一代的結構性異類。一般模型是在最前面放置一個詞元嵌入，而 Qwen4 的設計則帶有一張大型的 n-gram 表——由雙連詞（bigrams）與三連詞（trigrams）組成，經雜湊對應到一個遠比分詞器詞彙量更大的詞彙集——並在整個堆疊中持續從中饋入逐層嵌入查詢。阿里巴巴自家的預覽資料將 n-gram 元件描述為在 125B 參數的 MoE 主體之上額外增加數百億參數；社群對已發布檢查點的拆解則指出，該表檔案大小為 47.7 GiB。這些數字來自廠商與社群來源，而非獨立重現，且預覽版的表與 Qwen 4 最終實際出貨的版本之間確切關係為何，仍屬未知。

毫無疑問的是其工程後果。一張 47.7 GiB 的側表（side table），必須在每個解碼步驟中被查詢，這不是你能悄悄塞進 VRAM 某個角落的東西。在 96 GB 的顯示卡上，它會直接與 KV 快取競爭；在較小的顯示卡上，它根本放不下。這就是為什麼 SGLang——它在八月底就為這個預覽版本提供了 day-0 支援——在接下來三週裡，針對這單一資料結構（而非其周圍的模型）接連產出一個又一個 pull request。

在這個 PR 之前，是什麼壞掉了？

SGLang 已經有兩種方式來掌控局面，而兩者都有其硬傷。

• 釘選會將整張表保留在主機 RAM 中，並直接從那裡讀取。它確實可行、速度也快，但這讓主機記憶體需求成為絕對值——它沒有更小的版本。

• 以檔案為後備的做法稍早在另一個 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 旗標併用時會引發例外。明明還有一百八十 GB 備用，卻短少三百 MB，正是這個 pull request 所要消除的那類問題。

主機預備環境有哪些變更？

PR 新增的機制是檔案與裝置之間的中繼層。不再要求 GPU 解參考主機分頁，而是由 CPU 端元件透過載入器既有的映射讀取所需的列，並建議核心提前將那些分頁載入；環境變數，SGLANG_QWEN4_PLE_FILE_PREFETCH，可關閉這項建議，如果你想在沒有它的情況下進行量測。每個 PLE 層接著會取得兩個釘選緩衝區，各有 8,192 列——在 FP8 下各約 1.25 MiB——以及一個 worker。列會蒐集到其中一個緩衝區，同時另一個正被複製到裝置，因此蒐集與傳輸會重疊，而不是序列化。N-gram 識別碼是在主機上進行雜湊，而非在裝置上。圖重播在每次重播前會有一個準備呼叫，而啟動執行緒會等待前一個步驟。

最後那個細節就是代價，而 PR 直言不諱地指出：大約每個解碼步驟會增加 0.5 到 1 毫秒（相較於固定路徑）。其餘一切則是回報。在單張具備 96 GB 的 RTX PRO 6000 Blackwell、搭載 377 GiB RAM 的 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 毫秒，相較之下，三次受上限限制的檔案執行分別為 9.16 / 9.20 / 9.12 毫秒

• 並行數 16 — 固定為 16.54 毫秒，相較於上限的 17.62 / 17.85 / 17.37 毫秒，也就是從每秒 893 個 token 降至 827–840

• 預填吞吐量 — 在 8k pinned 下為每秒 620 個 token，相較於 capped 的 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 毫秒對比 6.73 毫秒

• 它所勝過的替代方案 — 在同一張 GPU 上透過主機記憶體管理讀取同一個檔案，並行度為 1 時耗時 10.8 ms，並行度為 16 時耗時 46.5 ms，而 PR 將此描述為在該並行度下釘選延遲的 2.8 倍

準確度方面回報為乾淨無誤。在八個 256 token 提示上的確定性貪婪輸出，於 FP8 TP4 上在固定版本與檔案路徑之間達到 token 完全一致，而 GSM8K 在 64 GB 上限下，固定版本為 97.6%，檔案路徑為 98.0%——這六題的差距，作者歸因於每次執行之間的變異，而非卸載路徑。這些數字全都是 pull request 作者自己的，僅測量過一次，僅在一台機器上，而且沒有人重現過。

公關承認的代價

對這份 pull request 的公正解讀，也應包含它拒絕做的事。數種執行模式在建構時即遭到拒絕，而非被默默降級，而且每次拒絕都指明釘選的後端作為後備：prefill CUDA graphs、data-parallel attention、prefill-decode 多工路徑、two-batch overlap、DLLM decode graphs，以及 compact ragged verify graphs，全都排除在外。同樣重要的是，它沒有新增任何旗標，也沒有新增任何使用者可見的切換開關 —— staging 路徑正是檔案後端在先前完全無法使用它的硬體上所做的。而準確度執行帶有一項作者主動提出的但書：設有上限的執行從未容納整張表，因為該表為 47.7 GiB，而上限最低可達 24 GB，因此，對整張表具有真正平坦、不可預測存取模式的工作負載，並不是這次所量測到的情況。

為什麼這對 Qwen 4 特別重要

剝除引擎細節後，模式便清晰可辨。阿里巴巴於 8 月 26 日發布了一份架構預覽，並附上指示，要開源社群在完整系列推出前準備好執行環境、量化與推論引擎。SGLang 照做了，接著花了三週提交 pull request，全都圍繞著那個讓此架構難以部署的元件。若把它讀成一則預測，這是在說明 Qwen 4 會對你的硬體提出什麼要求，而不是它在基準測試上能達到什麼表現。

這也讓時間線問題更加尖銳。Qwen 4 尚未發布，而圍繞它的九月猜測指向阿里巴巴 9 月 22 日至 24 日在杭州舉行的雲棲大會——先前幾代 Qwen 正是在這個場合發表的。此事完全未經證實，而上一輪預覽週期的模式是：架構預覽會比完整家族早數個月，而不是數週。在該大會開幕前三天開啟的 pull request 具有暗示意味，但也僅止於此。

對讀者而言，這一切的誠實總結是：Qwen 4 並不存在，Qwen3.8-Flash-Next 才存在，而後者能告訴你運行前者得付出多少代價。如果那張 47.7 GiB 的表格在有效佔用上持續縮減——而三週以來的 pull request 顯示這正被全力處理——那麼 Qwen 4 系列的部署門檻，就比預覽版發布當週所顯示的要低。

你今天實際上能用這個做什麼

這個 pull request 裡的內容都沒在 main 上提供，而它所鎖定的模型也不是你能透過 API 呼叫的東西。開放權重的 Qwen3.8-Flash-Next 檢查點屬於自架範疇：你得自己拉取權重、自己提供服務，而檔案支撐的 PLE 路徑正是你現在讀到的內容。它並未在此路由。真正被路由的是正式版變體——Qwen3.8-Flash，可透過qwen/qwen3.8-flash取得，每百萬輸入 token 為 0.15 美元、每百萬輸出為 0.47 美元，具備 100 萬 token 的上下文，並支援文字、圖像與影片輸入——以及規模更大的Qwen3.8-Max，價格分別為 2.00 美元與 6.00 美元。

對讀者來說，這個區別才是決定這週該怎麼做的關鍵。預覽版是你自己跑的研究；正式提供的版本則是同一套架構的生產路徑，而且只差一個端點。OrcaRouter 以0% 加價直接轉嫁供應商的標價，因此該端點的廠商價格若有變動，當天就會反映出來，而不是等到下一個計費週期；而且金鑰上的每一個模型都能透過同一個 OpenAI 相容的基礎 URL 存取，不必為每家供應商各自簽約、各自使用不同的 SDK 和憑證。對一套還這麼年輕的架構來說——引擎相關的工作仍在每週持續落地，路線圖也尚未公布——跨供應商的自動容錯移轉，是不必把生產路徑押在單一供應商開機時間上、又能依賴正式版本的務實做法。以上所談的都是你現在就能呼叫的模型。這完全沒提到 Qwen 4，而它並不在其中。

我們還不知道的事

Qwen 4 是否會以相同規模推出同一張表。那個 pull request 到底會不會合併——它有三個失敗的 CI 執行，而且還沒有任何審查。0.5 到 1 毫秒的每步效能損失，在作者的低併發設定之外是否仍然成立。以及 Alibaba 是否會在 9 月 22 日的 Apsara 上發表任何內容。就目前的證據來看，關於 Qwen 4 最保險的結論不是它拿到什麼分數，而是整個產業只為了讓它裝得下，正在打造多少機制——這本身就是在該模型還沒在任何型錄中擁有一個名字之前，值得知道的事。