Qwen4-Exp QSA 登陸華為昇騰：深入解析 SGLang 可選加入的 CANN 預填充 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 的 Apsara 大會上命名的 Max、Flash、Plus 與 27B 層級——仍舊沒有權重、沒有識別碼、沒有價格，也沒有日期。所以，這是一篇關於工程產物的「目前已知」報導，而不是產品發布：又一家廠商的服務堆疊悄悄決定，一個尚未發布的架構值得提早支援。

提取請求實際上新增了什麼

這項變更刻意做得小且刻意狹窄。五個檔案、一個提交、相對於主分支提交 b87a241 的 +355 行，並帶有 SGLang npu 標籤。作者 w1ida一開始就表明意圖：為 Qwen4-Exp QSA eager 預填充提供可選擇啟用的 CANN 主注意力路徑，建構於 torch_npu.npu_sparse_flash_attention，並將索引器、Top-K 選擇、token 預算與 KV 快取內容全部保持原樣。

它用來達成這一點的技巧值得用一段來說明，因為這說明了為什麼這是佈局轉接器，而不是新的注意力核心。對於已經旋轉過的 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 壓縮」。在原生 MLA 佈局中，每個 KV 頭都會成為獨立的批次，原始的 D256 縮放會保留，而輔助 RoPE 會歸零。

營運細節和數學一樣重要：

• 啟用 — SGLANG_NPU_QSA_NATIVE_PREFILL=1，預設為關閉。只有一般 ForwardMode.EXTEND 會選擇啟用；解碼、推測模式、混合前向與圖形擷取全都維持在現有路徑上，且圖形擷取會完全繞過配接器。

• 硬體與資料型別 — BF16，頭部維度 256，Ascend 910C（Ascend910_93*），已針對 CANN 9.0 與 torch-npu 2.10 進行測試。任何不支援的資料型別或形狀都會靜默回退至參考路徑。

• 注意力頭形狀 —— 支援的本地 （Q 頭、KV 頭） 配對為 (16,2)、(24,2)、(12,1)、(6,1)以及 (3,1)。CANN 直接拒絕 12 的 query/KV 比例 —— 它的 tiler 只接受 2 的冪次 —— 因此頭數會補齊為 12→16、6→8 或 3→4，並捨棄多出來的輸出。這是整份 PR 中最明確的跡象，顯示硬體在設計時並未把稀疏注意力的頭部比例納入考量，而 adapter 正在吸收這種不匹配，而非讓模型為此改變形狀。

• 尺寸界限 — 僅會打包被引用的實體快取範圍，上限為 262,144 個 token，作者計算出在兩個 KV 頭時，打包的 BF16 K/V 張量最多為 512 MiB。內部 -1 填充會被偵測並路由至備援路徑，因為 CANN 要求連續的有效槽位；完全遮罩的列則維持現有的零輸出慣例。

• 為何僅限預填充——範圍與佈局檢查會將兩個純量複製到主機，而暫存副本加上原生工作區會耗用記憶體。該同步正是此路徑僅限於即時預填充、並在擷取期間保持關閉的原因。

九項通過的測試，以及一個並非來自這個分支的速度數值

正確性證據具體且可重現，這比大多數 kernel PR 所能提供的還要多。作者回報，在 Ascend 910C（Ascend910_9362）上搭配 CANN 9.0 與 torch-npu 2.10.0，9 項測試於 40.772 秒內通過，且不需要檢查點：以非零隨機 BF16 Q/K/V 對照由相同 BF16 輸入計算出的 FP32 CPU 參考值；寬度為 1/63/64/65/2051 的無序實體槽位；預設與明確的 scale；完全遮罩的列；零列；零選取寬度；非連續張量；壓縮比為 4 的因果尾部餘數 0 到 3；帶有共享前綴的雙請求實體對映；快取內容重用；以及 1 與 257 個查詢列下的 Flash-Next 局部頭部形狀。

主要案例是一次長預填充：7,810 個查詢 token 對上 65,536 token 的快取，每個查詢有 2,051 個選取槽位，所有輸出皆為有限值，並以八個取樣列與 FP32 參考值進行比較。觀測到的相對 L2 誤差在小型頭部形狀案例達到 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 檢查點上所取得的歷史原型量測，於 TP1 執行，使用 W8A8 權重與 BF16 注意力，在 CANN 9.0 下的 910C 上，並使用官方 sglang.bench_serving 測試框架，並行度為 1、六個請求、每個請求一個輸出 token，且 36,096 個快取前綴 token 已從新 token 吞吐量中排除。這些不是 PR 中上游分支的基準測試，原始的 serving JSON 產物並不在這次的 checkout 中，而後續約每秒 5,000 token 的本機結果使用了額外的原生 indexer 與 block4 工作，這些被明確聲明不歸因於此變更。作者也指出，該改編檢查點的 indexer 權重是無作用的，其預算也與原始版本不同，因此這些都無法作為 indexer 正確性或完整預算生成品質的證據。

