Editing Openai/692aba85-5b10-8006-817a-d5a83b020f8e (section)

=== Assistant: INTELLECT-3 のテクニカルレポートは、 ===
INTELLECT-3 のテクニカルレポートは、
* モデルそのもの（106BパラメータMoE、12Bアクティブ）
* それを作るためのRLインフラ一式（prime-rl＋verifiers＋Environments Hub＋Prime Sandboxes＋512枚H200クラスタ）
* 具体的なSFT & RLレシピとベンチマーク結果

をまとめて公開した技術報告です。INTELLECT_3_Technical_Report

以下、セクション順にかみ砕いて解説します。

==== 1. イントロ：何を目指した仕事か ====

近年のポストトレーニングは、'''RLVR（Reinforcement Learning with Verifiable Rewards）'''が事実上の標準になりつつあります（OpenAI o3、Grok 4、DeepSeek R1 など）。
しかし OSS 側は、
* RLフレームワーク
* RL環境 & 評価
* 安定なトレーニングレシピ

がバラバラで、フロンティアラボの社内スタックに比べてまだ弱い、という問題意識があります。INTELLECT_3_Technical_Report

そこでこの論文では：
# GLM-4.5-Air-Base をベースに、SFT＋大規模RLで鍛えたモデル INTELLECT-3 を公開
# そのために作った 非同期大規模RLフレームワーク prime-rl を公開
# さらに RL環境群（verifiers＋Environments Hub）とコード実行基盤 Prime Sandboxes、H200クラスタ上の運用方法 まで含めて “再現可能なスタック” として出す

というのがメインの貢献です。

図1（p1）では、AIME24/25、LiveCodeBench v6、GPQA、HLE、MMLU-Pro などで、INTELLECT-3 が同クラスの GLM-4.5-Air ポストトレインや DeepSeek R1-0528 を上回り、一部では 3倍以上大きい GLM-4.6 に迫る／肩を並べることを示しています。INTELLECT_3_Technical_Report

==== 2. トレーニングインフラ ====

===== 2.1 prime-rl：大規模非同期RLフレームワーク =====

prime-rl は 「トレーナ」「オーケストレータ」「推論サービス」 の3役で構成されます（図2, p5）。INTELLECT_3_Technical_Report

====== 2.1.1 アーキテクチャ ======
* Trainer - 役割：ロールアウト＋報酬から勾配を計算し、ポリシーを更新 - 実装：PyTorch FSDP2 ベース、torchtitan 由来のコードを使い - データ並列 - テンソル並列 - コンテキスト並列 - MoE向け grouped GEMM - HF 互換モデルをそのまま扱える
* Inference サービス - vLLM をバックエンドにした OpenAI互換 API サーバ - 標準 API に加え /update_weights /reload_weights を追加して、 トレーナからの重み更新を受け取れるようにしている。
* Orchestrator（CPUプロセス） - 推論サーバからロールアウトを受け取り、バッチ化して Trainer へ送る - Trainer から新しい重みを受け取って Inference へ配布 - ロールアウト生成には verifiers 環境を使い、Environments Hub 上の任意の環境をそのまま使える

この3者が疎結合で動作するため、トレーニング用GPUと推論用GPUを完全に分離しつつ、両者を非同期に回せるのがポイントです。

====== 2.1.2 非同期オフポリシー学習 ======
* 通常の同期 on-policy RL だと、 「ロールアウト生成 → 勾配計算 → パラメータ更新」が逐次になるため、 推論側がパラメータ更新待ちで止まる。
* prime-rl では オフポリシーを許容して非同期化： - 推論側は少し古いパラメータ θₙ を使い続けてロールアウトを生成 - その間に Trainer 側は θₙ から θₙ₊₁ へ更新を進める
* 図3（p6）のように、理想化すれば「常に1ステップ遅れ」くらいの off-policy で走るイメージ。

このとき生じる trainer-inference のミスマッチは後述の 重要度サンプリング＋マスキング で制御します。INTELLECT_3_Technical_Report

====== 2.1.3 Continuous Batching & In-Flight Weight Updates ======

長いチェイン・オブ・ソートやエージェントロールアウトでは、ロールアウト長の分散が大きいため、同期バッチだと一番遅いサンプル待ちでGPUが遊びがちです。

