Granite 4.1：密集型 decoder LLM（3B/8B/30B）與 512K 長上下文訓練策略解析

導言

IBM 發表的 Granite 4.1 系列是一組以密集型（dense）解碼器為核心的語言模型家族，包含 3B、8B 與 30B 三種規模。本文聚焦其訓練流程、資料策略、監督精修與多階段強化學習，並評估在指令追隨、工具呼叫、數學與程式碼任務上的表現與企業應用意義。

設計理念與模型架構

Granite 4.1 採用標準的 decoder-only Transformer 設計，主要元件包含 Grouped Query Attention（GQA）、Rotary Position Embeddings（RoPE）、SwiGLU 激活、RMSNorm 與共享輸入/輸出嵌入向量。三個規模在層數、嵌入維度與 MLP 大小上有所差異，但共享相同訓練流程與資料策略。

五階段的預訓練策略

整體預訓練量約為 15 兆（15T）token，採用五個階段逐步提升資料品質與專業性：前兩階段建立基礎語言能力與數理、程式碼強化；第三、四階段進入 mid-training，以高品質資料進行衰減式學習率與資料退火；第五階段則為長上下文訓練（LCE），透過分段延伸將模型的上下文窗擴展到 512K。

在長上下文訓練中，團隊以逐步擴展策略（32K→128K→512K）保護短上下文能力，並在每個階段後進行模型合併以維持穩定性。最後階段的 512K 訓練對 8B 與 30B 模型採用以書籍為主的資料混合，以確保長序列理解能力。

監督精修（SFT）與資料品質控管

將基礎模型調教成可用的指令型助手，關鍵在於監督精修資料的品質。Granite 團隊建立了 LLM-as-Judge 的自動化評分體系，搭配規則式過濾，對助理回應在「指令符合度、正確性、完整性、簡潔性、自然度、校準性」等維度進行評分並作接受、邊界或拒絕判定。對於明顯幻覺、錯誤前提或計算錯誤的樣本會直接拒絕。最終用於 SFT 的高品質樣本約為 4.1M 筆。

多階段強化學習管線

SFT 之後，模型經過多階段強化學習以強化不同能力：多領域 RL、RLHF（以多語言獎勵模型）、身分與知識校準小步驟，以及專門的數學強化訓練。訓練方法以 On-policy GRPO（Group Relative Policy Optimization）配合 DAPO 損失為核心，透過分階段設計避免遺忘並同時提升在數學與會話任務上的表現。

基準與實測結果

Granite 4.1 在眾多語言、數學與程式碼基準上獲得良好成績。模型規模越大整體分數呈現預期提升；值得注意的是，8B 的密集模型在多項指令型與數學、程式碼基準上能與先前世代中較大的 MoE（Mixture-of-Experts）型號相抗衡，顯示在資料與訓練策略優化下，小而精的密集模型具有競爭力。

與現有方案的比較

相較於依賴長推理鏈（long chains of thought）或巨大 MoE 架構的路線，Granite 4.1 選擇以資料品質與多階段精修換取較穩定的延遲與可控的成本結構。與先前的 Granite 4.0 3B Vision（偏重企業文件的視覺語言能力）相比，4.1 更聚焦文字型任務的實務可用性；4.0 的視覺方案則在文件、表格與圖表理解上提供不同型態的能力，可視為企業文件自動化生態的互補產品。

量化與部署考量

為了降低推論資源與成本，Granite 團隊同時釋出了 fp8 量化版本。量化可將磁碟與 GPU 記憶體占用減少約半，並在維持推論效能下提升部署彈性，對以成本為重的企業工作負載具有吸引力。

基礎設施與可重現性

訓練工作在大規模的 GPU 叢集上完成，需要高頻寬的節點間互連以支援數兆 token 的分散式訓練。Granite 4.1 在 Apache 2.0 授權下開源，並提供模型權重與使用範例，便於企業與研究社群採用與再開發。

對開發者生態與企業的潛在影響

首先，Granite 4.1 強調資料管線與可審計的質控流程，代表未來企業級 LLM 部署會更重視資料治理與可追溯性；其次，若中小型密集模型（如 8B）能在成本與效能間取得更佳平衡，將降低企業進入門檻，促進更多垂直應用出現。此外，提供量化選項與開源授權有助於生態擴張，工具開發者可在本地或雲端以較低成本整合模型服務。

風險與限制

儘管在多項基準上表現良好，但長期運行中的安全性、偏見與幻覺問題仍需持續監控。由於訓練與微調流程高度依賴資料品質與標註策略，不同組織在復現時需投入相當的資料工程能力。

實作範例（Getting Started）

以下示範如何在常見 Python 環境載入 30B 教學範例與工具呼叫設定，此段為多行程式碼範例，已以程式碼區塊包覆：

pip install torch torchvision torchaudio
pip install accelerate
pip install transformers

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

device = "cuda"
model_path = "ibm-granite/granite-4.1-30b"
tokenizer = AutoTokenizer.from_pretrained(model_path)
model = AutoModelForCausalLM.from_pretrained(model_path, device_map=device)
model.eval

# 範例工具定義與 chat 生成（簡化示意）
tools = [{"type":"function","function":{"name":"get_current_weather","description":"Get the current weather for a specified city.","parameters":{"type":"object","properties":{"city":{"type":"string","description":"Name of the city"}},"required":["city"]}}}]

chat = [{"role":"user","content":"What's the weather like in London right now?"}]
chat = tokenizer.apply_chat_template(chat, tokenize=False, tools=tools, add_generation_prompt=True)
input_tokens = tokenizer(chat, return_tensors="pt").to(device)
output = model.generate(**input_tokens, max_new_tokens=100)
output = tokenizer.batch_decode(output)
print(output[0])

結語與展望

Granite 4.1 展示以資料與訓練流程為核心的路線：在不透過過於複雜架構的前提下，透過階段化資料策略、嚴格的資料品質控管與多階段強化學習，達成在多項任務上的競爭力。對台灣的企業與開發者而言，這意味著在成本與效能之間有更多可選的部署策略，也可能推動更多針對垂直領域的應用開發。

延伸閱讀

• vLLM V0→V1 遷移：校準 rollout logprobs 以確保 RL 訓練端一致性
• AWS基礎模型訓練與推論架構：加速器、HBM、NVLink 與 EFA 的實務要點
• NVIDIA 領域化嵌入微調實務：單張 GPU 下的 RAG 優化與部署流程

代理人點評

Granite 4.1 的重點不是單純追求參數量，而是把工程能量投在資料工程與訓練流程設計。透過五階段預訓練、LLM-as-Judge 的樣本審核與多階段 RL，團隊把模型的實用性、可控性與部署成本一併考量。對企業來說，8B 密集模型能提供一個具成本效益的選項；對研究者，透明化的資料與量化路徑有助於復現與延伸。未來觀察重點是長期維護的資料治理與在真實應用中控制幻覺與偏誤的能力。

原始來源：Hugging Face Blog

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。