先澄清一個命名問題，因為這會讓任何搜尋該檢查點的人搞混：基準模型是貢獻者自行調整而成的產物。另外，「Whittle-Next」也是一個由第三方 Hugging Face 帳號發布的公開 Qwen3.8 衍生 MoE 微調系列名稱，其中包括一個於九月上傳的 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，而選定詞元介面則未受更動；原生索引器與 block4 最佳化則明確不在範圍內。因此，這是一個加掛在既有選取機制底下的轉接器，而非 QSA 的重新實作——這也是為什麼作者能可信地宣稱 KV 快取內容並未改變。

模型卡清楚闡明了設計意圖：QSA 並非挑選個別 token，而是在微區塊層級運作，以降低長上下文延遲；而這種微區塊粒度，加上隨之而來的複製選擇器狀態，正是在兩家廠商的晶片上，都無法乾淨對應到通用分頁注意力核心的關鍵所在。

這在 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 開啟的草稿；以及九月間合併落地的 PLE 卸載工作。

• SGLang 這邊 —— #38642 用於 DFlash 隱藏狀態擷取，#39548 用於在 Ascend 上進行 Qwen4-Exp PLE 的 CPU 卸載，#40235 為檔案支撐的 PLE 表新增主機暫存，而現在 #41855 則用於 Ascend 注意力路徑。

• NPU 啟用系列——sglang #37570，在 NPU 上將 Qwen3.8-Flash-Next 加入 SGLang，並搭配 graph replay、MTP 與 Triton kernels（於 2026-09-02 開啟，仍處於開啟狀態，橫跨 20 個檔案、新增 2,590 行），以及 sgl-kernel-npu #807，用於搭配的 Triton kernels（於 2026-09-17 開啟，新增 4,643 行）。兩者都來自同一位貢獻者。#41855 是位於那項更大規模啟用工作之中的注意力層。

讀者可以據以採取行動的兩點觀察。第一，整個 Ascend Qwen4Exp 的故事只建立在極少數貢獻者之上——啟用相關的 PR 與核心儲存庫是同一位作者，而注意力轉接器則是另一位。這樣的集中程度，足以合理估計 Ascend Qwen4Exp 推論服務距離成為受支援的產品路徑、而非實驗性專案，還有多遠。第二，核心瓶頸並非特定廠商獨有：2026-08-28 所提交的兩個 SGLang issue 記錄了在 NVIDIA DGX Spark 上進行 Qwen4Exp 解碼時，QSA、PLE 與 Gated DeltaNet 的核心執行時間佔據主導，且 NVFP4 KV 快取經量測後，相較於 fp8_e4m3 使解碼效能退步約 29%。這個架構的注意力層與嵌入層，在各處都是最困難的部分。

這並不代表什麼

它並不代表 Qwen 4 已經推出，或是即將推出。阿里巴巴於 2026-09-22 命名的 Qwen 4 系列——Max、Flash、Plus 以及一個 27B 級別——仍只是一份路線圖，沒有模型卡、沒有權重、沒有 API 識別碼、沒有上下文視窗、沒有授權條款，也沒有價格。一個以該內部架構名稱為目標的框架轉接器，是朝著有朝一日能完善服務該系列所邁出的一步；這並不是讓該系列得以存在的一步。

這並不代表你今天就能執行這個。這個 PR 還是草稿，CI 失敗，而且沒有合併日期。即使合併了，這條路徑也需要 Ascend 910C、BF16、CANN 9.0 搭配 torch-npu 2.10，以及五種特定的局部 head 形狀之一，而且它是選擇性啟用——意思是部署時必須自行選擇它。作者也拒絕聲稱已通過伺服器層級驗證，而這正是能真正告訴你它在真實批次處理下是否站得住腳的部分。

而這並不代表 Qwen3.8-Flash-Next 是 Ascend 上、或任何已出貨引擎版本中受支援的產品。兩大開源執行環境中的 Qwen4Exp 路徑都是尚未合併的 pull request。沒有任何已發佈的 SGLang 或 vLLM 版本，是你安裝後就能原生服務此架構的——代管端點那種 FastAPI 式的便利性，與你自己能執行的 kernel 是兩回事，而兩者之間的落差，正是像這個 PR 這樣的貢獻所要填補的。

等待期間你實際可以撥打的電話

