如何给一次 LLM 工作流设置可执行的 Token 与费用预算？

简化版

请求级预算不是统计完账单再告警，而是在调用前预估、执行中扣减、结束后结算。根请求创建共享预算信封，包含输入/输出 Token、模型调用、工具费用、步骤数和总 Deadline；RAG、Agent 子任务、重试与 Fallback 都从同一信封消费，不能各自重新获得满额。

准入前为已知输入和最大输出预留额度，超预算时按业务策略缩小低价值上下文、换兼容模型、请求用户确认或拒绝。运行中接近软阈值就停止扩展计划并安全收尾，硬阈值禁止新副作用。llm-cost-control 讨论平台级 FinOps，本题强调单次工作流怎样把预算真正执行起来。

详细版

预算对象至少记录币种、价格表版本、剩余 Token/金额/步骤/时间和已预留未结算费用。每次模型或工具调用先 reserve，完成后按实际用量 commit 并返还差额；失败重试也计费，取消则结算已发生部分。

root budget envelope
  -> reserve(model call)
  -> reserve(tool call)
  -> child task gets bounded sub-budget
  -> commit actual usage / release unused reservation

预算决策与质量边界绑定：系统规则、权限信息和关键证据不可为省钱静默裁掉；高风险校验也不能绕过。日志要关联 root_budget_id、估算/实际误差、终止原因和最终任务成功，才能判断预算是否既控住尾部又没有制造更多失败返工。

完整版教学

平台成本账本回答“钱花到哪了”，请求预算闸门回答“这次任务最多还能做什么”。

一、为什么事后统计不等于预算控制

Agent 可能循环调用模型，Fallback 可能重复整段上下文，工具还可能按次收费。若只在日终看总账，单个异常请求已经造成费用和副作用。

预算必须参与准入和每一步决策。它像资源事务：先预留最坏可接受成本，结束后按实际结算，不能等余额为负才停止。

二、预算信封包含哪些维度

只限制 Token 会漏掉付费搜索、代码沙箱和人工审核；只限制金额又可能忽略 Deadline 与上下文硬上限。常见维度如下：

维度	示例上限	防止的问题
输入 Token	20,000	上下文膨胀
输出 Token	3,000	长生成失控
模型调用	6 次	重试/反思循环
工具费用	2 元	外部 API 超支
步骤/墙钟	10 步/60 秒	Agent 不终止

各维度同时生效，不能把剩余 Token 换成无限工具调用。

三、调用前怎样预估和预留

模型调用的输入 Token 可精确计数，输出未知，可按任务上限或条件分位预留。费用估算使用即将生效的模型与价格表版本：

reserved_cost = input_tokens × input_price
              + max_output_tokens × output_price
              + fixed_tool_reservations

若余额不足，可减少非关键候选、选择经验证的低价模型或拒绝。不能先执行后假设用户会补额度。

四、为什么要先预留再结算

十个并发子任务若都只检查当前余额，可能同时认为钱够并共同超支。原子预留把未来最大消费锁定，完成后再释放未用部分。

例如余额 1 元，两个子任务各最坏 0.7 元，只能有一个先获得预留；若其实际花 0.3 元，返还 0.4 后另一个才可能运行。分布式实现要用幂等 reservation_id 防止重试重复扣款。

五、子任务预算怎样分配

根工作流可把有限子预算授予规划、检索、生成和验证步骤。子任务不得突破父预算，也不能继续无限创建孙任务规避限制。

parent.remaining >= child.limit
sum(active_child_reservations) <= parent.remaining

并行分支的额度应在启动前全部预留；串行分支可按结果逐步释放。高价值验证步骤要预先留份额，避免生成阶段把预算吃光后无钱验收。

六、重试与 Fallback 怎样计入

每次已发出的模型调用都可能产生费用，即使超时或结果无效。重试从根预算继续扣减，并同时服从总 Deadline；不能让 SDK、网关和 Agent 各有独立三次重试。

Fallback 的预计额外费用应进入决策：廉价主模型失败概率高，可能比一次强模型更贵。应比较期望成本与成功率，而不是只看首跳单价。

七、接近预算时如何安全收尾

软阈值用于改变计划，例如停止继续搜索、减少候选数量、选择已有证据生成简要结果。硬阈值禁止启动新调用或新副作用，但允许必要的状态查询与补偿按预留额度完成。

如果任务无法在剩余额度内满足最低质量，应明确返回部分完成和缺口，而不是静默删掉引用或安全检查。不可逆动作开始前必须确认其执行与状态确认都有预算。

八、Token 预算怎样装配上下文

先扣系统规则、当前问题、输出预留和协议余量，再给历史、检索与工具 Schema 分区。低相关证据、未用工具和重复历史先淘汰；硬约束与授权上下文不可丢。

假设窗口 16K，输出预留 2K，固定指令/问题 3K，余量 0.5K，则可变上下文最多 10.5K。预算器应基于目标 Tokenizer 计数，不用字符数粗暴截断。

九、预算失败如何对用户表达

区分客户配额不足、平台容量过载、工作流估算超预算和执行中耗尽。API 返回稳定原因码、可重试时间和已完成范围，避免客户端对确定性超预算无限重试。

高价值任务可先向用户展示成本/时间估算并请求扩大授权。扩大额度必须绑定当前任务与有效期，不能变成永久无限预算。

十、怎样观测与校准估算器

记录预算初值、每次预留/结算、价格版本、估算与实际差、未用返还、终止原因、任务成功和人工接管。按任务、模型和输出长度分桶分析误差。

若 P95 实际输出 800 token，却一直预留 4,000，会不必要地拒绝并发任务；若经常低估，则会执行中途耗尽。通过真实分布校准，但高风险副作用仍应使用保守上界。

十一、常见误区与追问

• 误区：设置 max_tokens 就完成成本控制。 还存在输入、重试、工具、步骤和人工成本。
• 误区：每个 Agent 子任务可独立拿一份预算。 子任务必须共享根信封，否则并发会放大支出。
• 误区：超时调用没有返回，所以不计费。 上游可能已经执行并产生用量，需按实际结算。
• 误区：预算不足时先删安全检查。 质量和安全下限是硬约束，不是可选开销。
• 误区：余额检查与扣减分开也没关系。 并发请求会共同超卖，必须原子预留。
• 追问：输出未知怎样估算？ 按任务上限或经校准分位预留，结束后返还差额。
• 追问：何时允许用户加预算？ 在执行高成本步骤前展示范围，并将授权绑定任务、金额与有效期。

十二、加强记忆

请求预算记“根信封、先预留、后结算、子任务不增发”。同时限制 Token、金额、步骤、工具和 Deadline；重试与 Fallback 都消费同一预算。软阈值调整计划，硬阈值停止新动作，但必须为验证和补偿预留资源。最终以估算误差、超预算率和每次成功任务成本共同验收。