Thinking Machines 開源 Inkling：975B/41B 稀疏 MoE 多模態模型

看完這篇之後，你會知道稀疏 MoE（Mixture-of-Experts）怎麼把一顆 975B 參數的模型，壓成每個 token 只算 41B 的實際運算量；也會知道 Inkling 的 66 層 decoder 內部長什麼樣、它吃得下哪些輸入、吐得出什麼、以及你要自己把它跑起來，實際有哪些路可以走。

「前沿模型只能租 API」這個假設，從哪裡來

過去兩年，如果你想用一顆前沿等級的多模態模型——同時吃得下文字、圖片、聲音，還能寫扎實的程式碼——幾乎只有一條路：找一家大廠，付月費，打他們的 API。權重不會給你，架構細節模糊帶過，你能做的最多是調 prompt、調 system message，模型本身是一個黑盒子。這不是誰的陰謀，是算力現實：能把一顆數百 B 參數的模型訓好又跑穩的團隊沒幾家，他們自然傾向把模型包成服務賣，而不是把權重直接公開。對打 API 的一方來說，這也代表成本結構完全綁在對方的定價策略上——對方漲價、限流，或直接下架某個模型版本，你能做的只有被動接受，換一家繼續打 API。

Inkling 打破的正是這個預設的其中一半。Thinking Machines Lab 把這顆模型的權重，連同 model card 上的完整規格，直接放上了 Hugging Face，授權是「License: apache-2.0」——這代表你不只能免費拿去用，還能修改、微調、包進自己的產品裡再散布出去，不需要回頭問誰要授權。model card 上同時列出可以直接拿來部署的開源工具：SGLang、vLLM、TokenSpeed、Unsloth、Hugging Face Transformers。換句話說，這不是一份論文或一張成績單，是一份你可以拿去對著自己機房排產能的規格表。

這類釋出在過去並不常見，原因不難理解：訓練一顆前沿等級的模型，成本本身就是門檻，而如果把權重全部公開，任何人都能直接部署、微調，原本仰賴 API 計費的生意模式就少了一層保護。多數團隊選擇的折衷，是把模型包成服務，只留一個輸入框跟一支帳單。Inkling 選的是另一條路。

但「拿到權重」跟「跑得起來」中間還有一段路要走——這段路的起點，是先搞懂 Inkling 為什麼是 975B 總參數，卻只用 41B 活躍參數就能跑。這個落差，才是這篇文章真正要講的東西。

把 975B 參數擺上桌，為什麼不能整個跑起來

先把稠密（dense）模型的算法拿出來對照一次。一顆標準的 dense transformer，不管是 66 層還是 96 層，每一層的 feed-forward 子層都是同一組權重——處理每一個 token，都要把這一層的全部參數拿出來做矩陣乘法。這代表模型的總參數量跟每個 token 實際要算的量，是同一個數字：模型多大，算力就要多大，沒有折扣可打。

這件事對一個 975B 參數等級的模型意味著什麼。先不談訓練，只談推論（inference）——把權重全部載進顯存，再對每一個輸出的 token 都跑一次 975B 參數規模的矩陣運算，這個吞吐量會慢到大部分應用場景都等不起，顯存需求本身也已經是一般團隊負擔不起的等級。這正是為什麼過去幾年前沿模型即使釋出，也很少有 dense 架構做到千億參數以上還維持著「大家都跑得起」的期待——dense 架構的規模跟成本綁在同一條直線上，沒有妥協空間。

這裡的成本不只是「算得動」——顯存頻寬同樣是瓶頸。每算一個 token，都要把當下這一層要用到的權重從顯存搬進運算單元一次；模型越大，每個 token 要搬的資料量就越大，吞吐量的上限就被這條資料搬運的速度卡住，不是被算力卡住。這也是為什麼參數量跟每個 token 的成本，在 dense 架構下永遠是同一個數字——沒有辦法讓其中一個變小、另一個維持不變。

Inkling 沒有選 dense。它選的是稀疏 MoE（Mixture-of-Experts）——一種讓模型的總容量，跟每個 token 實際要算的量脫鉤的架構。975B 只是模型裡存在的知識總量，不是每次算一個 token 要動用的量。要理解這怎麼做到，得先把 MoE 的路由機制，從零講一次。

