AIを鍛えるために、AIを大量に動かす

AIを鍛えるために、AIを大量に動かす

MiMoのMixRL・MOPDと、旧世代GPUにも広がる仕事

Xiaomi MiMoチームの羅福莉（Luo Fuli）氏が、MiMo-V2.6の開発で行った、エージェント環境における大規模な強化学習の取り組みを公開した。モデルを実行環境の中で動かし、試行錯誤の結果を評価し、その経験によって能力を伸ばす実験である。(X)

MiMo-V2.6: The Hard Road to Scaling Up RL MiMo-V2.6 is very likely one of the largest single RL runs, by compute, that any open-source model team has undertaken to date. In an era when compute is brutally scarce, we still chose to dedicate a team of several dozen people to one… pic.twitter.com/qywzYZ99Ii — Fuli Luo (@_LuoFuli) September 21, 2026

ただし、これは「AIに道具を使わせて強化学習する方法が、初めて登場した」という話ではない。OpenAIは2025年のCodexの発表で、実際のコーディング課題と多様な環境を使った強化学習を明示していた。(OpenAI)

今回注目したいのは、どのような課題を混ぜ、どこを別々に鍛え、専門化した能力をどう一つのモデルへ戻すのか。その学習設計が、研究資源とともに外から見える形になったことだ。

本稿では、MixRLとMOPDを基礎から整理し、NVIDIAやOpenAIの公開情報との関係を確認する。そのうえで、こうした学習がなぜ大量の推論を必要とし、H100などの旧世代GPUにも仕事を残し得るのかを見ていく。

本稿は2026年9月23日時点の公開資料に基づく。実験の数値は、特に断らない限り開発チームによる報告である。

1．エージェントの強化学習自体は、すでに珍しくない

まず、今回の発表を業界全体の流れの中へ置いておきたい。

OpenAIは2025年4月のo3・o4-miniの発表で、モデルがツールを操作するだけでなく、いつ、どのように使うべきかを学習していると説明している。翌5月のCodexでは、実際の開発課題を使い、修正とテストを繰り返して解決へ進む振る舞いを強化学習で鍛えたと公表した。(OpenAI)

オープンモデル側にも先行例がある。Qwen3-Coderは2025年7月の発表で、計画、ツール使用、環境からのフィードバック、次の判断までを含む長い行動系列の学習を説明していた。(Qwen)

したがって、「これまで方法がまったく公開されていなかった」という理解も正確ではない。論文、学習フレームワーク、訓練データの公開は以前から進んでいた。

一方で、最先端モデルを作る実際の学習工程が、すべて同じ粒度で公開されているわけではない。 複数分野を混ぜる比率、報酬の設計、専門モデルの使い方、失敗した実験、計算資源の配分までそろって分かるとは限らない。

MiMoの意義は、完全に未知の学習原理を提示したことよりも、大規模なエージェント学習を成立させる構成を、具体的に説明した事例として捉える方が分かりやすい。

2．そもそも、強化学習では何が変わるのか

言語モデルの内部には、「重み」と呼ばれる大量の数値がある。入力された文章や、それまでに生成した内容から、次に何を出力するかを決める計算に使われる数値である。

モデルを学習するとは、基本的にはこの数値を調整することだ。

大きく分けると、事前学習では大量のデータから言語や知識、さまざまな規則性を学ぶ。教師あり追加学習、いわゆるSFTでは、望ましい回答や行動の例を学ぶ。そして強化学習では、モデルが出した結果に評価を与え、その評価を改善する方向へ振る舞いを調整する。OpenAIのInstructGPTも、望ましい出力を評価する仕組みを用意し、その評価に基づいてモデルを追加学習する方式だった。(OpenAI)

ここで重要なのは、MixRLとMOPDを組み合わせることで、初めてモデルの重みが変わるわけではないという点である。通常の言語モデルの強化学習でも、学習対象の重みは更新される。

今回の論点は、重みを変えるかどうかではない。

何を経験させ、その経験から得た能力を、どう壊さずに一つのモデルへ蓄積するか。

そこが高度化している。

「その場でやり直す」と「学習する」は別

例えば、モデルがコードを書き、テストのエラーを読み、修正して再実行したとする。

このやり直しは、固定された重みでもできる。エラーログという新しい入力を受け取り、次の出力を変えればよいからだ。

それに対して強化学習では、こうした試行を多数集め、成果を評価し、今後の似た状況でも良い行動を選びやすくなるように、モデル側を更新する。 この生成と更新を組み合わせた処理が、言語モデルのRLの基本構造である。(arXiv)

本稿で扱うMiMoの学習は、このモデル開発工程の話だ。利用者との会話のたびに、同じ規模の学習をその場で実施しているという意味ではない。

3．ハーネスは、モデルが仕事をするための周辺ソフトウェア

エージェント型の学習を理解するには、モデルとハーネスを分ける必要がある。

モデルは、次に何をするかを出力する。ハーネスは、その出力を実際の操作へつなぎ、結果をモデルへ返す周辺ソフトウェアである。

例えば開発作業なら、モデルが「このファイルを読む」「このコマンドを実行する」と出力したときに、実際にファイルを開き、プログラムを動かし、実行結果を次の入力へ渡す仕組みが必要になる。Codexの公開説明にも、ファイルの読み書き、コマンド実行、テストなどを使う構成が示されている。(OpenAI)

説明用の例として、バグ修正の一連の流れを考えてみよう。

依頼を読む → 関係するファイルを探す → 原因を考える → 修正する → テストする → 失敗を調べ直す → 完了する。

このような試行の生成を、rollout、ロールアウトと呼ぶ。そこで得られた出力・操作・観測の履歴が、trajectory、行動系列である。

評価するのは、最後の回答文だけではない。目的を達成したか、必要な検証をしたか、途中で不適切な操作をしていないかも学習の対象になり得る。

したがって、エージェントRLは単なる「文章を上手に書く訓練」ではなく、道具と環境を利用して、仕事を完了するための行動を学ぶ訓練に近い。MiMoが複数の課題とハーネスを混ぜるのも、この作業遂行能力を広く育てるためである。(Hugging Face)

4．MixRL――異なる仕事の経験を、同じモデルへ流し込む

MixRLは、複数分野の課題を混ぜて強化学習する方法である。

数学、コード、ツール操作、指示への厳密な従い方などを、別々のモデルだけで学ぶのではなく、共通のモデルで学習する。その際、異なる分野の課題を同じ学習バッチ、つまり一まとまりの更新用データへ含める。各課題の評価方法まで、すべて同じにする必要はない。(arXiv)

MiMo-V2.6の主要な混合RLでは、コード、一般的なエージェント作業、視覚、セキュリティの課題を扱い、複数のハーネスも混ぜると説明されている。(Hugging Face)

