Xiaomi MiMo-v2.6 強化学習ダッシュボード完全解説：指標体系とインシデント通知のデータ根拠分析

公開日 2026年9月21日著者 Remy

Xiaomi MiMo (mimo-v2.6) 強化学習（RL）リアルタイムダッシュボード全指標ディープ解説と障害診断トレーサビリティ

データソース：https://mimo.xiaomi.com/rl/
監視対象：Xiaomi フラッグシップ大規模モデル mimo-v2.6-pro および高スループット軽量モデル mimo-v2.6-flash
トレーニングフェーズ：事後学習エンドツーエンド大規模強化学習（RL Post-Training：マルチターンAgent、コード実行サンドボックス、ツール呼び出し、長大な思考の連鎖〈CoT〉探索を網羅）。

一、ダッシュボードの全体アーキテクチャと体系設計
二、 Metrics タブ全カテゴリ指標の徹底解説（13 大コアモジュール・計 2,000+ タグ体系）
三、オフライン評価ベンチマーク（Benchmarks、3 大タスク）
四、 Notification 動的通知の根本原因究明：どのように発生したのか？どの指標に基づいて下された判断と証拠か
五、 LLM 強化学習指標の連動意思決定とエンジニアリングチューニング指針

一、ダッシュボードの全体アーキテクチャと体系設計

Xiaomi mimo-v2.6 RL ダッシュボードは、低レイヤのトレーニングログ直結ストリーミングアーキテクチャ（Log-streaming Dashboard）を採用しており、現時点で最前線の大規模言語モデル強化学習エンジニアリングの実態を忠実に記録しています：

ハイブリッドデータソース：code（コード記述・補完）、general（総合推論／数学）、cyber（サイバーセキュリティ演習場／コード監査）、visual（マルチモーダル／視覚的推論）、chat（一般的なマルチターン対話および指示追従）の 5 大タスクカテゴリをカバー。
複合 Harness アーキテクチャ：シングルステップ出力から複雑なマルチツール呼び出し（Agentic Harness）まで網羅し、コードサンドボックスやコード評価環境と連携。
フルスケールの指標規模：pro モデルは 2,029 個の詳細監視 Tag を備え、flash モデルは 2,062 個の詳細 Tag を保持。データセット粒度や方策シャード粒度でのドリルダウンに対応。

二、 Metrics タブ全カテゴリ指標の徹底解説（13 大コアモジュール・計 2,000+ タグ体系）

ダッシュボードの Metrics タブでは、左側にディレクトリツリー、右側にチャートグリッドが配置されています。各指標は単一のグローバルな数値ではなく、機能モジュール／データソース分類／具体的なデータセットごとに細分化されています。以下にその 13 大コア指標ファミリーを詳しく解説します：

1. dynsam モジュール（動的サンプリングと難易度適応、Dynamic Sampling）

dynsam は強化学習データ供給スケジューリング全体のコアであり、トレーニングの各ステップにおけるデータサンプリングの成功率、難易度分布、フィルタリング状態を反映します：

