推理模型的用法:什么时候该用 o1 类模型

自从 OpenAI 放出 o1、又陆续有 o3、DeepSeek-R1、Qwen3 思考模式这批"推理模型"(reasoning model),社区里一直在争论一个问题:我到底什么时候该多花钱上推理模型? 很团队的现状是:要么啥都丢给推理模型,结果账单爆炸、响应卡顿;要么压根不用,在硬问题上被同事的 o1 秒杀。

这篇文章不讲营销话术,讲一线的判断标准:推理模型和普通模型的本质区别、它真正擅长的场景、用了反而吃亏的场景、成本与延迟的坑、怎么写 prompt 才不浪费它的推理能力,以及最后落到一个工程化方案——混合路由架构。

一、推理模型 vs 普通模型:差在哪

一句话:推理模型在回答前会"先想",而且这个想的过程是内置的、隐藏的。

普通模型(GPT-4o、Claude Sonnet、DeepSeek-V3 这类)本质上是"一次过"的下一个 token 预测,你给它 prompt,它直接生成回答。你当然可以在 prompt 里写 "Let's think step by step" 强制它显式分步,但那是外部诱导,模型本身没有"先想"的机制。

推理模型不一样。它在 RL 训练阶段就被奖励"先在内部生成一条思维链(hidden chain-of-thought)",这条链不出现在最终输出里(或者以折叠的 thinking 区块出现),但模型会花大量算力在上面探索、自我纠错、回溯。它把更多 compute 花在"想",而不是"说"。

带来的直接后果:

• 能力分布变了:在需要规划、长链推理的任务上,推理模型相比同代普通模型有肉眼可见的提升;在简单任务上几乎没差别,甚至更差。
• 延迟显著上升:thinking 阶段可能跑几十秒到几分钟,首个 token 延迟(TTFT)极高。
• 计费方式变了:thinking token 也按量计费,而且通常不会暴露给你完整内容,你却要为它买单。

理解了这一层,后面的所有判断都顺理成章。

二、推理模型擅长什么

实战中,我把"明显值得上推理模型"的任务归成五类:

1. 复杂数学与形式化证明。奥赛级数学、积分推导、概率论、数论,这类普通模型经常一步错步步错,推理模型能通过自我验证拿到正确结果。GSM8K 这种已经被刷烂的题不在此列,真正拉开差距的是 AIME、Putnam 难度的题。

2. 算法设计与复杂代码。注意不是"写代码"——CRUD、模板代码普通模型写得又快又好。值得上推理模型的是:有难度的算法题(动态规划状态设计、图论建模)、跨文件的复杂重构、并发/锁的 bug、性能瓶颈定位。这类问题的共同点是需要先在脑子里跑通多个方案再动手,正是推理模型的强项。

3. 多步逻辑推理。规则复杂的合规判断、多约束的调度问题、"如果 A 则 B,除非 C 同时 D"这种嵌套条件推理,推理模型的准确率明显高。

4. 科研与分析。论文复现、实验设计、对一组实验结果给出严谨的因果解释、统计方法选择。它会更小心地考虑混淆变量和反例。

5. 需要严谨的规划。多步骤任务分解、agent 的长程规划。一个典型场景:让推理模型先把一个模糊需求拆成可执行的子任务清单,再交给普通模型逐个执行。

共同特征是:问题有"正确答案"或可验证的标准,中间步骤错了能被发现。推理模型的价值就在于它能自我纠错。

三、推理模型不擅长什么(别用错地方)

更重要是知道什么时候不该用。以下场景用推理模型纯属浪费,甚至更差:

• 简单问答 / 信息检索。"Python 怎么读 JSON"、"Redis 默认端口是多少"——普通模型毫秒级返回,推理模型却要先思考 20 秒,体验灾难。
• 创意写作。推理模型被训练得过度"理性",写小说、slogan、文案时容易收得太紧、缺乏灵气。我有一次让 o1 写产品文案,它先花了 40 秒"分析受众心理",最后给出一段四平八稳的废话。
• 实时 / 多轮对话。客服、语音助手、游戏 NPC 这类对延迟敏感的场景,推理模型的 thinking 延迟直接毁掉体验。
• 格式化抽取与结构化输出。从发票里抽字段、JSON 化一段文本、NER——这是普通模型的舒适区,推理模型"杀鸡用牛刀",又慢又贵。
• 简单的工具调用 / function calling。除非工具组合本身需要复杂规划,否则没必要。

一句话:凡是"不需要想"的活,推理模型都不会做得更好,只会做得更慢更贵。

四、成本与延迟:thinking token 也烧钱

这是工程上最容易踩的坑。很多人以为"我只问了一个短问题,应该很便宜",结果账单一看——thinking token 占了 90% 的费用。

几个事实先摆清楚:

• thinking token 计费:o1/o3/DeepSeek-R1 的内部思维链都按 output token 价格计费(或者 R1 系列的 reasoning token 单独计价),而且因为推理模型倾向于"多想",这部分常常远超最终答案的长度。
• 延迟不可控:同一个问题,thinking 可能耗时 5 秒,也可能 90 秒,你没法在请求时承诺 SLA。对前端交互是致命的。
• 并发与吞吐:thinking 占用算力时间长,服务商对推理模型的速率限制往往更紧,排队现象更明显。
• 缓存友好度低:普通对话可以靠 prompt 缓存大幅降本,推理模型的 thinking 路径高度依赖具体问题,缓存命中率低。