この方法で狙うのは、能力の共有である。

例えば、ソフトウェア修正で役立つ「失敗した原因を切り分ける」という行動は、調査やツール操作にも役立つかもしれない。「分からないことを確かめてから次へ進む」という行動も、多くの仕事に共通する。

ただし、混ぜれば必ず相乗効果が生まれるわけではない。

ある分野で好まれる振る舞いが、別の分野では不利になる場合がある。NVIDIAのNemotron-Cascade 2の研究でも、学習によって推論が短くなった結果、数学の性能に悪影響が出たり、人間の好みに合わせる学習と厳密な指示追従の間にトレードオフが生じたりすると報告されている。(arXiv)

つまり、一つのモデルへ複数の能力を入れる作業は、単なる足し算ではない。

一つの能力を伸ばす更新が、別の能力にとっては望ましくない更新になり得る。 その干渉をどう扱うかが、学習設計の大きな問題になる。

5．難しいのは能力の干渉だけではない――仕事ごとに時間が違う

複数分野の学習を混ぜると、計算システムの側にも問題が生じる。

例えば、説明用に二種類の課題を考える。一方は短いプログラムを生成してテストする仕事、もう一方は多くのファイルを調べ、外部ツールを何度も使って成果物を作る仕事である。

両者では、生成する文章の長さも、ツールを待つ時間も、評価に必要な処理も違う。

単純な同期方式では、短い試行が終わっても、長い試行の完了を待ってから更新することになる。その待ち時間がGPUの利用効率を下げる。AReaLなどの非同期RL研究は、生成と学習更新を切り離し、この問題を緩和するために設計されている。(arXiv)

NVIDIAも、Nemotron-Cascade 2で一部の分野を同じRL工程へまとめた理由として、能力の干渉が小さいことに加え、回答の長さや検証時間が近いことを挙げている。(arXiv)

したがって、MixRLで重要なのは「何でも同時に学習すること」ではない。

一緒に学習する利点が大きい能力と、分けた方が扱いやすい能力を見極めることである。

ここで、専門化した能力を後から統合する蒸留が意味を持つ。

6．蒸留――専門家を毎回呼ぶ代わりに、その能力を学ばせる

AIにおける蒸留、distillationとは、教師モデルの出力や出力確率を手掛かりとして、生徒モデルを学習させる方法である。

複数のモデルを毎回すべて動かすと、推論の費用や運用が重くなる。そこで、教師側の振る舞いを一つのモデルへ移し、使いやすくする。この考え方自体は古く、複数モデルや専門モデルの知識を一つへ移す研究も以前から存在する。(arXiv)

よく知られているのは、大きなモデルから小さなモデルへの蒸留だ。しかし、蒸留の目的は必ずしも小型化だけではない。

別々に得られた能力を、一つのモデルへ統合するためにも使える。

例えば、コードに強い教師、数学に強い教師、指示追従に強い教師がいるとする。それぞれの得意分野を生徒へ学ばせれば、一つの生徒に幅広い能力を持たせることを狙える。

重要なのは、これが利用時のマルチエージェント構成とは異なることだ。

複数の専門AIを毎回呼び出して相談させるのではなく、学習時に専門能力を生徒の重みへ取り込む。 その結果、利用時には統合後のモデルを動かせる。複数の方策を一つへ統合する発想は、強化学習の方策蒸留でも研究されてきた。(arXiv)

7．MOPD――生徒自身の試行を、複数の教師から学び直す

Xiaomiが提案したMOPDは、Multi-Teacher On-Policy Distillation、複数教師によるオンポリシー蒸留の略である。

基本形は、共通の出発点から分野別のRL教師を育て、その能力を一つの生徒へ統合する構成だ。教師の訓練は独立して進められ、統合時には課題の分野に対応する教師を使う。(arXiv)

ここで最も重要なのが、On-Policy、オンポリシーという部分である。

方策、policyとは、その状況でどの出力や行動を選ぶかというモデルの振る舞い方を指す。オンポリシー蒸留では、教師が作った模範解答を読むだけではなく、生徒自身が生成した試行を使って学ぶ。

模範解答だけでは、生徒のつまずき方を十分に扱えない

例えば、生徒がコード修正の途中で、関係の薄いファイルを読み続けてしまったとする。

教師の模範解答には、最初から正しいファイルを調べる手順しか載っていないかもしれない。その場合、生徒が実際に入り込みやすい状況と、教材にある状況がずれる。

オンポリシー蒸留は、このずれを小さくするために、生徒自身が作った履歴を教師へ渡す。教師は、その同じ履歴を前提とした出力確率を返し、生徒はそれを学習信号として利用する。(Thinking Machines Lab)

MOPDでは、この教師を分野ごとに切り替える。コードの課題ならコードの教師、数学なら数学の教師、という対応である。すべての教師が毎回投票する構成ではない。(arXiv)

「合格・不合格」だけより細かな信号を得られる

通常の結果報酬では、長い試行の最後に「成功」「失敗」と評価されても、途中のどの選択を変えるべきかは分かりにくい。

オンポリシー蒸留では、文章やコードを構成する単位であるトークンごとの出力確率を使える。このため、試行の最後に一つの点数を返す方式より、細かな学習信号を作りやすい。(Thinking Machines Lab)

ただし、これは教師がすべての判断の正誤や、失敗の原因を完全に特定しているという意味ではない。得られるのは、基本的には「その履歴で、教師なら何を出力しやすいか」という情報である。

教師にも誤りがあり、教師の能力がそのまま無損失で移る保証もない。

また、MOPDは教師の重みを単純に平均する処理ではない。 生徒の出力分布を教師へ近づけるように、生徒を追加学習する。Xiaomiの論文では、その差を測るために逆向きのKLダイバージェンスという尺度を使っている。(arXiv)

厳密には、環境からの報酬を改善するRLと、教師の分布へ近づける蒸留は、学習信号が異なる。ただし、生徒自身の試行を使い、RLに近い更新処理で実装できるため、両者は同じ学習工程へ組み込みやすい。(Thinking Machines Lab)

8．MiMo-V2.6は、MixRLとMOPDをどう組み合わせるのか

ここでは、MOPDの一般的な説明と、MiMo-V2.6で公表された構成を区別したい。

MiMo-V2.6の説明は、主要な複数分野を最初から別々にRLし、最後にすべて合成する、というだけのものではない。

モデルカードでは、複数分野をまとめた混合RLを行った後に、拡張版のMOPD2を実施するとされている。(Hugging Face)

大きな役割分担としては、

複数の仕事を一緒に経験させて鍛えるMixRLと、教師が持つ能力を取り込むMOPD2を接続する。

そう理解するとよい。