稀疏 MoE：只啟動一部分參數的 transformer

普通的 dense transformer，每一層的 feed-forward 子層是一整塊權重，誰來都要過這一塊。MoE 的做法是把這一整塊拆成很多份「專家」（expert）——每個專家是一個獨立的小型 feed-forward 網路，擁有自己的一組權重。層裡再加一個路由器（router）：路由器看過這個 token 的表示法之後，決定要把它送去哪幾個專家處理，而不是全部專家都算一遍。

這就是「稀疏」兩個字的意思：專家的總數量可以很多、總參數量可以很大，但任何一個 token 實際走過的專家只有一小撮。模型「知道」的東西（全部專家加起來的知識）跟模型「這一步算」的東西（被路由到的那幾個專家），是兩件事。這種設計在近幾年的稀疏 MoE 模型裡越來越常見——除了被路由挑中的專家之外，通常還會保留一到兩個「共享專家」（shared expert），這種專家不經過路由篩選，每個 token 都會經過，用來承擔比較通用、每個 token 都用得到的計算，讓被路由挑中的專家可以專心處理比較特化的部分。

這種設計解決的是一個老問題：模型的容量（能記住、能分辨多少不同的模式）理論上應該跟參數量成正比，但如果每次都要把全部參數拿出來算，容量跟算力就被綁死在一起——想要更大的容量，就得付出等比例的算力。稀疏 MoE 把兩者拆開：專家數量、專家大小決定容量的上限，路由器每次只挑一小撮出來，決定的是算力的下限。理論上可以繼續加專家、把容量往上堆，只要路由器挑選的數量跟共享專家數量不變，算力幾乎不會多花。

Inkling 的 model card 把這個機制寫得很具體：

「each token is routed to 6 of 256 experts, plus 2 shared experts active on every token」

翻成白話——這一層總共準備了 256 個專家，路由器幫每個 token 挑出 6 個來處理，另外再加 2 個不用挑、每個 token 都會過的共享專家。一個 token 實際走過的專家數量是 8 個，占 256 個裡的一小部分。這就是為什麼 975B 總參數可以壓成 41B 活躍參數——大部分的「專家」在任何一個瞬間都是閒置的，只有輪到它們被路由挑中，才會被真正用上。

Inkling 內部長什麼樣：66 層、256 選 6、2 個常駐專家

把上面的機制套進 Inkling 實際的架構數字裡，會拼出一張完整的圖。model card 寫明這是一個「66-layer decoder-only transformer」——66 層，每一層都重複同一組子層設計。attention 的部分，model card 只寫了一句「Attention is a hybrid of local and global layers」：有的層只看鄰近的一段序列（local），有的層看得到整個序列（global），兩種都存在、混著用，但確切的排列規律沒有公開，不必猜。

為什麼要混著用兩種 attention。只看局部窗口的 local attention，運算量隨序列長度線性增加，划算，但看不到窗口外的東西；看得到整個序列的 global attention，能抓到很遠的關聯，但運算量隨序列長度成平方增加，序列一長就變貴。把兩種混在同一個 66 層的堆疊裡，是想同時要兩邊的好處——大部分層用便宜的 local，省下來的算力，留給少數幾層做真正需要看全局的 global。這是業界近年常見的組合，不是 Inkling 獨創，只是 model card 沒有公開它實際怎麼分配這兩種層。

下面這張圖把整條路徑拆成四個元件，點下去看每一個元件實際負責什麼、又不知道什麼。

點擊任一元件看它的責任與不知道的事 · 4 個元件

輸入嵌入層 · 責任

把文字（UTF-8）、圖片、音訊分別轉成模型看得懂的 token 序列，餵進後面的 66 層 decoder。

不知道：後面每一層要怎麼路由、會用到哪個專家。

Hybrid Attention · 責任（66 層）

每一層都要決定這個 token 該往回看多遠——66 層裡有的看局部窗口（local），有的看整個序列（global），兩種都存在、混著出現，但 model card 沒有公開確切的排列規律。

不知道：這個 token 之後會被路由到哪幾個專家。

MoE 路由器＋共享專家 · 責任

每一層的 FFN 子層都做同一件事：256 個專家裡選 6 個處理這個 token，另外 2 個「共享專家」不管路由結果，每個 token 都會經過。

