MiniMax-M2.7 を技術部視点で眺める｜229B MoE / 10B active・200K コンテキスト・自己進化エージェントの中身

こんにちは、パレイド技術部です。

2026 年 4 月 12 日ごろ、MiniMax-M2.7 の重みが Hugging Face でオープン化されました。MiniMax-M2.7 の重みが Hugging Face でオープン化されました。

これまで MiniMax Agent と MiniMax API 経由でのみ触れた MoE モデルが、モデルカード上で MiniMaxAI/MiniMax-M2.7 として正式にダウンロード可能になった、というのが今回の報です。

結論だけ先に言うと、MiniMax-M2.7 はかなり強い。ただし現時点で個人の一般的な Mac / Windows 機ではほぼ動きません。触るなら API、待つなら GGUF / MLX 版待ちが現実解です。

SWE-Pro で GPT-5.3-Codex 相当とされ、GDPval-AA ELO 1495 でオープンウェイト最高、といった触れ込みが並んでいるので、現状を技術部の視点で調べてみました。結論だけ先に書くと、現時点では個人の一般機で回す用途としてはかなり厳しいです。理由を config.json・ベンチマーク・メモリ見積もりの順で整理していきます。

先に取り上げた DeepSeek-V4 Preview の公開もあり、あちらは V4-Flash で 284B / 13B active、V4-Pro で 1.6T / 49B active という構成でした。M2.7 (229B / 10B active) は V4-Flash と同じ帯にいて、オープンウェイト MoE の「中規模上限」がここ最近でまとめて底上げされた、というのが手元から見た今週の印象です。

本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI（Claude 等）の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。

何が公開されたか
ベンチマークで見る現在地
新機軸: Self-Evolution と Agent Teams
ローカルで動く？
ライセンスと派生の広がり方
まとめ
参考

何が公開されたか

MiniMax-M2.7 は、前作 MiniMax-M2.5系 (2025 年公開、229B 総 / 10B active) の後継として開発されたモデルで、今回 2026-04-12 付けで Hugging Face (MiniMaxAI/MiniMax-M2.7) に重みが公開されました。

MiniMaxAI/MiniMax-M2.7 · Hugging Face

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

それまでは MiniMax Agent (agent.minimax.io) と MiniMax API (platform.minimax.io) 経由でのみ触れる状態で、今回のオープン化でようやく重みを手元に置いてローカル推論や蒸留・派生に使えるようになった形です。位置づけは「エージェントハーネスの構築と高度な生産性タスクに特化した MoE」で、MiniMax 自身が「モデルが自らの進化に深く参加する最初のモデル」と表現しているのが特徴的です。

MiniMax M2.7: Early Echoes of Self-Evolution

スペックの主要値を拾うと次のとおりです。

項目	値
総パラメータ	約 229B
アクティブパラメータ (推論時)	約 10B
アーキテクチャ	MiniMaxM2ForCausalLM (MoE)
hidden_size	3072
レイヤー数	62
エキスパート数 (layer 毎)	256
1 トークンあたり活性エキスパート数	8
ルーティング	sigmoid + routing bias
attention heads / kv heads	48 / 8 (GQA 6:1)
コンテキスト長	204,800 (≈ 200K)
rope_theta	5,000,000
dtype	BF16 (FP8 ビルド同梱)
MTP (Multi-Token Prediction)	有効、3 モジュール
ライセンス	Other (MiniMax Model License)

1 レイヤーあたり 256 エキスパートという密な MoE で、ルーティングは各トークンにつき 8 本だけ活性化する設計です。比率は 8/256 = 1/32、ざっくり「総パラメータの約 3% だけが 1 トークンあたりの計算に効く」構造です。アクティブ 10B が 229B 総の中に埋まっているのは、この比率からそのまま出てくる値です。

公式推奨のサンプリングは temperature=1.0, top_p=0.95, top_k=40 で、デプロイは SGLang / vLLM / Transformers が公式推奨、ModelScope / NVIDIA NIM も動作確認済みと案内されています。Tool Calling・Agent Teams・Dynamic Tool Search がネイティブ対応です。GGUF / MLX / AWQ 等のコミュニティ量子化ビルドは公開当日時点ではまだ走り始めの段階で、ここから数日〜数週間で出揃うことになるでしょう。

