エンタープライズ 記事 公開日 2026年4月29日

データエンジニアリング、事前学習（pre-training）、教師あり微調整（supervised fine-tuning）、強化学習の裏側を、Granite 4.1 LLMに向けて深掘りする技術ウォークスルー。

著者: Granite Team, IBM

---

TL;DR — Granite 4.1 は、密な（dense）デコーダのみの LLM ファミリー（3B、8B、30B）で、約 15T トークンを用いたマルチステージの事前学習パイプラインで学習されています。これには最大 512K トークンまでのロングコンテキスト拡張も含まれます。モデルはさらに、約 4.1M 件の高品質な厳選サンプルで教師あり微調整（supervised fine-tuning）を行い、また on-policy GRPO による強化学習を、DAPO 損失（Yu et al., 2025）を用いて実施しています。特筆すべき点として、より単純な密なアーキテクチャで、パラメータ数も少ないにもかかわらず、8B の instruct モデルは従来の Granite 4.0-H-Small（32B-A9B MoE）に匹敵するか、それを上回ります。なお、すべての Granite 4.1 モデルは Apache 2.0 ライセンスの下で公開されています。

リンク:

• Granite 4.1 HF コレクション
• GitHub リポジトリ
• Granite Docs

---

概要

高品質な小型言語モデルを構築することは、計算資源をスケールするだけでは不十分であり、学習を通じて厳密にデータをキュレーションする必要があります。Granite 4.1 では、データ量よりも品質を優先し、5 段階の事前学習ステージにわたってデータ混合比を段階的に洗練させました。さらに、LLM-as-Judge（LLM を審査員として用いる）フレームワークで教師あり微調整データを追加で厳選し、多段階の強化学習パイプラインを適用することで、数学、コーディング、指示追従、そして一般的なチャットにおける性能を体系的に強化しました。

---

モデル アーキテクチャ

Granite 4.1 のモデルは、デコーダのみの密な（dense）トランスフォーマーアーキテクチャを使用します。中核となる設計上の選択肢には、Grouped Query Attention (GQA)、Rotary Position Embeddings (RoPE)、SwiGLU 活性化、RMSNorm、および 共有された入出力埋め込み（input/output embeddings） が含まれます。

3 つのモデルサイズはいずれも同じ学習パイプラインとデータ戦略を共有しており、異なるのはアーキテクチャの次元（寸法）のみです。

---

事前学習（Pre-Training）

Granite 4.1は、5フェーズの学習戦略を用いて約15兆トークンでスクラッチから学習されます。フェーズ1〜2では基礎となる事前学習に焦点を当て、フェーズ3〜4では段階的に品質の高いデータをアニーリングしながら中盤の学習を行い、フェーズ5では長いコンテキスト学習を導入してコンテキストウィンドウを512Kトークンに拡張します。各フェーズでは異なるデータ混合比と学習率スケジュールを用い、幅広いWeb規模のデータから、より厳選された領域固有のコンテンツへと徐々に切り替えていきます。

図2: 5フェーズの事前学習パイプライン。フェーズ1〜2は事前学習、フェーズ3〜4は中盤の学習（高品質データのアニーリング）、フェーズ5は長いコンテキスト学習（LCE）です。

フェーズ1：一般的な事前学習（10Tトークン）

最初のフェーズでは、パワーの学習率スケジュールとウォームアップを用いた、一般的な学習データの混合によって広範な言語理解を確立します。

データ構成:

• CommonCrawl 約59% — 一般的なWebデータ
• コード 約20% — プログラミング言語およびリポジトリ
• 数学 約7% — 数学的推論データ
• テクニカル 約10.5% — 科学論文、技術ドキュメント、マニュアル
• 多言語 約2% — 非英語の言語データ
• 領域固有（Domain Specific） 約1.5% — 領域固有のコンテンツ

フェーズ2：数学／コードの事前学習（2Tトークン）

フェーズ2ではコードおよび数学データの割合が大幅に増え、一般的な言語カバレッジを維持しつつ、より強力な推論能力へと切り替えます。

データ構成:

• 数学 約35% — フェーズ1に比べて5倍増
• コード 約30% — 1.5倍増
• CommonCrawl-HQ 約12% — 高品質なCommonCrawlのサブセット
• 合成（Synthetic） 約9% — 合成の高品質データ
• テクニカル 約10%
• 多言語 約3%
• 領域（Domain） 約1%

フェーズ3：高品質データのアニーリング（2Tトークン）

