平台能力
推理模型
为复杂分析、数学、规划和代码任务选择推理模型，并处理好长耗时与输出预算。
推理模型适合多步骤分析、复杂规划、数学与高难度代码任务。它们和普通对话模型共用 POST /v1/chat/completions，差异在响应时间、输出预算和参数行为，而不是接口。
选型维度
推理模型与普通对话模型共用同一接口，差异体现在思考过程开销和输出预算上。选型时关注：
| 维度 | 需要确认的内容 |
|---|---|
| 上下文长度 | 长链路任务需要更大的输入与输出预算。 |
| 思考开销 | 推理过程是否单独计费，是否计入 Token 用量。 |
| 参数行为 | 是否限制或忽略 temperature 等采样参数。 |
| 输出上限 | 单次最大输出是否够放下完整推导与结论。 |
具体模型标识以模型目录为准，本文档不列举固定清单。
与普通对话模型的选择边界
| 适合推理模型 | 没必要用推理模型 |
|---|---|
| 复杂约束下的方案比较 | 关键词分类、简单改写 |
| 数学、逻辑、多步骤分析 | 固定格式的模板填充 |
| 大型代码问题与根因分析 | 低延迟闲聊、自动补全 |
| 需要验证假设的规划任务 | 确定性代码可直接算出的结果 |
调用要点
- 推理模型的思考过程会消耗 Token，
max_tokens要给足；只给512时常见表现是「还没输出结论就被截断」。 - 部分推理模型会限制或忽略
temperature等采样参数，不要依赖低温度来稳定结论。 - 交互产品要为单次请求设置可接受的总超时，并考虑对长任务改用异步或后台队列。
- 要求模型输出结论、假设和验证方法，不要把更长的回答等同于更高质量。
- 关键结论用测试、计算器、检索或业务规则验证后再落库。
成本控制
- 先用小请求确认模型可用，再放大输入。
- 对同类任务保留一个小模型基线，只在质量不达标时升级到推理模型。
- 记录每次请求的模型标识、Token 用量和耗时，按业务线拆分成本。