ベンチマークで見る現在地

モデルカードが提示する主要ベンチマークを、公開されている比較値と並べて整理します。

ベンチマーク	MiniMax-M2.7	備考
SWE-Pro	56.22%	GPT-5.3-Codex 相当
SWE Multilingual	76.5%	多言語リポジトリの SWE
Multi SWE Bench	52.7%	複数言語リポジトリ横断
VIBE-Pro	55.6%	プロジェクト一貫納品、Opus 4.6 に接近
Terminal Bench 2	57.0%	複雑システム操作
NL2Repo	39.8%	要件 → リポジトリ生成
MLE Bench Lite (22 ML 競技)	66.6%	Opus-4.6 = 75.7%, GPT-5.4 = 71.2%
GDPval-AA ELO	1495	オープンウェイト最高
Toolathon	46.3%	大規模ツール群の運用
MM Claw (skill 遵守率)	97%	40+ 複雑スキル、各 2,000+ トークン
MM Claw (end-to-end)	62.7%	Sonnet 4.6 に接近

数字の読みどころは コーディング系と ML 系で頭が揃ってきた ところです。SWE-Pro 56.22% は GPT-5.3-Codex 相当で、VIBE-Pro 55.6% は「プロジェクトを通しで仕上げる」系ベンチで Claude Opus 4.6 に手が届く値。MLE Bench Lite では Opus 4.6・GPT-5.4 に次ぐ 3 位で、オープンウェイトで公開されているモデルとしては ML コンペ系のトップ と言えます。GDPval-AA の ELO 1495 は Word / Excel / PPT を含むオフィス系タスクで測った値で、モデルカードの表記では「オープンウェイト最高」と明記されています。

一方で、昨日取り上げた DeepSeek-V4-Pro の Codeforces 3206 や LiveCodeBench 93.5 のような「クローズド最先端を抜く」数字までは届いていません。V4-Pro は 1.6T 総 / 49B active、M2.7 は 229B 総 / 10B active と、そもそもスケールが 1 ケタ違うので、この差は素直に受け止める位置づけです。M2.7 は「スケールを抑えながら、エージェント周りの使い勝手で刺す」側に振った設計と読むのが近そうです。

新機軸: Self-Evolution と Agent Teams

モデルカードとブログで MiniMax が力を入れて説明しているのが、単体モデル性能ではなく「モデル自身が進化する仕組み」です。

Model Self-Evolution モデル内部で「メモリを更新し、複雑スキルを構築し、実験結果をもとに反復改善する」自律ループを回す仕組みで、内部評価では RL レベルの 100+ ラウンド でプログラミングスキャフォルドを自律最適化し、30% のパフォーマンス改善が得られたと報告されています。ポイントは「学習時の RL」ではなく「推論時に観測した結果を自分のメモリに書き戻し、次の試行でそれを使う」側のループです。エージェント運用で言うところの「走らせるほど賢くなる」を、モデル単体の機能として組み込んだ位置づけになります。

Agent Teams 複数のエージェントが役割を分担しながら協働する機能で、「役割アイデンティティの安定性」と「プロトコル遵守」をモデル側で担保する、と説明されています。外部オーケストレーション (LangGraph や CrewAI など) で組むのが通例のマルチエージェントを、モデルの挙動として直接サポートする方向です。ベンチ値としては MM Claw end-to-end 62.7% が Sonnet 4.6 に接近しているあたりが、このネイティブ対応の効き方を示唆する数字でしょう。

MTP (Multi-Token Prediction) config に use_mtp: true, num_mtp_modules: 3 と入っており、1 ステップで複数トークン先まで予測する 仕組みが最初から組み込まれています。推論側でアクセプトレートが十分確保できれば、そのまま実効スループットの底上げに効く設計です。DeepSeek-V3 系でもおなじみの実装ですが、M2.7 は公式配布の重みに MTP モジュールが同梱されている点で「すぐ使える MTP」です。

