Mistral Medium 3.5（128B Dense，256K）

在 Clore.ai 上部署 Mistral Medium 3.5——128B 稠密、256K 上下文、双模式推理，于 2026 年 4 月发布。可在 4× H100 或 2× H200 上进行生产级 vLLM/SGLang 部署。

状态（2026年4月）： Mistral Medium 3.5 已于 2026年4月29日 由 Mistral AI 发布，作为 Mistral Medium 3 的继任者。权重可在 huggingface.co/mistralai/Mistral-Medium-3.5 按 Mistral 研究许可（MRL） 用于研究； Mistral 商业许可 则是超出评估范围进行生产使用所必需的。vLLM（≥ 0.8.x）和 SGLang 从首日就提供支持。

Mistral Medium 3.5 是一个 128B 稠密 Transformer ，配备 256K 令牌上下文窗口 以及 原生推理切换 ，可在同一检查点中在快速“即时”回复与更长的链式思维“深度”轨迹之间切换。此次发布将此前分散的三条 Mistral 线路整合为一个可切换模型—— Medium 3 （通用指令）、 Codestral （代码）以及 Mistral 的推理预览——这对于需要在多个权重间切换的工程团队来说是最大的变化。

对于 Clore.ai 用户来说，实际影响在于显存规模。一个 FP8 的 128B 稠密模型在 KV cache 之前大约占用 128 GB ，因此它 不能 在单张 80 GB GPU 上以全精度运行——你需要 4× H100 80 GB （FP8）或 2× H200 141 GB 才能通过 vLLM 顺畅提供服务。在市场上，这大约对应 24–48 美元/天 的 4× H100 配置，或 30–50 美元/天 的 2× H200，这也是大多数团队的最佳选择。单 H100 部署只有在激进的 Q4 GGUF 量化（通过 llama.cpp 约 70 tok/s）下才可行，而 256K 上下文在压缩时会首先消失。

主要特性

• 128B 稠密参数 ——没有 MoE 路由花招，VRAM 和延迟表现可预测，比稀疏模型更易微调

• 256K 上下文窗口 ——完整代码库分析、长文档 RAG、多轮智能体循环且不截断

• 双模式推理 ——切换 reasoning_mode=instant 可获得接近聊天的延迟，或 reasoning_mode=deep 以在答案之前显示 <think> 轨迹

• 统一指令 + 代码 + 推理 ——一组权重取代 Medium 3 + Codestral + 推理预览

• 函数调用与结构化输出 ——原生 JSON Schema 强制约束，兼容 OpenAI 的工具调用格式

• 开放权重 ——MRL 用于研究，商业许可可用；权重保留在你自己的机器上，不会往返发送到供应商 API

• 首日支持 vLLM 和 SGLang ——适合生产的 FP8 路径、张量并行、分块预填充、连续批处理

推理模式

Medium 3.5 是首个以单一检查点同时提供“快速”和“思考”答案的 Mistral 模型。该切换在请求时控制，而不是在加载时控制，因此同一个 vLLM 进程可为同一调用方处理两种模式。

模式	适用场景	典型 TTFT	输出形式
instant （默认）	聊天、自动补全、分类、函数调用等对延迟敏感的场景	50–250 毫秒	仅答案
deep	代码审查、多步骤规划、数学、复杂调试、智能体规划步骤	首个答案令牌前 1–6 秒	<think>...</think> 轨迹，然后是最终答案

在 deep 模式下，模型会在可见回复之前输出一段隐藏推理片段（由 <think>...</think> 聊天模板包裹）。这会让每轮额外消耗几百到几千个令牌，因此 不要为每个请求都启用它 ——把它留给那些你本来会对小模型提示“逐步思考”的任务。一个合理的做法是将 instant 设为默认，仅在 deep 用于工具调用规划步骤或最终答案综合时才升级。

供应商建议的采样。 Mistral 建议 temperature=0.15 用于 instant 以及 temperature=0.7 配合 top_p=0.95 用于 deep 模式。零温度采样往往会过早截断推理轨迹。

选择你的部署

Clore.ai 市场上的三种现实配置。先按 VRAM 预算选择，再看吞吐量。

