Inkling 2 Small 權重開放下載：394 GB、Apache 2.0，還有一張節點規模的帳單

Inkling 2 Small 儲存庫中的第一個權重提交，時間戳為 2026 年 11 月 12 日 19:53 UTC——比本文撰寫時間早九小時。在那之前，這個模型還只是一張費率卡和一張基準測試表：Thinking Machines Lab 於 11 月 5 日推出它，當時權重封閉、提供 Tinker 端點，並表明打算「下週」以 Apache 2.0 發布檢查點。因此，模型本身已問世八天。新變化在於你現在可以下載它，而且這個下載檔案可不小。

兩個儲存庫已公開。主要檢查點共 36 個檔案、393.5 GB，其中 24 個是 safetensors 分片。MXFP8 變體為 622.8 GB。兩者在模型卡的中繼資料裡都宣告為 Apache 2.0。到目前為止，整個公告就只有這些——模型卡、這些儲存庫，以及附加在發布文章後的一段更新。以下所有內容都是根據這些主要來源，加上隨它們一起發布的兩份 serving 操作指南讀出來的；而且有必要直白指出仍然缺失的東西：作為開放這些權重所述前提的外部安全測試，尚未公布。

下載的內容實際上是什麼？

先從規模談起，因為這是最先決定這個模型究竟能不能讓你使用的因素。混合精度配置幾乎能完全解釋這個數字，這是個好跡象，表示公開的數據彼此一致，而不是行銷文案。

• 檢查點拆分 — 第 0 到 39 層使用 NVFP4 專家，第 40 到 47 層使用 MXFP8 專家，依照 SGLang cookbook。

• 預測大小——以每個參數平均 5.33 位元計算，在那個 40/48 與 8/48 的拆分下，594B 個參數會得到 396 GB。

• 實測大小 — 主儲存庫為 393.5 GB，包含分詞器與設定檔。

• MXFP8 儲存庫 — 622.8 GB，而 safetensors 索引計入 612.4B 個儲存參數，相較之下主要儲存庫為 383.1B，因為將專家權重打包為四位元會減少計入的元素數量，而非模型本身。

底層架構是一個 48 層的僅解碼器 Transformer，搭配稀疏混合專家前饋區塊：384 個路由專家、每個 token 啟用 8 個、隱藏寬度 4,608、48 個注意力頭對應 8 個鍵值頭且每個維度為 128，以及 201,024 個 token 的詞彙表。注意力是混合式而非統一式——48 層中有 40 層使用 1,024 個 token 的滑動視窗，只有 8 層是全域，長上下文預算正是來自這裡。視覺塔是一個獨立的 23 層 Transformer，隱藏寬度 1,024、16 個頭，讀取 20×20 像素的區塊並以 2×2 合併，因此每個影像 token 涵蓋 40×40 像素的區域；卡片要求影像每邊介於 40 到 4,096 像素之間。

另外還接上一個多 token 預測頭，用於推測式解碼——五層、區塊大小為 8、Markov 秩為 256，目標層位於 5、11、17、23、29、35、41 以及最終區塊。這些正好就是那八個全域注意力層，而這個細節告訴你：草稿頭是圍繞混合堆疊設計的，而不是事後才加上去。Thinking Machines 將產生的解碼器稱為「DSpark」。

有一項行政事項要提醒任何法務審查會要求書面文件的人：授權在模型卡的中繼資料中宣告為 Apache 2.0，且模型卡會連到標準條款，但儲存庫目錄樹中沒有 LICENSE、LICENSE.md、LICENSE.txt 或 NOTICE 檔案。這四個檔案都找不到。這項宣告確實存在，而且明確無疑；大多數法務團隊預期會找到的那份文件並不在那裡。

硬體清單，以及廠商與操作指南說法不一致之處

模型卡給出的是 VRAM 下限。服務配置方案給出的是拓撲。它們不是同一個數字，而兩者之間的差距是這頁上最實用的重點。

• NVFP4 主要組態 — 至少 500 GB 的彙總 VRAM；該顯示卡的範例為 2× B300 或 4× H200。