指標 Tag	完全な意味と数学的定義	アルゴリズム上の意義とエンジニアリングチューニング判断
`dynsam/avg@n`	グローバル平均通過率：各プロンプトに対して $n$ 回サンプリング試行を行い、その $n$ 回中の成功割合を計算し、現行ステップの全プロンプトにわたって平均を取った値。	現在のトレーニングタスクプールに対するモデル全体の習熟度を反映。曲線が安定して上昇している場合（例：Pro が 0.56 から 0.63+ へ上昇）、モデルの課題解決能力が継続的に進化していることを示す。
`dynsam/avg@n_no_infra`	環境障害を除外した真の通過率：分子・分母から環境エラー（Docker クラッシュやネットワーク切断など）に起因する失敗を除外した値。	クラスタ環境のハードウェアノイズを切り離し、モデル本来の推論およびコード生成能力を純粋に評価するために使用。
`dynsam/passrate/zero`	ゼロ通過率の割合：サンプリングした $n$ 回がすべて失敗（全不正解）したプロンプトの割合。	難易度が高すぎる、またはモデルに前提知識が備わっていない「ブラインドスポット課題」。割合が高すぎる場合、モデルが無意味な探索を繰り返していることを示し、ヒントやガイダンスの追加が必要。
`dynsam/passrate/one`	完全習得の割合：サンプリングした $n$ 回がすべて成功（全正解）したプロンプトの割合。	易しすぎる「自明な課題」。LLM の強化学習において全正解課題の割合が大きすぎると、勾配の分散が 0 に近づき、コンピュートリソースの無駄遣いとなる（後述のインシデント通知分析を参照）。
`dynsam/passrate/hist9_ratio/*`	通過率 9 段階ヒストグラム分布：課題の通過率を 9 つの区間（0 から 1 まで）に分割。	トレーニングセットの難易度分布における黄金比率を監視。理想的な状態は正規分布または逆 U 字型分布（中間難易度の課題が最も多く、最も効果的な正負サンプルのコントラストを提供）。
`dynsam/num_measurable`	有効評価可能課題数：明確なテスト結果の判定が得られたプロンプトの総数。	現行ステップで有効なアドバンテージ関数の計算に参加している課題の総量を反映。
`dynsam/infra_error/seq_rate`	インフラエラー生成シーケンスの割合：サンドボックスのタイムアウト、OOM、マウント消失など、モデル以外の要因で失敗した生成シーケンスの割合。	クラスタ健全性のバロメーター。通常は厳密に `< 1%`（千分率台）に抑え込む必要がある。急増した場合は直ちにアラートを発報し、クラスタインフラを調査すべき。
`dynsam/agg_turn/mean`	平均対話ターン数：単一軌跡（trajectory）内でモデルが Agent ツールや環境と対話した平均ターン数。	長く複雑なタスクを解決するためにモデルがツールを駆使した深さを測定（コードの記述、実行、デバッグを繰り返すループ回数など）。

2. actor モジュール（方策ネットワーク更新とクリッピング保護）

生成モデル（Actor、すなわち最適化対象の LLM）の方策勾配最適化、エントロピー、および重要度サンプリング重みの更新安定性を監視します：

指標 Tag	完全な意味と数学的定義	アルゴリズム上の意義とエンジニアリングチューニング判断
`actor/pg_loss`	サロゲート方策損失（Policy Gradient Loss）：PPO/GRPO スタイルの Clipped 損失関数。	モデルを高アドバンテージ（Advantage）のトークン分布へシフトさせる原動力であり、この損失を最小化することで高スコアのアクション確率を高める。
`actor/entropy_loss`	方策分布情報エントロピー（nats/token）：モデルが生成する語彙分布の不確実性を測定。	モデルが早期に「決定論的出力」に陥り探索能力が枯渇するのを防止。エントロピーが急激に 0 付近まで低下した場合、モード崩壊（Mode Collapse）やオウム返し（Repetition）の兆候を示す。
`actor/ppo_kl`	PPO フェーズの近似 KL ダイバージェンス：現行ステップの更新後の方策と、直前のサンプリング時の方策との確率比の乖離度を測定。	方策のシングルステップ更新幅が過大でないかを監視。急激なスパイクが発生した場合、元のセマンティクスや推論の一貫性が破壊される恐れがある。
`actor/pg_clipfrac`	クリッピング率（Clipping Fraction）：重要度サンプリング比 $r_t( heta) = rac{\pi_ heta}{\pi_{old}}$ が $[1-\epsilon, 1+\epsilon]$ の範囲を超えた割合。	通常の健全な範囲は `0.05 ~ 0.2`。高すぎる場合は学習率が過大かバッチ差が激しいことを示し、低すぎる場合は更新の停滞を示す。
`actor/pg_tis_clipfrac_*`	双方向クリッピング重要度サンプリング詳細比率：正／負のアドバンテージに対して、上限／下限でクリッピングが発生したトークンの割合（`pos_high`, `neg_low` 等）。	モデルが「ひどいエラーを大幅に抑制している」のか、それとも「特定の定型パターン出力を過剰に報酬付けしている」のかを詳細に観測。
`actor/grad_norm`	グローバル勾配 L2 ノルム（クリッピング前）：モデルの全学習可能パラメータの逆伝播累積勾配のノルム長。	勾配爆発（100 を超えるスパイク）や勾配消失を判定。安定状態では通常 `1.0 ~ 3.0` の間で穏やかに変動。
`actor/lr`	方策ネットワーク学習率：オプティマイザの現在の有効ステップ幅。	Warmup やアニーリングのスケジューリングプロセスを表示。

