生产中的推理模型：何时使用，何时不使用

大多数采用推理模型的团队都会犯同样的错误：他们开始在所有地方使用它们。一个新模型发布，带着令人印象深刻的基准测试数据，然后在一周内，它就处理了客户支持、文档摘要以及它真正为之构建的那两个真正困难的问题。然后，基础设施账单就来了。

推理模型——o3、支持扩展思维的 Claude、DeepSeek R1 及其后续版本——确实与标准 LLM 不同。它们在生成输出之前会执行内部的思维链（chain-of-thought），花费更多的计算周期来探索问题空间。这种额外的工作在需要多步骤逻辑的任务上带来了真正的提升。但它也导致每次请求的成本增加 5–10 倍，并增加 10–60 秒的延迟。这两点都无法作为默认设置被接受。

推理模型有何不同

标准 LLM 根据输入上下文预测下一个 token。推理模型通过一个中间步骤来扩展这一点：在生成最终答案之前，它们会生成一个内部的思维追踪——一个代表深思熟虑、回溯和假设检验的 token 序列。这个追踪要么是隐藏的（OpenAI 的 o-系列），要么是向开发者显露的（Claude 的扩展思维，它通过 API 暴露思维块）。

机械的结果是，模型可以在确定答案之前探索多个解决方案路径并排除错误的路径。在那些第一个看起来合理的答案常常是错误的问题上——复杂算法分析、多步数学、安全漏洞检测——这一点非常重要。而在那些第一个看起来合理的答案通常是正确的问题上——摘要、格式转换、情感分类——它几乎没有任何改变。

Claude 最近的 API 变化说明了该领域的发展方向。旧的 budget_tokens 参数曾要求开发者手动设置推理 token 上限，现在已被弃用，转而支持自适应思维 (thinking: { type: "adaptive" })。模型现在根据请求本身决定是否推理以及推理的深度。这减轻了配置负担，但并未改变基本的成本结构：当模型进行推理时，你仍然需要按输出费率支付思维 token 的费用。

10–20% 规则

从成功在生产中部署推理模型的团队那里得到的最清晰的信号是：他们只将推理模型应用于 10–20% 的请求，并且这些请求都具有一套共同的特性。

真正受益于推理的任务：

• 需要可验证的正确性。 答案的对错可以通过检查来确定——可编译并通过测试的代码、可验证的数学结果、有明确解决方案的逻辑谜题。
• 多步骤依赖链。 第 5 步的正确答案取决于正确完成第 1-4 步。标准模型可能会丢失中间状态；推理模型则能维护它。
• 罕见但高成本的失败。 错误的安全性审计、不正确的架构建议、并发代码中遗漏的竞态条件——失败的下游成本超过了额外计算的成本。
• 低延迟容忍度。 没有人会在聊天窗口中等待 30 秒的响应。推理模型适用于异步管道、批处理作业或用户预期需要等待的工作流。

不受益的任务：

• 大规模模式匹配。 摘要、分类和信息提取是学习到的模式映射。当瓶颈是识别而非推理时，更多的计算周期并无帮助。
• 会话界面。 用户期望低于 2 秒的响应。15 秒的思考暂停会破坏交互模式，无论答案质量如何。
• 创意和主观输出。 营销邮件或产品描述没有可验证的正确答案。扩展思维只会导致过度思考，而不是更好的写作。
• 高并发、低利润任务。 如果你每天运行一百万个请求且利润紧张，10 倍的成本乘数就不是权衡——而是停业。

构建路由架构

实际的解决方案不是“使用推理模型”或“不使用推理模型”。它是一个分类优先的架构，在任何昂贵的推理发生之前，将每个请求路由到适当的模型层级。

一个最小的路由系统包含三个组件：

复杂性分类器。 一个轻量级模型（甚至是一个基于规则的系统）评估传入请求并输出一个复杂性信号。好的特征包括：token 计数、prompt 中是否存在多步骤依赖、任务是否映射到已知类别、类似请求的历史准确性。分类器必须快速——毫秒级延迟——这样它才不会成为瓶颈。

模型层级。 将复杂性分组映射到模型选项。一个简单的三层设置：用于简单请求（摘要、查找、格式化）的快速/廉价模型，用于中等复杂度的标准前沿模型，以及用于经证实困难问题的推理模型。这些层级应根据你的实际工作负载分布进行校准。

