摘要: IBM 於 2026 年 4 月 29 日推出 Granite 4.1,包含 3B、8B、30B 三種 Apache 2.0 稠密模型。官方自報評測宣稱 8B instruct 穩定追平或超越前代 32B MoE,BFCL V3 分數為 68.3 對 64.7。家族刻意不內建推理模式,以換取可預估延遲與成本,但文章提醒這些比較出自 IBM 自家 harness。
Granite 4.1 是 IBM 在 2026 年 4 月 29 日推出的模型家族,成員為 3B、8B 與 30B 三種尺寸,清一色是 decoder-only 的稠密語言模型,權重同樣掛在 Apache 2.0 之下。最搶眼的宣稱只有一個:8B instruct「穩定追平或超越」自家前代的 32B MoE(Granite 4.0-H-Small)——在工具呼叫評測 BFCL V3 上,8B 拿下 68.3,高於前代的 64.7。
2026 年的發表會由推理模型領銜,各家比的是誰的思考鏈更長,IBM 卻選了相反的方向:Granite 4.1 從設計上就不給推理模式,寧可放棄「思考」,也要把延遲與成本固定在可預測的區間——這正是企業部署最在意的痛處。開源陣營的路線分歧,也因而多了一個具體例證。
稠密架構回歸:8B 對上 32B MoE
這一代全線捨棄 MoE,改走純稠密設計(GQA、RoPE、SwiGLU、RMSNorm、tied embeddings),整個堆疊裡找不到路由器或稀疏層。IBM 公布的自家評測是這樣的:BFCL V3 項目中,3B 得分 60.8,以些微之差壓過參數量將近兩倍的 Qwen3-8B(60.2);30B 繳出 73.7,贏過 Gemma-4-31B 的 72.7;IFEval 部分,8B 的 87.1 與 Qwen3.5-9B 的 87.2 幾乎並駕齊驅;GSM8K 方面,8B 與 30B 分別錄得 92.5 和 94.2。上下文長度上,8B 與 30B 都可達 512K,3B 則止步於 128K。選稠密的理由很務實:結構單純、微調門檻低、每個 token 會耗掉多少算力,事先就能估出來。
推理模式:設計階段就排除
這個家族不內建 chain-of-thought——缺的並非工程進度,而是一項寫進設計的取捨。IBM 的說法很直白:企業場景倚賴的是延遲可預估、token 消耗穩定、開銷壓得夠低,冗長的思考鏈會把這三件事一次全毀。耐人尋味的是,訓練語料並沒有迴避 Long CoT(第三階段約佔 12.5%),只是模型在推論時不會把這段思考輸出。另外備有 FP8 量化版本(只量化線性層),記憶體佔用大約砍半,效能多半保得住,並以 vLLM 為調校目標。
15T tokens 的預訓練與四階段 RL
預訓練吃進約 15T tokens,分五個階段推進:首階段規模 10T,組成以 CommonCrawl 為大宗(約 59%),程式碼佔 20%、數學佔 7%;第二階段把數學與程式碼分別拉到 35% 和 30%;第五階段處理上下文延伸(32K → 128K → 512K),且每個階段結束都接一次 model merge,避免短上下文能力被訓練沖掉——如此坦白的工程披露並不多見。後訓練先交給 LLM-as-Judge 按六個維度打分,藉此留下約 410 萬筆 SFT 樣本,凡涉及幻覺、錯誤前提或算錯的樣本一律剔除;接著進入四階段 RL(on-policy GRPO、DAPO loss):RLHF 一役讓 AlpacaEval 平均竄升約 18.9 分,代價卻是數學能力受創,於是第四階段專責收復失土——GSM8K 拉回約 3.8 分,DeepMind-Math 更彈回約 23.5 分。整套訓練跑在 CoreWeave 的 NVIDIA GB200 NVL72 上。
家族版圖不僅限於語言模型
這次登場的不僅是 LLM。Granite Speech 4.1 是一款 2B 語音模型,詞錯率壓到 5.33%,擠進 OpenASR 排行榜前段班,另有主打吞吐量的 NAR 版本;Granite Vision 4.1 專攻文件理解,強項在表格、圖表與鍵值抽取,伴隨釋出百萬級圖表資料集 ChartNet;Guardian 4.1 是以 8B 為基礎的審核模型,可搭配任何 LLM,負責抓出偏見、幻覺與越獄;再加上涵蓋 200 多種語言的 Granite Embedding Multilingual R2。權重取得管道含 Hugging Face(ibm-granite)、Ollama、watsonx、OpenRouter 等平台,vLLM、SGLang、llama.cpp 也都在支援之列。整個家族都能落地在企業自己的環境裡運行,這條路線正好與我們年初記下的開源分歧相互呼應(2026 開年觀察)。
怎麼解讀這些自評分數
Firethering 的第三方分析先立起必要的但書:前述每一組對比皆出自 IBM 自家的評測 harness;趨勢固然與第三方結果吻合,方法論本身仍該拿出來檢視。另一種持平的讀法是:8B 能贏過 32B MoE,既證明 4.1 的資料工程有料,也暴露 4.0 的 MoE 做得不夠到位——「大概兩者都是」。開發者要的答案不複雜:Apache 2.0 授權、512K 上下文、3B 在消費級機器上就跑得動,拿自己的工作負載親手實測一輪,永遠比盯著排行榜可靠。