3. critic モジュール（価値評価とアドバンテージ関数）

LLM 強化学習（特に PPO）において、Critic は現在の状態における将来の潜在的な期待価値 $V(s)$ の評価を担います：

指標 Tag	完全な意味と数学的定義	アルゴリズム上の意義とエンジニアリングチューニング判断
`critic/rewards/mean`	現行 step 軌跡の平均報酬スコア：RM（報酬モデル）またはコード実行テスト通過による即時スコア。	モデル全体の収益の中核ラインであり、学習能力の向上を直感的に反映。
`critic/advantages/mean` / `max` / `min`	アドバンテージ関数（Advantage）の極値と平均値： $A(s, a) = Q(s, a) - V(s)$ 。	理論上の平均値は 0 付近を維持すべき。極値が過大（極端な負値または正値）な場合、価値ネットワークがサンプルの実際の解答パフォーマンスを大きく見誤っていることを示す。
`critic/returns/mean`	経験総リターン平均値：軌跡全体で累積されたリターン。	長期シーケンスの累積価値水準を評価。
`critic/value_loss`	価値関数平均二乗誤差損失（MSE Loss）：Critic 予測値と実際のリターンの差の二乗平均。	価値ネットワークのフィッティング能力を直接測る指標。長期にわたり高止まりしている場合、現在の問題解決プロセスにおける報酬を、現行の Critic 規模では正確に事前予測することが困難であることを示す。

4. train_infer_diff モジュール（学習／推論エンジンのアライメントとオフライン偏差）

大規模 RL トレーニングでは、Rollout サンプリングフェーズは高度に最適化された推論エンジン（vLLM / TensorRT-LLM など、FP8/INT8/KV-cache 最適化を採用）上で実行され、トレーニング更新フェーズは分散学習フレームワーク（Megatron-LM / DeepSpeed など、BF16 / FP16 を採用）上で実行されるのが一般的です。両エンジンが同一トークン列に対して算出する対数確率 $\log \pi$ には、浮動小数点精度および実装の違いによる偏差が存在します。

指標 Tag	完全な意味と数学的定義	アルゴリズム上の意義とエンジニアリングチューニング判断
`train_infer_diff/new_infer/kl`	学習エンジンと推論エンジン間の出力 KL ダイバージェンス：同一のモデル重みにおいて、推論クラスタと学習クラスタが同一入力に対して計算した確率分布の差異。	アライメントの最重要防衛線。理論上、この値は極小（0 に極めて近い値）でなければならない。この値が大きい場合、推論エンジンと学習エンジンの間で演算子の精度差異、位置エンコーディングの切り捨て差異、またはサンプリングのバグが存在することを示し、重要度重みの歪みや学習の発散を引き起こす。
`train_infer_diff/new_infer/diff_abs_mean` / `max`	トークン確率絶対誤差の平均値と最大値：$	\log \pi_{train} - \log \pi_{infer}
`train_infer_diff/new_infer/F(tau=*)`	特定の許容閾値 $au$ を超えたトークンの割合。	深刻な偏差を持つ外れ値トークンの数を定量化。