配置	精度	总 VRAM	上下文（实际可用）	吞吐量	推荐 Clore 方案	说明
1× H100 80 GB	Q4 GGUF（llama.cpp）	80 GB	32K–64K	约 50–70 tok/s	单 GPU，评估/开发	激进量化；长代码质量会有所损失
4× H100 80 GB	FP8（vLLM）	320 GB	完整 256K	约 80–140 tok/s	生产最佳点	TP=4，持续流量下每美元 tok 数最佳
2× H200 141 GB	FP8 或 BF16	282 GB	完整 256K	约 90–130 tok/s	高上下文，管理的 GPU 更少	拓扑更简单，256K 下 KV cache 仍有余量

默认选择： 4× H100 80 GB FP8 通过 vLLM。你将获得完整 256K 上下文、约 100 tok/s 的持续吞吐、兼容 OpenAI 的 API，以及干净的张量并行扩展——每天成本大致相当于一个 Claude Opus 重度使用席位。

服务器要求

组件	最低配置（Q4 单 GPU）	推荐配置（FP8，4× H100）	高上下文（2× H200）
GPU 显存	80 GB（1× H100）	4× 80 GB = 320 GB	2× 141 GB = 282 GB
系统内存	128 GB	256 GB	256 GB
磁盘（NVMe）	200 GB	400 GB	400 GB
网络	用于 HF 下载需 1 Gbps+	1 Gbps+	1 Gbps+
CUDA	12.4+	12.4+	12.6+
驱动	≥ 555	≥ 555	≥ 555
启动时间	3–6 分钟（冷拉取）	6–12 分钟（冷拉取，4 个分片）	5–10 分钟

首次冷启动主要受 HuggingFace 下载影响——FP8 权重大约是 128 GB，BF16 更接近 256 GB。请在 /root/.cache/huggingface 挂载持久卷，这样每台服务器只需承担一次带宽成本。

在 CLORE.AI 上快速部署

最快路径是官方的 vllm/vllm-openai 镜像，并将张量并行设置为你的 GPU 数量。下面示例假设为 4× H100 实例。

Docker 镜像：

vllm/vllm-openai:latest

端口：

22/tcp
8000/http

启动命令（4× H100，FP8）：

vllm serve mistralai/Mistral-Medium-3.5-FP8 \
    --tensor-parallel-size 4 \
    --max-model-len 65536 \
    --gpu-memory-utilization 0.90 \
    --enable-chunked-prefill \
    --enable-auto-tool-choice \
    --tool-call-parser mistral \
    --reasoning-parser mistral \
    --tokenizer-mode mistral \
    --config-format mistral \
    --load-format mistral \
    --served-model-name mistral-medium-3.5 \
    --host 0.0.0.0 \
    --port 8000

替代方案 — 2× H200 BF16：

vllm serve mistralai/Mistral-Medium-3.5 \
    --tensor-parallel-size 2 \
    --max-model-len 131072 \
    --gpu-memory-utilization 0.92 \
    --enable-chunked-prefill \
    --enable-auto-tool-choice \
    --tool-call-parser mistral \
    --reasoning-parser mistral \
    --tokenizer-mode mistral \
    --config-format mistral \
    --load-format mistral \
    --served-model-name mistral-medium-3.5 \
    --host 0.0.0.0 \
    --port 8000

从 --max-model-len 65536 开始，即使硬件可以容纳更多。KV cache 内存会随上下文线性增长，而大多数工作负载从未达到 256K。确认请求分布后再提高。

SGLang 替代方案 （在 Hopper 上对长预填充通常更快）：

python3 -m sglang.launch_server \
    --model-path mistralai/Mistral-Medium-3.5-FP8 \
    --tp-size 4 \
    --tool-call-parser mistral \
    --reasoning-parser mistral \
    --mem-fraction-static 0.88 \
    --context-length 65536 \
    --served-model-name mistral-medium-3.5 \
    --host 0.0.0.0 \
    --port 8000

使用示例

