Xiaomi MiMo推論モデル
(github.com/XiaomiMiMo)- XiaomiのMiMo-7Bは、推論タスクのためにゼロから学習された7B言語モデルシリーズで、Base・SFT・RLモデルのチェックポイントをオープンソースで公開
- 2025年5月30日のアップデートでは、SFTデータセットを約50万件から600万件に拡大し、RL学習ウィンドウサイズを32Kから48Kへ拡張したことで、MiMo-7B-RL-0530のAIME 2024性能が80.1に到達
- 事前学習では約25兆トークンと3段階のデータ混合戦略を使用し、推論パターン密度を高めるためのデータフィルタリング・合成推論データ・Multiple-Token Predictionを含む
- 事後学習では、数学・コード問題13万件、ルールベース検証器、ルールベース正確性報酬、コード問題向けのテスト難易度ベース報酬と容易な問題の再サンプリング戦略を使用
- デプロイではSGLang、XiaomiのvLLMフォーク、HuggingFaceの例を提供しており、他の推論エンジンでのMiMo検証はまだ完了しておらず、貢献を受け付けている
MiMo-7Bシリーズの目標と公開範囲
- MiMo-7Bは、言語モデルの推論ポテンシャルを事前学習から事後学習まで引き出すことを目標としたモデルシリーズ
- 公開されたチェックポイントは次の4種類
- MiMo-7B-Base: 推論ポテンシャルを備えたBaseモデル
- MiMo-7B-RL-Zero: BaseモデルをRLで学習したモデル
- MiMo-7B-SFT: BaseモデルをSFTで学習したモデル
- MiMo-7B-RL: SFTモデルをRLで学習したモデル
- モデルはHuggingFaceとModelScopeで提供
- 技術レポートはarXivで公開
2025年5月30日アップデート
- MiMo-7B-RL-0530は、SFTデータセットを約50万件から600万件へ拡大し、RL学習ウィンドウサイズを32Kから48Kへ継続的に拡張した結果を反映
- AIME 2024でMiMo-7B-RL-0530は80.1を記録し、DeepSeek R1の79.8を上回った
- 主なベンチマークの変化は次のとおり
- MATH500 Pass@1: 95.8 → 97.2
- AIME 2024 Pass@1: 68.2 → 80.1
- AIME 2025 Pass@1: 55.4 → 70.2
- LiveCodeBench v5 Pass@1: 57.8 → 60.9
- LiveCodeBench v6 Pass@1: 49.3 → 52.2
- GPQA-Diamond Pass@1: 54.4 → 60.6
- Alignbench1.1, GPT-4.1評価: 6.9 → 7.4
事前学習: 推論向けBaseモデル
- MiMo-7B-Baseは、推論タスクのためにゼロから学習されたBaseモデル
- 事前学習では約25兆トークンを使用
- データ処理では、テキスト抽出ツールを改善し、多次元データフィルタリングを適用して、事前学習データの推論パターン密度を高めた
- 多様な大規模合成推論データを生成するために複数の戦略を使用
- 事前学習には3段階のデータ混合戦略が適用
- Multiple-Token Predictionを追加学習目標として組み込み、モデル性能と推論速度を改善
事後学習とRL学習方式
- 事後学習では、ルールベース検証器で確認可能な数学・コード問題13万件をRL学習データとして使用
- 各問題は品質確保のために精製と難易度評価を経る
- 報酬は、潜在的な報酬ハッキングを避けるためルールベース正確性報酬のみを使用
- 難しいコード問題における疎な報酬の問題を緩和するため、テスト難易度ベースのコード報酬を導入
- 難易度の異なるテストケースに細分化されたスコアを付与
- ポリシーはより高密度な報酬シグナルで最適化可能
- 容易な問題にはデータ再サンプリング戦略を適用してロールアウトサンプリング効率を高め、特にRL学習後半のポリシー更新を安定化
RLインフラとモデル構造
- Seamless Rollout Engineは、RL学習と検証を高速化するために開発
- 設計では、連続ロールアウト、非同期報酬計算、早期終了を組み合わせてGPUのアイドル時間を削減
- 性能改善の数値は次のとおり
- 学習速度2.29倍向上
- 検証速度1.96倍向上
- MiMo-7BのMTPレイヤーは事前学習とSFT中にチューニングされ、RL中は固定
- MTPレイヤー1つを投機的デコーディングに使う場合、受理率は約90%
- vLLMでMTPをサポートし、RLシステムの推論エンジン堅牢性を強化
評価結果
- MiMo-7B-RLは、数学およびコード推論タスクでOpenAI o1-miniに匹敵する性能を示すとされる
- 主なモデル比較でのMiMo-7B-RLの数学・コード結果は次のとおり
- MATH-500 Pass@1: 95.8
- AIME 2024 Pass@1: 68.2
- AIME 2025 Pass@1: 55.4
- LiveCodeBench v5 Pass@1: 57.8
- LiveCodeBench v6 Pass@1: 49.3
- MiMo-7Bシリーズ内部比較では、RL適用後に性能が大きく向上
- MATH500: Base 37.4 → RL-Zero 93.6 → SFT 93.0 → RL 95.8
- AIME 2024: Base 32.9 → RL-Zero 56.4 → SFT 58.7 → RL 68.2
- LiveCodeBench v5: Base 32.9 → RL-Zero 49.1 → SFT 52.3 → RL 57.8
- 評価設定は
temperature=0.6 - 反復評価条件は次のとおり
- AIME24とAIME25は32回反復平均
- LiveCodeBench v5、LiveCodeBench v6、GPQA-Diamond、IF-Evalは8回反復平均
- MATH500とSuperGPQAは単一実行
デプロイと推論利用
- SGLangはMiMoモデル対応とMTP対応により、MiMoをメインストリームでサポート
- 関連PR: MiMo model support, MTP
- 利用ドキュメントはSGLang documentsで提供
- vLLM推論にはXiaomiのvLLMフォークの使用を推奨
- 推奨フォーク: XiaomiMiMo/vllm
- 当該フォークはvLLM 0.7.3ベースで開発
- MTPパラメータをロードしない形でvLLMローダーを登録することも可能
- HuggingFace推論例では
AutoModelForCausalLM.from_pretrainedとAutoTokenizer.from_pretrainedを使用 - 推奨プロンプト設定は空のsystem prompt
- 他の推論エンジンでのMiMo検証はまだ完了しておらず、HuggingFaceリポジトリのモデル定義に基づく貢献を受け付けている
1件のコメント
Hacker Newsの意見
論文でコードデータ向け強化学習段階をどう処理したのかが興味深かった。難しいが解けるコード生成課題を単体テストで実行して学習したとのことだが、ほかのモデルもこうした学習段階を踏んでいるのか気になる
論文では、テストケースのない問題を削除し、正解コードがあってもすべてのテストを通過できなければ除外し、正解コードのない問題は高度な推論モデルで16回サンプリングしてもどのテストも解けなければ捨てるとしている。簡単な問題もMiMo-7BのSFT版でふるいにかけ、最終的に3万件のコード問題を作ったという
また、強化学習の反復ごとに数千問、かつ問題ごとに数百件のテストケースを評価する必要があるため、GPUの遊休時間をなくすために超大規模な単体テストを並列実行するオンラインジャッジ環境を作ったという
小さなモジュール式の問題なら可能だろうが、入力が20万トークンの問題ではこうした方法は難しいかもしれない
中国発のAIモデルで、なぜ英語優先モデルがこれほど多いのか気になる。自国のユーザーを対象にするつもりがないのか、それとも中国語優先モデルを公開しても西側では注目されにくいからなのか分からない
https://commoncrawl.org/
中国語で何かを直接試すのは明らかに不可能で、翻訳が必要になる
例としては、英語の「small」の反対が big、フランス語の「petit」の反対が grand、中国語の「小」の反対が「大」へとつながるようなものだ。関連図もかなり面白い
英語はインターネットの共通語であり最大のコーパスを占めるが、主流モデルは英語データセットを使って言語間の関連を構築できる。だからこそ、データ・技術・リソースが不足していて独自の地域モデルを作りにくい言語圏にも、はるかに強いAIと推論能力をもたらせる
https://www.anthropic.com/research/tracing-thoughts-language...
https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-...
人気ウェブサイトのかなりの部分はアプリ専用でもあり、良いLLM学習に必要なコーパスを確保するのは不可能だ
7Bモデルとしてはコーディング性能が信じがたいほど強い。自分が使っているGemini Pro 2.5が67.8で、このモデルは57.8、60.6のGemini 2.5 Flashにもかなり近い
llama4に関する話を見て評価結果にはかなり懐疑的になっているので、非公開評価でどのあたりに出るかは見てみないと分からないが、今の数値は非常に印象的だ
LM Studio、Ollamaなどで使えるGGUF版: https://huggingface.co/jedisct1/MiMo-7B-RL-GGUF
Ollamaでggufファイルを使うとき、通常は一緒に使うModelfileを自分で作って使うのか、それともOllamaのデフォルト設定が新しいモデルにもそのまま合うことを期待するのか気になる
https://github.com/ollama/ollama/blob/main/docs%2Fmodelfile....
モデルを読み込むのに必要なすべての情報がモデルファイル内にあり、ユーザーが追加情報を与える必要がないという内容である
https://github.com/ggml-org/ggml/blob/master/docs/gguf.md
せっかく複数ファイルの混乱をなくしたのに、Ollamaがまた追加してしまった感じで残念
ollama pullをすると、Modelfileもblobと一緒にダウンロードされる。モデルを恒久的に修正するには、Modelfileをテキストエディタにコピーして必要な変更を加え、既存のModelfileから新しいモデルを作れるOpen WebUIで使っている自分のワークフローは、
ollama show qwen3:30b-a3b-q8_0 --modelfileで確認し、Modelfileの内容をadmin -> models -> OpenwebUIに貼り付けたあと、名前をqwen3:30b-a3b-q8_0-monkversion-1のように変え、num_gpu 90のようなパラメータでレイヤー数を調整し、その後で元のファイルを残すか削除するというものModelfile内には、新しいModelfileを作るには
FROMを# FROM qwen3:30b-a3b-q8_0のように変えろという案内があり、パスが正しいかも確認する必要がある。自分はモデルをOllamaのデフォルト位置ではなく大きなNVMeドライブに保存しているので、これは重要付け加えると、Modelfileワークフローは本当に面倒でひどいパターンなので嫌いだ。30〜60GBあるモデルもあるのに、パラメータを一つ変えるために全体をコピーするのはばかげたやり方
それでもOllamaには良い点も多く、始めやすくしてくれる。vLLM、SGLang、Mistral.rs、llama.cppは設定にずっと多くの作業が必要
ベンチマークで、現時点で多くの評価で最高性能のO3やGemini Pro、Claude 3.7のような上位モデルを外しているのを見ると少しおかしい
比較対象の大半が7Bモデルだという点を見るべき。例外もオープンウェイトモデルのQwen-2.5-32B-RL-Zeroで、MiMo-7Bは32Bパラメータモデルよりもうまくやっている
MiMo-7Bは、7Bモデルをゼロから学習してQwen-32Bのようなより大きいモデルを上回り、数学・コードのベンチマークではOpenAI o1-miniに匹敵すると主張している。これがついに事前学習 + RLHF最適化がスケールの力を上回り始めたサインなのか、それとも狭い能力をベンチマークするのがうまくなっただけなのか気になる
READMEではどんな種類の強化学習か明かされておらず、単にRLとだけ書かれている。研究者が忙しいことも、良い文章を書くには時間がかかることも分かるが、こういう詳細は抜かさないでほしい
このモデルをXiaomi 15シリーズのスマートフォンのAIアシスタントに使うのか気になる。おそらく可能性は高そうだが、どんな結果になるかはよく分からない
7Bモデルでこういうベンチマーク数値が出るのは信じがたい
少し前にOllamaで適当な12Bモデルを動かしてみたが、使っていたマシンを考えると驚くほどよく、しかも速く感じられて驚いた。1年ほど前ならそうではなかったはず
https://qwenlm.github.io/blog/qwen3/