そこで、AReal や PipelineRL で広まった手法を取り入れて：
* Continuous Batching - オーケストレータが常に多数のロールアウトリクエストを「プール」しておき、 - ひとつ終わるたび即座に新リクエストを投入 → 推論GPUの利用率を常に高く維持
* In-Flight Weight Updates - Trainer から新しい重みが届くと、推論サーバは一瞬生成を中断して重みをアップデート - その後のトークンは新しいポリシーで生成 - 1本の軌跡の中に複数世代のポリシーが混在し得る - ポリシーの古さが一定ステップ数（max_off_policy_steps）を超えた軌跡は破棄

図4（p7）では、タイムライン上で「ロールアウト開始・終了」と「ポリシー更新」が重なっているイメージが描かれています。INTELLECT_3_Technical_Report

====== 2.1.4 Multi-Client Orchestrator ======

vLLM 標準の multi-node data parallel では、ノード数を増やしてもスループットが頭打ちになったため、
* 各ノードを独立した推論サーバとみなし
* オーケストレータが「ノードごとに1クライアント」を持ち、
* ロールアウトをラウンドロビンで振り分ける

という カスタム data-parallel 方式を採用。これによりノード数にほぼ線形でスケールしたと述べています。INTELLECT_3_Technical_Report

====== 2.1.5 オンライン難易度フィルタ ======

カリキュラム学習として、
* 問題ごとに過去の解答成功率から easy / normal / hard のプールを作成
* 各ステップでプールごとのサンプリング割合を制御
* さらに「常に成功 or 常に失敗」する問題のロールアウトは破棄

といったオンラインフィルタで、常にちょうど良い難易度帯を出し続けるように調整しています。INTELLECT_3_Technical_Report

====== 2.1.6 長いシーケンス長への対応 ======

RL中に自然とシーケンス長が伸びる（長く考えるようになる）ため、48k〜72kトークン級での訓練を効率的に回す必要があります。INTELLECT_3_Technical_Report

アプローチは2つ：
# Context Parallelism（Ring Attention系） - Q/K/V をGPU間で回しながら注意を計算 - 256kトークンまで伸ばせたが、 - データ並列度が半減 - 精度劣化も見られた → 本番設定には不採用
# Activation Offloading - 層出力だけ保存し、中間活性はバックプロップ時に再計算（フルチェックポイント） - さらに出力アクティベーションをCPUへオフロード（torchtuneベース） - これで 48k → 72k まで伸ばしつつ、MFU低下は 0.1% 程度に抑えた

====== 2.1.7 Distributed Muon ======

GLM 系はプレトレで Muon optimizer を使っているため、ポストトレーニングでも Muon を継続使用するのがよいとされる一方、Muon は 行列単位の更新 を行うので、FSDP でシャーディングされた勾配にはそのまま適用できません。INTELLECT_3_Technical_Report

試した方法：
* ラウンドロビン gather/scatter - 各 rank が一部の行列を集めて Newton-Schulz を計算し、更新済み勾配を scatter - しかしノード数が増えると gather が多すぎて InfiniBand が詰まる
* All-to-all ベースの手法（最終採用） - all-to-all collective で勾配を再配置し、Mu on を分散適用 - 実装には Dion の OSS 実装を利用

====== 2.1.8 Mixture-of-Experts の効率化 ======

MoE 層には torchtitan の実装を使い、grouped GEMM カーネルで専門家をまとめて実行。
* 実験の結果、 - シーケンス長と hidden dim が大きい今回の設定では、 既に grouped GEMM が十分に飽和しており、 - Expert Parallelism（EP）を入れてもスループットがむしろ下がることが分かった（scatter/gather オーバーヘッドのみ増える）。INTELLECT_3_Technical_Report
* 図5（p9）のベンチマークでは、 シーケンス長 32k〜65k では 128 experts まではTFLOPSが飽和領域にとどまるため、EPは不要という判断。

推論側では HF の MoE 実装を使う必要があるため、トレーナ側の state dict をHF形式にオンザフライ変換して vLLM に渡す工夫もしています。

===== 2.2 verifiers と Environments Hub：RL環境の設計 =====

verifiers は '''「RL環境＝データセット＋ロールアウトロジック＋報酬関数」'''として切り出すライブラリです。INTELLECT_3_Technical_Report