エージェント用途で 1 セッションが数十ターン・数十ツール呼び出しに及ぶことを前提にすると、この 3 点は単体ベンチの数字以上に効いてくる設計です。

ローカルで動く？

ここからが技術部として一番関心があるところです。総パラメータ (メモリ容量軸) とアクティブパラメータ (推論 FLOPs = 速度軸) を分けて考えるのは、V4-Flash で整理したときと同じ構えです。

公式が示しているハードウェア情報 モデルカードと inference README を当たった範囲では、VRAM / メモリの具体数値は明記されていません。公式配布されている重みは BF16 版と FP8 ブロック量子化版 (float8_e4m3fn, weight_block_size=[128, 128]) の 2 系統で、推論は SGLang / vLLM / Transformers いずれでも回る建て付けです。GPU 並列数の推奨値も DeepSeek-V4 のように固定値で出てはおらず、「まず公式ウェイトで動かせる環境を用意できるかどうか」からが出発点になります。

以下の容量見積もりはすべて一般的な量子化換算からの概ねの推定で、公式値ではない点を先にお断りしておきます。公開翌日時点で実ビルドの実測値はまだ揃っていません。

ビルド	推定必要メモリ (当サイト試算)	個人機の射程
BF16 (ネイティブ)	概ね 460GB	× 大型サーバ領域
FP8 ブロック量子化 (ネイティブ同梱)	概ね 229GB	△ Mac Studio M3 Ultra 256GB / 512GB でギリ射程
Q4 量子化ビルド (登場見込み)	概ね 115GB	△ Mac Studio 128GB / M5 Max 128GB クラスでかろうじて？
Q3 量子化ビルド (登場見込み)	概ね 86GB	△ 96GB / 128GB クラスで射程内
Q2 量子化ビルド (登場見込み)	概ね 57GB	△ 64GB 機にはなお入らない
1.58bit 三値化相当 (登場未定)	概ね 46GB	64GB MacBook に入るかどうかのライン

表をまとめて言うと、VRAM 8GB〜32GB の一般的な Mac / Windows 機ではロードできない帯です。

一般読者が手にできるハードウェア、という技術部の前提を軸に置くと、M2.7 を個人のローカル環境で素直に動かすのは、例えば Mac Studio M3 Ultra 256GB 以上のクラスを持っている読者限定 の話になります。これは月々の課金で言えば MacBook Air の 10 倍以上のマシンコストがかかる帯で、「手元で誰でも回せる」側の話ではなくなります。

速度軸の話を補足しておくと、アクティブ 10B なのでメモリさえ確保できれば理論上の演算量は 10B Dense に近く、Qwen3-32B Dense より軽く回ることが期待されます。MoE の旨味が素直に出る設計で、Mac Studio 大容量機に積める読者にとっては「知識容量は巨大だが動かしたときは 10B 並に軽い」という気持ちのいい挙動になるはずです。逆に言うと、計算量は軽いのにメモリに乗せきれない というのが個人機で引っかかる最大のポイントで、MoE の設計思想がそのままボトルネックの場所を変えた格好です。

「アクティブ 10B なら 32GB あればも動くのでは」と思うところ、 V4-Flash の記事でも触れた話ですが、改めて M2.7 で整理しておきます。

計算量とメモリは別軸。アクティブ 10B は「1 トークン生成あたりの FLOPs が 10B Dense 相当」という速度側の話で、メモリ常駐サイズとは直接つながりません。
MoE はエキスパート選択が毎トークン動的。256 本あるエキスパートから 8 本がトークンごとに動的に選ばれるので、理屈上は 全 256 本がすぐアクセスできる場所に置かれている必要があります。
量子化しても 32GB には入らない。Q2 まで削っても 57GB、1.58bit 三値化級で 46GB。32GB MacBook Air M5 の単独ロードは素直には成立しません。

「動くアプローチ」としては llama.cpp の MoE expert offload、ktransformers、mlx-lm の MoE 最適化 が候補です。エキスパートを SSD / CPU RAM に逃がし、選ばれた 8 本だけを GPU / ユニファイドメモリに引き上げるやり方で、Qwen3-235B A22B で先行事例が増えてきている経路です。