• MXFP8 版本 — 至少 800 GB；例如 4× B300 或 8× H200。

• SGLang，各 GPU 拓撲 — GB200、GB300 與 B300 採用 TP 4 / EP 4；B200 採用 TP 4 / EP 4，建議使用 TP 8 以保留 KV 餘裕；H200 搭配 NVFP4 採用 TP 8 / EP 8；MI350X 與 MI355X 採用 TP 8 / EP 8；Vera Rubin 採用 TP 4 / EP 4；TPU7x 在四晶片主機上採用 8 / 8。

• 在 B200 或 GB200 上使用 MXFP8 — TP 8 / EP 8，每顆 GPU 約有 151 GB 的權重。

• 這一切背後的限制條件——專家並行必須等於張量並行，因為 NVFP4 的專家啟用縮放係數涵蓋每個專家的完整輸入寬度，無法進行張量並行分片。

所以這張卡 4× H200 的範例雖然達到 500 GB 的下限，但這並不是 cookbook 驗證過的拓撲；H200 在清單上是以 8 路列出的。儲存與記憶體下限只告訴你裝不裝得下，卻不會告訴你跑不跑得動；而對這個 checkpoint 來說，在多數人手上的硬體上，第二個數字是第一個數字的兩倍。如果你正在做資源配置，請照著 recipe 規劃，而不是照著下限。

AMD 路徑才兩天，尚未合併

讓這篇報導浮現的雷達，抓到的是 AMD 支援的 pull request，而不是權重釋出；而單就這個 PR 本身，誠實的定位是：它是引擎層面的工作——那種不算新聞的東西。它在這裡之所以重要，只是因為它與 checkpoint 在同一週落地，而且它是第二家擁有容器映像的晶片廠商。

此拉取請求為 MI350X 與 MI355X 新增 gfx950 支援，並疊加在基礎的 Inkling 2 Small 移植之上。變更內容：ROCm 核心位於獨立的 *_hip.py 模組中，僅在 HIP 下才會觸及，CUDA 與 NPU 路徑未受影響；統一 KV 池與全圖預填成為啟動預設；MegaMoE 會被拒絕而非嘗試；除非環境旗標允許，否則忽略 quick-reduce 量化。除非第二個環境變數覆寫，否則需要 gfx950——這意味著 MI300 等級的顯示卡會在啟動時被拒絕，而 PR 作者表示 gfx942「尚未執行過」。

PR 中的測量數據是作者自行提供且未經審查的：在單一 MI350X 上通過 426 項單元測試，在 balanced effort 下於 GSM8K-200 上達到 98.0%，而在接受長度為 4.04 時使用 DSpark 達到 97.5%；在輸入 2,048、輸出 512 時，每個輸出 token 的時間在 balanced 下為 5.15 毫秒，而使用 DSpark 時為 2.10 毫秒。換算下來，在八個加速器上的單一資料流中，約為每秒 194 與 476 個輸出 token。啟用 AITer 後，準確率數字變為 97.5% 與 96.5%。

此 PR 的狀態為草稿。CI 尚未在其上執行——基礎作業因缺少標籤而受阻，且針對待審查的提交沒有記錄到任何 AMD 執行——而所有列出的程式碼擁有者仍在等待審查。請將 MI350X 支援視為本週可從原始碼建置的東西，而不是可購買的產品。

提供它指的是開發用映像檔，而不是正式發行版

兩大主流堆疊都具備首日支援，但兩者都尚未正式推出。SGLang 明確表示，目前尚未在任何發行版中提供支援，並指向 dev-inkling-2-small 建置，Hopper 與 Blackwell、Vera Rubin、MI35x 及 TPU7x 各有獨立映像檔。vLLM 要求使用 nightly 或更新版本，或使用 vllm/vllm-openai:inkling-2-small 映像檔。對這種規模且如此新的模型來說，這很正常，但這改變了「支援」的含義：你追蹤的是一個分支，而 rebase 可能弄壞你的部署。

真正會造成問題的操作細節：