MOPD2は、通常の生徒自身による試行に加え、教師の行動履歴やSFTの実演例を途中までの文脈として利用する。そこから続く判断を生徒に生成させることで、前半の長い作業を毎回最初から再現せず、特定の判断地点を学習に使える。検証が難しい課題への能力拡張も目的として説明されている。(Hugging Face)

つまり、MOPD2では「最初から最後まで、すべて生徒自身の履歴だけで学ぶ」という形にも限定していない。

共同で経験させる工程と、教師の成果を利用する工程を使い分ける。 これが組み合わせの意味である。

そして、ここでいう専門教師は、MoEモデル内部の「専門家」と呼ばれる計算ブロックとは別の概念だ。複数の教師を用意することと、モデル内部で一部の計算ブロックだけを動かすことは、異なる階層の設計である。

9．NVIDIAにも近い構成がある

この方向はMiMoだけのものではない。

NVIDIAが2026年3月に公開したNemotron-Cascade 2も、段階的なRLと、複数分野のオンポリシー蒸留を組み合わせている。(NVIDIA)

Cascade RLは、複数の学習工程を順番に進める方式である。ただし、単純に分野を一つずつ追加すると、それまでの能力が低下することがある。

そこでNemotron-Cascade 2では、学習途中で保存したモデルのうち、各分野で良かったものを教師として利用する。後の学習で低下した能力を取り戻し、全体のバランスを整えるために蒸留を挟む。(NVIDIA)

この方法は、専門能力を育てる工程と、それを統合・回復する工程を分けるという点で、今回の話に近い。

なお、略称には注意が必要だ。

XiaomiのMOPDはMulti-Teacher On-Policy Distillation、NVIDIAの論文にあるMOPDはMulti-Domain On-Policy Distillationである。 名称の展開は違うが、複数の教師を利用し、生徒自身の出力に基づく学習で能力を統合するという共通点がある。(arXiv)

したがって、RLで専門能力を伸ばし、蒸留で一つのモデルへ戻すことは、すでに実用化された有力な学習設計の一つといえる。

一方で、学習の順番、教師の選び方、課題の混ぜ方まで各社共通の標準になったわけではない。

10．OpenAIのAstraやGPT-6世代も同じなのか

ここは、確認できる事実と推測を分ける必要がある。

OpenAIはGPT-6 Astraの発表で、事前学習、強化学習、アラインメントの研究を組み合わせたと説明している。システムカードにも、強化学習を通じて推論方法を改善し、異なる戦略を試し、誤りを認識することを学ぶという記述がある。AstraでRLが使われていることは、公式に確認できる。(OpenAI)

しかし、今回確認した公式資料では、MiMoと同じ意味でのMixRLやMOPD2の採用は説明されていない。GPT-6世代の各モデルについて、専門教師の数、能力統合の方法、蒸留を入れる時期なども特定できない。

整理すると、次のようになる。

この区別は重要だ。数学にもコードにも強く、ツールも使えるという結果だけから、内部の学習手順を一意に逆算することはできない。Astraの公式発表とシステムカードはRLの利用を裏付けるが、同一の能力統合方式まで裏付けるものではない。(OpenAI)

同じ課題に取り組んでいることと、同じ解法を採用していることは別なのである。

11．MiMoがスケールさせたのは、試行回数だけではない

MiMoのモデルカードでは、RLの1ステップについて、1,568課題に対して、それぞれ16回の試行を生成する設定が示されている。単純に掛けると、1ステップあたり25,088本の試行になる。(Hugging Face)

ここでいう本数はGPU枚数ではない。一つの課題に対して複数の解き方を試し、その差を学習に使うための数である。

公式発表では、ProとFlashの公開RL実験をそれぞれ30ステップ、6日未満で実施したとされている。また、当該実験のProについて、学習外の長期ソフトウェア開発評価であるDeepSWE v1.1のスコアが58.4から72.6へ改善したと報告している。これは開発チームによる実験結果であり、他社との条件を完全にそろえた独立比較を意味しない。(MiMo)

もちろん、6日でモデル全体をゼロから作ったわけでもない。その前に基盤モデルや学習システムの開発がある。

採点にも計算量を使う

試行数を増やしても、評価が雑なら良い学習にはならない。

例えば、二つのコード修正がどちらもテストを通過した場合、合格・不合格だけでは差を付けられない。一方は必要な部分だけを修正し、もう一方は無関係な変更を大量に加えているかもしれない。

MiMoは、同じ課題に対する複数の試行を比較し、成功した解き方の質にも差を付ける採点方式を説明している。成果を作るAIだけでなく、成果を評価する側にも計算を使うのである。(Hugging Face)

ただし、採点にAIを使えば問題が解決するわけではない。

採点の抜け穴を利用し、本来の仕事をしていないのに高い報酬を得ることも起こり得る。Anthropicは、実際のClaude訓練から取り出したプログラミング課題を使い、こうした報酬の不正な獲得を研究している。(Anthropic)

計算量だけでなく、環境の質と、成功を正しく判定する能力もスケールさせなければならない。

12．公開されたのは、完成モデルだけではない

Xiaomiは、モデルの重みと技術レポートに加えて、7,000件超のRLタスク環境、学習フレームワーク、組み合わせ可能な軽量ハーネスを公開対象として説明している。環境とのやり取り、試行の収集、報酬評価、モデル更新までを研究できる構成である。(MiMo)

また、MiMo-V2.6-Distill-Qwen-9Bも用意している。

これはQwen3.5-9BをMiMo生成データでSFTしたモデルであり、公開モデルカードでは、エージェントRL研究の出発点として位置づけられている。つまり、この9Bモデル自体を「MOPD2を実施した完成品」と混同すべきではない。(Hugging Face)

大規模モデルの完成品だけが公開されても、同じ規模の設備を持たない研究者には、学習方法を検証しにくい。

小型の出発点と環境があれば、報酬の設計、ハーネスの変更、課題の混合方法などを比較する実験へ進みやすくなる。

ただし、これは巨大モデルの全開発工程を、誰でもそのまま再現できるという意味ではない。研究の入口を広げることと、フロンティア開発の全費用・全資源を取り除くことは別である。

13．強化学習は「学習のための推論」を大量に必要とする

ここから計算資源の話へ移ろう。

強化学習と聞くと、GPUがずっと重みの更新をしているように思える。しかし実際には、更新に使う経験を作るために、モデルを何度も動かす必要がある。

その部分は、計算としては推論である。

試行生成と学習更新の分離は、AReaLなどの学習基盤で実装されている。教師の出力確率を使うオンポリシー蒸留では、教師側の計算も追加される。ただし、教師が毎回長い模範解答を新しく生成するとは限らず、生徒の履歴を入力として確率を計算する使い方もある。(arXiv)

