Mistral は今回、少し逆説的な決断をした。
過去2年間、モデルベンダーの戦略は基本的に「専用ツールを専用タスクに」だった。推論にはシンキングモデル、チャットにはインストラクトモデル、プログラミングにはコーディングモデル。ユーザーはシーンごとにモデルを選ぶか、より一般的には異なるタスクに異なる API を呼び出す。
Mistral Small 4 はその道を一気に閉ざした。
1つのモデルで、Magistral レベルの推論能力、Pixtral のマルチモーダル入力、そして Devstral のコーディングエージェント機能を備えている。ユーザーはもうモデルを選ぶ必要がなく、どれだけ深く考えてほしいかを伝えるだけでいい。
重要な数字
総パラメータ 119B、128エキスパート、トークンあたり4アクティブ――トークンあたり約 6B のアクティブパラメータ（embedding と出力層を含めると約 8B）。256K コンテキストウィンドウ。Apache 2.0 オープンソース。
推論強度の切り替えが最も興味深い設計だ。「高速回答」モードで低レイテンシを実現することも、シンキングモデルのように段階的に問題を解く「深度推論」モードに切り替えることもできる。同じモデルで2つの運用モード。
公式パフォーマンス数値：Mistral Small 3 と比較して、レイテンシ最適化シナリオでエンドツーエンドの完了時間が 40% 減少、スループット最適化シナリオで秒間リクエスト数が 3 倍に。
ベンチマーク：スコアより出力効率
AA LCR ベンチマークで、Mistral Small 4 は 0.72 を記録し、出力長はわずか 1.6K 文字。Qwen シリーズが同スコアに到達するには 5.8-6.1K 文字が必要――3倍以上の差だ。
これはスコアの高低の問題ではない。出力が短いということは、推論レイテンシが低く、API コストが少なく、ユーザーエクスペリエンスが直接的になるということ。同じスコアに3倍のテキスト量を必要とするモデルは、大規模運用で実際のコスト差になる。
LiveCodeBench では Small 4 が GPT-OSS 120B を上回り、同時に出力量が 20% 少ない。この効率差は高頻度呼び出しシナリオで瞬時にコスト差に変わる。
デプロイ
推奨構成は 4x HGX H100、4x HGX H200、または 2x DGX B200。NVIDIA との連携は vLLM と SGLang の2つの推論フレームワーク最適化に具体化されている。コミュニティ側では llama.cpp、Transformers、SGLang がすでに対応済み。
ローカルで動かす場合、119B の総パラメータ意味着至少需要 200GB+ VRAM。MoE アーキテクチャの利点は、実際の推論時にパラメータのごく一部しかアクティブにならないことだ。量子化後のデプロイハードルは大幅に下がる。
判断
Small 4 のポジショニングは明確だ。Opus や GPT-5.5 と絶対能力で競うものではない。「1つのモデルでほとんどのシーンをカバーし、かつ安く動く」ことが売りだ。
中小チームにとって、このアプローチは魅力的だ。3〜4種類のモデル API 接続、デバッグ、フォールバックロジックを維持する代わりに、Small 4 1つでチャット、ドキュメント分析、簡単なプログラミング、推論をカバーできる。天井を少し犠牲にして、デプロイの複雑さを大幅に削減する。
ただし、トップクラスの推論深度やプログラミング能力が必要な場合、Small 4 の「何でもできるが極致ではない」ポジショニングは物足りないかもしれない。コーディング能力は Devstral レベル――十分だが、SWE-bench ランキング上位レベルではない。
Mistral が選んだのは实用主義の道だ。モデル能力が過剰でコスト感度が高い 2026 年において、「1つのモデルですべてをこなす」というコストパフォーマンスの物語は、「我々は某項目で一位だ」よりも実際にお金を出す人の心を動かす。
次に注目すべきは、Small 4 の設定可能な推論モードが実際のシーンでベンチマークと同じパフォーマンスを発揮するかどうかだ。ベンチマーク環境での「深度推論」と実業務シーンでのパフォーマンスは往々にして別物である。
関連記事：
主なソース：