工程上的应对:给推理模型设独立的 budget 上限(每请求最大 thinking tokens)、用异步队列而不是同步 HTTP、在产品侧用"正在深度思考..."的进度态管理用户预期。最重要的是——做用量监控,按任务类型分别统计推理模型的花费,不然一个月烧掉几十万你还以为是模型贵,其实是用错了地方。

五、怎么驾驭推理模型:三条铁律

把推理模型用好,prompt 写法和普通模型完全不同。我总结三条铁律:

铁律一:给它时间,别催。 推理模型的价值就在于多想,你在 prompt 里写"快速回答""简短回复"等于亲手阉割它的能力。除非真的只是要它总结,否则默认让它想充分。

铁律二:prompt 要简明,别过度指导。 这是最常见的反模式——把普通模型那套"Let's think step by step, first analyze X, then consider Y..."搬到推理模型上。推理模型自己会规划思维链,你强行规定步骤反而干扰它。描述清楚问题和目标,把推理过程交给模型。 少给 hint,多给 context。

铁律三:验证它的推理链,别盲信。 推理模型不是不会错,只是错得更隐蔽。它会在 thinking 里自信地走一条错误路径,最后给你一个看起来很顺的答案。代码题一定要跑测试,数学题一定要验算,关键决策一定要人工 review 它的中间结论。把推理模型的输出当"一个很聪明但偶尔自信犯错的同事的草稿"对待。

还有一条实用技巧:让推理模型输出它的关键中间假设,方便你定位它错在哪一步,而不是只看最终答案。

六、混合架构:让路由层做选择

真正的工程答案是:别全站用一种模型,建一个路由层按任务复杂度分流。 这是目前几乎所有成熟 AI 团队的标配架构。

                   用户请求
                      │
                      ▼
           ┌──────────────────────┐
           │   路由层 (Router)     │
           │  分类:简单 / 硬推理   │
           └─────────┬────────────┘
            ┌────────┴────────┐
            ▼                 ▼
     ┌─────────────┐   ┌──────────────┐
     │ 快通道        │   │ 慢通道         │
     │ GPT-4o mini │   │ o3 / R1      │
     │ Claude Haiku│   │ (异步队列)     │
     │ DeepSeek-V3 │   │              │
     └─────────────┘   └──────────────┘
            │                 │
            └────────┬────────┘
                     ▼
                 统一回包 + 用量埋点

路由层怎么判断复杂度?几种实战做法,由轻到重:

1. 关键词 / 意图规则:数学公式、"证明""推导""算法复杂度"这类信号直接路由到推理模型;翻译、摘要、抽取走快通道。最简单,够用 80% 场景。
2. 小模型分类器:用一个便宜的模型(或微调过的 BERT 类)先打一个难度标签,再决定路由。准确率更高,多一次轻量调用。
3. 级联(cascade):先让快模型尝试,设一个置信度或自检阈值(比如"如果没把握就回 ROUTE_TO_REASONING"),不通过再升级到推理模型。性价比最高,我推荐这条作为默认。

路由层除了分流,还要做三件事:统一日志和用量埋点(按通道分别统计成本和延迟)、降级策略(推理模型超时就回退到快模型)、A/B 实验框架(持续验证路由策略是否合理)。

一个常见误区:路由不是一次性的。一个复杂任务可以被拆成"推理模型做规划 + 快模型做执行",这才是 agent 框架里的标准玩法。

七、实战:哪些任务推理模型明显更强

空谈不如看实测。下面这些是我和团队在过去半年反复验证过、推理模型相对同代普通模型有显著优势的任务(不是"略好",是"差一个段位"):

• LeetCode Hard / Codeforces 1800+:o3 类模型能稳定出思路,普通模型经常卡在错误贪心。
• SQL 复杂查询优化:多表 join + 窗口函数 + 性能优化建议,推理模型给的执行计划更靠谱。
• Bug 根因分析:给一段报错栈 + 相关源码,推理模型更能定位到真正的根因而非表面症状。
• 论文复现:照着 paper 写代码,推理模型对模糊表述和缺失细节的容忍度更高。
• 多约束排班 / 调度:有硬约束 + 软约束的优化问题,推理模型的解更接近最优。
• 形式化验证 / TLA+ / Coq:几乎只有推理模型能玩转。

反过来,这些任务实测推理模型没有显著优势,甚至更差:简单代码补全、翻译、改写润色、RAG 问答、闲聊、结构化抽取。这些就别浪费钱了。

一个判断口诀:问题"难"且"可验证",上推理模型;问题"简单"或"开放无标准答案",用普通模型。

小结

• 本质区别:推理模型把更多算力花在隐藏的思维链上,"先想再答",擅长难且可验证的问题,代价是更慢更贵。
• 该用的场景:复杂数学/证明、算法与难代码、多步逻辑、科研分析、严谨规划——共同点是"有正确答案、中间错能被发现"。
• 别用的场景:简单问答、创意写作、实时对话、结构化抽取——用了只会更慢更贵,甚至更差。
• 成本与延迟:thinking token 照样计费,延迟不可控,务必设 budget、做异步、按任务类型监控用量。
• 工程化标配:建路由层做分流,优先用"级联"策略——快模型先试,不通过再升级推理模型。

金句收尾:推理模型不是更强的模型,而是另一种模型——它解决的问题维度不一样。把它当万能锤子,只会把每一颗钉子都砸得很慢、很贵。