フェーズ3では、よりバランスの取れた高品質な混合比と、指数関数的減衰の学習率スケジュールによって中盤学習（mid-training）へと移行します。ここから、チェーン・オブ・ソート（思考過程）と合成の指示データをブレンドし始めます。

データ構成:

• CommonCrawl-HQ 約16.67%
• 数学 約16.67%
• コード 約16.67%
• 合成（Synthetic） 約8.5%
• テクニカル 約12.5%
• 多言語 約4.5%
• 長いチェーン・オブ・ソート 約12.5% — 推論の軌跡
• 言語インストラクション 約7.5% — 指示チューニングデータ
• コード・インストラクション 約4.5% — 指示チューニングデータ

フェーズ4：高品質データ・アニーリング — 改良（0.5Tトークン）

第4フェーズでは、学習の途中から線形の学習率減衰をゼロまで継続し、利用可能な最高品質のデータにモデルを集中させます。

データ構成：

• CommonCrawl-HQ 約40%
• Code 約20%
• Math 約20%
• Long Chain-of-Thought 約6%
• Code Instructions 約5%
• Language Instructions 約9%

図3： 事前学習フェーズを通じてデータ混合がどのように変化するか。フェーズ1ではウェブ中心だったものが、フェーズ3〜4では指示データや推論データを含む、高品質なデータ中心へと段階的にシフトしている点に注目してください。

フェーズ5：ロングコンテキスト学習（LCE）

第5かつ最終フェーズでも、学習の途中から実施します。コンテキストウィンドウを 4K から 512K へと、段階的なロングコンテキスト拡張プロセスを通じて拡張します。

1. 32K拡張 — フェーズ4と同じデータ混合を使用
2. 128K拡張 — フェーズ4と同じデータ混合を使用
3. 512K拡張 — 80% 書籍 + 20% コードリポジトリデータ（8bと30bのみ）

LCEフェーズでは、1e-4から始まり 0 へ減衰する指数関数型の学習率スケジュールを使用します。短いコンテキストでの性能を劣化させずに、長いシーケンスをモデルがネイティブに扱えるようにするため、各LCEステージの後にモデルマージを行います。ベースモデルのRULERベンチマーク：

---

SFT：データ準備 & 品質管理

教師あり微調整（SFT）は、ベースモデルを信頼できる指示追従アシスタントへと変えるものです。そのため、データ品質は非常に重要です。というのも、少数の誤ったサンプルや幻覚（ハルシネーション）が混ざるだけでも、望ましくない挙動を学習してしまう可能性があるためです。これに対処するため、厳密なLLM-as-Judge（LLMによる審査）フレームワークと、ルールベースのフィルタリングを組み合わせて、高品質なサンプルを厳選します。さらに、このパイプラインは各サンプルを構造・意味・ふるまい（行動）という観点から自動的に評価し、可能な場合は問題を修正し、品質基準を満たさないサンプルは除外します。

図4： SFTデータ品質パイプライン。生の会話データは、多次元のルーブリックを備えたLLM-as-Judgeを通過し、accept/borderline/reject（採用/境界/不採用）の判定が出力されます。ハードリジェクトの欠陥（幻覚、誤った前提、誤った計算）は、スコアにかかわらず自動的に却下されます。

厳密なLLM-as-Judgeフレームワークでは、アシスタントの応答のみを評価し、システムプロンプト、ユーザー入力、取得したドキュメント、ツール出力は厳密にコンテキスト情報として扱います。これにより、審査では「何をするように求められたか」ではなく、「モデルが実際に言ったこと」を評価できます。RAGの設定では、取得したコンテキストに基づいていない応答は幻覚としてフラグされ、ツール利用の出力は、許可されたツールのセットおよびそれらのパラメータスキーマに照らして検証されます。

LLM-as-Judge、ルールベースのフィルタリング、グローバルな重複排除パイプラインを通過した後、これらの約410万件の高品質サンプルに対して基盤モデルを微調整します。以下の詳細は、3つのモデルバリアントすべてに適用されます。

学習設定：

---

強化学習：マルチステージRLパイプライン

SFTの後、特定の領域におけるモデルの能力をさらに向上させるために、マルチステージの強化学習パイプラインを適用します。単一のRLパスではなく、複数のターゲットを絞ったRLステージを実行し、それぞれ異なる能力に最適化します。

トレーニング手法