部署后，找到你的 http_pub URL，在 我的订单 在 Clore.ai 上（例如 abc123.clorecloud.net）。在从服务器外部调用时，请将下面示例中的 localhost:8000 配合 https://YOUR_HTTP_PUB_URL 替换掉。

1. 聊天 — 即时模式（默认）

低延迟回复，无可见推理轨迹。适合聊天 UI、自动补全、分类。

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistral-medium-3.5",
    "messages": [
      {"role": "system", "content": "You are a senior backend engineer."},
      {"role": "user", "content": "Write a Go HTTP middleware that rate-limits per API key with a token bucket."}
    ],
    "temperature": 0.15,
    "max_tokens": 1024,
    "extra_body": {"reasoning_mode": "instant"}
  }'

2. 聊天 — 深度模式（推理切换）

启用 <think> 轨迹，并在最终答案之前显示。用于复杂调试、规划、数学。

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistral-medium-3.5",
    "messages": [
      {"role": "user", "content": "A user reports our payment webhook fires twice for 1% of orders. Walk through the most likely root causes in order of probability and propose a diagnostic plan."}
    ],
    "temperature": 0.7,
    "top_p": 0.95,
    "max_tokens": 4096,
    "extra_body": {"reasoning_mode": "deep"}
  }'

响应将包含一个 reasoning_content 字段（vLLM 会解析该 <think>...</think> 片段并从可见消息中提取出来），以及 content。根据你的产品决定是否去除或展示该轨迹。

3. Python — 兼容 OpenAI 的客户端

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

# 即时模式 — 聊天
response = client.chat.completions.create(
    model="mistral-medium-3.5",
    messages=[
        {"role": "system", "content": "You are a helpful coding assistant."},
        {"role": "user", "content": "Refactor this Python function for readability."}
    ],
    temperature=0.15,
    max_tokens=1024,
    extra_body={"reasoning_mode": "instant"}
)
print(response.choices[0].message.content)

# 深度模式 — 规划步骤
plan = client.chat.completions.create(
    model="mistral-medium-3.5",
    messages=[
        {"role": "user", "content": "Plan a migration from MongoDB to PostgreSQL for a 2TB orders table with zero downtime."}
    ],
    temperature=0.7,
    max_tokens=4096,
    extra_body={"reasoning_mode": "deep"}
)

msg = plan.choices[0].message
print("思考中：\n", getattr(msg, "reasoning_content", ""))
print("\n答案：\n", msg.content)

4. 结构化输出 — JSON Schema

Medium 3.5 通过 vLLM 的 response_format支持基于 JSON Schema 的解码。适用于下游消费者是解析器而不是人的场景。

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="x")

schema = {
    "type": "object",
    "properties": {
        "severity": {"type": "string", "enum": ["low", "medium", "high", "critical"]},
        "categories": {
            "type": "array",
            "items": {"type": "string", "enum": ["auth", "payments", "db", "ui", "infra"]}
        },
        "summary": {"type": "string", "maxLength": 240},
        "next_action": {"type": "string"}
    },
    "required": ["severity", "categories", "summary", "next_action"],
    "additionalProperties": False
}

response = client.chat.completions.create(
    model="mistral-medium-3.5",
    messages=[
        {"role": "system", "content": "Classify the incoming bug report. Return strict JSON."},
        {"role": "user", "content": "Login fails for users with apostrophes in their email, returning 500 from /webapi/login."}
    ],
    temperature=0.0,
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "triage", "schema": schema, "strict": True}
    },
    extra_body={"reasoning_mode": "instant"}
)

import json
print(json.loads(response.choices[0].message.content))

5. 函数调用

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="x")

tools = [{
    "type": "function",
    "function": {
        "name": "search_orders",
        "description": "按用户 ID 和可选日期范围搜索订单数据库",
        "parameters": {
            "type": "object",
            "properties": {
                "user_id": {"type": "string"},
                "start_date": {"type": "string", "format": "date"},
                "end_date": {"type": "string", "format": "date"}
            },
            "required": ["user_id"]
        }
    }
}]

response = client.chat.completions.create(
    model="mistral-medium-3.5",
    messages=[{"role": "user", "content": "查找用户 u_4821 在 2026 年 4 月的所有订单。"}],
    tools=tools,
    tool_choice="auto",
    temperature=0.1
)