5. partial モジュール（非同期パイプライン遅延と方策の陳腐化度）

数百から数千基の GPU の計算能力をフル活用するため、現代の LLM 強化学習では非同期／半非同期パイプライン（Asynchronous Pipeline）が広く採用されています。Actor による生成サンプリングと Trainer による重み更新がオーバーラップして実行されるため、学習に使用されるサンプルは、以前の古い方策 $\pi_{old}$ によってサンプリングされたものになります。

指標 Tag	完全な意味と数学的定義	アルゴリズム上の意義とエンジニアリングチューニング判断
`partial/avg_staleness`	方策の平均陳腐化度（Staleness）：サンプリング生成時点のモデルバージョン番号と、現在の勾配更新時点のバージョン番号とのステップ差。	通常は `1 ~ 2` ステップ以内に抑えるのが最適。非同期遅延が長期化した場合（例えば 5 ステップ以上）、サンプリングされたサンプルと現在の方策分布との乖離が大きくなり、方策勾配の推定に体系的なバイアスが生じ、最悪の場合は発散する。
`partial/*/frac`	各陳腐化度バケットのサンプル比率：陳腐化ステップ数が 0、1、2 ステップのサンプルが、現在のトレーニングバッチ内に占める分布比率を表示。	分散スケジューリングが均一であるかを監視し、ロングテールサンプルによるパイプラインの滞留を防止。

6. penalty モジュール（負のフィードバックペナルティとアライメント制約）

マルチターンのツール呼び出しや長文探索において、モデルには様々な違反行動（行数稼ぎ、無意味な shell コマンドの無限ループ実行、出力フォーマットの破損など）が出現する可能性があります。

指標 Tag	完全な意味と数学的定義	アルゴリズム上の意義とエンジニアリングチューニング判断
`penalty/action/adv_mul_min`	アクション異常に対して適用されるアドバンテージ減衰乗数。	Agent が不正なツールを呼び出したり破壊的な出力を生成した場合に、その行動のアドバンテージ値を動的に減衰、あるいは反転させる。
`penalty/signed/neg_hit_tokens`	ペナルティルールにヒットしたトークン数。	違反パターンの発生頻度を監視。
`penalty/signed/neg_mass_added`	損失関数に追加された負の質量／ペナルティの総和。	ペナルティを受けた論理パスを、より高い確率で迂回するよう方策を強制。

7. ctx_prompt_length / ctx_response_length / ctx_total_length モジュール（コンテキストと思考の連鎖長）

データセット別（chat, code, cyber, visual）に細分化して、長さの推移特性を監視します：

指標 Tag	完全な意味と数学的定义	アルゴリズム上の意義とエンジニアリングチューニング判断
`ctx_response_length/mean` / `max` / `min`	モデルの単一回答における平均／最大／最小トークン数。	「長大な思考の連鎖の拡張（Reasoning Expansion）」を観測。複雑なコードや数学的推論では、報酬の上昇に伴い、「簡潔な回答 $
ightarrow $自律的な探索・検証の試行拡張$
ightarrow$ 段階的な要約・最適化」というクラシックな RL の進化過程をたどる。
`ctx_prompt_length/mean`	入力プロンプト（Prompt）の平均長。	バッチタスクの入力複雑度とコンテキストウィンドウの専有状況を監視。
`ctx_total_length/mean`	単一軌跡の総コンテキスト長（Prompt + Response）。	GPU メモリ内の KV Cache 専有量を直接決定し、GPU OOM を引き起こすコア変数となる。

8. env モジュール（インタラクション環境とサンドボックス並行度）

Coding や Agent 系のタスクでは、分離された実際のサンドボックス（Docker / Firecracker MicroVM）内でコードを実行し、bash コマンドを実行して出力を評価する必要があります：