また、すべてがGPUの仕事になるわけではない。

通常のコードテスト、ファイル操作、文字列による正答確認などは、CPU側で実行できる。AReaLも、こうしたCPU処理をGPU計算と分離し、並行して進めている。(arXiv)

つまり、エージェントRLの計算需要は、

モデルを動かすGPU、モデルを更新するGPU、環境を実行するCPU、履歴を保存するメモリやストレージ、それらを結ぶネットワーク

へ分かれる。

「AIを使うための計算」に加えて、次のAIを鍛えるために、AIを大量に使う計算が必要になるのである。

14．H100は、その分業の中で何を担当できるのか

H100は、試行生成、採点モデル、教師モデルの計算、そしてモデルの規模によっては学習更新自体にも使える。

実際、PipelineRLの論文では、7Bモデルの実験に128基のH100を使用し、48基を生成、80基を学習へ割り当てている。 これは当該研究の設定であり、MiMoのGPU構成や、RL全般に共通する比率ではない。(arXiv)

ここから分かるのは、H100がエージェント学習に利用可能だということだけではない。

生成と更新を分ければ、役割に応じて計算資源を配置できる。

異なるGPUを組み合わせる研究例もある。AReaL-Hexでは、H20を試行生成へ、H800を学習更新へ割り当て、同一予算の均一GPU構成と比較して効率を高めたと報告している。(arXiv)

ただし、これはH100とBlackwellの直接比較ではない。「異なる処理を、異なるハードウェアへ割り当てる利点」を示す事例である。

古いGPUで動かすことと、古いモデルを使うことは違う

例えばH100群が試行生成を担当するなら、学習中のモデルの十分に新しい重みを、そのH100群へ配布する必要がある。

「古いGPUだから、古いAIに経験を集めさせればよい」という話ではない。

更新が進んでいるのに、生成側だけが古い重みのままでは、学習に届くデータが古くなる。非同期RLは、このデータの鮮度と、ハードウェアの稼働率を両立させる必要がある。(arXiv)

さらに、巨大モデルを載せるメモリ容量、長い文脈を保持する領域、GPU間通信も必要になる。MiMo-V2.6-Proのような巨大なモデルを、単体のH100で簡単に動かせるという意味ではない。(Hugging Face)

15．新世代の方が高性能なのに、なぜ旧世代が使われるのか

ここは、性能と経済性を分けて考えると分かりやすい。

Blackwellなどの後続世代は、H100世代から演算能力やメモリ周辺を拡張している。例えばDGX B200は、8GPUで合計1,440GBのGPUメモリと64TB/sのHBM帯域を備える。新世代の性能上の利点が、RLという用途によって消えるわけではない。(NVIDIA)

それでも旧世代を使う理由があるのは、最も効率の良い設備を、必要な量だけすぐに使えるとは限らないからだ。

NVIDIAは2026年8月公表の10-Qで、BlackwellとRubinの供給に一定の制約があると説明している。また、導入側でも土地、電力、建物、資金の不足が制約になり得るとしている。

説明用の状況を考えてみよう。

新世代GPUはすでに重要な仕事で埋まっている。追加導入には時間がかかる。一方、既存のH100設備には使える余力がある。

このときの選択肢は、必ずしも「H100か、新世代か」ではない。

H100で今から処理するか、新世代が空くまでその仕事を待たせるか。

H100を動かす費用より、そこで得られる成果の価値が大きければ、性能で劣っていても使う理由がある。

したがって、今回の話は、余ったH100を埋めるために無理に用途を作ったというより、追加の学習需要が生まれ、既存設備でも採算が合う仕事が増え得るという構造に近い。

電力が上限なら、判断は変わる

一方、データセンターの電力や冷却能力が限界なら、同じ話にはならない。

H100を動かすために、より効率の良い新世代GPUを止めなければならないのであれば、その電力枠をどちらへ配分するかが問題になる。

新世代GPUが実際に導入可能で、対象処理の電力効率にも優れるなら、旧世代を置き換える理由が強くなる。

つまり、経済性は条件次第である。

GPUそのものが不足しているのか。導入できる電力が不足しているのか。予算が不足しているのか。

この違いによって、H100の価値は変わる。

また、すでに購入したH100を使い続ける判断と、今からH100を新規購入する判断も別だ。既存設備でも電力、保守、売却や他用途への転用を諦める費用は残るが、新規購入では取得費用まで含めて比較する必要がある。

16．新用途は旧世代を支え得るが、需要増加を保証しない

ここまでの話から、いくつかの点を分けておきたい。

まず、エージェントRLの存在は、MiMo以前から確認されている。 MiMoの発表によって、GPUの用途が突然ゼロから誕生したわけではない。公開によって実験の参加者や回数が増える可能性はあるが、その波及量は別途確認する必要がある。(OpenAI)

また、H100がよく使われることと、高い価格で使われることは同じではない。価格が下がったからこそ採算の合う用途が広がる、という場合も考えられる。

そして、学習手法の改善は、計算需要を増やすだけでなく、同じ性能へ到達するための計算量を減らす方向にも働く。 オンポリシー蒸留や非同期RLの研究は、まさに学習信号やハードウェア利用の効率を高めようとしている。(Thinking Machines Lab)

総需要が増えるかどうかは、効率改善による節約よりも、実験規模、対象課題、利用者数の拡大が大きいかで変わる。

半導体需要についても、既存のH100を再利用するだけなら、それが直ちに新しいGPUやHBMの購入になるわけではない。既存設備の空きを埋める段階と、新規設備投資まで押し上げる段階は区別すべきである。

公開情報で確認できるのは、H100を使ったRL実験と、異種GPUによる分業の実証、そして新世代設備の供給・導入制約である。MiMoの発表がH100需要や価格をどれだけ押し上げたかまでは確認できない。(arXiv)

17．計算資源の競争は、GPU対ASICだけでは捉えられない

ここまで、エージェントの強化学習が、試行生成、評価、教師モデルの計算、重みの更新といった複数の処理から成り立つことを見てきた。

この分業をハードウェアの側から見ると、「GPUとASICのどちらが勝つのか」という二者択一では整理しきれない。

まず、x86、Grace、Vera、GPU、TPU、ASICは、すべて同じ階層の分類ではない。

x86はCPUが解釈する命令体系の系統であり、GraceとVeraはNVIDIAのCPU製品である。GraceはArm Neoverse V2コアを採用し、VeraはArm系の独自Olympusコアを採用する。したがって、CPU側の比較では、主にIntel XeonやAMD EPYCなどのx86サーバーと、Grace・VeraなどのArm系サーバーを比べることになる。(NVIDIA Docs)