反馈循环。 根据真实数据或人工审查跟踪每个层级的准确性。路由决策是关于哪个模型合适的假设；准确性数据会告诉你这个假设是否成立。随着数据积累，调整层级阈值。

async def route_request(prompt: str, task_type: str) -> str:
    complexity = await classify_complexity(prompt, task_type)

    if complexity == "simple":
        return await call_model("claude-haiku-4-5", prompt)
    elif complexity == "moderate":
        return await call_model("claude-sonnet-4-6", prompt)
    else:
        # 真正困难问题的推理模型
        return await call_model(
            "claude-opus-4-6",
            prompt,
            thinking={"type": "adaptive"}
        )

一个架构陷阱是：不要让路由器无状态。孤立看起来简单的请求，在考虑对话历史或用户上下文时可能会变得复杂。将相关上下文传递给分类器，否则你会在最关键的案例上进行错误的路由。

积极缓存推理模型的输出

推理模型的输出生成成本高昂，且通常具有足够的确定性，可以进行缓存。推理模型请求的缓存命中可以完全收回额外成本。这显著改变了具有重复或近似重复输入的工流程的经济效益。

标准的缓存 TTL（生存时间）对于推理输出来说通常太短。如果每次提交相同模块时，代码审查都产生相同的架构建议，那么该输出应该缓存数小时，而不是数分钟。原因：推理过程本身开销大，且除非代码发生变化，否则答案不太可能改变。

对于具有可预测输入模式的应用——例如每天处理相似函数的代码审查机器人，或每周评估相似条款的合规性检查器——使用常见输入预热缓存是值得前期投入的。你在预热时支付一次费用，然后在整个期间从缓存中提供服务。

需要监控什么

标准的 LLM 监控会跟踪延迟、Token 计数和错误率。推理模型需要额外的指标：

• 思考 Token 分布。 每个请求消耗的思考 Token 数量，以直方图形式呈现。双峰分布通常表示路由失败：你正在将简单的请求发送到推理层。
• 每个层级的成本占总开销的百分比。 如果推理层消耗了你 LLM 预算的 30-40% 以上，但只处理了 10% 的请求，那么你的路由阈值设置有误。
• 按层级划分的准确性。 路由到推理层的请求是否真的从中受益？如果推理层在相同任务类型上的准确性没有比标准层显著更高，请重新校准。
• 延迟百分位数。 按层级和任务类型划分的 P50 和 P99 延迟。推理模型的 P99 可能会非常长，应通过明确的超时进行限制。

一个监控反模式：在没有按层级细分的情况下跟踪总体准确性。这会模糊推理模型是否物有所值。你需要每个层级的准确性才能知道路由决策是否正确。

回退级联模式

对于偶尔遇到难题的、对延迟敏感的应用，级联模式比静态路由效果更好。从一个快速、廉价的模型开始。评估置信度。如果置信度低（通过输出熵或轻量级验证器衡量），则升级到下一个层级。

async def cascade_request(prompt: str) -> str:
    # 尝试 1：快速模型
    result, confidence = await call_with_confidence("claude-haiku-4-5", prompt)

    if confidence > CONFIDENCE_THRESHOLD:
        return result

    # 升级到标准模型
    result, confidence = await call_with_confidence("claude-sonnet-4-6", prompt)

    if confidence > CONFIDENCE_THRESHOLD:
        return result

    # 最后手段：推理模型
    return await call_model(
        "claude-opus-4-6",
        prompt,
        thinking={"type": "adaptive"}
    )

级联模式会在升级的请求上增加延迟，但这些请求的延迟成本已经由问题的难度所证明是合理的。快速路径仍然保持快速。

实践中的决策

在使用推理模型之前，请回答三个问题：

1. 是否存在可验证的正确答案？ 如果无法检查正确性，那么推理就不能增加有效信号。
2. 对于此请求，10-60 秒的延迟是否可接受？ 如果不可接受，请排除同步推理模型的调用。
3. 错误的答案在这里的成本是否高于额外的计算成本？ 如果失败模式风险较低，那么标准模型就足够了。

大多数生产请求都未能通过这些检查中的至少一项。那些通过所有三项检查的请求，正是推理模型能够证明其成本合理性的请求。这通常只占总请求量的一小部分——但却是最重要的一部分。

错误不在于使用推理模型。而是将它们视为即插即用的升级，而非一个具有实际应用限制的专用工具。