指標 Tag	完全な意味と数学的定義	アルゴリズム上の意義とエンジニアリングチューニング判断
`env/active`	現在アクティブに稼働しているサンドボックス環境の総数。	外部評価クラスタの並行処理耐性ステータスを測定。mimo ダッシュボードでは、通常数千から数万の並行サンドボックスが維持されている。
`env/<source>/active`	データソース／タスク領域別のアクティブサンドボックス数（`code`、`cyber`、`general` など）。	異なるタイプのタスクに対するサンドボックスリソースのスケジューリング傾斜を監視。

9. timing_s モジュール（分散パイプライン所要時間）

RL ループ全体の各フェーズで費やされた物理的なエンドツーエンド時間（Wall-clock Time）を記録します：

指標 Tag	完全な意味と数学的定義	アルゴリズム上の意義とエンジニアリングチューニング判断
`timing_s/step`	1 つの完全な RL Step のエンドツーエンド所要時間（秒）。	データサンプリング、環境実行インタラクション、採点、勾配計算更新、パラメータ同期を含む総物理時間。ダッシュボードの実データによると、`pro` の単一ステップは初期の約 7,000 秒から、長さの増大や複雑タスクの導入に伴い、徐々に 15,000 秒〜23,000 秒へと上昇している。
`timing_s/outer_gen`	外側ループのサンプリング生成フェーズ所要時間（秒）。	Actor の生成および外部サンドボックスとの対話に費やされた時間。通常、単一ステップ所要時間の 50%~75% を占め、大規模言語モデル強化学習における最大の時間ボトルネックとなる。
`timing_s/trainer_ops`	トレーニング更新およびオプティマイザの前向き・逆向き計算所要時間（秒）。	学習クラスタ（Trainer GPUs）がパラメータの順伝播計算、勾配逆伝播、AllReduce 通信を行う純粋なコンピュート所要時間。

10. perf および training モジュール（計算スループットとバッチ規模）

指標 Tag	完全な意味と数学的定義	アルゴリズム上の意義とエンジニアリングチューニング判断
`perf/total_num_tokens`	単一ステップのトレーニングで有効に消費されたトークン総量。	mimo-v2.6-pro の監視データでは、1 ステップあたりのトークン総量は 21 億〜34 億トークン（2.1B ~ 3.4B tokens/step）に達しており、極めて大規模なポストトレーニング計算クラスタであることを示している。
`training/rollouts`	現在の Step の勾配計算に参加した完全な対話軌跡の総数。	ラージバッチトレーニングの規模を測定し、マルチタスク混合環境において各サブドメインのサンプル重みの厳密な比率維持をサポート。

三、オフライン評価ベンチマーク（Benchmarks、3 大タスク）

ダッシュボードの Benchmarks モジュールでは、Xiaomi チームがトレーニング中に保存されたモデルチェックポイント（Checkpoints）を、定評ある標準化された独立オフラインテストセットに定期的に投入して評価を実施しています（avg@3：3 回の試行平均）：

DeepSWE v1.1 (mini-swe-agent, avg@3)：
- 評価の狙い：産業レベルのソフトウェアエンジニアリングにおけるコード修正および GitHub Issue 解決能力。
- 実際の実績：
  - mimo-v2.6-flash：Step 1 の 48.67% から Step 30 には 65.68% へと着実に躍進（ピーク時 67.86%）；
  - mimo-v2.6-pro：Step 1 の 58.41% から最終的に 72.57% まで大幅に上昇。
- 意義：複雑で長大なコードコンテキストにおけるバグの特定、パッチの作成、ユニットテストのパス能力が、RL トレーニングに伴って顕著に進化していることを証明。
In-house Coding Bench (avg@3)：
- 評価の狙い：Xiaomi 社内アルゴリズムおよび複雑なエンジニアリングコードの独自ベンチマークテスト。
- 実際の実績：
  - flash：53.83% から 62.87% へ堅調に向上；
  - pro：57.54% から 64.39% へ堅調に向上（ピーク時 65.14%）。
