Reasoning Budget 和普通 max tokens 有什么区别？

普通 max tokens 通常限制生成总量或可见输出上限；Reasoning Budget 还要考虑模型内部推理消耗。推理 Token 可能不可见，但会占用上下文、影响延迟并计入账单。

所有复杂任务都应该使用高推理强度吗？

不应该。生产系统应先按任务风险、复杂度、用户等级和延迟预算分级，再决定是否启用推理模型、使用何种 effort 或 thinking_level。

如何发现推理预算设置过低？

重点观察 incomplete、max_output_tokens、超时、空输出、低置信结果和人工复核率。如果这些指标在复杂任务上升，应扩大预算或调整降级策略。

Reasoning Budget 是不是只为了省钱？

不是。它同时服务于成本、延迟和质量。预算太低会导致复杂任务失败，预算太高会拖慢链路并放大账单。合理策略是让简单任务少思考、复杂任务充分思考、高风险任务可审计。

LLM Reasoning Budget 生产实战：用推理开关、Token 上限与超时策略管住成本

背景：推理模型把”算得更久”变成了可治理资源

推理模型不只是生成更多文字。它们会在最终答案之前消耗额外的内部推理计算，用来拆解问题、比较路径、检查约束或在工具调用之间继续规划。这个能力适合复杂代码生成、数学推理、长文档判断、策略规划和高风险决策，但它也把线上系统带入了一个新问题：用户看到的输出很短，账单和延迟却可能很高。

OpenAI 的 Reasoning 文档明确区分了 input tokens、visible output tokens 和 reasoning tokens。这些 reasoning tokens 不会直接通过 API 暴露为完整原始思考过程，但它们会占用上下文窗口，并且会作为 output tokens 计费。Google Gemini 的 thinking 文档也说明，开启 thinking 后价格由 output tokens 和 thinking tokens 共同构成，并可从 usage 中读取 thought token 相关字段。Anthropic 的 extended thinking 则提供 budget_tokens 或更新模型上的 adaptive thinking / effort 机制，用于限制内部推理过程可使用的预算。

这意味着，生产系统不能只用”模型单价 × 输出字数”估算成本。推理模型需要单独设计 Reasoning Budget，把任务分级、推理开关、effort、Token 上限、超时、降级和可观测性统一纳入调用链路。

核心原理：Reasoning Budget 不是一个参数，而是一组运行时边界

1. 内部推理 Token 是隐藏但真实的成本

对普通聊天模型来说，成本治理通常围绕输入长度、输出长度、模型选择和缓存命中率展开。推理模型多了一层：模型可能先生成不可见的推理 Token，再输出最终答案。

因此一次调用至少要关注四类数据：

指标	含义
`input_tokens`	用户输入、系统提示词、上下文、工具结果等输入
`visible_output_tokens`	用户最终可见的回答
`reasoning_tokens / thought_tokens`	模型内部推理消耗
`finish_status / incomplete_reason`	是否因 Token 上限、上下文窗口、超时或安全策略提前结束

如果系统只记录可见输出，就会误判”这次调用很便宜”。如果只限制最终回答长度，也可能出现模型在内部推理阶段耗尽预算，最后没有产生有效可见答案的情况。

2. effort / thinking_level 决定推理深度，但不能替代业务策略

不同平台的控制方式不同。OpenAI 的 Responses API 使用 reasoning: { effort: "medium" } 控制推理强度，并用 max_output_tokens 限制总生成空间。Azure OpenAI 的 Chat Completions 示例中也提供了 reasoning_effort 与 max_completion_tokens。Anthropic 的 extended thinking 使用 thinking 配置控制是否启用以及预算上限；Google Gemini 则提供 thinking_level、thought summaries 和 usage 中的 thought token 统计。

但工程上不能把这些参数直接暴露给业务方随意填写。更稳妥的做法是把平台差异包装成统一的业务策略：

{
  "task_type": "contract_risk_review",
  "risk_level": "high",
  "latency_class": "async_or_slow_ok",
  "reasoning_policy": {
    "enabled": true,
    "effort": "high",
    "max_generated_tokens": 12000,
    "timeout_ms": 90000,
    "fallback": "medium_effort_retry_then_manual_review"
  }
}

在这个模型中，业务只描述任务类型和风险等级，平台层负责把策略翻译成 OpenAI、Anthropic、Gemini 或 Azure 的具体参数。

3. Reasoning Budget 需要同时约束质量、延迟和账单

