Mistral Small 4 をローカルで実行する方法

Mistral Small 4 は、Mistral AI が 2026年3月に新たにリリースしたマルチモーダルAIモデルで、推論、思考、コーディング、マルチモーダル機能を単一アーキテクチャに統合しています。256Kのコンテキストウィンドウ、Mixture-of-Experts（MoE）設計（~119B 総パラメータ、トークンあたり ~6.5B がアクティブ）**を備え、ベンチマークでは GPT-OSS 120B のような同等のオープンモデルを上回りつつ、**より高速な推論（最大 40% のレイテンシ削減）**を実現します。

ローカルで実行するには、大容量メモリGPU（推奨：48GB以上のVRAM）または量子化デプロイに加え、Transformers、vLLM、Ollama などのフレームワークが必要です。

Mistral Small 4 とは？

複数の仕事をこなす単一モデル

Mistral Small 4 は「万能型」と考えるのが最もわかりやすいでしょう。Mistral の従来の instruction、reasoning、coding 系列の強みを 1 つのモデルに統合しています。同社のリリース表現を使えば、Small 4 は 推論向けの Magistral、マルチモーダル向けの Pixtral、エージェント的コーディング向けの Devstral の能力を統合した最初の Mistral モデルです。テキストと画像の入力を受け取り、テキストを出力し、チャット、コーディング、エージェントワークフロー、文書理解、リサーチ、ビジュアル分析を目的としています。

このリリースが重要な理由

実務上の大きな意味は、Mistral Small 4 がモデル切り替えのオーバーヘッドを減らすことです。高速な instruct モデルに 1 つ目のプロンプトを送り、reasoning モデルに 2 つ目のプロンプトを送り、vision モデルに 3 つ目のプロンプトを送る代わりに、単一のエンドポイントを使い、必要に応じて reasoning_effort 設定を調整できます。Mistral は明確に、reasoning_effort="none" は Small 3.2 系のチャットに近い高速で軽量な応答を提供し、reasoning_effort="high" は従来の Magistral モデルに近い、より深く冗長な推論を行うと述べています。

Mistral Small 4 の性能ベンチマーク

主な性能ハイライト

👉 これにより、本番運用レベルのAIシステムに最適です。

アーキテクチャ（主要な技術的ポイント）

• モデルタイプ: Mixture-of-Experts（MoE）
• 総パラメータ数: ~119B
• トークンあたりのアクティブパラメータ数: ~6.5B
• エキスパート数: ~128（各フォワードパスで 4 つがアクティブ）

👉 このアーキテクチャにより、小規模モデルのコストで大規模モデル級の知能が実現でき、高密度モデルと比べてローカルデプロイに適しています。

Mistral Small 4 を導入する際に計画すべき要件

公式の最小構成と推奨インフラ

Mistral はここをかなり明確に示しています。最小構成は NVIDIA HGX H100 x4、NVIDIA HGX H200 x2、または NVIDIA DGX B200 x1 です。最適性能のための推奨構成は HGX H100 x4、HGX H200 x4、または DGX B200 x2 です。これは、完全に公式な運用パスが、単一のコンシューマGPUではなくデータセンター級マシンを想定していることを強く示しています。

実際にはどういう意味か

Mistral Small 4 は open-weight で、その規模のわりに効率的ですが、それでも 256k コンテキストウィンドウを持つ 119B の MoE システムです。実運用では、この組み合わせによりコンテキスト長が伸びるほどメモリ負荷が急速に高まり、持続的な性能は通常マルチGPUのテンソル並列化と効率的なサービングソフトウェアに依存します。だからこそ、主要なセルフデプロイエンジンとして vLLM を推奨し、単一マシンで「そのまま動く」前提よりも、OpenAI互換のサービングパターンを提供しているのです。

推奨セットアップ（プロ向け）

ハードウェアが重要な理由

なぜなら:

• 119B パラメータモデル（MoE であっても）
• 大きなコンテキスト（256K トークン）
• マルチモーダル処理

👉 最適化なしでは、コンシューマGPUには重すぎます

Mistral Small 4 をローカルで実行する方法（ステップごと）

ステップ 1）重みを取得し、アクセス条件に同意する

vLLM はデフォルトで Hugging Face から重みを取得するため、READ 権限付きの Hugging Face アクセストークンが必要であり、モデルカード上の条件に同意しなければなりません。実用的なローカルセットアップとして、NVIDIA ドライバ、CUDA 対応ランタイム、Python、および選択したチェックポイントに十分なGPUメモリを備えた Linux マシンを準備してください。すでに自分のストレージ上にアーティファクトを持っている場合は、Hugging Face の設定をスキップして、代わりに vLLM にローカルパスを指定できます。

ステップ 2）公式推奨のサーバースタックを使う

セルフデプロイには vLLM を推奨しており、これは OpenAI互換API を公開できる高度に最適化されたサービングフレームワークと説明されています。セルフデプロイ用ドキュメントでは TensorRT-LLM や TGI も代替として言及されていますが、このモデルファミリーにおける推奨パスは vLLM です。

ステップ 3）Mistral 推奨の Docker イメージを取得するか、vLLM を手動でインストールする

Mistral Small 4 では、必要なツールコールおよび reasoning 解析の修正を含むカスタム Docker イメージ、またはパッチ適用済みの vLLM ビルドを手動でインストールすることが推奨されています。モデルカードではカスタムイメージが提供されており、Mistral が vLLM チームと協力して変更を upstream に取り込んでいることも記載されています。

実用的な開始例は次のとおりです:

