详细解释
推理模型 Reasoning Model（Long Chain-of-Thought 与 Slow-thinking LLM）是一类先进行较长内部思考、再给出答案的模型，用户提问后往往要等待数秒到数十秒，模型会在这段时间里生成大量用户看不见的思考内容，最后再输出一段简短结论。它和普通对话模型的本质区别有两点。第一是先想后答：普通模型收到问题后直接逐词生成答案，推理模型则先生成一段思考链，在思考中拆解问题、试错、回头检查，再给出收敛后的结论，本质上是用更多的推理时算力换准确率，也就是 测试时计算扩展。第二是思考链的来源：普通对话模型也可以通过提示词要求它一步步来，那种思考是被提示诱导出来的；而推理模型的思考链是模型内部生成的行为，由训练阶段用强化学习激励出来，不需要用户提示，也不容易通过提示词完全关掉。理解这条链路可以先看 思维链 的基础概念。
推理模型的能力提升集中在可验证的硬任务上。DeepSeek 在 DeepSeek-R1 论文 中公开了用纯强化学习激励长链推理的完整方法。数学计算、代码生成、多步逻辑推理、复杂规划这类任务，普通对话模型的准确率往往在 45% 至 60% 徘徊，推理模型能做到 85% 至 95%，提升幅度非常显著。这条能力主要来自可验证奖励的强化学习：用 可验证奖励强化学习 给数学题、代码题自动判分，再配合 组相对策略优化 一类算法更新策略，模型自己学会多想一想能答对更多。代价同样明显：输出 Token 量通常是普通模型的 5 至 20 倍，思考 Token 会显著抬高 延迟 与单次成本；而且在分类、改写、格式转换这类简单任务上，思考不仅没有收益，还可能因为过度自我怀疑而拉低准确率。换句话说，推理模型是用钱和时间换准确率，值不值取决于任务难度。
在 API 调用层面有四个工程要点。第一，思考内容与最终答案通常分离返回，主流接口会把推理过程放在独立字段里，业务侧只应展示最终答案，避免把内部思考直接暴露给终端用户。第二，思考预算参数要显式设置，多数推理模型提供思考档位或思考 Token 上限，不设上限容易让简单请求也跑出上万思考 Token。第三，最大输出 Token 数 必须给足，思考 Token 也算在输出里，若上限设置得偏小，模型会只输出半截思考就断掉，答案随之被截断。第四，流式场景要把思考中与回答中分成两个阶段做交互。唯元智创 在网关侧为每个请求分别记录输入 Token、可见输出 Token 与思考 Token，对超预算请求自动降档，并按请求难度做动态路由，把推理预算集中花在真正的难题上。
普通对话模型与推理模型对比表
| 维度 | 普通对话模型 | 推理模型 | 典型数值差异 | 对成本影响 | 对延迟影响 | 选型建议 |
|---|---|---|---|---|---|---|
| 首 Token 延迟（TTFT） | 0.3 至 0.8 秒 | 3 至 20 秒 | 相差 5 至 30 倍 | 等待期间不额外计费 | 延迟显著上升，实时对话体验退化 | 实时高并发场景用普通模型或低档 |
| 输出 Token 量 | 1 倍基准 | 5 至 20 倍 | 相差 5 至 20 倍 | 直接抬高单次成本 | 生成时间同比例拉长 | 成本敏感场景先算清单次预算 |
| 数学准确率 | 45% 至 60% | 85% 至 95% | 提升 25 至 45 个百分点 | 每次调用更贵但更少返工 | 单题思考数秒到数十秒 | 竞赛数学与复杂计算选推理模型 |
| 代码通过率 | 40% 至 60% | 75% 至 92% | 提升 20 至 35 个百分点 | 明显降低反复调试成本 | 长文件修改时延迟较明显 | 复杂调试与算法题选推理模型 |
| 指令遵循 | 稳定，格式约束听话 | 简单任务反而下降 | 简单任务下降 3 至 10 个百分点 | 格式错误带来额外重试成本 | 影响不大 | 严格格式约束任务优先普通模型 |
| 幻觉表现 | 事实类错误率较高 | 推理类错误减少，事实类仍会错 | 可验证推理错误降 20 个百分点以上 | 错误代价高时不省钱 | 影响不大 | 事实类任务仍需检索与引用核对兜底 |
这张表最值得注意的是输出 Token 量与首 Token 延迟两行：推理模型的成本与等待几乎全部来自那部分看不见的思考 Token，而它在简单任务上的收益接近于零。因此选型的关键不是「哪个模型更强」，而是「这个任务到底需不需要多步推理」。
推理强度档位与场景匹配表
| 思考档位 | 典型思考 Token 量级 | 相对延迟倍数 | 相对成本倍数 | 适用任务 |
|---|---|---|---|---|
| 关闭思考 | 0 | 1 倍 | 1 倍 | 分类、改写、抽取、闲聊 |
| 低档 | 200 至 800 | 1.5 至 3 倍 | 1.5 至 3 倍 | 一般问答、轻量代码 |
| 中档 | 800 至 3000 | 3 至 8 倍 | 3 至 8 倍 | 多步推理、代码调试 |
| 高档 | 3000 至 12000 | 8 至 20 倍 | 8 至 20 倍 | 竞赛数学、复杂规划、合规推理 |
| 最高档 | 12000 以上 | 20 倍以上 | 20 倍以上 | 极少数超难题，须先做对照实验 |
| 自动路由（唯元智创 推荐） | 0 至 12000，按难度分配 | 1 至 12 倍 | 比全量高档省 40% 至 70% | 企业混合负载、通用助手 |
这张表的结论是「收益随难度上升而放大、随难度下降而塌陷」：在难题上每多给一倍思考预算往往能换来数个百分点提升，而在简单任务上多给思考预算几乎是纯浪费，甚至因为过度思考引入自我怀疑而拉低正确率。落地时不要一上来就上最高档，而应从低档或中档起步，用真实业务样本跑一遍档位与准确率的对照，找到性价比拐点，再交给自动路由按难度分档。
实战经验与避坑
-
简单任务不要开推理模型，纯属浪费钱和延迟：意图分类、情感判断、字段抽取、文本改写、格式转换这类任务，答案的确定性极高、几乎不需要多步推理，实测开启高思考档后准确率提升普遍在 1 个百分点以内，而延迟从 0.5 秒涨到 5 秒以上、成本翻 8 至 20 倍。这类任务应当明确关闭思考或走低档，把预算留给真正需要的场景。一个实用的判断标准是：如果让一个熟练的实习生 3 秒内就能给出答案，那这个任务就不需要推理模型。
-
最大输出 Token 数必须给够，思考 Token 也算在输出里：这是推理模型最容易踩的坑。思考 Token 属于输出 Token 的一部分，如果上限按答案长度去设，模型会在思考阶段就把额度用光，最终只输出半截思考、根本来不及给出答案，用户看到的就是一段莫名其妙的自言自语。正确做法是把上限设为预期思考量加预期答案长度，再留 50% 至 100% 的余量，例如预期思考 3000 Token、答案 500 Token，就把上限设到 6000 至 8000。上线后要监控截断比例，一旦发现因长度上限而停止的响应占比偏高，就该立刻抬高上限。
-
不要把模型的原始思考内容直接展示给终端用户：思考内容是模型内部生成的，直接展示有三个问题：可能泄漏系统提示词与内部策略；可能包含自相矛盾、反复推翻的表述，让用户觉得模型不靠谱；对多数用户来说一长串内心独白只会造成困惑。正确做法是只展示最终答案，把思考内容记录到日志用于排查与优化；如果产品确实想让用户看到正在思考，更稳妥的方式是展示一个抽象的进度提示，而不是原始思考文本。事实类任务仍建议用 检索增强 与引用核对兜底，不能只靠推理。
-
流式场景要区分思考中与回答中两个阶段做不同交互：推理模型的流式输出通常先吐思考内容、再吐最终答案，如果不做区分，前端会把一大段思考混进答案里，体验很差。工程上应解析接口返回的阶段标记，把思考阶段渲染成折叠面板或正在思考的提示，等进入回答阶段再切换到正常的正文流式渲染。这样做还有一个好处：用户在思考阶段就能看到界面有反馈，等待体感明显改善。对延迟更敏感的产品，可以在思考阶段先给出一个已理解问题、正在推导的占位文本。
-
用推理模型做抽取类任务时，要在提示里明确要求直接输出结构化结果：抽取、分类这类任务本不需要长篇推理，但很多推理模型会默认先想一大段，既慢又贵，还可能因为自我怀疑而漏抽或多抽字段，甚至在思考里脑补出原文没有的内容。正确做法是在系统提示里明确写清不要长篇思考、直接输出结构化结果，并把思考档位调到关闭或低档；如果模型支持，还可以配合结构化输出约束，强制它按指定字段返回。实测这一句话就能把抽取任务的思考 Token 压掉一半以上，而对准确率几乎没有影响。
-
要按请求难度做动态路由，把推理预算花在真正的难题上：推理模型的价值在于难题上的准确率跃升，如果所有请求都开高档，成本会失控而大部分预算被浪费在简单任务上。合理架构是在网关层先做一个轻量难度判定，把请求分成简单、中等、困难三档，简单任务走普通模型或关闭思考，中等任务走低到中档，只有明确识别为难题的请求，比如数学符号密集、多文件代码修改、长链条合规判断，才走高档。实测这样做能在整体准确率基本不掉的前提下，把推理相关成本压掉 40% 至 70%。