推理预算过低，复杂任务可能提前中断、输出空结果、漏掉约束或给出未经充分检查的答案。推理预算过高，又会带来更长延迟、更高账单和更难预测的排队压力。

因此 Reasoning Budget 的目标不是”越省越好”，而是让每一类任务都有可解释的边界：

任务类型	推荐策略
简单分类、字段改写、短文本摘要	默认不用推理模型，或使用低 thinking
多约束判断、复杂代码、数学推导、合同条款分析	允许 medium / high
低价值批量任务	优先使用普通模型、低 effort 或异步批处理
高价值但不要求实时的任务	允许更高推理预算，并用队列和人工复核兜底
面向用户实时交互的任务	优先控制超时和流式反馈，不让推理阶段无限拉长首 Token 时间

工程落地：从”每次调用调参数”升级为预算策略层

任务分级：先判断是否值得 reasoning

上线推理模型前，先把业务请求分成四类：

第一类是 routine task，例如翻译、格式转换、标签分类、短问答。这类任务使用普通模型或低推理预算即可。

第二类是 ambiguous task，例如”帮我判断这个投诉是否需要升级""从这些材料里找异常”。这类任务可以用低到中等推理预算，并要求模型输出判断依据。

第三类是 constraint-heavy task，例如代码修复、保险规则判断、合同风险条款识别、财务口径解释。这类任务适合中高推理预算，因为错误成本高，且需要处理多条约束。

第四类是 open-ended planning task，例如复杂 Agent 规划、迁移方案拆解、多步骤排障。这类任务应优先异步执行，允许更高预算，但必须配套超时、审计和人工确认。

统一策略表：不要把 provider 参数散落在业务代码里

建议建立一张 llm_reasoning_policy 配置表或等价配置文件，至少包含以下字段：

CREATE TABLE llm_reasoning_policy (
  id VARCHAR(64) PRIMARY KEY,
  task_type VARCHAR(128) NOT NULL,
  enabled BOOLEAN NOT NULL,
  default_effort VARCHAR(32) NOT NULL,
  max_generated_tokens INTEGER NOT NULL,
  timeout_ms INTEGER NOT NULL,
  fallback_policy VARCHAR(128) NOT NULL,
  max_cost_usd NUMERIC(10, 4),
  require_human_review BOOLEAN DEFAULT FALSE,
  updated_at TIMESTAMP NOT NULL
);

业务代码只传入 task_type，网关或 SDK 中间层根据策略生成 provider-specific request。

OpenAI 示例：记录 reasoning tokens 与 incomplete

OpenAI 文档提醒，如果生成 Token 达到 max_output_tokens 或上下文窗口限制，响应可能返回 status: "incomplete"，并且可能在没有任何可见输出前就已经消耗了输入和 reasoning tokens。因此生产代码必须显式处理 incomplete，而不是只判断 HTTP 200。

import OpenAI from "openai";

const openai = new OpenAI();

async function runReasoningTask(input: string) {
  const response = await openai.responses.create({
    model: "gpt-5.5",
    reasoning: { effort: "medium" },
    input,
    max_output_tokens: 4000,
  });

  const usage = response.usage;
  const reasoningTokens = usage?.output_tokens_details?.reasoning_tokens ?? 0;

  if (response.status === "incomplete") {
    return {
      ok: false,
      reason: response.incomplete_details?.reason,
      reasoningTokens,
      partialText: response.output_text ?? "",
    };
  }

  return {
    ok: true,
    text: response.output_text,
    inputTokens: usage?.input_tokens,
    outputTokens: usage?.output_tokens,
    reasoningTokens,
  };
}

Anthropic 示例：把 thinking 预算放在策略层

Anthropic 的 extended thinking 文档说明，budget_tokens 控制 Claude 可用于内部推理过程的最大 Token 数，并且必须小于 max_tokens。这类约束适合由平台层统一校验。

{
  "model": "claude-sonnet-4-6",
  "max_tokens": 16000,
  "thinking": {
    "type": "enabled",
    "budget_tokens": 10000,
    "display": "omitted"
  },
  "messages": [
    {
      "role": "user",
      "content": "Review this migration plan and identify blocking risks."
    }
  ]
}

对大多数业务系统，display: "omitted" 更合理：不把思考摘要暴露给最终用户，只把最终答案、证据和结构化判断结果写入业务链路。

Gemini 示例：把 thought token 纳入账单口径

Gemini thinking 文档说明，开启 thinking 后可在 usage 中读取 thought token 相关字段，并建议根据任务复杂度控制 thinking level。生产系统应把 total_thought_tokens 和普通 output tokens 分开记录。