一方、GPUやTPUは、モデル内部の大規模な計算を担うアクセラレータである。TPUは機械学習向けに設計されたASICの一種であり、TPUとASICが別々の対立陣営というわけではない。 TPUにも行列演算だけでなく、ベクトル処理や制御を担う計算部分がある。(Google Cloud Documentation)

この違いを踏まえると、エージェント学習の計算資源は、次のように分けて考えられる。

これは処理の役割を整理したもので、すべての環境実行がCPUだけで済むという意味ではない。ただし、モデル計算と環境実行を切り離す設計は実際に存在する。例えばNVIDIAのNeMo GymはCPU側で動作し、モデルの推論エンジンを通信経由で呼び出す構成になっている。(NVIDIA Docs)

何というチップを使うかより先に、どの仕事を担当させるのかを分ける必要がある。

18．x86の強みは「RL向きの命令」より、既存ソフトウェアとの互換性

エージェントに既存のソフトウェアを修正させる場合、そのソフトウェアが元々動いていた環境を再現する必要がある。

例えば、x86向けの実行ファイル、特定のライブラリ、既存のコンテナを組み合わせた環境なら、x86サーバーで動かす方が追加作業を減らしやすい。

ここでの利点は、強化学習の計算式がx86に適していることではない。

学習対象となる仕事を、元の環境に近い状態で実行しやすいことである。

コンテナに入れても、CPUの違いは消えない

Dockerなどのコンテナは、プログラムと依存するソフトウェアをまとめ、環境を再現しやすくする仕組みである。しかし、x86向けの実行ファイルを自動的にArm向けへ変換するものではない。

Docker公式資料も、x86向けのlinux/amd64コンテナをArm環境で動かすには、エミュレーションなどが必要になると説明している。エミュレーションとは、別のCPUの動きをソフトウェアで再現する方法だ。コンパイルや圧縮・展開などでは、直接実行する場合より大幅に遅くなることがある。(Docker Documentation)

実際、ソフトウェア修正能力を評価するSWE-benchの公式リポジトリでは、2026年9月23日時点でもx86-64環境を推奨し、Arm対応を実験的な扱いとしている。一方、Arm上で環境を構築する手順も用意されており、「Armでは実行不可能」という意味ではない。(GitHub)

したがって、比較すべきなのはCPUの演算速度だけではない。

環境を移植する手間、依存ソフトウェアをそろえる手間、結果が元の環境と同じ意味を持つか確かめる手間も、学習基盤を作る費用になる。

ただし、最初からArmに対応した環境を用意できるなら、この互換性の差は小さくなる。Dockerも、複数のCPU向けに作ったイメージから、実行先に合うものを選ぶ仕組みを提供している。(Docker Documentation)

x86の利点は、既存資産がx86を前提としているときに強く現れる。あらゆるエージェント学習で、x86が本質的に速いという話ではない。

19．GraceとVeraは、CPUの仕事を別の方向から改善する

x86に互換性の利点があるとしても、GraceやVeraがエージェント学習に不向きということにはならない。

Graceを使う構成の特徴の一つは、CPUとGPUを密接につなげることだ。

例えばGH200では、Grace CPUとHopper GPUをNVLink-C2Cで接続する。公称900GB/sの接続帯域に加え、CPUとGPUがメモリを一貫した形で扱える仕組みを備える。これは、CPUとGPUの間でデータを移したり、両方のメモリを利用したりする処理を意識した設計である。(NVIDIA)

ただし、CPU側のメモリを利用できることと、そのメモリがGPUのHBMと同じ速度になることは別だ。Graceの公式仕様でも、CPU側のLPDDR5XとGPU側のHBMは、容量と帯域を分けて記載されている。どこにデータを置き、どれだけ移動させるかは依然として重要になる。(NVIDIA Docs)

Veraが重視するのは、エージェントを待たせるCPU処理

Veraでは、エージェントやRLの実行環境が、より明示的な設計対象になっている。

NVIDIAは、VeraのOlympusコアについて、多数の処理を同時に動かした状態での一つひとつの処理の速さ、メモリへの不規則なアクセス、分岐の多いプログラム、待ち時間のばらつきを重視していると説明している。(NVIDIA Developer)

その理由は、エージェントの作業に順序があるからだ。

コードを実行し、結果を読み、その結果から次の操作を考える。一つの試行の中では、前の処理が終わらないと進めない場面がある。一方、学習全体では、このような試行を大量に並列実行したい。

そのためCPUには、単にコアが多いだけでなく、多くの環境を同時に動かしても、各環境を安定して前へ進められることが求められる。NVIDIAも、VeraをGPUのホストCPUとしてだけでなく、コード実行やツール操作、隔離環境を担う独立したCPU基盤として位置づけている。(NVIDIA)

例えば説明用に、一つの試行が「モデルの生成20秒、環境の実行80秒」で終わるとする。モデル生成だけを4倍速くしても、全体は100秒から85秒になるだけだ。

これは製品の測定値ではないが、CPU側が長い場合に、GPUだけを速くする効果が限られることを示している。実際のシステムでは別の試行を重ねて処理できるため、この待ち時間がそのまま全GPUの停止時間になるわけではない。

ここで重要なのは、CPUの仕事が増えることと、その仕事を必ずx86が取ることは別だという点である。

Veraも、その仕事を取り込むための設計である。ただし、メーカーが示す設計目標や測定結果から、すべての条件でx86より有利だとは結論できない。比較には、同じソフトウェア、同じ同時実行数、同じ電力・メモリ条件などが必要になる。

20．環境はx86、モデル計算はGrace系GPUやTPUでもよい

ここで、CPUとアクセラレータの議論をつなげよう。

x86向けのソフトウェアを学習課題に使うとしても、AIモデルを動かす側までx86へ統一する必要はない。

モデル計算を担う設備と、コードを実行する設備を分離すれば、次のような配置が考えられる。

GraceやVeraを使うGPU設備でモデルを動かし、外部のx86サーバーでビルドやテストを実行する。

あるいは、

TPUでモデルを動かし、そのモデルが操作するソフトウェア環境はx86サーバーへ置く。

これらは設計上の例であり、MiMoの実際の設備構成を示したものではない。

分離の考え方自体は、NeMo Gymのような公開実装に見られる。同実装では、環境側はモデル内部へ直接アクセスせず、HTTP経由で推論を呼び出す。ただし、公開されているこの構成はvLLMとの接続を前提としており、TPUへ接続するなら対応する実装と検証が別途必要になる。(NVIDIA Docs)

また、「x86＋旧世代GPU」と「Arm系CPU＋新世代GPU」という二択でもない。例えばDGX B200は、8基のB200 GPUと2基のIntel Xeon CPUを組み合わせている。新世代GPUをx86と使う構成も存在する。(NVIDIA Docs)

分けられる仕事と、近くに置きたい仕事