for call in response.choices[0].message.tool_calls or []:
    print(call.function.name, call.function.arguments)

性能提示

1. 优先使用 Hopper 上的 FP8 检查点。 Mistral-Medium-3.5-FP8 是供应商提供的 FP8 构建，在 Hopper 级硬件上质量损失几乎可忽略，体积大约比 BF16 小 2 倍。对于 4× H100 和 2× H200，它都是正确的默认选择。

2. 张量并行 = GPU 数量。 对于 4× H100 使用 --tensor-parallel-size 4；对于 2× H200 使用 --tensor-parallel-size 2。在单节点上使用流水线并行通常会降低 128B 稠密模型的吞吐量。

3. 将 max-model-len 限制为你实际使用的长度。 256K 下的 KV cache 非常庞大——单个完整上下文序列就可能占用 30–50 GB。除非你确认有更高需求，否则将 --max-model-len 65536 （或 32768）设为上限，并仅在完成分析后再提高。

4. 启用分块预填充。 --enable-chunked-prefill 可在大提示仍在处理时继续输出解码令牌。对于 100K+ 的提示，这就是“有响应”和“超时”之间的区别。

5. 缓存权重。 在 /root/.cache/huggingface 上挂载 Docker 卷并在重启之间复用。每次冷启动都重新下载 128 GB，是“vLLM 启动似乎很慢”的最常见原因。

6. 为了获得一点额外余量，可对 KV cache 量化。 在 4× H100 上，你可以使用 --kv-cache-dtype fp8来容纳更多并发会话。供应商报告称质量几乎无损；在生产切换前，请先在你的评估集上验证。

7. 不要为每个请求都使用 deep 模式。 推理轨迹会消耗真实令牌和真实延迟。按任务类型路由：分类、自动补全和工具参数生成保持在 instant；规划和验证步骤升级到 deep.

8. 投机解码有帮助。 vLLM 和 SGLang 都支持草稿模型投机解码（例如配合 Ministral 3B 草稿）。对于长代码补全，这通常能在不损失质量的情况下带来 1.3–1.7 倍吞吐提升。

基准测试

供应商公布的数据——请独立验证。 下表来自 Mistral AI 于 2026 年 4 月 29 日的公告。独立第三方复现（LMSys、EQ-Bench、SWE-Bench 排行榜）仍在陆续出现。请将其视为方向性参考，而非权威结论。

基准	Mistral Medium 3.5（供应商）	参考点（供应商引用）
MMLU-Pro	~78%	Llama 4 Maverick 约 76%，GPT-5.4 约 81%
HumanEval	~92%	Codestral 25.01 约 88%，GLM-5.1 约 94%
LiveCodeBench（2026 年 4 月）	~68%	GLM-5.1 约 72%，Llama 4 Maverick 约 64%
AIME 2025（深度模式）	~62%	GPT-5.4 约 73%，GLM-5.1 约 58%
GPQA Diamond（深度模式）	~59%	Claude Opus 4.6 约 63%，GLM-5.1 约 57%
长上下文召回（128K）	~95%	Llama 4 Maverick 约 93%

Mistral 想要达到的定位： 大致处于 Llama 4 Maverick / GLM-5.1 级别的通用任务表现，代码能力差距更小，具有独特的推理切换。它并不是被定位为 GPT-5.4 / Claude Opus 4.6 的挑战者。

故障排除