{
  "task_id": "risk-review-20260703-001",
  "provider": "gemini",
  "model": "gemini-3.5-flash",
  "thinking_level": "low",
  "usage": {
    "input_tokens": 3280,
    "output_tokens": 420,
    "thought_tokens": 860
  },
  "latency_ms": 4810,
  "finish_status": "stop"
}

预算治理的关键指标

Reasoning Budget 上线后，至少要观察以下指标：

指标	含义与行动建议
`reasoning_token_ratio`	reasoning tokens / total generated tokens。比例过高说明大量预算花在内部推理上，需判断任务是否真的需要
`empty_visible_output_rate`	没有可见输出但产生了推理成本的比例。通常说明 `max_output_tokens` 过低、上下文过长或任务难度超过预算
`incomplete_rate_by_policy`	按策略分组统计 incomplete。某任务长期 incomplete，不能简单加大预算，应检查提示词、输入长度和任务拆分
`p95_latency_by_effort`	不同 effort 下的 P95 延迟。高 effort 不应混入实时低延迟链路
`cost_per_successful_task`	成功完成一个业务任务的总成本。高推理预算如果显著减少重试和人工复核，整体可能仍然划算

常见误区

误区一：只限制 visible output

只要求”回答不超过 200 字”并不等于成本低。推理模型可能先花大量内部 Token 做分析，再输出 200 字结论。生产上必须同时设置总生成上限、推理预算和超时。

误区二：所有复杂任务都开 high

高推理强度不一定带来等比例质量提升。很多任务的主要瓶颈是输入质量、规则定义、证据不足或输出格式不清，而不是推理预算不足。应先用离线样本测量不同 effort 的边际收益。

误区三：把 thought summary 当成可审计证据

思考摘要可以帮助调试，但不应直接作为法律、财务、医疗或合规审计证据。真正可审计的应是输入材料、引用片段、业务规则、模型最终输出、人工复核意见和版本信息。

误区四：超时后简单重试同一个 high 请求

如果 high effort 请求超时，直接重试可能只是重复烧钱。更好的策略是：缩短输入、降低 effort、拆分任务、转异步队列或进入人工复核。

误区五：跨模型比较不固定预算

比较 reasoning 模型时，如果一个模型允许 30k thinking tokens，另一个只允许 2k，就不能只比较最终准确率。需要固定任务、输入、输出格式、预算、超时和重试策略。

上线检查清单

策略与权限

是否定义了哪些任务允许启用 reasoning。
是否按用户等级、业务价值、风险等级设置不同预算。
是否禁止业务方绕过平台层直接传 high effort。
是否为高预算任务设置审批、配额或异步队列。

参数与回退

是否设置 max_output_tokens、max_completion_tokens 或等价上限。
是否为每种任务配置超时。
是否处理 incomplete、空输出和部分输出。
是否定义低 effort 重试、普通模型降级、任务拆分和人工复核策略。

可观测性

是否记录 input tokens、output tokens、reasoning tokens / thought tokens。
是否记录 effort、thinking_level、budget_tokens、模型版本和策略版本。
是否按任务类型统计成功率、超时率、人工复核率和单位成功成本。
是否能追踪一次业务任务内部的多次模型调用，而不是只看单次 API 调用。

质量验证

是否建立不同 budget 档位的离线回放集。
是否比较 low / medium / high 的边际收益。
是否验证复杂任务在低预算下的失败类型。
是否把”更贵的推理”与”更少的重试/人工复核”一起评估。

适用场景

Reasoning Budget 最适合以下生产场景：

多约束判断：合同、理赔、审计、财务分析等场景，需要模型跨多个条款、字段和上下文做推理。
技术推理：代码生成、代码审查、SQL 生成、迁移脚本分析等，需要模型在约束之间反复检查。
多步骤规划：Agent 规划、复杂工单排障、数据迁移方案拆解等，需要模型先决定步骤，再分派执行。
最终裁决：复杂文档抽取后，从多个抽取结果中判断冲突、缺失和风险等级。

不适合的场景也很明确：普通分类、模板化回复、短文本改写、大规模低价值批处理、严格低延迟入口，不应默认启用高推理预算。

总结

Reasoning Budget 的本质是对”模型内部思考”这一资源进行精细化治理。它不是一个开关或单个参数，而是一套覆盖任务分级、预算策略、平台适配、超时降级和可观测性的完整体系。好的预算策略让简单任务少思考、复杂任务充分思考、高风险任务可审计，最终在质量、延迟和成本之间找到可解释的平衡点。