2026 年 4 月 29 日,IBM 發布 Granite 4.1 模型家族: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
Granite 4.1 全系列回到稠密架構(GQA、RoPE、SwiGLU、RMSNorm、tied embeddings),沒有 MoE 路由,沒有稀疏層。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 為 92.5、30B 為 94.2。上下文 8B 與 30B 達 512K,3B 上限 128K。稠密的好處很實際:架構簡單、容易微調、每 token 計算量可預測。
刻意拿掉推理模式
Granite 4.1 沒有 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。
不只語言模型
4.1 家族不只是 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 可跑消費級機器,用自己的負載實測,永遠快過相信排行榜。
參考來源
- The IBM Granite 4.1 family of models — IBM Research
- Granite 4.1 LLMs: How They’re Built — Hugging Face
- Granite 4.1: IBM’s 8B Model Matching 32B MoE — Firethering
本文由 AI 協助自上述來源整理，經人工審核後發布。