Mistral Large 4の重み公開、巨大AIを動かすMoEと推論制御の仕組み｜2026年10月31日版
Mistral AIが「Mistral Large 4」のモデル重みを公開しました。注目点は、約1兆パラメータのモデルを自社環境で運用できることと、回答時の推論量を3段階で調整できることです。
巨大なモデルでも、毎回すべての計算を動かすわけではありません。必要な部分を選んで使うMoEという設計と、問題に応じて考える量を変える仕組みが、運用コストを左右します。ただし、計算量が減っても、モデル全体を保存・配置する負担まで同じ割合で軽くなるわけではありません。
2026年10月31日、日本時間時点で確認できる公式発表とモデルカードをもとに、公開された仕様と導入時の判断点を整理します。
- 変化： API経由の利用に加え、公開重みを使った自社運用を選べる。
- 仕組み： MoEで計算対象を絞り、推論量はlow・medium・highから指定する。
- 注意点： GPUメモリ、応答時間、ライセンスは、それぞれ別に確認する必要がある。
重み公開で変わるのは、モデルを置く場所
今回の公開では、学習済みモデルの重みを取得し、自社で推論環境を構築する道が開かれました。
10月6日のパブリックプレビューから追加の強化学習を経て、コード生成や防御的なセキュリティ業務、推論効率を改善したとMistralは説明しています。重み公開の公式発表では、API利用だけでなく、組織がモデルを管理・調整する用途を打ち出しました。
企業にとっての意味は具体的です。機密性の高いソースコードや社内文書を扱う際、外部APIへ送る構成に加え、自社管理の基盤へモデルを配置する構成を検討できます。
ただし、重みが公開されたことと、運用が簡単になったことは別です。 自社運用では、GPUの確保、更新、監視、アクセス制御も利用側の仕事になります。
MoEは「約1兆の全部」を毎回動かさない
Mistral Large 4の規模を読むときは、総パラメータ数と、各トークンの計算で使うパラメータ数を分ける必要があります。
公式モデル仕様では、総パラメータ数は1.05兆、アクティブなパラメータ数は520億とされています。テキストと画像を入力し、テキストを出力するモデルで、最大コンテキスト長は100万トークンです。
必要な専門部分へ計算を振り分ける
MoEはMixture-of-Expertsの略です。複数の「エキスパート」と呼ぶ計算部分を持ち、入力に応じて一部を選びます。
公開モデルカードによると、このモデルには128の選択対象エキスパートがあり、各トークンでは4つを使います。これに共有エキスパートが加わります。
モデルカードは、トークン当たりのアクティブな規模を490億、埋め込み層と出力層を含めて520億と説明しています。「1兆」と「520億」は異なる部分を数えた数字で、矛盾ではありません。
計算対象が少なくても、保存する重みは大きい
ここが導入時の落とし穴です。使うエキスパートを選ぶことで計算を抑えても、選択に備えてモデルの重みを保持・配置する必要は残ります。
したがって、「アクティブ520億だから、通常の520億モデルと同じ設備で動く」とは判断できません。必要なメモリは、重みの精度、GPUへの分散方法、入力の長さ、同時処理数によっても変わります。
日本の開発現場でも、最初に確認すべきなのはパラメータ数の大小だけではありません。実際に投入する文書量と同時アクセス数で、モデルが収まり、応答を返せるかが判断の出発点になります。
推論モードは、回答のために使う量を調整する
もう一つの変更点は、同じモデルで推論量を切り替えられることです。
公式発表は、用途に応じた3段階を示しています。
- low： 簡単なタスク向け。従来のNoneモードに代わる設定。
- medium： 日常的なタスク向け。
- high： 難しい問題向け。既定値。
これはモデルの重みを別の小型モデルへ交換する操作ではありません。同じモデルに対し、リクエストごとに推論の強さを指定する仕組みです。
実務では、すべてを既定のhighで処理する前に、定型的な抽出、短い質問、複雑なコード修正を分けて評価する余地があります。ただし、lowへ変更しても必要な正確さを保てるかは、自分たちの入力で確かめる必要があります。
トークン削減は、そのまま速度倍率にはならない
Mistralの発表によると、Terminal-Bench 4.0のスコアはプレビューから13ポイント改善して41％となり、出力トークンは30％減りました。これは同社が公表した評価結果です。
読み取れるのは、評価された条件で、より少ない出力でタスクを解く効率が改善したことです。出力30％減を、そのまま処理時間30％短縮と読み替えることはできません。
実際の待ち時間には、入力の読み込み、GPU間の通信、ツール実行、混雑も含まれます。コード修正用途なら、生成速度だけでなく、テストに通った修正を得るまでの時間を測るほうが実用的です。
自社運用では、ライセンスと実装条件を先に確かめる
重みを取得できても、用途の条件は確認が必要です。
モデルカードでは「Mistral Ecosystem Open-Weight License」を採用し、商用・非商用での利用を認める一方、Model-as-a-Service事業の運営には別の商用ライセンスが必要と説明しています。社内で使うケースと、モデル提供サービスを外部へ販売するケースを同じ扱いにはできません。
技術検証では、次の順に範囲を絞ると判断しやすくなります。
- 用途を決める： 社内文書の読解か、コード修正か、画像を含む資料分析か。
- 実装を確かめる： 使用する推論エンジンとモデル形式で、必要な機能が動くか。
- 負荷を測る： 想定する入力長と同時処理数で、メモリ使用量と待ち時間を記録する。
- 成果を比べる： 推論モードごとに、正答率や修正成功率を含めて評価する。
セキュリティ用途でも、モデルが修正案を出した時点で作業は終わりません。変更のレビューと回帰テストを通し、既存機能を壊していないことを確かめる工程が必要です。
継続ウォッチ：自分の業務で「成功までのコスト」を測る
今回の公開で見るべきなのは、モデルの大きさだけではありません。自社で配置できる選択肢と、推論量を調整する操作が組み合わさった点です。
次に確かめたいのは、以下の3点です。
- 推論モードの差： lowやmediumでも、業務に必要な精度を保てるか。
- 長文処理の負荷： 入力が長くなったとき、メモリ使用量と待ち時間がどう増えるか。
- 修正の成功率： コード生成量ではなく、レビューとテストを通る変更を何回で得られるか。
導入判断では、まず同じ業務サンプルを3つの推論モードで処理し、成功率、所要時間、使用トークンを並べる。その比較が、API利用を続けるか、自社運用へ進むかを判断する材料になります。