两类模型差在哪
推理模型（o 系列、DeepSeek-R1、各家的推理档）在回答前先做内部推理，输出里往往附带推理内容，数学与多步分析更强，但慢且贵；通用对话模型直接生成，快而便宜，改写、抽取、客服这类任务表现足够。两者不是替代关系而是分工关系：把任务按难度分流，是成本与体验同时改善的标准做法。
基本信息
| 推理模型 | 内部思维链，推理 token 计入输出计费，延迟高 |
|---|---|
| 对话模型 | 直接生成，延迟低，按普通输出计费 |
| 职责划分 | 推理模型做难题攻坚，对话模型承接高频任务 |
| 控制手段 | 推理档位参数（如 reasoning_effort）与任务路由 |
| 提示差异 | 推理模型给清约束即可，对话模型可用示例引导 |
什么时候用哪一类
| 任务特征 | 推荐模型 | 原因 |
|---|---|---|
| 数学推导、算法设计 | 推理模型 | 需要多步验证，错一步结论就废 |
| 分类、抽取、改写 | 对话模型 | 任务明确，推理开销纯属浪费 |
| 复杂故障排查 | 推理模型 | 要串联多条线索并排除假设 |
| 客服与实时对话 | 对话模型 | 用户对首字延迟敏感，体验优先 |
| 长文摘要与结构化 | 对话模型 | 结果导向，过程推理无额外收益 |
路由落地的几种方式
- 按接口分：不同功能入口绑定不同模型，改动最小
- 按规则分流：关键词或任务类型命中则升级到推理模型
- 按置信度升级：小模型输出不达标时自动重问一次
- 按用户分层：免费档用轻模型，付费档走推理模型
- 人工指定：把选择权交给使用者，在高价值场景保留上行通道
用档位参数控制推理开销
用档位参数控制推理开销
curl -s https://api.openai.com/v1/chat/completions -H "Authorization: Bearer $OPENAI_API_KEY" -H "Content-Type: application/json" -d '{"model":"gpt-5-mini","reasoning_effort":"low","messages":[{"role":"user","content":"把这句话写得更礼貌"}]}' # 低推理档位
# 档位越高推理越充分，延迟与费用同步上升，按任务难度取档
# 推理模型的采样参数多受限，改参数前先查该模型的支持列表
# 推理内容是否对外展示由产品决定，多数场景只展示最终答案路由本身也会错：给低置信度留一条升级通道，比指望分流规则永远正确更实际。
推理模型延迟高，聊天与客服场景体验会明显变差；上线前用真实任务做分流评测，别只看单题正确率。