问题	解决方案
加载时 CUDA out of memory （4× H100）	你很可能是误加载了 BF16。请使用 FP8 检查点（Mistral-Medium-3.5-FP8）或降级为 --max-model-len 32768.
加载时 CUDA out of memory 请求中途在 256K 上下文下	KV cache 爆掉了。降低 --max-model-len，启用 --kv-cache-dtype fp8，或限制 --max-num-seqs （试试 8）。
深度模式产生空的 reasoning_content	请确认 --reasoning-parser mistral 已在 vLLM 中设置，并且 temperature ≥ 0.5。零温度采样会截断轨迹。
深度模式下首令牌时间过慢	这是预期行为——深度模式会在任何可见输出之前先输出一个 <think> 片段。请使用 stream=true 向客户端流式返回，并展示“思考中…”的 UI 状态。
403 Forbidden 来自 HuggingFace 下载	Mistral Medium 3.5 受限。请在模型卡上接受 MRL，并在容器环境变量中设置 HF_TOKEN 。
tokenizer_mode mistral 错误	这三个标志必须一起设置： --tokenizer-mode mistral --config-format mistral --load-format mistral.
工具调用被静默丢弃	同时设置 --enable-auto-tool-choice 以及 --tool-call-parser mistral。没有解析器时，vLLM 会把工具参数作为纯文本返回。
吞吐在约 32 个并发会话后崩溃	你碰到了 KV-cache 驱逐。降低 --max-model-len，提高 --gpu-memory-utilization 到 0.92，或扩展到第二个副本。
阻止商业使用的许可错误	MRL 仅限研究用途。在向付费用户提供服务前，请联系 Mistral 销售获取商业许可。

常见问题

问：Mistral Medium 3.5 与 Llama 4 Maverick——我该选哪个？

两者处于相近的量级（Maverick 是 17B-active MoE，总代价 400B；Medium 3.5 是 128B 稠密）。如果你想要可预测的 VRAM/延迟、单个检查点中的双模式推理切换，以及更强的代码表现，请选 Medium 3.5 。如果你需要可无限制商用的宽松许可（Llama 4 是社区许可，Medium 3.5 在生产中需要 Mistral 商业许可），或者你想要 MoE 在单次请求层面带来的更低每 token 推理成本，请选 Llama 4 Maverick 。

问：如何启用推理模式？

在 OpenAI Python 客户端中传入 extra_body={"reasoning_mode": "deep"} ，或在 HTTP JSON body 的顶层包含 "reasoning_mode": "deep" 。默认值是 "instant"。在服务端，请确保 vLLM 是用 --reasoning-parser mistral 启动的，这样 <think> 片段才会被解析到 reasoning_content 字段中，而不会泄漏到 content.

问：为什么是 4× H100 而不是 2× H100？

FP8 权重在 KV cache 之前大约是 128 GB。2× H100 80 GB 总共只有 160 GB——足够加载权重，但几乎没有 KV cache、激活值，甚至中等上下文窗口的余量。实际上，2× H100 在超过 8K 上下文时几乎立即 OOM。 4× H100 是可用的 256K 能力部署的最低配置；如果你更愿意以略高的单卡成本管理更少的 GPU，那么 2× H200（282 GB）是替代方案。

问：我可以商用 Mistral Medium 3.5 吗？

默认的 Mistral Research License（MRL）允许研究和内部评估，但 不能 商业生产。面向付费客户的部署需要 Mistral 商业许可 ——请联系 Mistral 销售。这与之前应用于 Medium 3 和 Codestral 的限制相同。如果商业友好的许可是硬性要求，请看 Mistral Small 3.1 （Apache 2.0）或 Llama 4 （Llama 社区许可）。

问：Medium 3.5 支持视觉或音频吗？

不支持。Medium 3.5 仅支持文本。对于 Mistral 的多模态，请使用 Mistral Large 3，它带有 2.5B 视觉编码器。Clore.ai 上的其他多模态选项可查看 Qwen3.5-Omni 或 Gemma 3。

相关指南

• Mistral Large 3 ——675B MoE 多模态前沿模型，Apache 2.0，适用于需要视觉和最高质量的场景

• Mistral 与 Mixtral ——较旧的 Mistral 7B 和 Mixtral 8x7B/8x22B，适用于单 GPU 部署

• vLLM ——生产级服务框架，是 Medium 3.5 的推荐后端

• Llama 4 ——在这个规模上最接近的开放权重同行，宽松许可替代方案

外部链接

• HuggingFace 上的 Mistral Medium 3.5

• Mistral Medium 3.5 FP8 检查点

• Mistral AI 公告（2026 年 4 月 29 日）

• Mistral 研究许可

• vLLM 文档

• SGLang 仓库

• Clore.ai 市场 — 以每天 $0.50 起租用 H100 / H200