NVIDIA 悄悄為 Meta 的 816B 旗艦模型推出了一款 Drafter

NVIDIA published nvidia/Muse-Spark-Open-816B-A42B-DFlash2 to Hugging Face on October 16, 2026, and told nobody. The repository is a draft checkpoint — a 4.38-billion-parameter speculative-decoding model whose entire job is to guess the next several tokens of Muse-Spark-Open-816B-A42B, Meta's 816-billion-parameter open-weight flagship, so the large model can verify a whole block of guesses in one forward pass instead of emitting one token at a time. There is no NVIDIA blog post, no announcement thread, no press release, and as of writing the repository shows zero downloads and zero likes. What it does have is a model card with acceptance-length tables, a working vLLM invocation, and a short list of things it conspicuously declines to claim. This is what the artifact says and what it does not. What the numbers cannot tell you is whether any of it has gone wrong in the field: the documented AI incidents and agent failures around models in this class are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

已發布的內容，依可檢查的順序

以下所有內容都來自該儲存庫，或來自 Hugging Face 為其提供的自家 API。其中沒有任何一項需要信任廠商基準測試。

• 時間點——該 repo 建立於 2026 年 10 月 16 日 04:40 UTC，其權重約在四十分鐘後提交；模型卡本身的發布資訊寫著「Huggingface: 10/16/2026」。NVIDIA 開發者部落格上沒有隨附的發布文章，而且模型卡只引用了 DFlash 論文與 Model Optimizer 專案。

• 此產物 — 一個 BF16 格式的 safetensors 檔案，4,384,162,432 個參數，約 8.8 GB 儲存空間。架構類別為 DFlash2DraftModel，具有五個稠密解碼器層，非因果滑動視窗注意力、視窗大小為 2,048，隱藏大小為 8,192，128 個查詢頭對上 16 個鍵值頭、每個 64 維，以及詞彙量為 202,048。區塊大小為 8；草稿會從目標的 62 層中取用五層——3、19、31、47 和 59。

• 它無需權限審核—— Hugging Face 回報該儲存庫為公開且無限制。你現在就可以下載這個草稿模型，而 Meta 的目標儲存庫仍隔著一道必須接受條款的登入關卡。

• 授權堆疊——草稿檢查點受 NVIDIA Open Model Agreement 規範，而模型卡另外疊加 Meta 的 Muse Model License，任何以此為基礎打造的成果都必須加上「Built with Muse Spark Open」的標註字串。

• 由 NVIDIA 所述的來源——該模型卡自身的第三方聲明明白指出，Muse-Spark-Open-816B-A42B「並非由 NVIDIA 擁有或開發」，而這款草稿模型「是由 NVIDIA 訓練，以供搭配該目標模型使用」。訓練提示來自 NVIDIA 的 Nemotron-Post-Training-Dataset-v2，約 348 萬筆多語言樣本，涵蓋數學、程式碼與 STEM，而回應則由目標模型在五個推理投入等級下合成。

• 工具鏈——模型卡上寫著，這個模型是以「NVIDIA Model Optimizer 0.47 的預發布版本」訓練而成。Model Optimizer 0.47.0 已於 2026 年 9 月 23 日公開發布，0.48.0rc0 則在 10 月 8 日接續推出，因此這款草稿模型所依據的配方，如今已是第三方能夠重新執行的東西了。

這不是這個模型的第一個草稿模型，也不是 NVIDIA 的第一個草稿模型

那兩項事實對於判斷這裡真正新的是什麼都很重要，因為單憑其中任何一項，都會讓這次推出看起來像另一回事。

NVIDIA 自夏季以來便一直悄悄為他人的開放權重發布 DFlash 系列的草稿模型：六月中旬的 MiniMax-M2.7-DFlash，六月到七月間陸續推出的 Kimi-K2.6-DFlash 與接著的 Kimi-K2.7-Code-DFlash，以及八月初的 Nemotron 3.5 Lightning 30B 草稿模型。來自 NVIDIA 的 Muse Spark Open 草稿模型是這個系列的下一個作品，而非首次登場。

