GPT-4o 和 GPT-4o mini 怎么选
同一个任务用 gpt-4o 还是 gpt-4o-mini，答案不是"看预算"这么笼统。这篇按四类真实任务拆开对比：摘要分类、多轮对话、结构化抽取、代码生成，给出用奖励函数分流的具体做法和一套可复现的评测脚本。
gpt-4o 和 gpt-4o-mini 是同一个团队里最常同时出现的两个模型。前者贵但更稳，后者便宜但偶尔"聪明过头地犯错"。绝大多数团队的做法是"重要的用 4o，不重要的用 mini"，但这句判断太模糊，落地时没人说得清哪条请求算重要。
这篇给一套可执行的拆分方法：按任务类型分层，用少量抽样确定分流阈值，最后给出路由代码。
先说结论
- 拿不准就先全量跑 mini，只把失败样本升级到 gpt-4o，这个顺序比反过来省钱得多
- 结构简单、输出可控的任务（分类、抽取、短摘要）mini 通常够用
- 需要跨段推理、长链条工具调用、严格格式遵循的任务，用 gpt-4o 省下的返工时间超过差价
- 分流不要按"业务重要性"拍脑袋，按可量化的失败信号分（格式错误率、人工驳回率、字段缺失率）
- 分级路由必须记录每次升级的原因，否则一个月后没人知道钱花在哪
两个模型的真实差别在哪
价格上的差距是一个数量级，但能力差距不是。差异主要集中在三个维度：
| 维度 | gpt-4o | gpt-4o-mini | 影响场景 |
|---|---|---|---|
| 指令遵循稳定性 | 高 | 中 | 严格 JSON、字段名不能错的抽取 |
| 多步推理 | 强 | 中偏弱 | 需要前后文对照的判定类任务 |
| 长上下文一致 | 强 | 中 | 长文档问答、跨章节引用 |
| 速度 | 较快 | 更快 | 前端流式体验 |
| 单价 | 高 | 低 | 高并发场景的成本差放大 |
其余维度（中文表达、常见知识、日常问答）两者差别不大，mini 完全能打。所以选型问题本质是：你的任务卡在上表哪一个维度上。
按任务类型分层
把业务里的调用先归成四类，分法比按业务线分更有效，因为难度写在任务结构里，不写在业务名字里。
第一类：短分类与打标签。 输入一段文本，输出固定枚举值之一。这类任务 mini 的正确率通常和 4o 接近，因为决策空间小。用 mini。
第二类：结构化抽取。 从自由文本里抽字段，输出必须是合法 JSON。这里 mini 的问题不是答错，而是偶尔多写字段或少写字段。做法是：mini 抽 + 服务端做 schema 校验，校验不过再升级一次，而不是一开始就上 4o。
第三类：多轮对话。 用户会追问、会纠正、会引用上文。mini 在前两轮表现好，到第五轮以后容易丢掉早先的约束。做法是：mini 跑默认会话，检测到"用户明确指出模型理解错了"就升级。
第四类：代码与长文档。 直接上 4o 或对应的强模型。mini 在这个区间返工率高，返工一次的 token 成本往往比直接用贵模型还高。
用奖励函数定分流阈值
"感觉不行就升级"没法自动化。可行的是定义一个奖励函数，把失败信号量化：
import json
def route_score(sample: dict) -> float:
"""分数越低越该升级。字段名按业务定义。"""
score = 1.0
if not sample.get("schema_valid"):
score -= 0.6 # 结构不合法，直接判失败
if sample.get("review_rejected"):
score -= 0.5 # 人工驳回
if sample.get("missing_field_ratio", 0) > 0.2:
score -= 0.3 # 必填字段缺失过多
if sample.get("turns", 0) >= 5:
score -= 0.1 # 多轮会话风险随轮次上升
return score先让 mini 全量跑一周，把每个请求的 route_score 记下来，然后看分布：分数在 0.4 以下的样本占比是多少、这些样本换成 4o 之后通过率提升多少。用这两个数就能算出升级的边际收益，比凭经验拍一个阈值靠谱。
分流代码
下面是实际可跑的分级路由，思路是「mini 优先 + 失败重试一次升到 4o」：
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["ZAIMOD_API_KEY"],
base_url="https://api.zaimod.com/v1",
)
def chat(messages, need_json=False):
tier = "gpt-4o-mini"
kwargs = {}
if need_json:
kwargs["response_format"] = {"type": "json_object"}
resp = client.chat.completions.create(
model=tier, messages=messages, temperature=0.2, **kwargs
)
text = resp.choices[0].message.content
if need_json:
try:
json.loads(text)
except json.JSONDecodeError:
# 只在格式崩了的时候升一级重试
resp = client.chat.completions.create(
model="gpt-4o", messages=messages, temperature=0.2, **kwargs
)
text = resp.choices[0].message.content
record_escalation("json_invalid")
return text关键点是只在可验证的失败上升级。JSON 解析失败是可验证的，所以值得升级；"回答得好不好"不可验证，升级了也不一定更好，那种情况应该去改 prompt 而不是换模型。
三个容易忽略的细节
- 温度设置要一致：用 mini 调出来的 prompt 在 4o 上未必最优，两者对温度的敏感度不同。分流实验时把温度固定住，否则变量太多。
- 扣掉重试成本再比较：mini 升级到 4o 意味着一次请求付两份钱。真正要比的是「mini 直出价 + 升级概率 × 4o 价」和「4o 直出价」。
- 按 token 而不是按次数算：长输入场景下，输入 token 占大头。同一个提示词在两个模型上的输入计费口径不同，要用实际 token 数算，不能用请求数估算。单价见价格页。
FAQ
能不能干脆全用 gpt-4o-mini？
如果任务是短分类、日常问答、内容初稿，可以。它的弱项集中在严格格式和长链条推理上，不碰这两块就没明显影响。
能不能全用 gpt-4o？
能，但多数团队会在账单上发现大量钱花在了"mini 也能做对"的请求上。分层不是省钱技巧，是让贵的算力只花在真正需要它的地方。
升级判定的数据存在哪？
落库里，字段至少包括 request_id、initial_model、escalated、reason。没这三列，一个月后无法复盘分流是否有效。
模型换了之后还要重新评测吗？
要。每次换主力模型或上游版本变动，用固定的一百条测试集重跑一遍，看通过率是否漂移。
延伸阅读
- LLM API 价格对比：主流模型按 token 单价的横向对照
- Token 怎么算：模型成本估算方法：预算模型前的第一步
- LLM 返回非法 JSON 怎么修：比换模型更省的做法
- 模型列表：可调用型号与上下文长度
需要按量付费、一个 Key 覆盖全部型号？注册后即可开始，请求体完全兼容 OpenAI SDK，上面这段代码改掉 api_key 就能跑。