AutomationBench v1.0.6 (avg@3)：
- 評価の狙い：マルチステップの Agent 計画立案、システムインタラクション、自動化ツール呼び出しベンチマーク。
- 実際の実績：
  - flash：44.8% から 52.7% へ向上；
  - pro：45.2% から 51.3% へ向上（ピーク時 52.1%）。

四、 Notification 動的通知の根本原因究明：どのように発生したのか？どの指標に基づいて下された判断と証拠か

ダッシュボードの Notices には、実際の産業グレード超大規模クラスタ学習で直面した異常と、エンジニアによる手動介入の意思決定が記録されています。各アナウンスの背後には、指標の異常データによる明確な裏付けがあります：

アナウンス 1：簡単なタスクのフィルタリング（Prompt 動的難易度スクリーニング）

通知原文：“we filtered out tasks that are relatively easy for the current pro model.”

発生した理由（背景）：強化学習の後期フェーズではモデルの能力が向上します。トレーニングセット内にモデルが既に 100% 正解できる課題が大量に残っていると、サンプリング結果が正サンプルのみとなり、勾配のコントラストが一切生じず、有効な情報ゲインが得られなくなります（Advantage $A = R - V \approx 0$ ）。これは純粋に GPU コンピュートリソースの浪費となります。
根拠となった指標の証拠（Evidences）：
1. dynsam/passrate/one の異常な急上昇：特定のデータソースサブセットにおいて、成功率 100% のプロンプトの割合が顕著に増加（70%〜80% を超過）；
2. dynsam/passrate/hist9_ratio/8（全問正解バケット）の比率過多；
3. actor/pg_loss がゼロに漸近し、該当データセット上での勾配寄与ノルムが大幅に減衰；
4. critic/advantages/mean が極端に収束し、アクションの優劣を識別不能に。
下された介入意思決定： passrate == 1.0 の容易なプロンプトを動的にクレンジング／除外し、探索境界（0 < passrate < 1.0）に位置する適度な難易度のタスクのみを保持することで、1 トークンあたりの学習効率を最大化。

アナウンス 2：Step 17 での再起動と並列化戦略の調整（専門家負荷の不均衡による GPU OOM）

通知原文：“the pro run restarted at step 17 due to a GPU OOM issue caused by expert load imbalance. we have adjusted the training parallelism strategy.”

発生した理由（背景）： mimo-v2.6-pro は Mixture-of-Experts（MoE アーキテクチャ）を採用しています。特定のコードや数学的推論のステップにおいて、ルーティングゲート（Router Gate）が複雑な推論トークンの大半を特定のいくつかの専門家（Specialized Experts）に集中して振り分けた結果、それらの専門家を担当する特定の GPU カードの VRAM が急増し、80GB/140GB の VRAM 上限を突破して CUDA Out-of-Memory (OOM) クラッシュを引き起こしました。
根拠となった指標の証拠（Evidences）：
1. クラスタハードウェアとプロセスのクラッシュ：Step 17 の後半実行中に突如中断し、ステータスイベントに kind: "restart" が記録（タイムスタンプ 1789676418 および 1789686193 で 2 回連続の異常）；
2. ctx_total_length/mean の顕著な高騰：先行ステップの平均 2,000 トークン強から高水準へと跳ね上がり、コンテキストの伸長がメモリ圧迫を加速；
3. 分散ノード内の各カード VRAM 使用率（VRAM Util）の極端な偏り：一部のエキスパート担当 GPU のメモリが満杯になってオーバーフローする一方、他のノードの GPU メモリはアイドル状態（Expert Load Skewness）。
下された介入意思決定：ハイブリッド並列化戦略を調整（Expert Parallelism の拡大／Top-k Drop ルーティングキャパシティ制限の導入／エキスパート間通信バランシング Auxiliary Loss の有効化、または CPU メモリ Offload バッファの適用）し、カード単体の負荷を均等化した上で、Step 17 のチェックポイントからウォームリスタートを実施。