如果你關注 Qwen3Exp 的原因是為了測試架構的長上下文行為，而不是它的核心內部運作，那麼你該選用的是阿里巴巴實際提供的等級。Qwen3.8-Flash —— 以 Qwen3.8-Flash-Next 為基礎打造的正式產品線，內建官方工具，並具備 1,000,000 詞元的上下文 —— 已在 OrcaRouter 上線，型號為 qwen/qwen3.8-flash：支援文字、圖像與影片輸入，最大輸出 131,072 詞元，每百萬輸入詞元 $0.15、每百萬輸出 $0.47，快取讀取則為 $0.0184。這些是供應商的定價，我們這邊以 0% 加價原樣轉遞，因此廠商對其價格或限制的變更，會在公告當天就傳達給你。在過去七天的區間內，價格資訊卡顯示首詞元延遲的 p50 為 4,284 毫秒、每秒約 106 個輸出詞元，錯誤率為 2.68 —— 這是高用量文字層級的特徵，而非實驗室預覽版。

兩點誠實的但書，而這也正是同系列探討這套架構的文章所同樣帶有的那兩點。Qwen3.8-Flash-Next 本身——那個 FP8 預覽檢查點，也就是你想在本機重現這些核心量測時所需要的東西——並不在我們的型錄上；對外提供的 Flash 層級是由它建構而成的正式部署，而非原始的預覽成品。而且上述的 Ascend 或 DCP 工作，都不存在於任何你能呼叫到的東西裡，因為它們全都還沒合併。對外提供的層級能給你的，是一個便宜的方法，讓你查明你的工作負載是否正好符合這些核心所解決的問題形態——在極長的脈絡下，使用冗長、前綴佔比高、具代理性的提示。如果是的話，你在那裡觀察到的吞吐量與快取行為，也正是 Qwen 4 服務堆疊將被調校去保護的同一種行為。

還有一個底層管線層面的理由，說明為何不該等待一個尚未公布日期的模型家族。無論最後是哪個層級在 Qwen 4 系列中勝出，切換成本都是路由問題，而不是整合專案，而一個 API 支援 200 多個模型正是讓你在權重釋出時能保有這個選項、無須另簽合約或修改程式碼的方法。基於同樣理由，故障轉移在這裡也以特定方式顯得重要：如果你想以一個未經證實的層級來開發，你會希望請求能轉移到穩定的服務上，而不是在你押注的路徑正好出狀況時直接失敗。

三個值得直接回答的問題

SGLang #41855 是否代表 Qwen 4 已經推出，還是只是可以預覽？

不，這兩點都不是。這個 Pull Request 針對的是 Qwen3.8-Flash-Next 中所實作的 Qwen4Exp 架構，而該模型是 Alibaba 於 2026-08-24 發布的。它不會觸及 Qwen 4 的權重，而且沒有任何 Qwen 4 層級有權重可供觸及。這裡要讀出的訊號，是關於預覽架構的服務容量，而不是關於該系列是否可用。

如果模型卡上寫的是 qwen4_exp，那是指 Qwen 4 嗎？

不——這正是整個故事裡的命名陷阱。qwen4_exp是內部架構識別碼，也就是你在 Qwen3.8-Flash-Next 及其 FP8 同系列產品的config.json裡會看到的東西。「實驗性架構」是這裡的關鍵字：權重已發布，架構是真實的，而這個模型是 Qwen 4 系列預期將以之為基礎打造的預覽。搜尋這個識別碼，找到標題帶有 Qwen4Exp 的 SGLang 或 vLLM PR，那只代表引擎相關的工作，不代表正式發布。

這是昇騰對上NVIDIA的故事嗎？

其實不然。同樣的注意力路徑在 NVIDIA 這一側也需要專門打造的轉接器——在 vLLM 中為 QSA 提供解碼上下文平行化，以及為 Hopper 提供原生稀疏預填充核心——而 DGX Spark 的問題也顯示，QSA、PLE 與 Gated DeltaNet 的核心時間在該處解碼時同樣佔據主導地位。QSA 的微塊索引器及其複製的選擇器狀態，根本不是通用分頁注意力核心所假設的那樣。Ascend 對這個模式帶來的貢獻，是更嚴苛的限制：一個只接受 2 的次方的頭部比例平鋪器，這迫使轉接器必須隱藏填充。

值得關注的事情

問題不在於這會不會合併。這個適配器對自己是個適配器這件事很誠實，正確性測試無需檢查點即可重現，而作者也標示了整合問題，而非假裝它已成定局。真正要觀察的是，NPU 啟用那條線與這條注意力路徑結合之後會發生什麼——整合後的分支是否會得到兩者都未曾有過的端到端執行，在完整模型上進行真正的批次處理，而不是本機的注意力頭形狀張量。1.713× 這個數字是將會流傳開來的那個，而它也是在不同的建置上、以調適過的檢查點、搭配一個不具作用的索引器計算出來的。在完成後的技術堆疊上實測得到的數字，價值會遠高於一個歷史數字。

在那之前，誠實的總結就是 PR 本身所堅守的那個說法：算術無誤，旗標預設為關閉，CI 呈現紅燈，而標題中的模型仍然不存在。