もっとも、何でも遠くへ分散すれば効率が上がるわけではない。

ツールへの操作指示と実行結果を送る処理と、巨大なモデルの重みを頻繁に配布する処理では、通信量も要求も違う。学習更新の途中で大量のデータを交換するGPU同士には、速い通信が必要になる。

AReaL-Hexも、異なるGPU群へ生成と更新を分ける一方、重み同期の費用や、生成した経験が古くなりすぎない制約を扱っている。(arXiv)

したがって、設計の方向は、異なるチップを一つの同期計算へ無造作に混ぜることではない。

密接に通信する計算は近くへまとめ、切り離せる仕事は、それに合う別の資源へ任せる。

この分業によって、CPUの互換性とGPU・TPUの計算効率を、別々に追求する余地が生まれる。

21．TPUやASICは、エージェントRLに後から参加するだけではない

新しい用途では、柔軟なGPUで実験し、処理が固まってから専用アクセラレータへ移す、という流れが考えられる。

ただし、これを「研究はGPU、本番はTPUやASIC」という固定的な分業にしてしまうと、実態を捉え損ねる。

Googleが2025年9月に公開したTunixは、TPU向けの追加学習基盤であり、強化学習と蒸留に対応する。学習ループを変更しやすい設計も特徴としている。さらに、現在の資料には、複数ターンのツール操作、非同期の試行生成、重み同期の管理が説明されている。TPU上で新しいエージェント学習を研究すること自体が可能なのである。(Google Developers Blog)

TPUは、特定のモデルの重みを回路に固定し、そのモデルしか動かせない装置でもない。重みをメモリから読み出し、行列演算などを実行する。JAXのPallasでは、TPU向けの独自の計算処理も記述できる。(Google Cloud Documentation)

ここでは、二種類の「実装」を分ける必要がある。

一つは、既存のTPUやASICに合わせて、ソフトウェアを最適化すること。もう一つは、将来のチップ自体を、その用途に合わせて設計し直すことである。

前者なら、新しい半導体が完成するのを待たずに対応できる場合がある。

「用途が新しい」と「計算方式が新しい」は違う

例えば、同じモデルを使ってコード修正、調査、採点の仕事を増やしても、内部の主要な計算は大きく変わらない場合がある。

その場合、仕事の名前が新しくなっただけで、毎回GPUから実験を始め直す必要はない。

一方、モデル構造、メモリの使い方、更新方法、必要な演算が変われば、対応するソフトウェアの充実度が重要になる。

GPUの柔軟性が特に価値を持つのは、新用途という名称そのものより、計算の実装がまだ固まっておらず、変更と検証を繰り返す場面と考える方がよい。

また、ASICを一括りにもできない。学習対応の装置と、推論だけを担当する装置では役割が違う。推論専用の設備に重み更新まで任せることはできないが、試行生成や教師モデルの計算へ使う余地はある。

重み更新への対応も、チップ名だけでは分からない

RLでは、学習中のモデルの重みを生成側へ配布する必要がある。そのため、固定モデルを長期間配信する場合とは、運用上の要求が異なる。Tunixにも、この重み同期と試行生成の競合を管理する仕組みがある。(Tunix)

ただし、「ASICは重みが変わるたびに最初からコンパイルし直す」という理解も正しくない。

AWS Neuronには、対応する形式で準備したモデルについて、実行プログラムを保ったまま重みを置き換える機能がある。計算構造や配列の形が変わることと、同じ形の重みの値が変わることは別なのである。(AWS Neuron Documentation)

22．MOPDは、異なる計算資源へ分担させる余地を作る

MOPDでは、生徒モデルが作った履歴に対して、教師モデルから学習信号を得る。

このとき教師は、必ずしも最初から長い回答を生成し直す必要はない。すでに生徒が生成した系列を入力し、それに対する出力確率を前向き計算で求める使い方ができる。Thinking Machines Labも、オンポリシー蒸留の教師計算について、この特徴を説明している。(Thinking Machines Lab)

この構造をハードウェア側から見ると、次のような違いがある。

生徒の試行生成では、出力を順番に作り、途中でツールの結果を待ち、更新された重みを受け取る。

一方、ある学習段階で教師を固定して使うなら、教師側は、同じモデルで多数の履歴を処理する仕事としてまとめやすくなる。

ここからは配置に関する推論だが、教師の確率計算や一部の採点をTPU・ASICへ切り出し、生徒の実験や更新をGPU側へ置く構成も候補になる。反対に、全体をTPUへ統一した方が、通信と運用を単純化できる場合も考えられる。

重要なのは、単純な文章生成速度だけで判断しないことだ。

必要な確率情報を取り出せるか、教師と生徒のトークンの対応を扱えるか、数値精度は十分か、長い履歴を処理できるか、結果の転送に費用がかからないか。こうした条件まで満たす必要がある。実際、NeMo RLのオンポリシー蒸留も、生徒の会話履歴から教師の出力を計算し、学習用の損失へつなぐ構成を持つ。(NVIDIA Docs)

MixRL・MOPDは、特定のアクセラレータを排除する方式ではない。むしろ、性質の異なる計算を見分け、それぞれに合う資源へ割り当てる余地を持つ。

23．新用途の探索と専用化は、同時に進み得る

ここまでを踏まえると、新用途と計算資源の関係は、一方向の世代交代ではなく、複数の流れが重なるものとして見えてくる。

説明用に、ある新しい学習方法Aを考える。

最初は、どの課題を混ぜるか、どんな評価を返すか、どの計算処理が遅いかも十分に分かっていない。既存コードを変更しやすいGPU環境が手元にあれば、まずそこで実験する合理性がある。CUDAは、独自の並列計算、メモリ管理、非同期実行などを記述する基盤を提供している。(NVIDIA Docs)

研究段階で重要なのは、一回の実行費用だけではない。

思いついた変更を実装し、間違いを調べ、次の実験結果を得るまでの総費用と時間である。

その後、Aの処理が固まり、大量に繰り返す部分が見えてきたら、GPU向けの実装をさらに磨くことも、TPUへ移すことも、将来の専用チップへ反映することも考えられる。

しかし、その頃には、新しい学習方法Bや記憶方式Cの実験が始まっているかもしれない。

この場合、AがGPUから離れても、BやCが新しいGPU需要を作る。

個々の用途は専用化されても、用途全体では、まだ実装の固まっていない仕事が生まれ続ける。

これが、柔軟な計算基盤への需要が続くという仮説の中心である。

ただし、すべての研究がGPUから始まるわけではなく、すべての用途がASICへ移るわけでもない。TPU上の学習環境が整っている組織なら、初期の研究からTPUを使える。Tunixは、そのための公開基盤の一例である。(Google Developers Blog)