Muse Spark Open 在這一個之前也早就有 drafter 了。一個隸屬於第三方組織的 DFlash2 checkpoint 已於 10 月 13 日發布到 Hugging Face，而針對同一目標的 DSpark checkpoint 上次更新則是在 10 月 15 日——兩者都大約是在 Meta 自家的 day-zero 堆疊分別為其中一個 runtime 命名 DFlash V2、為另一個命名 DSpark 之後的一個月。所以，「Muse Spark Open 有 drafter 存在」並不是這則報導的重點。

這個來龍去脈更狹窄，卻也更實用：NVIDIA 自家、以 Model Optimizer 訓練的 BF16 DFlash2 檢查點如今已針對該模型推出，並在 Blackwell 硬體上發布，以 vLLM 作為其經過測試的引擎。如果你正在選擇要執行哪個 drafter，這個選擇實際上就是選擇服務堆疊，而這正是兩條路徑分道揚鑣之處。

數字，以及附加於其上的確切條件

NVIDIA 在三個測試集上報告一項量值：接受長度，也就是以草稿長度 7 測得、每個生成步驟平均發出的符元數。

• MT-Bench，80 個兩輪問題——在貪婪解碼下每個獲接受的步驟為 3.73 個 token，在取樣下則為 3.01。數學是最強的類別，達 4.47；人文學科最弱，為 2.92。

• SPEED-Bench 質性，880 個提示詞涵蓋 11 個類別——貪婪解碼 3.72、取樣 3.01。多語言達到 4.27、程式設計 4.15，而寫作則以 3.05 拖在後頭。

• SPEED-Bench 吞吐量，32,000 個 token 的輸入 —— 貪婪解碼 3.30、取樣 2.78，而問題正是在這裡浮現：高熵類別的表現驟降至貪婪解碼 2.51、取樣 2.16，相較之下低熵文本則為 3.71。

• 測試條件 — 推理強度 xhigh、4,096 個輸出 token、並行數 32，在單一 GB300 節點上以 TP4 與 EP4 運行，透過 vLLM 提供服務，目標模型採用 NVFP4。貪婪解碼的數據為 temperature 0；取樣數據為 temperature 1.0，且不使用 top-p 或 top-k 截斷，並採用機率式草稿取樣方法。

這三項但書應該放在那些數字旁邊，而不是放在它們下面。第一，它們是廠商自行回報的，我們尚未重現其中任何一項，也沒有其他人發表過這個檢查點的獨立測量結果。第二，接受長度不是加速比——它是用來計算加速比的上限。每個被接受的 token 仍必須由一個 8160 億參數模型驗證，而草稿模型本身的前向傳遞也有成本；NVIDIA 並未公布每秒 token 數比率，也沒有延遲比較，而這正是讀者在決定是否部署此技術時會想知道的數字。第三，這一切都是在併發數 32 下測量的，而這並非推測式解碼通常最划算的情境——其增益集中在延遲受限、低批量的單一請求流，而忙碌的伺服器獲益較少。

這些表格完全沒有衡量的是輸出品質。貪婪解碼下的驗證旨在回傳目標模型自身的 token，因此 greedy 欄位幾乎只是一項純粹的速度宣稱。取樣欄位才是應該用你自己的流量來測試的，因為機率式草稿模型改變的是分布被走訪的方式，而不只是速度有多快。

你實際上會如何開啟它

這張卡提供一種支援的呼叫方式，那就是 vLLM 伺服器上的一個旗標。你 serve 目標模型，並透過 speculative-config 引數傳入 drafter：方法為 "dflash"，模型是 NVIDIA 檢查點，推測 token 數量為 7，草稿取樣方法為機率式，而該命令需要信任遠端程式碼。TensorRT-LLM 是這張卡列出的第二個引擎；vLLM 則是被指名為加速引擎、且是在 Blackwell 上測試過的那一個。