====== 2.2.1 環境の構成要素 ======
# dataset - 各行が1問題：入力プロンプト＋メタデータ（正解、テストケースなど）
# rollout メソッド - 1問題＋OpenAI互換クライアントを受け取り、 - ツール呼び出しやマルチターン対話を含む一連の行動を実行 - 学習に必要なログ（token ids, logprobs 等）を収集
# Rubric - 複数の reward function をまとめる抽象 - 各 reward は (プロンプト, completion, 正解, rollout state) を受けてスカラーを返す - 重み付き合成で最終報酬を作る - 投票・ランキングなど相対評価にも対応
# load_environment - 前処理やリソース確保を行い、環境インスタンスを生成するエントリポイント

ロールアウトは asyncio ベースで非同期に大量並列実行。図6（p10）のクラス階層では、
* Environment（基底）
* MultiTurnEnv（マルチターン）
* ToolEnv / StatefulToolEnv（ツール呼び出し）
* SandboxEnv（コンテナ実行）
* CodeEnv（テストケース付きコード環境）

と段階的に機能が拡張される様子が示されています。INTELLECT_3_Technical_Report

====== 2.2.2 prime-rl との統合 ======
* 環境は Python モジュールとして Environments Hub から pip install できる。
* prime-rl のオーケストレータは、モジュール名だけ指定すれば - 環境をロード - ロールアウト実行 - 報酬・logprobs などを Trainer に渡す
* EnvGroup によって 複数環境を1つの「大環境」として束ねることができ、 task ID 列でどのサブ環境で評価するかを振り分ける。

====== 2.2.3 Environments Hub ======
* 環境を 独立したPythonパッケージとして登録・バージョン管理するレジストリ。
* 従来の「トレーニングリポジトリ内のサブフォルダ形式」から脱却し、 - 評価専用の利用 - バージョン固定 - 外部コントリビューション をやりやすくしている。

====== 2.2.4 評価 ======

トレーニング中のオンライン評価も verifiers 環境で行い、
* オーケストレータが訓練リクエストと評価リクエストを同じ推論プールに投げる
* 評価のオーバーヘッドを「訓練の隙間」に隠しつつ、リアルタイムにスコアを監視

という形になっています。

===== 2.3 Prime Sandboxes：コード実行基盤 =====

====== 2.3.1 素朴な Kubernetes 実装の限界 ======

「kubectl exec でエフェメラル Pod に入ってコードを走らせる」という素朴な設計だと、
* API Server & etcd が制御プレーンのボトルネックになり、
* 数千並列のとき 1コマンドのレイテンシが2.5秒まで悪化した、という測定結果が示されています。INTELLECT_3_Technical_Report

====== 2.3.2 Prime Sandboxes のアーキテクチャ ======

これを解決するために、
* Rust 製 Gateway - 軽量HTTP APIで実行リクエストを受付 - Kubernetes APIではなく Headless Service を通じてPod IPを直接解決 - kube-proxy を迂回し、Pod へ直接接続
* 高スループット CoreDNS - Headless Service 由来の大量のAレコード更新に耐えるよう、CoreDNS構成をカスタム
* Sidecar パターンのサンドボックスPod - 特権 sidecar が nsenter でターゲットコンテナの namespace 内へ侵入してコマンド実行 - これにより ローカルプロセス並の速度とフルコンテナ隔離を両立

というかなり攻めた設計になっています。INTELLECT_3_Technical_Report

====== 2.3.3 非同期ライフサイクル管理 ======

Pod の Ready 検知も、
* Kubernetes API や Kopf controller でのイベント監視に頼ると、 - 大量Pod同時起動でバックログが溜まり、 - 実際には起動済みなのに「Ready通知が来ない」時間が長くなる

ため、
* Kopf はエラーハンドリング等のメンテ専用に縮小し、
* Pod 側の sidecar からトレーニングバックエンドへ Webhook を直接送ることで 起動完了を即時通知する方式に変更。
* この結果、クラスタ負荷に関わらず 起動から Ready まで常に < 10 秒に抑えられたと報告。INTELLECT_3_Technical_Report

====== 2.3.4 イメージ配布と高密度化 ======