実際の流れは、各組織が持つ設備、ソフトウェア、開発者の経験、処理規模、移植費用によって変わる。

24．AIによる改善は、新用途の発見と専用化の両方を速め得る

この循環をさらに速める可能性があるのが、AI自身による研究開発への参加である。

AIが実験案を出し、コードを作り、結果を評価し、次の改善案を考える。その成果が次のモデルや計算基盤の改善に使われれば、AIが、自分たちを動かす技術を改善するループの一部になる。

そして、その改善対象は、モデルの学習方法だけではない。計算を実行するソフトウェアから、専用チップの設計まで広がっている。

AlphaEvolve――AIが学習処理とTPU・GPUを改善する

Google DeepMindが2025年5月に公表したAlphaEvolveは、その具体例である。Geminiがプログラムを提案し、自動評価で正しさや性能を確かめ、有望な案をさらに改善する仕組みだ。(Google DeepMind)

Googleによると、AlphaEvolveはGeminiの学習に使う計算処理を改善したほか、TPU向けの演算回路の変更も提案した。この変更は機能が正しいことを確認する検証を経て、将来のTPU設計へ取り込まれた。また、GPU向けの低水準の計算処理を高速化した事例も報告されている。(Google DeepMind)

つまり、AIが改善するのは、GPU上で動くプログラムだけではない。GPU以外の計算資源を、より効率よく使うための設計にも参加している。

Jalapeño――チップを設計するAIと、そのチップを使いこなすAI

OpenAIのJalapeñoは、この関係をさらに具体的に示している。

2026年6月に発表されたJalapeñoは、LLMの推論を対象とする独自アクセラレータである。OpenAIがモデル、計算処理、推論サービスの要求を踏まえて設計し、Broadcomがシリコン実装やネットワーク、Celesticaがボード・ラックなどのシステム化を支える構成だ。(openai.com)

OpenAIは、設計開始からテープアウト、つまり製造へ渡すための設計確定まで9か月だったと説明している。その過程では、OpenAIのモデルが設計・最適化の一部を加速したという。ただし、AIだけでチップ全体を設計したという意味ではなく、開発期間の短さをAIだけの効果とみなすこともできない。公式説明でも、人間の技術者による共同開発とBroadcomの実装技術が挙げられている。(OpenAI)

さらに重要なのは、チップを作った後のソフトウェアである。

OpenAIは2026年8月の報告で、CodexとGPT-Astraを使い、当初の計画に含まれていなかった三つの公開重みモデルを、2か月で高性能に動作させたと説明している。また、GPT-OSSの一部のAttention・MoE処理では、AIが生成した実装が人間の専門家による既存実装より1.5～1.8倍速かったとしている。ただし、これは選ばれた処理部分の結果であり、モデル全体の高速化率ではない。(OpenAI)

同社はJalapeñoを、人間にもAIにも計算の配置や通信、同期を扱いやすいプログラミング対象として設計したと説明している。AIでチップ開発を支援するだけでなく、AIがそのチップを使いこなすためのコードを書きやすくするという、双方向の設計である。(OpenAI)

ここから読み取れるのは、専用チップの価値が回路だけで決まらないということだ。新しいモデルを動かすための実装と最適化を速められれば、専用チップが対応できる仕事の範囲も広げやすくなる。

AIは、新しい実験も、専用化も速め得る

この二つの事例を踏まえると、AIによる改善は、計算資源の需要へ二方向に作用すると考えられる。

一方では、実験案の作成や実装、検証の手間が減り、新しい学習方法や評価方法を試しやすくなる。試せる仕事が増えれば、変更と検証を進めやすいGPUなどの計算基盤への需要を押し上げる可能性がある。

他方では、同じAIが、既存の処理をTPUやASICへ移すための実装や最適化、さらにはチップ設計そのものも支援する。Jalapeñoの事例は、「専用ハードウェアはできたが、対応ソフトウェアの開発に時間がかかる」という問題を、AIが小さくし得ることを示唆する。(OpenAI)

したがって、AIによる改善の加速を、そのままGPUだけの需要増加へ結び付けることはできない。

新しい仕事を生む速度と、その仕事を効率化・専用化する速度が、同時に上がる可能性がある。

ここから考えられるのは、例えば次のような循環である。

AIが計算基盤を改善する → 同じ予算で処理できる試行が増える → より多くの経験や実験結果が得られる → 次のモデルと計算基盤の改善へ使う。

これは公開事例から考えられる発展の方向であり、完全自律の再帰的改善や、際限のない加速が実証されたという意味ではない。また、推論向けのJalapeñoが、MiMoの学習更新を含む全工程に対応すると示されたわけでもない。

専用化と、既存設備の活用は両立する

専用チップの導入が進んでも、すべての仕事が一度に移るとは限らない。OpenAI自身も、Jalapeñoの展開と並行して、学習・推論の双方でNVIDIAなどのアクセラレータを引き続き広く導入すると説明している。ただし、これはH100など特定の旧世代を使い続けると約束したものではない。(OpenAI)

旧世代GPUまで仕事が残るかどうかは、新しい実験の規模と、必要な性能、使える設備、電力、運用費によって変わる。本稿で述べた通り、効率改善による節約と用途の拡大は同時に起こり得るため、総需要や新規購入への波及は別に検証する必要がある。

また、コードの生成や最適化が速くなっても、検証、製造、設備導入、電力確保までが同じ速度で進むとは限らない。その時間差の中で、条件を満たす既存設備を使う合理性は残り得る。

AIが速めるのは、GPU上の探索だけではない。TPUやASICへの専用化も速め、その先で可能になる新しい仕事も増やし得る。

JalapeñoとAlphaEvolveが示すのは、単に「AIがチップを作る」という話ではなく、モデル、ソフトウェア、半導体が互いの改善に関わる循環が、すでに一部で動き始めているということである。

25．旧世代GPUに需要が残るのは、柔軟性と採算が両立する範囲

新用途が継続的に生まれるなら、GPU全体に仕事が供給され続ける可能性はある。

ただし、そこからもう一段、分ける必要がある。

GPUという種類への需要が残ることと、H100など特定世代への需要が残ることは、同じ命題ではない。

新しい研究でも、巨大なメモリ容量や速い通信、新しい計算機能が必要なら、新世代の設備が選ばれる。一方、小型モデルでの予備実験、対応可能な規模の試行生成、評価モデルの実行などでは、既存設備を使う余地がある。

本稿で紹介したAReaL-Hexも、性質の違うGPUを生成と更新へ分担させる研究である。ただし、その成果はH20とH800を使った条件で得られたもので、あらゆる旧世代GPUの採算を保証するものではない。(arXiv)

旧世代を使い続ける合理性は、例えば次の条件から生まれる。