{{1}}背景{{/1}} — vLLM 的 TP 4 方案在單一托盤上上限為 262,144 個 token；完整的 1,048,576 token 視窗則需要跨兩個節點的 TP 8。在 TP 4 下，單一 1M token 請求需要 64.47 GiB 的 KV 快取，這超過單一托盤剩餘的容量。

• 推測解碼 — SGLang 使用內附的 DSpark head，每步驗證 8 個 token；vLLM 的對應機制則以機率式草擬設定 7 個推測 token。該配方警告，若採貪婪式草擬，在溫度 1.0 下接受率會下降 15% 到 25%。

• 解析器 — 推理使用 inkling，工具呼叫使用 inkling2；若未設定，SGLang 會自動選取兩者。vLLM 的工具呼叫解析器需選擇性啟用，而該配方指出工具呼叫尚未進行端到端基準測試，僅做過單元測試。

預填充/解碼分離 — 僅在四 GPU GB300 托盤上以 1P1D 驗證，NVFP4，無 MegaMoE，且靜態記憶體比例被迫下調至 0.86，因為自動的 0.963 值會記憶體不足。此拆分不適用於 MXFP8 檢查點。

• 編碼器 disaggregation（拆分解耦）——尚未納入映像中，而且若無法連上任何狀態良好的編碼器，語言伺服器就會停止運作。

• 記憶體餘裕——在 TP 4 的 192 GB B200 或 GB200 元件上，KV 容量約為 GB300 托盤所能提供的三分之一；長上下文併發的真正限制是這個，而不是卡上標示的視窗大小。

模型卡本身也有一則社群回報，來自上傳後最初幾小時，標題為「Hopper 卡目前與 vllm 映像檔不相容」。看不到維護者回覆，我也無法重現，因此請把它視為警示而非已確認的發現，並在提交 Hopper 節點前先檢查。SGLang 那邊確實列出 H200 的 8 路配置，所以 Hopper 路徑並未關閉——只是不是 vLLM 配方所描述的那條路徑。

自架主機的成本是什麼，以及為什麼答案很少是價格

下載 394 GB 的理由是控制權，而非單位經濟效益，而算一下就能很快看出這一點。

在 Tinker 上，模型定價為每百萬輸入 token 0.30 美元、每百萬快取輸入 token 0.03 美元、每百萬輸出 token 1.00 美元，上下文為 256K。Artificial Analysis 測得每秒 84 個輸出 token，首個回答 token 耗時 67.71 秒；每個索引任務 1.18 美元、每項任務 29.6 分鐘，整套測試的輸出 token 數為 154M，而同業中位數為 89.8M。這個 token 數量就是線索：這是一個回答前會長時間思考的模型；若按輸出列表價計算，單一條串流全速運行一小時會產生約 302,000 個 token，也就是大約 30 美分的輸出。要勝過每小時一美元的節點，你需要讓約四條串流保持忙碌；要勝過每小時二十美元的節點，則需要六十六條。很少有評估工作負載——代理式工作負載更是少之又少——能對一個首 token 時間達 67 秒的模型維持那樣的併發量。

改為自行擁有權重，你換到的是：以你自己的條件使用完整的 1M 視窗，而不是 Tinker 的 256K 服務層級；生產環境前不必排 beta 候補；可在自己的技術堆疊上進行微調；資料永遠不離開你的網路；以及不按 token 計費的評估掃描。你放棄的是：可運作的發行版建置、必須買而不是租的八路拓撲，以及你現在得自行維護的服務堆疊。

這就是這項決策最誠實的樣貌，也正是路由層適合發揮作用的地方，不必被要求假裝它託管了實際上並未託管的東西。Inkling 2 Small 不在 OrcaRouter 目錄中——我們本週查了即時模型清單，215 個模型裡沒有 inkling 條目——因此這個模型的 API 路徑仍落在 Thinking Machines 自家的 Tinker 平台，以及依據發布更新所說的數家第三方推論供應商。至於用單一金鑰存取超過 200 個模型確實能給你一條退路：你可以用單一節點執行自架實驗，並讓生產環境繼續使用我們確實有提供路由的模型；若實驗崩潰，會有自動容錯轉移；而對於我們有提供路由的模型，供應商列表價格會原樣傳遞。當第二家與第三家託管商也支援這些檢查點時，容錯轉移這條路就不再只是理論——而原本作為下載 394 GB 主要理由的供應商鎖定，也會隨之減弱。