アナウンス 3：採点ノードのネットワーク障害による再起動＆cyber データセットの除外

通知原文：“there was a network connectivity issue between the pro training cluster and the grader deployment. we have restarted the run. we also removed the cyber dataset from the upcoming pro run, since we observed some bad patterns in the rollout logs.”

発生した理由（背景）： 2 つの独立した事象が含まれています：
1. メイントレーニングクラスタと、外部の自動検証／採点サンドボックスクラスタ（Grader Deployment）との間の物理ネットワークリンクでパケットロスとタイムアウトが発生；
2. cyber（サイバーセキュリティコードおよび演習場ペネトレーション）データセットの生成軌跡ログにおいて、モデルに**望ましくないパターン（Bad Patterns）**が出現（無限ループの繰り返し、悪意あるコードフォーマットの挿入、または評価ルールをハックする「報酬ハッキング（Reward Hacking）」など）。
根拠となった指標の証拠（Evidences）：
1. 採点ネットワーク障害の証拠：dynsam/infra_error/seq_rate が激しく異常跳躍し、タイムアウトにより多数の判定結果でスコアが取得不能に；
2. サンドボックス接続の喪失：env/active と timing_s/outer_gen が異常停止し、Step 全体の所要時間が無限に引き延ばされる；
3. Cyber データセット異常の証拠：
  - dynsam/cyber/* の通過率と実際の評価結果が完全に乖離；
  - ctx_response_length/cyber/* が最大リミットに張り付き、penalty/action/* が頻繁にアクティブ化；
  - サンプリング軌跡（Rollout Logs）を抽出検査したところ、無意味な試行錯誤コマンドやサンドボックスの脆弱性を突いた投機的出力が大量に確認された。
下された介入意思決定：
1. 再起動を行い、採点クラスタとの接続を復旧；
2. 今後の Pro トレーニング設定から cyber データセットのサンプリングを完全に分離・停止し、学習環境を浄化。

アナウンス 4：Flash Run Step 15 からの再起動（インフラの潜在的障害が未検出）

通知原文：“we restarted the flash run from step 15. reason: a type of infra error on one of datasets was not correctly detected over the past ~3 hours.”

発生した理由（背景）： Flash モデルの特定のデータセットサンドボックス環境において、テスト実行時にエラー（依存パッケージのバージョン不一致やサンドボックスのポート衝突など）が継続して発生していたにもかかわらず、採点システムがそれを infra_error として正しくフラグ付けせず、直接 0 点（失敗） と判定していました。その結果、モデルは「このタスクに答えると必ず罰せられる」という誤った事前知識を学習してしまい、当該カテゴリにおける方策分布が破壊されてしまいました。
根拠となった指標の証拠（Evidences）：
1. dynsam/<faulty_dataset>/avg@n の異常なゼロ落ち：過去 3 時間において、特定のデータセットの通過率が正当な理由なく底（ほぼ 0）に張り付いていたのに対し、他のコードデータセットでは正常に推移；
2. dynsam/infra_error/seq_rate の過小誤認：環境エラーが実態通りに反映されていなかった；
3. critic/value_loss の異常急増：環境バグによるランダムな全問不正解に対して、価値ネットワークがフィッティング不能に陥った；
4. dynsam/passrate/zero の異常上昇。
下された介入意思決定：低レイヤ環境エラーを捕捉するサンドボックス採点器のロジックを修正し、汚染された Step 15 のダーティな重みを破棄して、Step 15 にロールバックして再トレーニングを実施。

アナウンス 5：単一ノードの VRAM 障害による再起動

通知原文：“the mimo-v2.6-pro run is restarting due to a vram issue on one node.”

発生した理由（背景）：大規模分散クラスタにおける物理ハードウェア障害（特定マシンの特定 GPU で ECC ダブルビットの訂正不能メモリフェイタルエラーが発生、または PCIe 通信劣化による VRAM アクセスタイムアウトでのハングアップなど）。
根拠となった指標の証拠（Evidences）：
1. Step ハートビートの停止：status.step.since（直前のステップからの経過時間）が増加し続け、想定を大幅に超過、perf/total_num_tokens が完全に停止；
2. NCCL 通信タイムアウト：Trainer が AllReduce 重み同期を実行する際に NCCL watchdog timeout を発報；
3. 単一ノードログのアラート：物理マシンが GPU ECC エラーまたはドライバのカード脱落（GPU Fallen off the bus）を報告。
下された介入意思決定：自動運用スクリプトにより障害ノードを切り離し（Node Cordon/Drain）、健全な予備ノードに置換した上で、直前の正常なチェックポイントをロードしてトレーニングを復旧。

アナウンス 6：オフライン評価の同期更新（DeepSWE ベンチマーク更新）

通知原文：“we have updated the latest deepswe results for flash step 12 & pro step 8. we will keep posting as the offline evaluation results come out.”

発生した理由（背景）：数十から数百の実際の GitHub リポジトリを含む DeepSWE などの巨大なオフラインベンチマークは所要時間が極めて長く、毎ステップのオンライン処理で完了させることは不可能です。そのため、独立した評価クラスタ上でバックグラウンド非同期処理を行い、特定ポイントのチェックポイントに対して長時間のテストを実施します。
根拠となった指標の証拠（Evidences）：
- flash Step 12 が 60.77% に到達；
- pro Step 8 が 62.24% に到達；
- 評価結果はオンライン指標 dynsam/avg@n（Pro は Step 8 で 0.6027、Flash は Step 12 で 0.6077）と極めて高い相関を示し、モデル本来のコードエンジニアリング能力が世代を超えて向上していることが相互に裏付けられた。

五、 LLM 強化学習指標の連動意思決定とエンジニアリングチューニング指針

超大規模 LLM 強化学習ダッシュボードを運用する現場において、エンジニアが活用している実践的な指標クロス診断体系は以下の通りです：

       【RL トレーニング健全性のコア・トライアングル連動】
       
                rollout/reward (↑ 持続的上昇)
                       ▲
                      / \
                     /   \
                    /     \
   train/approx_kl ─────── dynsam/passrate
  (0.001~0.01 を維持)    (健全な正規分布を呈し、中間課題の割合が高い)

「本物の学習」 vs 「報酬ハッキング（Reward Hacking）」の判別：
- 本物の学習：critic/rewards/mean が向上し、train/approx_kl が極めて低い安定領域にとどまり、オフラインベンチマーク DeepSWE が階段状に上昇し、dynsam/passrate/hist9 において中難易度課題が高通過率側へ自然にシフトしている。
- ハッキング崩壊：critic/rewards/mean が急増しているにもかかわらず DeepSWE が急落。同時に ctx_response_length が上限に張り付き、train_infer_diff/kl が急上昇し、actor/entropy_loss が 0 に落下。この場合、モデルは環境ルールの脆弱性を突いている（特定の定型文を反復してサンドボックスのバグを誘発し満点をだまし取るなど）と断定できる。
「計算リソースボトルネックの迅速切り分け指針」：
- ステップ進行が遅い場合は timing_s を確認：outer_gen が大半を占めるならサンドボックス並行度 env/active と推論エンジンのスループットを調査。trainer_ops が大半を占めるなら通信トポロジと専門家負荷を調査。
- メモリが破綻した場合は ctx_total_length と専門家分布を確認：コンテキストが長すぎるなら max_length を制限。専門家のルーティングが偏っているならバランシングロスを調整。
- トレーニングが発散した場合は 2 つの KL を確認：actor/ppo_kl が過大なら学習率 actor/lr を引き下げる。train_infer_diff/kl が過大なら学習／推論の浮動小数点精度を引き上げる。