イメージ配布は2段構え：
# 専用レジストリ＋Lazy Pulling - 動的環境向け - エントリポイントに必要なレイヤだけ先読みし、残りはバックグラウンドでストリーミング
# Warm Pool - 標準的なランタイムイメージ用に、常に起動済みPodをプール - 取得即実行可能

さらに、1ノードに256サンドボックスを詰め込むことを目標とした bin-packing スケジューラと、
* RLは「短時間CPUスパイク＋長時間待ち」のワークロードなので、
* CPUを Burstable QoS で大幅オーバーサブスクライブ

という設計でリソース効率を高めています。INTELLECT_3_Technical_Report

====== 2.3.5 セキュリティ ======
* ランタイムには gVisor (runsc) を採用して、ユーザ空間カーネルでホストを隔離
* ネットワークポリシーで外部通信を制限
* 必要に応じて GPU をマウントしたサンドボックスも支援

===== 2.4 GPUクラスタ運用 =====
* 512枚の NVIDIA H200（64ノード）
* ネットワーク：400Gbps NDR InfiniBand（ConnectX-7）、AllReduce の tail latency を監視し、160GB/s 以上を目標
* 構成管理：Ansible による IaC
* ジョブ管理：Slurm + cgroup v2（ジョブ終了時に cgroup ごとプロセス凍結・破棄）
* ストレージ：Lustre（高スループット）＋NVMe-NFS（メタデータ多め用途）
* 監視：DCGM → Prometheus、Xid エラーや熱スロットリング検知でノードを事前に drain

と、かなり “HPC すぎる” レベルまでチューニングされています。INTELLECT_3_Technical_Report

==== 3. INTELLECT-3 の具体的な学習 ====

===== 3.1 環境ミックス =====

6カテゴリの環境を組み合わせています。INTELLECT_3_Technical_Report
# Math（i3-math, 21.2k問） - 元データ：Skywork-OR1, Acereason-Math, DAPO, ORZ-Hard などから高難度問題を抽出 - 検証： - まず math-verify で記号的に採点 - 間違い判定になったものは CompassVerifier-7B（LLM judge）でも再チェック → ルールベースの偽陰性を補正 - 難易度付け：Qwen3-4B-Thinking が8サンプル生成したときの成功率で easy / normal / hard に分ける
# Code（i3-code, 8.6k問） - Python 単発プログラミング問題 - SYNTHETIC-2 データセットをベースに、1問あたり最大15テストケースを Prime Sandboxes で実行 - サンドボックスが壊れた場合はその completion をマスク - 難易度付けは Qwen3-4B-Instruct の成功率で
# Science（i3-science, 29.3k問） - MegaScience からフィルタした物理・化学・生物など - math-verify＋LLM judge の二段構えで採点 - 難易度付けも Qwen3-4B-Instruct
# Logic（i3-logic, 11.6k問） - SynLogic 由来の29種類の論理パズル／ゲーム（ブール式評価、クロスワード、数独、マインスイーパーなど） - 同様に Qwen3-4B-Instruct の成功率で難易度付け
# Deep Research（deepdive 環境） - Serper ベースの web search tool、click / open tool、finish tool を使う「ウェブ調査」環境 - z-AI DeepDive データセットから - SFT 用軌跡 1k - RL 用 2.2k - 検証として、Qwen3-4B-Instruct を SFT→RL した小実験を行い、 図7（p15）のように RL 中に平均報酬がちゃんと上がることを確認（環境実装の検証）。
# Software Engineering（deepswe / mini-swe-agent-plus） - R2E-Gym と mini-swe-agent-plus をベースにしたエージェント scaffold を2種類用意 - サンドボックス内で - Bash 実行ツール - ファイル編集ツール を使ってGitHubリポジトリのバグ修正を行う - 最大200ターンまで行動可、最後にテストスイートで成功判定 - 2万以上のGitHubリポを事前にインストールしたイメージを Prime Sandboxes 上に用意

===== 3.2 Supervised Fine-Tuning（SFT） =====

SFT は2段構え。INTELLECT_3_Technical_Report

====== ステージ1：一般チャット＋Reasoning SFT ======

データソース（表1, p16）：
* NVIDIA Nemotron Post-Training Dataset v1 の - OpenReasoning-Math（200万例, 78.1Bトークン） - OpenReasoning-Code（190万例, 94.3B） - OpenReasoning-Science（31万例, 32B） - OpenReasoning-Tool（80万例, 3.8B）
* AM-DeepSeek-R1-0528-Distilled の - General Chat（95.2万例, 8.4B） - Instruction Following（5.4万例, 0.4B）