対象モデルがメモリに収まり、必要な処理に対応している。新世代設備をすぐに使えない一方、既存設備には余力がある。そして電力、保守、運用まで含めても、その仕事を進める価値が費用を上回る。

反対に、処理が遅すぎて学習全体を待たせるなら、空いているだけでは有効な戦力にならない。電力や冷却が上限なら、より効率のよい新世代へ枠を渡した方がよい場合もある。

また、この論理は旧世代GPUだけに固有のものではない。既存のCPUやTPUなどでも、必要な機能を満たし、採算が合えば使い続ける余地がある。

「古いから使う」のではなく、「今ある資源の中で、その仕事を進める合理性があるから使う」のである。

ASICの比率が上がっても、GPUの計算量は増え得る

市場全体を見るときには、割合と絶対量も分けたい。

考え方を単純化し、同じ基準の計算量へ換算するなら、

GPUが担当する計算量 ＝ 試行回数 × 一試行あたりの平均計算量 × GPUで実行する割合

と整理できる。これは予測モデルではなく、要因を分けるための概念式である。

AIによって実験数が大きく増えれば、一試行の計算量が減り、TPUやASICの担当割合が増えても、GPU側の総計算量が増える場合がある。

ただし、総計算量が増えても、一台あたりの実効性能や稼働率が上がれば、必要な台数が同じように増えるとは限らない。さらに、稼働が続くこと、高いレンタル価格が維持されること、新規購入が増えることも別である。

26．見るべきは、チップの名前ではなく学習全体の進み方

最終的に重要なのは、「GPU、TPU、x86、Armのどれが速いか」という単独の比較だけではない。

必要な品質の経験を集め、正しく評価し、目標とするモデル性能へ到達するまでに、全体でいくらかかるか。

その中には、モデル計算だけでなく、実行環境の待ち時間、移植と検証、重みの同期、メモリとストレージ、ネットワーク、電力、設備を用意するまでの時間も含まれる。

例えば、x86が既存ソフトウェアの再現費用を下げることもあれば、Grace系の接続構造がデータ移動を改善することもある。Veraのように、エージェント環境を処理するCPU自体を改善する方向もある。TPUは、研究段階から学習と蒸留へ参加できる。これらは一つの勝者へ収束するというより、異なる制約への対応として理解できる。(Docker Documentation)

計算資源の需要も、GPUとHBMだけへ集中するとは限らない。

多くの環境を同時に動かすならCPU側のメモリが必要になり、履歴や実行環境を保存するならストレージが必要になる。分業を広げれば、結果や重みを移す通信も重要になる。GraceやVeraがLPDDR5Xを組み込むように、CPU側のメモリ設計も、AIインフラの性能を左右する要素である。(NVIDIA Docs)

ただし、CPUメモリの重要性が増したことから、HBMが不要になるとは言えない。別の仕事を担う資源の需要が増えることと、既存の資源を置き換えることは違う。

ここまでの流れから考えられるのは、次のような構造である。

実装が固まっていない仕事には、変更と検証を進めやすい計算基盤を使う。処理が固まった部分は、その規模と条件に合う設備へ最適化する。その間にも次の仕事が生まれ、対応可能な既存設備が一部を分担する。

GPUはその重要な受け皿だが、探索を独占するわけではない。TPUやASICも、成熟した用途だけを待っているわけではない。そしてCPUも、単にGPUへデータを渡す補助役にとどまらない。

したがって、旧世代GPUの需要が続くという仮説は、

専用化が進まないからGPUが残るのではなく、専用化が進んでも、次の仕事が生まれるからGPUの仕事が残り得る。

と表現できる。

そのうち旧世代が担当する範囲は、性能、互換性、供給、電力、運用費によって決まる。

AIの進歩が広げるのは、単一のチップの用途だけではない。異なる計算資源へ何を任せ、どう組み合わせれば、次の改善へ最も効率よく到達できるかという、設計の選択肢そのものなのである。

27．第三者評価でも示された、MiMoの能力と利用費用

Artificial Analysisは、MiMo-V2.6-Proが総合指標「Intelligence Index」で46点を獲得し、公表時点で公開重みモデルの首位に立ったと報告した。評価課題1件あたりの加重平均API費用は約0.13ドルで、能力と利用費用の組み合わせでも注目される。(X)

MiMo-V2.6-Pro debuts as the top open weights model on the Artificial Analysis Intelligence Index (46). At $0.13 per Intelligence Index task, it lands on the Intelligence vs. Cost per Task Pareto frontier@Xiaomi has just released MiMo-V2.6-Pro, an open weights model with major… pic.twitter.com/W3BrQ7q4Lk — Artificial Analysis (@ArtificialAnlys) September 21, 2026

この指数には、ハーネスを使って成果物を作るエージェント評価も含まれる。開発元の説明に加え、完成モデルの作業遂行能力を外部から確認する材料になる。ただし、この結果だけでMixRL・MOPDそれぞれの寄与を切り分けることはできない。(Artificial Analysis)

能力の高いモデルを低費用で使えれば、新用途の試行も広がり得る。ただし、0.13ドルは特定の評価条件での平均であり、あらゆる仕事の完了費用や、提供側の計算原価ではない。(Artificial Analysis) 能力の向上、用途の拡大、旧世代GPUへの需要波及は、つながり得るが別々に検証すべき段階である。

結び――大きくするだけでなく、どう経験させるか

MiMoのMixRLとMOPDを理解すると、モデル開発が単純な「大きなモデルを一度学習する工程」だけではないことが見えてくる。

複数の仕事を経験させる。成果を評価する。能力が干渉する部分を調整する。専門化した教師から学ぶ。そして、その改善を一つのモデルの重みに残す。

この方向はMiMoだけのものではなく、NVIDIAにも近い構成がある。OpenAIのAstraについてもRLの利用は確認できる。ただし、具体的な能力統合の方法まで同一だとは言えない。(NVIDIA)

MiMoの公開は、こうした工程を外部から検討し、実験するための材料を増やした。

そして、経験から学ばせるには、経験を作るための計算が要る。学習するAIだけでなく、試行するAI、採点するAI、教師として信号を返すAIも動かさなければならない。

その分業の中には、旧世代GPUでも担当できる仕事がある。ただし、それはH100の性能上の優位が復活したという意味ではない。

新世代の方が高性能でも、使える計算資源には限りがある。増え続ける仕事のうち、旧世代でも十分に価値を生み出せる部分を分担させる。

今回の発表は、モデルの学習方法だけでなく、計算資源をどう使い切るかという問題にもつながっている。

AIを鍛えるために、AIを大量に動かす。その計算をどれだけ良い経験と確かな評価へ変えられるかが、モデル開発とAIインフラに共通する課題なのである。