ただし実効速度は SSD / メモリ帯域で律速され、数 tok/s クラスまで落ちるのが通常で、エージェントのように何十ターンも往復する用途にはまず使い物にならない速度です。「動きはする」と「実用で回せる」の間に大きな溝がある帯、というのが公開翌日時点での正直な見立てです。ここは MLX 版の量子化ビルドが揃ったタイミングで手元の M5 で測って数字を置きに行きます。

近隣 MoE との比較

モデル	総パラメータ	アクティブ	Q4 目安	32GB 機で素直に動くか
Qwen3-Next 80B A3B	80B	3B	〜45GB	△ (量子化でギリ)
MiniMax-M2.7	229B	10B	〜115GB	× (Q2 でも 57GB)
Qwen3-235B A22B	235B	22B	〜130GB	× (128GB クラス必要)
DeepSeek V4-Flash	284B	13B	140〜160GB	× (Q2 でも 71GB)
DeepSeek V4-Pro	1.6T	49B	800GB〜1TB	× (大型サーバ領域)

M2.7 は Qwen3-Next 80B A3B と Qwen3-235B A22B の中間にいて、229B という総パラメータの割に計算量 10B active が軽いのが特徴です。

ただし「総パラメータを丸ごとメモリに乗せる」必要がある MoE の制約がある以上、個人の一般機で素直に動かすのは厳しく、Mac Studio 128GB 以上 があってようやく Q3/Q4 の量子化ビルドが射程、FP8 ネイティブで回したければ Mac Studio M3 Ultra 256GB クラスが現実ラインです。

同じ帯の Qwen3-235B A22B で 128GB Mac Studio 勢が苦労している様子を眺めると、M2.7 も似た位置の「Mac Studio 用ハイエンドモデル」として付き合うのが無理のない構えに見えます。

ライセンスと派生の広がり方

ライセンスは Hugging Face 上の表記で “Other” となっており、これは MiniMax が独自に提示する Model License の扱いです。MIT / Apache ほど自由ではなく、商用利用や派生物配布には個別条項を確認する必要があります。同日の DeepSeek-V4 Preview が MIT で出してきたのとは直接比較できない条件です。

それでもオープン化された事実は 1 年スパンで効いてきます。蒸留による小型化、GGUF / MLX / AWQ の量子化ビルド、派生 Finetune、各種 API 事業者のホスティングといった経路が、今後数週間〜数か月かけて立ち上がります。現時点で個人機に落ちてくる段階ではありませんが、ここを起点にどのサイズまで降りてくるかを見届けるのが、オープン化の意味として一番大きいところです。

まとめ

MiniMax-M2.7 の重みが 2026-04-24 付けで Hugging Face にオープン化 された。これまで API / Agent 経由でのみ利用できたモデルが、ローカル推論・蒸留・派生に使える状態になった
スペックは 229B 総 / 約 10B active の MoE、200K コンテキスト、BF16 + FP8 ネイティブ同梱、62 層 / 256 エキスパート / 1 トークン 8 本活性、MTP 3 モジュール同梱。ライセンスは MiniMax Model License (MIT ではない)
ベンチマークは SWE-Pro 56.22% / VIBE-Pro 55.6% / GDPval-AA ELO 1495、MLE Bench Lite 66.6% で Opus 4.6・GPT-5.4 に次ぐ。Model Self-Evolution と Agent Teams のネイティブ対応が設計の柱
ローカル運用は現時点では 厳しめ の結論。32〜64GB クラスの一般的な Mac / Windows 機では素直にロードできず、Mac Studio 128GB 以上 があってようやく Q3/Q4 の量子化ビルドが射程に入る帯。公開翌日の本日時点では MLX / GGUF ビルドも出揃っていない
一般読者に向けた現実解は、当面は MiniMax API 経由で触る。オープン化のメリットは蒸留・派生・量子化が出揃ってから享受する、という構えが素直な位置