Mistral Small 4 是 Mistral AI 于（2026 年 3 月）发布的全新多模态 AI 模型，将推理、推断、编码与多模态能力统一到一个架构中。它具备256K 上下文窗口、Mixture-of-Experts（MoE）设计（~119B 总参数，~6.5B 每 token 激活参数），在基准中优于同类开源模型（如 GPT-OSS 120B），并提供更快的推理（时延最多降低 40%）。
要在本地运行，建议使用大显存 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 的性能基准
关键性能亮点
| 指标 | Mistral Small 4 |
|---|---|
| 架构 | MoE |
| 上下文窗口 | 256K |
| 时延 | ↓ 最多 40% |
| 编码基准 | 超过 GPT-OSS 120B |
| 输出效率 | 令牌减少 20% |
👉 这使其非常适合用于生产级 AI 系统。
架构（关键技术洞见）
- 模型类型：Mixture-of-Experts（MoE）
- 总参数：~119B
- 每 token 激活参数：~6.5B
- 专家数：~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 兼容的服务方式，而不是单机“开箱即用”的默认路线。
推荐配置（专业）
| 组件 | 推荐 |
|---|---|
| GPU | 48GB–80GB VRAM（A100 / H100） |
| CPU | 16–32 核 |
| RAM | 128GB |
| 存储 | NVMe SSD |
为什么硬件很重要
因为：
- 119B 参数模型（即便是 MoE）
- 大上下文（256K tokens）
- 多模态处理
👉 没有优化的话，对消费级 GPU来说太重了
如何在本地运行 Mistral Small 4（分步）
步骤 1）获取权重并接受访问条件
vLLM 默认从 Hugging Face 拉取权重，因此你需要一个具备 READ 权限的 Hugging Face 访问令牌，并在模型卡上接受相关条件。对于实际的本地环境，准备一台装有 NVIDIA 驱动、支持 CUDA 的运行时、Python，以及足够显存以容纳所选检查点的 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 vs GPT-OSS vs Qwen 3.5（完整对比）
Mistral Small 4：高效 MoE
- 119B 总参数
- ~6.5B 每 token 激活参数
- 128 专家（启用 4 个）
- 多模态（文本 + 图像）
👉 关键思路：容量很大，但每个 token 的计算量很低
带来：
- 高性能
- 低时延
- 更低推理成本
GPT-OSS：面向部署的实用 MoE
- 120B 版本：~117B 总参数 / 5.1B 激活
- 20B 版本：~21B 总参数 / 3.6B 激活
- 仅文本
👉 关键思路：在最小硬件上运行强大模型
- 可在单张 H100 GPU上运行
- 强工具使用 / 结构化输出支持
Qwen 3.5：高能力扩展
- 高达 122B 参数
- 更高的激活参数数（~20B+）
- 多模态 + 强多语种
👉 关键思路：即便计算成本上升，也要最大化能力
性能基准对比
| 类别 | Mistral Small 4 | GPT-OSS（120B / 20B） | Qwen 3.5（Plus / MoE） |
|---|---|---|---|
| 输入 / 输出 | 文本 + 图像输入 → 文本输出上下文：256K tokens | 文本输入 → 文本输出上下文：~128K tokens | 文本 + 图像 + 视频 → 文本输出上下文：最高 1M tokens |
| 价格（API） | $0.15 /M input$0.60 /M output | 无官方 API 定价（自托管）→ 成本取决于基础设施 | $0.40–0.50 /M input$2.40–3.00 /M output |
| 架构 | MoE（Mixture-of-Experts）119B 总计 / 6.5B 激活128 专家（启用 4 个） | MoE Transformer120B：117B / 5.1B 激活20B：21B / 3.6B 激活 | 混合 MoE + 高级层最高 397B 总计（A17B active） |
| 多模态 | ✅ 支持图像 | ❌ 仅文本 | ✅ 支持图像 + 视频 |
| 推理控制 | ✅（reasoning_effort） | ✅（低/中/高模式） | ✅ 自适应推理 |
| 上下文效率 | ⭐⭐⭐⭐⭐（输出更短） | ⭐⭐⭐⭐ | ⭐⭐⭐（输出更长） |
| 工具 / 代理支持 | ✅ 原生工具、代理、结构化输出 | ✅ 强工具使用、结构化输出 | ✅ 完整代理生态 |
| 编码能力 | ⭐⭐⭐⭐⭐（Devstral 级别） | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 部署 | 重（建议多 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 是非常合适的选择。对那些重视部署可控、数据驻留与更低边际 token 成本、同时又希望拥有现代通用模型的团队来说，它尤其具有吸引力。
准备好访问 Mistral Small 4 了吗？那就来 CometAPI 吧！