不知道：前面 attention 算出的注意力分佈長什麼樣——它只認 token 帶著的表示法本身。

輸出文字頭 · 責任

把跑完 66 層之後最後一層的表示法，轉回文字 token——不管輸入當初是文字、圖片還是音訊，輸出永遠只有 UTF-8 文字。

不知道：輸入原本是哪一種模態。

「不知道」這一欄容易被略過，但正是這張圖真正想講的部分：每個元件只認得自己那一份輸入，不會去猜前後其他元件做了什麼。路由器不管 attention 算出的注意力權重長什麼樣，它只看 token 帶著的表示法本身；輸出頭不管輸入原本是文字、圖片還是語音，它只管把最後一層的表示法轉回文字。這種各管一段、不越界的設計，本身就是這條路徑可以疊到 66 層還維持穩定的原因之一。

用最粗略的方式描述這條路徑，大概長這樣（下面是示意寫法，不是 Inkling 真正的原始碼）：

for layer in range(66):
    x = hybrid_attention(x, kind=layer.attn_kind)  // local 或 global
    scores = router(x)                             // 對 256 個 expert 打分
    top6 = pick_top_k(scores, k=6)                  // 選出 6 個
    experts_to_run = top6 + [shared_1, shared_2]    // 加 2 個常駐
    x = sum(e(x) for e in experts_to_run)

output = text_head(x)   // 只還原成文字

這段假想程式碼裡藏著一個容易忽略的細節：8 個專家（6 個路由挑的加 2 個常駐）要跑完之後才加總，不是二選一。所以「41B 活躍參數」這個數字，包含的是這 8 個專家的參數量，加上 attention 層、embedding 層這些每個 token 都要過的非專家部分。model card 沒有把這條算式拆給你看——這裡只能確認 41B 是官方給的活躍參數總數，沒辦法從 256 選 6 加 2 這個比例反推出精確的算式。

吃得下文字、圖片、語音，只吐文字——以及部署這件事

架構之外，Inkling 的 model card 把輸入輸出的模態也寫得很明確：

「general-purpose multimodal model that accepts text, image and audio inputs and generates text outputs」

文字用 UTF-8 編碼；圖片是「any pixel-based format」，邊長建議（ideally）落在 40px 到 4096px 之間；音訊要 WAV 格式、16kHz 取樣率，長度建議（ideally）在 20 分鐘以內。輸出只有一種——「generates output as UTF-8 encoded text」，不管輸入當初是哪一種模態。

「建議」這兩個字要留意——model card 用的是 ideally，不是「僅接受」或「超出會報錯」。這代表 40px 到 4096px、20 分鐘這些數字，是官方建議的舒適區間，不是寫死的硬邊界。下面的滑桿可以拖動，看這兩條輸入邊界實際落在哪裡：

拖動兩條滑桿，看輸入邊界落在哪裡 · 2 組滑桿

圖片邊長 1024px · 在建議範圍內

音訊長度 10 分鐘 · 在建議範圍內

三種輸入模態最後匯進的是同一組 decoder——不管進來的是文字、圖片還是語音，都被轉成同一種 token 表示法，送進前面講過的 66 層 hybrid attention 加 MoE 路由，最後只有一條路可以出去：文字。

文字輸入（UTF-8）

圖片輸入（40 到 4096px）

音訊輸入（16kHz WAV，20 分鐘以內）

輸出：只有文字（UTF-8）

這裡有一段容易被忽略的落差：model card 另外寫了一句「Training data includes a broad variety of content types, including text, images, audio, video」——訓練資料裡有影片，但輸入模態清單裡沒有影片。訓練時看過的模態範圍，比推論時真正吃得下的輸入模態範圍更廣。model card 沒有解釋這個落差的原因，這裡也不替它猜。這類訓練看過、推論吃不下的落差，在多模態模型裡不算罕見——訓練階段本來就會盡量塞進多樣的資料類型，能不能同時開放對應的推論輸入，是另一層工程決定，跟訓練資料的廣度未必是同一回事。model card 另外提到「We conducted safety evaluations ahead of release, spanning both everyday human-AI interaction and dangerous-capability testing」，只說明有做過安全評估，沒有公布評估方法或結果，這裡同樣不延伸。