docker pull mistralllm/vllm-ms4:latestdocker run -it mistralllm/vllm-ms4:latest

ステップ 4）モデルをサーブする

Mistral 推奨のサーバーコマンドは以下です:

vllm serve mistralai/Mistral-Small-4-119B-2603-NVFP4 \  --max-model-len 262144 \  --tensor-parallel-size 2 \  --attention-backend TRITON_MLA \  --tool-call-parser mistral \  --enable-auto-tool-choice \  --reasoning-parser mistral \  --max_num_batched_tokens 16384 \  --max_num_seqs 128 \  --gpu_memory_utilization 0.8

このコマンドは、ローカル運用の文脈で最も重要な実践的ヒントです。つまり、このモデルが本格的なGPUバックエンド、長いコンテキストウィンドウ、そして Mistral 専用のツールおよび reasoning パーサを有効にして動かすことを前提としていることを示しています。

ステップ 5）アプリケーションをローカルエンドポイントに接続する

vLLM は OpenAI互換の REST API を公開するため、通常は既存の OpenAI SDK コードの接続先を http://localhost:8000/v1 に向けるだけで、アプリケーションロジックの大部分を変更せずに済みます。Mistral の例では base_url="http://localhost:8000/v1" と空の API キーを使っており、これはローカル開発でよくあるパターンです。

from openai import OpenAIclient = OpenAI(api_key="EMPTY", base_url="http://localhost:8000/v1")resp = client.chat.completions.create(    model="mistralai/Mistral-Small-4-119B-2603-NVFP4",    messages=[{"role": "user", "content": "Summarize the document in five bullets."}],    temperature=0.7,    reasoning_effort="none",)print(resp.choices[0].message.content)

ステップ 6）速度または品質向けに調整する

モデルをローカルでテストする場合、複雑なプロンプトには reasoning_effort="high"、そのモードでは temperature=0.7 が推奨されています。一方で、reasoning を無効にしている場合はより低い temperature が適しています。また同じモデルカードでは、最高精度向けの FP8 チェックポイントと、スループットおよび低メモリ使用量向けの NVFP4 チェックポイントを分けているため、最適な構成は品質、速度、ハードウェア使用量のどれを重視するかによって変わります。

ステップ 7: 任意 – Ollama 経由で実行する（簡易版）

ollama run mistral-small-4

👉 最適な用途:

• ローカル開発
• 素早いセットアップ

Mistral Small 4 vs GPT-OSS vs Qwen 3.5（完全比較）

Mistral Small 4: 極めて効率的な MoE

• 119B 総パラメータ
• トークンあたり ~6.5B がアクティブ
• 128 エキスパート（4 つがアクティブ）
• マルチモーダル（テキスト + 画像）

👉 重要なポイント: 非常に大きな容量だが、トークンあたりの計算量は少ない

これにより以下が得られます:

• 高性能
• 低レイテンシ
• 推論あたりの低コスト

GPT-OSS: デプロイ向けの実用的な MoE

• 120B 版: ~117B 総計 / 5.1B アクティブ
• 20B 版: ~21B 総計 / 3.6B アクティブ
• テキスト専用

👉 重要なポイント: 最小限のハードウェアで強力なモデルを動かせること

• 単一の H100 GPU で動作可能
• 強力なツール利用 / 構造化出力サポート

Qwen 3.5: 高能力スケーリング

• 最大 122B パラメータ
• より高い アクティブパラメータ数（~20B+）
• マルチモーダル + 強力な多言語対応

👉 重要なポイント: 計算コストが上がっても能力を最大化すること

性能ベンチマーク比較

reasoning を有効にすると、Small 4 は LCR、LiveCodeBench、AIME 2025 において GPT-OSS 120B に匹敵または上回りつつ、より短い出力を生成します。Mistral は一例として、Small 4 が AA LCR で 1.6K 文字のみで 0.72 を記録した一方、同等の Qwen の結果では 5.8K～6.1K 文字が必要だったと述べています。また、Small 4 は LiveCodeBench で GPT-OSS 120B を上回りながら、出力を 20% 少なく抑えるともしています。

ローカル用途で最良の選択はどれか？

私見では、Mistral Small 4 は、強力な汎用チャット、コーディング、エージェント作業、マルチモーダル対応を備えた、バランスの取れたローカルまたはプライベートデプロイを求めるなら、最良の「単一モデル」候補です。GPT-OSS は、明確なローカルサービングガイダンスがあるオープンな OpenAI モデルを求めるなら最もわかりやすい選択肢で、とくに小さい 20B 版が有力です。Qwen3.5 は最も幅広いファミリーであり、多言語対応、複数サイズ帯、柔軟なローカルサービングオプションを重視するなら注目すべきです。

これらの主要なオープンソースモデルへ API でアクセスしたく、ベンダーを切り替えたくない場合は、CometAPI をおすすめします。GPT-oss-120B や Qwen 3.5 plus API などを提供しています。

言い換えれば、Small 4 はホスト型モデルとして利用することも、重みを取得して自前のインフラでセルフホストすることもできます。

結論

Small 4 は、open-weight、マルチモーダル、推論対応のモデルを必要とし、さらにそれをセルフホスト、ファインチューニングし、既存の OpenAI スタイルのアプリケーションスタックへ統合したい場合に非常に適しています。特に、デプロイ制御、データレジデンシー、限界トークンコストの低減を重視しつつ、なおかつ最新の汎用モデルを求めるチームにとって魅力的です。

Mistral Small 4 にアクセスする準備はできましたか？ それなら CometAPI へどうぞ！