いずれも DeepSeek-R1-0528 由来の高品質な思考トレースを含む合成データ。

設定：
* コンテキスト長 65k
* 1エポック、1ステップあたり ≈33M トークン
* Optimizer: Muon, weight decay 0.01
* LR: 5e-5（300ステップで 1e-8 から線形ウォームアップ）
* FSDP world size=64, DP replicate 8 → 512 GPUをフル活用
* 図8(a) の loss カーブはスムーズで、発散やスパイクは見られない

====== ステージ2：Agentic SFT ======

目的：
* ツール利用
* 長時間エージェント行動
* 65k 以上の長コンテキストへの慣れ

追加データ：
* SWE-Swiss（SWEエージェントタスク）
* Toucan Tool（ツール利用データ）
* Environments Hub 上の各環境で DeepSeek-R1-0528 を走らせて作った軌跡

設定：
* ステージ1の最終チェックポイントから再開
* 文脈長 98k（Context Parallelism により拡張）
* 2エポック、800ステップ
* Muon, LR 5e-8 から線形減衰
* 図8(b) の loss も安定

====== チャットテンプレートと「常に思考する」設計 ======
* Qwen3 / GLM 系に似た <|system|>, <|user|>, <|assistant|>, <|im_start|>, <|im_end|> の構造
* ツールコールは XML 風タグ
* 特徴的なのは - ユーザ側には「思考モードの切り替え」を見せず、常に内部で<|think|>トークンを使って思考させる - multi-turn で reasoning_content を自動パースし、前ターンの思考をうまく継続できるようにしている - 実際に使うときは qwen3_coder tool parser と deepseek_r1 reasoning parser を使うことを推奨

===== 3.3 Reinforcement Learning フェーズ =====

====== 設定 ======
* バッチサイズ：256プロンプト × 各プロンプト16ロールアウト
* 最大コンテキスト長：65,536
* オンライン難易度フィルタ＋「easyプールのpass率1問題を除外」
* max_off_policy_steps = 8
* Optimizer: Muon, LR 1e-6
* クラスタ構成： - 60ノード（計480 H200）を使用 - うち 16ノードを Trainer、44ノードを Inference に割り当て（≒1:3） - in-flight weight update ありの場合、1ステップ ≈1500秒 なしだと 2倍以上かかる

====== 学習アルゴリズム：masked importance sampling（IcePop系） ======

目的：非同期 off-policy による trainer-inference ミスマッチを安全にコントロールすること。INTELLECT_3_Technical_Report

数式的には、N本のロールアウト {y_i} に対して
* 重要度比 ri,t=πtrain(yi,t∣x,yi,<t;θ)πinfer(yi,t∣x,yi,<t;θold)r_{i,t} = \frac{\pi_{\text{train}}(y_{i,t}|x,y_{i,<t};\theta)}{\pi_{\text{infer}}(y_{i,t}|x,y_{i,<t};\theta_\text{old})}ri,t=πinfer(yi,t∣x,yi,<t;θold)πtrain(yi,t∣x,yi,<t;θ)
* これを [α, β] = [0.5, 5] の範囲内にあるトークンだけ採用し、それ以外はマスク（寄与0）
* ロールアウト i の報酬 Sᵢ に対し、同一プロンプト内で平均を引いた A^i,t=Si−mean(Sj)\hat{A}_{i,t} = S_i - \text{mean}({S_j})A^i,t=Si−mean(Sj) をトークンごとの advantage とみなす
* さらに どこか1トークンでも重要度比が非常に小さい（< 1e-5）ロールアウトは全体を破棄

という設計です。

これは CISPO に近い発想ですが、clipping ではなく masking にすることで、比率が暴れたサンプルがノイズとして残るのを防いでいる、と説明しています。図10（p18）では、GSPO と CISPO 系アルゴリズムを比較したとき、GSPO が高 off-policy 設定（async-8）で突然 reward 崩壊を起こす様子が示され、これが実験上の安全性問題になると述べています。

====== オンライン評価 ======