On-policy GRPO（Group Relative Policy Optimization）（Shao et al., 2024）に、DAPO（Decoupled Clip and Dynamic sAmpling Policy Optimization）損失（Yu et al., 2025）を組み合わせて使用します。これは、標準的なGRPOと比べてより安定した学習シグナルを提供します。ただし、動的サンプリングは計算負荷が高いため、学習実行中はこれをオフに切り替えます。

RL学習設定

RLパイプライン

図10は、Granite 4.1モデルを学習させるための強化学習（Reinforcement Learning）パイプラインを示しています。多様な強化学習レシピを用いた広範な実験を通じて、この一連の手順が致命的な忘却を最小化しつつ、複数のドメインにまたがって性能を最大化することが分かりました。

図10: Granite 4.1の強化学習パイプラインは、4つの連続した段階（Multi-domain RL、RLHF、IdentityおよびKnowledge-calibration RL、Math RL）で構成されます。

マルチドメインRL

この段階では、複数のドメインから引き出したデータの統一的な混合物に対して、モデルを共同で学習させます。そのため、あらゆる勾配更新がタスク全体の多様性を反映し、致命的な忘却を防ぎ、ベンチマーク全体の性能を押し上げ、個々のタスクに対する後退（リグレッション）を最小化します。

この段階で扱うさまざまなドメインには、以下が含まれます：

この段階では、45,504個の固有プロンプト（全てのGranite 4.1モデルで平均）でモデルを学習し、マルチドメイン強化学習においては、学習率5e‑7で、KL損失係数（$\beta$）が0.05の組み合わせが最も良い結果を示すことが分かりました。

RLHF

モデルの有用性とチャット能力をさらに高めるために、多言語スカラー報酬モデルを用いて、汎用チャットのプロンプトでモデルを学習させます。この段階では、SFTチェックポイントと比較して、Alpaca-Evalにおいて平均で約18.9ポイント（Granite 4.1モデル3つの平均）改善が見られました。

以前に学習した知識からの方策ドリフト（policy drift）を抑えるため、この段階では控えめな学習率3e-7と、KL損失係数$\beta$が0.09となるようにします。このRLHF段階では、固有プロンプトの平均が17,920個です。

Identity & Knowledge-calibration RL

この段階では、アイデンティティおよび知識のキャリブレーション（calibration）を行うプロンプトに対して、モデルを数ステップ（約40ステップ）のみ学習させます。この小さな学習段階によって、モデルの自己同定能力が大きく改善することを確認しました。

RLHF段階と同様に、学習率を3e-7、KL損失係数$eta$を0.09とし、この段階では1728個のユニークなプロンプトを使用しました。

Math RL

RL学習中、RLHF段階によって数学ベンチマークのスコアが低下することが分かりました（例：GSM8K、DeepMind-Math）。Math RL段階により、この低下からモデルが回復し、数学ベンチマークにおいて元のSFTの性能を上回ります：GSM8Kでは平均で約3.8ポイント、DeepMind-Mathでは平均で約23.48ポイント向上します。この段階ではユニークなプロンプトを平均13,504個使用し、多ドメインRL段階と同様に、学習率を5e-7、KL損失係数$eta$を0.05としました。

---

結果

ベースモデルのベンチマーク

指示モデルのベンチマーク

対応言語: 英語、ドイツ語、スペイン語、フランス語、日本語、ポルトガル語、アラビア語、チェコ語、イタリア語、韓国語、オランダ語、そして中国語。

---

Granite 4.1：主要なオープンソース・モデルとの比較

Granite 4.1は、長い「思考の連鎖（chain of thought）」に依存せずに、競争力のある指示追従およびツール呼び出しの能力を提供します。長時間の推論トレースを避けることで、予測可能なレイテンシ、安定したトークン使用量、そして運用コストの低さを実現します。これによりGranite 4.1は、効率性、信頼性、コスト管理が重要となるエンタープライズのワークロード向けに、プロダクション対応のオープンソース選択肢となります。

Granite 4.1-8B 対 Granite 4.0-H-Small（32B-A9B）

印象的な結果です。Granite 4.1-8Bの高密度モデルは一貫して、前世代のGranite 4.0-H-Smallを同等または上回るのです。Granite 4.0-H-Smallは、9Bのアクティブパラメータを持つ32BパラメータのMixture-of-Experts（MoE）モデルです。

図13: ベンチマーク全体におけるGranite 4.1-8B（濃い青）とGranite 4.0-H-Small 32B-A9B（薄い青）。8Bの高密度モデルは、IFEval、AlpacaEval、MMLU-Pro、BBH、GSM8K、DeepMind-Math、Evalplus、ArenaHard、BFCL V3、そしてMBPP（+）において、大きなMoEモデルに匹敵する、または上回ります。

