Test-time Compute：推理预算、动态路由与早停系统设计

推理模型的“多想一会儿”会提高部分难题表现，也会放大 token、延迟和不确定性。生产系统不能对每个请求都开最大推理预算，而要把额外计算当作可度量、可中止、可验证的资源。

一、30 秒面试回答

我会把 test-time compute 设计成预算控制问题，而不是固定开启 reasoning mode。请求先经过能力与风险过滤，再用任务类型、规则置信度、检索充分性、初答验证结果和用户 SLA 估计难度；简单任务走低预算模型，复杂但可验证的任务才升级为更多采样、搜索、反思或更强模型。每个 run 有 token、时间、采样次数和工具步数上限；验证器提前确认结果时早停，预算耗尽则给出已验证部分、请求澄清或转人工。路由、预算、验证器版本和实际成本进入 trace，离线用质量-成本曲线证明额外计算的边际收益。

二、适用边界

适合增加推理预算	不适合盲目增加
可执行代码、数学、结构化抽取	无可靠事实来源的开放问答
有明确约束的规划与工具任务	高风险但不可验证的专业结论
可由检索证据或规则校验的 RAG	权限、审批和安全策略判断
多步骤故障定位	用户只需要快速简答

额外推理不能替代证据、权限和业务规则。验证器不可靠时，更多采样可能只是更自信地重复错误。

三、预算控制面

request -> policy/capability filter -> difficulty estimate
        -> budget tier (S/M/L) -> solve/verify loop -> early stop
        -> answer, abstain, clarify, or escalate

预算至少包含输入/输出 token、wall-clock、采样数、搜索深度、工具调用和金额。按租户、场景和风险定义硬上限；不要让模型自行决定无限反思。高优先级交互式任务保留 TTFT/时延预算，离线任务才适合更大搜索空间。

3.1 预算账本与分层配额

并发 fan-out 需要先预留、后结算：请求预算防止单次失控，会话预算限制多轮累计，租户预算限制公平使用，全局池保护平台容量。每个分支启动前根据预计 token、verifier、Judge、工具和重试成本 reserve；运行中按实际 usage settle，取消或失败后释放未使用额度。预算燃尽时按优先级排队、异步化、降级或拒绝，不能让多个分支同时超支后才发现账单异常。

四、动态路由与早停

难度信号可来自规则、问题长度/结构、检索空召回、初答验证失败、历史同类成功率和用户选择的精度模式。路由应保守：低置信难度判断可先走小预算并验证，而不是直接消耗最大算力。

早停条件包括：执行测试通过、多个独立候选收敛、证据已充分、收益低于阈值、时间/成本预算耗尽或出现安全/权限阻断。任何工具副作用仍由外部审批和幂等执行器控制。

4.1 增量价值路由与安全早停

路由器不只选 S/M/L，而是在“更强模型、提高 effort、增加 K、加入 verifier、搜索、澄清、转异步或人工”中选择预计净收益最高的下一步，并受 SLA、风险和预算硬约束。离线评估完整路由策略，线上保留小比例 shadow 流量校准难度与收益预测，避免困难样本总被升级造成选择偏差。

早停分为：确定性停止（测试/schema/证据通过）、统计停止（候选在固定最大样本下不可反超且样本独立性可信）、经济停止（下一轮预期收益低于成本）和执行停止（取消未完成分支、记录 partial result）。有副作用的工具不能依靠取消“回滚现实”，仍需审批、幂等和补偿。

五、评测与成本门禁

比较 baseline、不同预算 tier 和不同验证器时固定任务集、模型版本、工具和随机种子。按任务难度、可验证性、语言和租户切片报告任务成功、验证通过率、P95 延迟、token、每成功任务成本和早停比例。只有在独立 holdout 上存在稳定边际收益的 tier 才进入线上路由；不能因为少数竞赛题提升就对所有用户加预算。

5.1 Verifier 与双层成本门禁

Verifier 也是受治理的预算参与者：按任务切片维护误放/误杀、置信度校准、耗时和单次成本；验证器不可靠或证据不足时，不自动扩大搜索，应改为引用证据、澄清或人工复核。

发布门禁看关键切片质量不退化、增量质量/增量成本、每成功任务成本和 P95/P99 成本的置信区间。运行时另设熔断：预测与实际成本偏差、fallback storm、verifier 失败率或预算燃尽速度异常时，暂停某个 tier、转异步或限流；禁止静默把高风险任务降到能力不等价模型。

六、高频问答

Q：什么时候该用更强推理模型？

当任务复杂且能验证、用户价值覆盖额外成本、SLA 允许时。先用轻量路由或初答验证收集信号，再升级；不能把模型规模当作权限或事实正确性的替代品。

Q：怎样防止推理成本失控？

为每个 run 设置 token、时间、采样、工具步数和金额预算；按租户限额；验证成功即早停；追踪每个 tier 的质量-成本曲线，并对循环、重试和异常长输出告警。

Q：多次采样取多数票可靠吗？

只在候选相对独立且有可靠验证/聚合规则时有意义。相同模型和 Prompt 的错误往往高度相关；多数票不能解决缺证据、权限或系统性偏见问题。

七、项目讲法模板

我们将 reasoning compute 做成动态预算控制面：按任务可验证性、检索充分性和初答验证结果选择预算 tier，并在 token、时延、采样与工具调用上设硬上限。代码和结构化任务用执行/规则验证提前早停，证据不足则澄清或转人工。上线前用固定 holdout 比较质量、延迟和每成功任务成本，线上 trace 记录路由与预算，因此把“多想”限制在真正有边际收益的场景。

继续学习：Test-time Scaling、推理成本与性能优化、LLM 推理容量与弹性伸缩设计、LLM-as-a-Judge 校准与发布门禁。