分數的部分，model card 列出六項 benchmark：

benchmark	分數	測的是什麼
SWEBench Verified	77.6%	真實世界的軟體工程任務
SWEBench Pro	54.3%	進階、更長鏈的軟體工程任務
AIME 2026	97.1%	數學競賽題
GPQA Diamond	87.2%	研究生等級的科學問答
MMMU Pro	73.3%	多模態理解
VoiceBench	91.4%	語音理解

SWEBench Verified 跟 SWEBench Pro 測的是真實世界的軟體工程任務；AIME 2026 是數學競賽題；GPQA Diamond 是研究生等級的科學問答；MMMU Pro 測多模態理解；VoiceBench 測語音理解。六項橫跨 coding、數學、知識問答、多模態、語音——這張表想證明的事情很直接：開放權重不等於閹割版，這是一顆敢把分數攤在檯面上、跟緊閉源前沿模型放在同一張成績單上比的模型。六項橫跨五個不同能力面向，覆蓋的廣度本身就是一個訊號：這不是單一領域特化調校出來的分數，是同一顆通用模型在不同任務上分別交出的成績。要提醒的是，這些分數是 model card 自己公布的，不是第三方覆核過的結果。

部署的部分，model card 列出五個可以直接拿來自架的開源工具：

model card 列出的五個自架路徑

• SGLang

  為結構化生成設計的推論引擎，擅長處理多輪、多分支的生成流程。

• vLLM

  以 PagedAttention 聞名的高吞吐量推論服務框架，是業界最廣泛使用的自架服務選項之一。

• TokenSpeed

  model card 列出的第五個部署選項，公開討論較少，這裡不臆測它的技術細節。

• Unsloth

  專注於讓微調（fine-tuning）更省顯存、更快的工具鏈，適合想在 Inkling 上繼續微調的人。

• Hugging Face Transformers

  官方參考實現，通用但吞吐量通常不是這幾個選項裡最高的，適合先驗證正確性。

點選任一列看說明

SGLang

為結構化生成設計的推論引擎，擅長處理多輪、多分支的生成流程。

vLLM

以 PagedAttention 聞名的高吞吐量推論服務框架，是業界最廣泛使用的自架服務選項之一。

TokenSpeed

model card 列出的第五個部署選項，公開討論較少，這裡不臆測它的技術細節。

Unsloth

專注於讓微調（fine-tuning）更省顯存、更快的工具鏈，適合想在 Inkling 上繼續微調的人。

Hugging Face Transformers

官方參考實現，通用但吞吐量通常不是這幾個選項裡最高的，適合先驗證正確性。

權重、授權、部署路徑都齊了，剩下的問題是生態普不普及。中文技術部落格 gslin 在 7 月 17 日的觀察是：

「這是目前少數非中國的 open source license model，而且是能站上台的等級」

他也補上一句關於部署現況的觀察：

「看起來是有支援不少平台提供現成的服務，不過目前還沒在 OpenRouter 上看到」

按他的說法，這是目前少數非中國團隊釋出、站得上台面的開源授權前沿模型，但撰文當下，想直接透過現成的代管服務去試用，還沒有那條最方便的路。開放權重解決的是「能不能自己架」，生態普及解決的是「要不要自己架」——這是兩條進度不一樣的時間軸，前者已經到位，後者還在路上。

對一個台灣的工程團隊來說，這張規格表能拿來做的事很具體：先用 41B 活躍參數去估算顯存與吞吐量，看跟現有機房的 GPU 排不排得上；再對照 model card 列出的五個部署工具，挑一個跟現有推論棧相容的；最後拿六項 benchmark 當基準，跟現在正在付費的 API 模型比對，看差距是不是小到可以承受自架帶來的維運成本。這三個步驟只要有一步卡住，答案都可能是「還不到時候」——但至少現在有規格表可以拿來算，不是只能猜。

Take-away：Inkling 真正動搖的不是排行榜名次，是「前沿等級的多模態模型只能用 API 租」這個預設——975B 總參數、41B 活躍參數的稀疏 MoE 設計，配上 Apache-2.0 授權跟五個現成的部署工具，把「自己架一台前沿模型」從一句口號，變成一張可以拿去對著自己機房排產能的規格表。