既然它已經打開，它現在位於何處

權重釋出時，分數並沒有改變；改變的是，它現在進入了先前被排除在外的排行榜。在 Artificial Analysis 的開放權重排名中，Inkling 2 Small 以 31 的 Intelligence Index 在 28 個模型中排名第四，而比較組的中位數為 24。

• Kimi K3.1 Pro — 46.

• DeepSeek V4.1 Flash 1017 以最高努力程度 — 33。

• GLM-5.3 以最高強度 — 32。

• Inkling 2 Small — 31.

• MiMo-V2.6-Pro 與 Ling 3.1 Flash 1019 — 各 30 個。

• Mistral Large 4 在高強度模式下 — 26。

• Qwen3.8 27B 於 xhigh — 20.

那份清單中值得注意的一欄並不是最頂端。Inkling 2 Small 之上的每個模型都來自中國實驗室，而來自非中國實驗室的最佳開放權重模型是 26 分的 Mistral Large 4。開放這些權重會把這個特定差距從 20 分縮小到 15 分，並改變非中國欄位的最頂端。它並沒有觸及前沿：最佳開放模型仍領先 15 分，而封閉模型還要更遠。

廠商自家的評估表更長、也更美化，而且其中每一個數字都是 Thinking Machines 用自家測試框架在高強度設定下跑出來的——未經重現，因此是上限而非預期。對代理式工作真正重要的幾項是：SWE-bench Pro v2 Hard 86.3%、DeepSWE v1.1 72.1%、Vibe Code Bench v1.1 81.6%、BrowseComp 90.2% 與 DeepSearchQA 90.9%（兩者皆搭配壓縮）、MCP Atlas 完整版 85.4% 與公開版 85.0%、HLE 純文字 44.1%、FrontierCode v2.0 25.4%。反向的一項則是 Terminal Bench Science 的 5.7%，這個數字絕對值偏低，與其說是廣泛能力的主張，不如說符合長時程、長思考的特性。廠商在 Intelligence Index 印出 30.6，而即時榜單顯示 31——這是快照差異，並非爭議。

什麼會改變這項評估？

三件事，按重要性排序。

原本應該為這次發布把關的安全流程並未公開。Thinking Machines 七月關於通往開放權重之安全路徑的文章描述了四個外部組織對第一代 Inkling 進行部署前測試，而 11 月 5 日的發布文章則將這次發布與「外部安全測試與紅隊演練」連結起來。11 月 12 日宣布權重的更新只有一句話和一個連結——指向 Hugging Face 儲存庫——沒有評估結果、沒有紅隊演練發現，也沒有修訂先前的條件。這不代表測試沒有發生。這代表讀者無法查核，而有採購政策要求提供證據的組織在這裡也找不到。

正式發行等級的支援會改變誰能採用它。目前的选择是 SGLang 的開發分支、vLLM 的 nightly 版本，或從尚未合併的草稿自行建置 AMD 路徑。一旦支援進入有正式標籤的發行版，這個模型就成為部署決策，而非工程專案，八路拓撲也不再是研究用配置。

在預設設定下進行獨立重現，會讓你了解 31 在實務上究竟有多少價值。agentic 列才是最值得關注的——SWE-bench Pro 的 86.3 與 DeepSWE 的 72.1，對一個擁有 17B 活躍參數的模型而言是很有力的說法，而且這些成績是在最高投入下產生的。第三方在預設投入下的執行結果總是較低。問題是低了多少，而 Thinking Machines 之外還沒有人回答這個問題。

在至少其中一項真正落地之前，對 Inkling 2 Small 的正確描述異常精確：這是一個你今天就能下載的 Apache 2.0 檢查點，卻沒有任何已發布的服務堆疊支援；它最強的主張來自打造它的實驗室；而其授權關卡在原本應先行的文件作業尚未完成的情況下就開啟了。那是真正的發布，也是真正的缺口，而缺口才是值得關注的部分。