返却形式: {"translated": "翻訳されたHTML"}

Granite 4.1 モデルファミリー比較

図 14: Granite 4.1 ファミリーにおける比較 — 30B、8B、および 3B モデル。スコアはモデルサイズに応じて予測可能にスケールし、30B モデルがすべてのベンチマークで先行しています。

FP8 量子化

また、vLLM による推論向けに最適化した、Granite 4.1 モデルの fp8 量子化バリアントも公開しました。精度は 16 ビットから 8 ビットに低下し、その結果、ディスク使用量と GPU メモリ使用量の両方が約 50% 削減されます。量子化は、LLM Compressor を用いてトランスフォーマー ブロック内の線形演算子の重みと活性にのみ適用され、他のすべての層は元の精度のまま保持されます。

インフラストラクチャ

私たちは CoreWeave でホストされている NVIDIA GB200 NVL72 クラスター 上で Granite 4.1 Language Models を学習しました。

• ラック内通信: 72-GPU NVLink ドメイン
• ラック間通信: ノンブロッキング、フル Fat-Tree NDR 400 Gb/s InfiniBand ネットワーク
• スケール: クラスター全体にわたる数千台の GPU

このインフラストラクチャは、必要とされるトークン量における効率的な分散学習のために求められる、スケーラブルで高帯域の相互接続を提供します（事前学習だけで 15T+ トークン）。

---

はじめに

Granite 4.1 モデルは Apache 2.0 ライセンス のもとで利用可能です。以下は、ツール呼び出しの例付きで 30B の instruct モデルを始める方法です。

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)
# CPU で実行する場合は device_map を削除する
model = AutoModelForCausalLM.from_pretrained(model_path, device_map=device)
model.eval()

返却形式: {"translated": "翻訳されたHTML"}tools = [
    {
        "type": "function",
        "function": {
            "name": "get_current_weather",
            "description": "指定した都市の現在の天気を取得します。",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {
                        "type": "string",
                        "description": "都市名"
                    }
                },
                "required": ["city"]
            }
        }
    }
]

# 必要に応じて入力テキストを変更してください
chat = [
    { "role": "user", "content": "いまロンドンの天気はどうですか？" },
]
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])

予想される出力:

<|start_of_role|>system<|end_of_role|>以下のツールにアクセスできる、役に立つアシスタントです。ユーザーの問い合わせを支援するために、1つ以上のツールを呼び出して構いません。

<tools></tools> XMLタグ内に、関数のシグネチャが提供されています。
<tools>
{"type": "function", "function": {"name": "get_current_weather", "description": "指定した都市の現在の天気を取得します。", "parameters": {"type": "object", "properties": {"city": {"type": "string", "description": "都市名"}}, "required": ["city"]}}}
</tools>

各ツール呼び出しについて、<tool_call></tool_call> XMLタグ内に、関数名と引数を含むjsonオブジェクトを返してください：
<tool_call>
{"name": <function-name>, "arguments": <args-json-object>}
</tool_call>。提供されたツールのリストに存在しないツールの場合、その要求を満たすことができない旨をユーザーに通知してください。<|end_of_text|>
<|start_of_role|>user<|end_of_role|>いまロンドンの天気はどうですか？<|end_of_text|>
<|start_of_role|>assistant<|end_of_role|><tool_call>
{"name": "get_current_weather", "arguments": {"city": "London"}}
</tool_call><|end_of_text|>

リソース:

• Granite 4.1 HFコレクション
• PRISM: Mid-TrainingにおけるRetentionとInteractionを解明する
• GitHub: ibm-granite/granite-4.1-language-models
• Graniteドキュメント
• Graniteコミュニティ・リソース

---

Granite 4.1は、高品質なオープンソース言語モデルに向けた大きな前進です。事前学習のキュレーションから教師あり微調整、そしてマルチステージの強化学習に至るまで、あらゆる段階でデータ品質と厳密さを優先することで、ポストトレーニング・パイプラインを大幅に改善します。その結果、指示への追従、ツール使用、会話パフォーマンスがより強力になり、注意深く訓練された密な8Bモデルが、はるかに大規模なMoEアーキテクチャに匹敵し得ることを示しています。コミュニティがこれらのモデルをどのように採用し、どのように発展させていくのかを楽しみにしています。