为什么需要对比
国内开发者最近开始盯上 Mistral，原因很直白：价格便宜。按月调用 500 万 tokens 的聊天机器人，用 GPT-4-turbo 每月烧掉约 $2000，换到 Mistral-medium 只需要 $540——差距 73%。另一个原因是合规，Mistral 的服务器在欧盟，数据不用路过美国。但大多数人卡在第一步：现有的代码都是按 OpenAI API 写的，换过去要改多少？改完会不会出幺蛾子？我们团队上个月刚把一个生产环境服务迁移完，踩了不少坑，今天把实测数据摊开。
候选工具与评测维度
本次对比对象是 OpenAI 的 gpt-3.5-turbo、gpt-4-turbo，以及 Mistral 的 mistral-tiny、mistral-small、mistral-medium（2025 年 1 月版本）。评测维度集中在五个：端点路径、请求参数、响应结构、流式模式、功能能力（函数调用、多模态）。为什么只挑这些？因为 80% 的项目只用到 chat completions 接口，其他比如 embedding、fine-tuning 都很少碰。我们列了一张对比表：
| 维度 | OpenAI API | Mistral API | 差异程度 |
|---|---|---|---|
| 端点 | /v1/chat/completions | /v1/chat/completions | 一致 |
| 认证 | Bearer Token | Bearer Token | 一致 |
| 请求字段 | model, messages, temperature, max_tokens | 完全同名 | 基本一致 |
| 流式 | stream: true, SSE 格式 | 相同 | 一致 |
| 函数调用 | tools, tool_choice | 2025 年 1 月仍未正式支持 | 重大差异 |
| 多模态 | 图像、音频输入 | 仅支持文本，视觉模型能力弱 | 重大差异 |
| 错误码 | 429（限流）、401（认证）、500 | 同语义但部分字段不同 | 小差异 |
| 上下文窗口 | GPT-4-turbo 128k tokens | Mistral-medium 32k tokens | 差异较大 |
说实话，这张表一出来，胜负已经分明——纯文本对话场景迁移成本极低，复杂应用直接劝退。
兼容性实测：端点、参数、响应结构
我们团队在 Day 1 拿到一个开源的聊天后端，代码约 800 行，用 requests 直接调用 OpenAI。把 base_url 改成 https://api.mistral.ai/v1，API key 换掉，跑通第一个请求只用了 10 分钟。参数方面，temperature、max_tokens、stop、top_p 全部原样兼容。响应结构也一样，choices[0].message.content 路径完全相同。我们跑了 300 个随机 prompt，92% 的响应格式完全匹配，剩下 8% 只是 finfish_reason 字段的取值不同——Mistral 有 "length" 和 "stop"，OpenAI 会额外返回 "content_filter"。
流式兼容性更让人意外。Mistral 的 SSE 数据块结构和 OpenAI 逐字相同，连 delta 字段名都没改。我们只改了一行代码（将 stream=True 的解析逻辑里的 URL 替换）就实现了流式输出。第 2 周我们做压力测试，发现一个坑：Mistral 的限流返回 429 时，Retry-After 头的单位是秒，而 OpenAI 用毫秒。我们写了个通用重试逻辑，判断单位时漏了这个差异，结果生产环境疯狂重试。血泪教训。
函数调用是硬伤。我们试了把 OpenAI 的 tools 参数直接传送过去，Mistral 返回 400 错误。查阅文档发现，Mistral 目前只支持 JSON mode（强制输出合法 JSON），但无法绑定外部函数，更没有 tool_choice。一个依赖工具调用的智能客服项目，第 2 周我们花了 3 小时重构，最终改成“先生成 JSON，我们自己去执行”的后处理模式，代码膨胀了 30%。
迁移成本：代码改动量、时间、费用
我们选了三个样本项目来量化迁移成本。第一个是 50 行的翻译脚本，改动 3 行（URL + 模型名），花了 15 分钟。第二个是 200 行的聊天机器人，带流式和重试逻辑，改动 18 行，耗时 45 分钟。第三个是 800 行的多模态应用，需要同时处理图片和文本——直接失败，因为 Mistral 的视觉模型在 2025 年 1 月还无法稳定识别长文图片。总体而言，对于纯文本任务，代码改动量通常在 10% 到 15% 之间，迁移耗时为 2 小时左右（工程师熟练度中等的实测值）。真香。
成本差异更直观。假设一个应用每月输入 100 万 tokens，输出 50 万 tokens。用 GPT-4-turbo 按 $10 每百万输入、$30 每百万输出计算，月成本 $1000 + $1500 = $2500。用 Mistral-medium（$2.7 输入 / $8.1 输出）只需 $270 + $405 = $675，节省 73%。我们自己的知识问答系统从 gpt-3.5-turbo 换到 mistral-tiny，月成本从 $200 降到 $45，性能上仅有 5% 的对话质量下降（用 BLEU 和人工评分双测），但可以忽略。
不过呢，上面这些数字都基于“无函数调用、无多模态”的前提。如果你需要工具调用，迁移成本呈非线性上涨。我们给一个电商客服接入 Mistral 的 JSON 模式来替代函数调用，代码重写加上测试，花了整整 6 天。回头算账，这种投入还不如继续用 OpenAI。
推荐场景与局限
现在给出适用场景的清单：
- 用 Mistral：纯文本对话、摘要、翻译、代码生成、情感分析。凡是只需要“输入文本输出文本”的任务，都可以迁移。
- 用 OpenAI：需要工具调用的 agent、多模态输入（图片、语音）、需要 32k tokens 以上的长上下文、对错误率极其敏感的金融或医疗场景。
我们团队更倾向于混合架构：把高频、低风险的简单任务扔给 Mistral，把复杂推理和工具编排留给 OpenAI。上个月我们在一个内部运维机器人上实现了这种双引擎，成本下降了 58%，同时保持了关键功能的稳定。
说实话，Mistral 的模型能力在某些场景下已经追平了 GPT-3.5-turbo，但距离 GPT-4 还有差距。我们跑了 GLUE 基准测试，mistral-medium 得分 82.4，gpt-4-turbo 得分 89.1，差距 6.7 个点，但价格差了 4 倍。如果你做的是客服问答，这 6 个点的差距可能感知不到；如果你是写法律文档审查，那还真不敢用 Mistral。
选型决策树
如果你正在评估迁移，按这个顺序做选择题：
- 你的应用需要图像输入吗？需要 → 留下。
- 需要外部函数调用（比如查天气、下单）？需要 → 留下。
- 上下文窗口要超过 32k tokens？要 → 留下。
- 对成本极度敏感，且能接受 5% 的响应质量下降？是 → 换 Mistral。
- 需要私有化部署？Mistral 的开源模型（如 Mistral 7B）可以自己 docker 跑，OpenAI 不行。
最后一点：我们团队在三个月前做了一个失败的尝试——为了省 60% 成本，把一个知识库问答系统全部迁到 Mistral，结果频繁出现与事实相悖的幻觉，用户投诉增多。后来我们加了一层 OpenAI 做校验，才把正确率拉回 95%。所以别把所有鸡蛋放一个篮子。
明确推荐
如果你现在跑的是纯文本生成，并且没碰过 tools 和图像输入，那么 Mistral API 的兼容性足以让你在 2 天内完成迁移，省下至少一半的钱。但我也要承认，Mistral 在函数调用和生态工具上不如 OpenAI 成熟，SDK 的 debug 信息也少得可怜，遇到奇怪 bug 时只能靠抓原始 HTTP 响应来排查。
话说回来，我们的最终结论是：轻量任务可以走 Mistral，重度依赖工具链的任务别碰。迁移前先拿 3 天试运行你的核心流程，测错误率，看超时——我们就是这么干的。你准备好了吗？