有兩個落差值得點名。這張卡的支援硬體列的是 NVIDIA Blackwell 搭配 Linux，所以這是資料中心 GPU 的路線，而不是能納入 Apple 晶片或消費級配置的東西。而 SGLang——Meta 自家發布素材讓 DFlash V2 走的就是這個執行環境——完全沒出現在 NVIDIA 為這個檢查點列出的引擎清單中。這兩個草稿模型不能互換；如果你的服務堆疊是 SGLang，這個儲存庫就不是為你寫的。

起草者為讀者改了什麼，以及沒改什麼

推測解碼是大型模型推論中，會影響到那些永遠不會下載權重的人的那個環節，因為它是決定超大型開放模型能以多低廉成本提供服務的主要槓桿。更好的起草模型意味著每一步有更多被接受的 token，也就意味著每顆 GPU 有更高吞吐量，而這最終會反映在 API 上更低的價格與更快的首個 token。這就是為什麼一個 4.38B 模型會成為新聞，即使幾乎沒有讀到相關消息的人會實際去跑它。

話雖如此，這一個並不會把 816B 模型放到你的桌上。它是某個目標模型的 8.8 GB 附加元件，而該目標模型最小可實際使用的檢查點是以數百 GB 為單位，執行於 Blackwell 晶片，並受兩份相互疊加的授權條款規範。它不是讓你拿來聊天的模型，本身不會產生任何文字，而且若沒有那個它被訓練來為其草擬內容的目標，它根本無法執行。

如果你想要 Muse Spark 的能力，卻不想沾上那些東西，那條正式提供的產品線就是它所在之處：Muse Spark 1.2 與 Muse Spark 1.1 是 OrcaRouter 所路由的兩個檢查點，兩者都採用 Meta 的定價，0% 加價直接轉嫁，因為供應商的價格是直接轉嫁而非加價。Muse Spark Open 與這個 DFlash2 草稿檢查點不在我們的目錄上，我們也不會暗示並非如此——自架權重的草擬器就是自架基礎設施。我們在這件事上仍然有用的地方，是那些無聊的部分：橫跨 200+ 個模型的單一 API、供應商效能下降時的自動容錯移轉，以及一套路由 DSL，讓你透過設定而非修改程式碼來在模型之間移動流量，這是一種便宜的方式，可以了解一個未經實證的檢查點在真實流量下的表現，而不必把生產路徑押在它身上。

什麼能解決這些懸而未決的問題？

有四件事會改變這篇文章，而它們都不是關於NVIDIA意圖的謎團。

• 端到端加速數字——每秒 token 數或延遲，對照同一硬體上條件相符的非投機式基準，且由 NVIDIA 以外的任何人測量。接受長度只告訴你草稿經常命中，並不代表伺服器變快了。

• BF16 與 NVFP4 目標的比較 — 每一份已發佈的表格都是對照 NVFP4 目標進行測量，而這正是大多數人實際會用來服務的目標，但該卡並未回報任何目標以更高精度執行的案例。

• vLLM 與 TensorRT-LLM 之外的支援 —— 若該檢查點出現在 SGLang 中，Muse Spark Open 的兩款 DFlash2 草稿模型就變得可相互替代，而不再綁定於特定技術堆疊，此時要在兩者之間做選擇就變得簡單了。

• 使用已發布工具重新訓練——這個草稿模型出自 Model Optimizer 0.47 的發行前組建。既然 0.47.0 已於 9 月 23 日公開，而 0.48.0rc0 已於 10 月 8 日推出，這個配方可供檢視，而以它訓練出的檢查點，回報的結果可能會稍微好一點。

至少在那些事情中的第一項落地之前，誠實的總結是：NVIDIA 已經為別人的旗艦模型推出了一個文件完善、無使用門檻、硬體專用的草稿模型，公布了接受長度，還略過了公告——而值得在意的理由不是 Muse Spark Open 變快了，而是讓 8160 億參數的開放權重能在規模上負擔得起的基礎設施，正以如此悄無聲息的方式不斷到來。