Mistral Small 4 是 Mistral AI（2026 年 3 月）新近發佈的多模態 AI 模型，將 推理、推導、程式碼與多模態能力 統一於單一架構。它具備 256K 上下文視窗、Mixture-of-Experts（MoE）設計（約 119B 總參數、每個標記約 6.5B 啟用參數），提供 更快的推理（延遲最高降低 40%），並在多項基準上優於同級開源模型，如 GPT-OSS 120B。
若要在本地執行，你需要 大顯存 GPU（建議 ≥48GB VRAM） 或 量化部署，並搭配 Transformers、vLLM 或 Ollama 等框架。
什麼是 Mistral Small 4？
一個模型對應多種任務
Mistral Small 4 最適合被理解為「全能型」：它將 Mistral 先前的指令、推理與編碼家族優勢融合為一體。依公司發佈說法，Small 4 是首個統合 Magistral（推理）、Pixtral（多模態任務）與 Devstral（代理式編碼）能力的 Mistral 模型。它接受 文本與圖像輸入、輸出文本，面向聊天、編碼、代理式工作流、文件理解、研究與視覺分析。
為什麼這次發佈很重要
實務上的意義在於 Mistral Small 4 降低了模型切換成本。你無需將一個提示送往快速指令模型、第二個給推理模型、第三個給視覺模型，而是可使用單一端點並視需求調整 reasoning_effort。Mistral 明確表示，reasoning_effort="none" 可帶來類似 Small 3.2 風格聊天的快速輕量回應，而 reasoning_effort="high" 會產生更深入、篇幅更長的推理，類似其先前的 Magistral 系列。
Mistral Small 4 的效能基準
關鍵效能亮點
| Metric | Mistral Small 4 |
|---|---|
| Architecture | MoE |
| Context Window | 256K |
| Latency | ↓ up to 40% |
| Coding Benchmarks | Beats GPT-OSS 120B |
| Output Efficiency | 20% fewer tokens |
👉 這使其非常適合用於 生產級 AI 系統。
架構（關鍵技術洞見）
- Model Type: Mixture-of-Experts (MoE)
- Total Parameters: ~119B
- Active Parameters per Token: ~6.5B
- Experts: ~128 (每次前向傳遞啟用 4 個)
👉 此架構以「小模型成本實現大模型智慧」，相較於稠密模型更適合本地部署。
若計畫採用 Mistral Small 4 的部署需求
官方最低與建議基礎設施
Mistral 在此相當明確：最低配置為 4x NVIDIA HGX H100、2x NVIDIA HGX H200，或 1x NVIDIA DGX B200；建議配置為 4x HGX H100、4x HGX H200，或 2x DGX B200。這強烈暗示完整的官方路徑面向資料中心級機器，而非單張消費級 GPU。
實務上的意涵
Mistral Small 4 為開放權重且在同級中高效，但畢竟是 119B 的 MoE 系統，且具備 256k 的上下文視窗。在實際部署中，這種組合會使記憶體壓力隨上下文長度快速攀升，穩定效能通常仰賴多 GPU 的張量並行與高效的服務框架。因此建議以 vLLM 作為主要自部署引擎，並以 OpenAI 相容的服務模式對外提供，而非單機「開箱即用」預設。
建議配置（專業）
| Component | Recommendation |
|---|---|
| GPU | 48GB–80GB VRAM (A100 / H100) |
| CPU | 16–32 cores |
| RAM | 128GB |
| Storage | NVMe SSD |
為何硬體關鍵
因為：
- 119B 參數模型（即使是 MoE）
- 大型上下文（256K 標記）
- 多模態處理
👉 若無最佳化，對 消費級 GPU 而言負擔過重
如何在本地執行 Mistral Small 4（逐步指南）
步驟 1）取得權重並接受存取條款
vLLM 預設自 Hugging Face 取得權重，因此你需要具備 Hugging Face 存取權杖（READ 權限），並在模型卡上接受條款。實務上，準備一台安裝 NVIDIA 驅動、支援 CUDA 執行環境、Python，且 GPU 記憶體足夠的 Linux 主機即可。若你已在本地儲存了相關檔案，可略過 Hugging Face 設定並直接將 vLLM 指向本地路徑。
步驟 2）使用官方建議的服務端技術棧
建議透過 vLLM 進行自部署；vLLM 是高度最佳化的服務框架，可提供 OpenAI 相容 API。自部署文件同時提及 TensorRT-LLM 與 TGI 作為替代方案，但對此模型家族仍以 vLLM 為首選。
步驟 3）拉取 Mistral 推薦的 Docker 映像，或手動安裝 vLLM
Mistral Small 4 建議使用已包含工具呼叫與推理解析修正的自訂 Docker 映像，或手動安裝經過修補的 vLLM 版本。模型卡提供了自訂映像，並指出 Mistral 正與 vLLM 團隊合作將變更上游合併。
一個實用的起點如下：
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 特定的工具與推理解析器。
步驟 5）讓你的應用連線至本地端點
由於 vLLM 提供 OpenAI 相容的 REST API，你通常只需將既有的 OpenAI SDK 程式碼指向 http://localhost:8000/v1，大部分應用邏輯可保持不變。Mistral 的範例使用 base_url="http://localhost:8000/v1" 與空白 API key，這是常見的本地開發模式。
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；當關閉推理時，較低的溫度更合適。模型卡也提供追求最佳準確度的 FP8 檢查點與著重吞吐與更低記憶體使用的 NVFP4 檢查點，選擇需視你優先考量品質、速度或硬體足跡而定。
步驟 7：可選 — 透過 Ollama 執行（簡化）
ollama run mistral-small-4
👉 最適合：
- 本地開發
- 快速上手
Mistral Small 4 與 GPT-OSS 與 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+）
- 多模態 + 強大的多語言能力
👉 核心理念：即使計算成本上升，也要最大化能力
效能基準比較
| Category | Mistral Small 4 | GPT-OSS (120B / 20B) | Qwen 3.5 (Plus / MoE) |
|---|---|---|---|
| Input / Output | 文字 + 圖像輸入 → 文字輸出上下文：256K 標記 | 文字輸入 → 文字輸出上下文：~128K 標記 | 文字 + 圖像 + 視訊 → 文字輸出上下文：最高 1M 標記 |
| Price (API) | $0.15 /M 輸入$0.60 /M 輸出 | 無官方 API 價格（自託管）→ 成本取決於基礎設施 | $0.40–0.50 /M 輸入$2.40–3.00 /M 輸出 |
| Architecture | MoE（Mixture-of-Experts）119B 總計 / 6.5B 啟用128 位專家（啟用 4 個） | MoE Transformer120B：117B / 5.1B 啟用20B：21B / 3.6B 啟用 | 混合 MoE + 進階層級最高 397B 總計（A17B 啟用） |
| Multimodal | ✅ 支援圖像 | ❌ 僅文本 | ✅ 圖像 + 視訊 |
| Reasoning Control | ✅ (reasoning_effort) | ✅ (low/med/high modes) | ✅ 自適應推理 |
| Context Efficiency | ⭐⭐⭐⭐⭐（輸出較短） | ⭐⭐⭐⭐ | ⭐⭐⭐（輸出較長） |
| Tool / Agent Support | ✅ 原生工具、代理、結構化輸出 | ✅ 強大的工具使用、結構化輸出 | ✅ 進階代理生態 |
| Coding Ability | ⭐⭐⭐⭐⭐（Devstral 等級） | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Deployment | 重（建議多 GPU） | 彈性（可單 GPU 運行） | 重（偏好雲端規模） |
在啟用推理時，Small 4 在 LCR、LiveCodeBench 與 AIME 2025 上可匹敵或超越 GPT-OSS 120B，同時產生更短的輸出。Mistral 引述一個例子：Small 4 在 AA LCR 上得到 0.72 分，僅用 1.6K 字元；而可比的 Qwen 結果需要 5.8K–6.1K 字元。此外，Small 4 在 LiveCodeBench 上優於 GPT-OSS 120B，且輸出長度減少 20%。
哪個是本地部署的最佳選擇？
我的看法：若你想要在本地或私有環境中以單一模型同時具備強大的通用聊天、編碼、代理式工作與多模態支援，Mistral Small 4 是最佳的「一站式」選擇。若你想要可公開取得、且對本地服務方式有明確指引的 OpenAI 模型，特別是較小的 20B 版本，GPT-OSS 是最清晰的選項。若你更在意多語言覆蓋、尺寸層級齊全與靈活的本地服務選項，則 Qwen3.5 是最廣的家族可供選擇。
如果你想用 API 存取這些頂尖開源模型，又不想更換供應商，我推薦使用 CometAPI，它提供 GPT-oss-120B 與 Qwen 3.5 plus API 等等。
換言之，你既可將 Small 4 作為託管模型使用，也可拉取權重並在自有基礎設施上自託管。
結論
當你需要 開放權重、多模態、具推理能力，且可 自託管、可微調、並可整合至現有 OpenAI 風格應用棧的模型時，Small 4 是極佳選擇。它尤其適合重視部署控制、資料駐留與較低邊際標記成本，同時仍希望擁有現代通用能力的團隊。
準備好存取 Mistral Small 4 了嗎？歡迎前往 CometAPI！