図9（p17）では、AIME24/25, HLE, LiveCodeBench, GPQA のスコアが、ステップを追うごとに着実に上昇していることが示されています。
* どのベンチマークも まだ明確に頭打ちになっていない → さらに RL を継続すればまだ伸びる余地がある、というのが著者の結論です。

==== 4. 評価結果 ====

===== 4.1 ベンチマーク =====

表2（p19）に、主要モデルとの比較がまとまっています。INTELLECT_3_Technical_Report

| モデル                      | AIME24 | AIME25 | LCB v6 | GPQA | HLE   | MMLU-Pro |
| ------------------------ | ------ | ------ | ------ | ---- | ----- | -------- |
| INTELLECT-3              | 90.8   | 88.0   | 69.3   | 74.4 | 14.6  | 81.9     |
| GLM-4.5-Air (post-train) | 84.6   | 82.0   | 61.5   | 73.3 | 13.3  | 73.9     |
| GLM-4.5 (base)           | 85.8   | 83.3   | 64.5   | 77.0 | 14.8  | 83.5*    |
| GLM-4.6                  | 92.0   | 90.3   | 73.0   | 78.8 | 13.3* | 83.1     |
| DeepSeek R1-0528         | 83.2   | 73.4   | 62.5   | 77.5 | 15.9  | 75.3     |
| DeepSeek v3.2            | 88.1   | 84.7   | 71.6   | 81.4 | 17.9  | 84.6     |
| GPT-OSS 120B             | 75.8   | 77.7   | 69.9   | 70.0 | 10.6  | 67.1     |

* 一部スコアは AA Index 由来。

ポイントとしては：
* 同じGLM-4.5-Airベースでも、Prime Intellect版RLの効果がかなり大きい - 例：LCB v6 で 61.5 → 69.3（+7.8pt） - MMLU-Pro でも +8pt 程度
* 3倍大きい GLM-4.5 / 4.6 に対しても、AIME や LCB では肉薄 or 逆転
* 一方、GPQA / HLE / MMLU-Pro の一部では DeepSeek v3.2 がまだ上 → INTELLECT-3 は「GLM系の中では非常に強いが、全体トップではない」という位置づけ

また、全モデル同一設定で評価するために、
* 可能な限り各社の公式APIを使用
* Environments Hub 上の公開実装を用いて再現可能性を確保

していると明記されています。

==== 5. 結論と今後の課題 ====

結論として著者らは：
* INTELLECT-3 は 100Bクラスのオープンモデルとして非常に強い Reasoning/Agent モデル
* それを支える prime-rl＋verifiers＋Environments Hub＋Prime Sandboxes＋H200クラスタ運用ノウハウ を一式OSS化したことが本質的貢献
* これにより「大企業のクローズドRLスタック」と「個人/小規模ラボ」のギャップをかなり埋えられる

と主張します。INTELLECT_3_Technical_Report

今後の方向性としては：
# Agentic RL のさらなるスケール - 現状でも報酬カーブは伸び続けているので、DeepDive や SWE など agentic 環境を厚くして継続学習すべき。
# よりリッチな RL 環境 - Environments Hub には既に500以上の環境（自律AI研究、コンピュータ操作、定理証明、ブラウザ自動化、法律・金融など）があるが、 INTELLECT-3 はその一部しか使っていない。 - これらコミュニティ環境をフル活用することで、現実タスクに近いスキルを強化したい。
# 長期ホライズンエージェントとコンテキスト管理 - 「コンテキストウィンドウは有限資源」とみなし、 - 自分でコンテキストを切り出す - サブタスクごとに自己プロンプトする - 外部メモリを自分で管理 といった機能を、できるだけシンプルなツールの組み合わせとして与え、RLで end-to-end 学習させたい。 - 最近指摘されている「Long context でも、実効的な reasoning window はかなり短い（context rot）」問題を、 RLで“自分で文脈を管理する能力”を学習させることで克服する狙い。INTELLECT_3_Technical_Report

ざっくりまとめると、

: INTELLECT-3 は「GLM-4.5-Air を土台に、きっちり作り込んだ大規模非同期RLスタックで鍛えた 100B級オープンReasoningモデル」であり、
: 同時に「誰でも同じ手法で自分のモデルを鍛えられるようにするための、RLインフラ一式の技術マニュアル」

という位置づけのテクニカルレポートだと言えます。