推理时扩展：另一种 Scaling 的工程账单
过去两年，”Scaling Law 是否失效”的讨论反复出现。支持者说模型能力还在上升，质疑者说边际效益在递减。但争论的焦点已经悄悄从训练时计算转移到了推理时计算。
o1 是这个转变的公开标志。它的核心逻辑是：与其在训练时堆更多 token，不如在推理时给模型更多”思考时间”。这个逻辑在 2025 年被反复验证和复现——DeepSeek-R1、Gemini 2.0 Flash Thinking、Claude 的 extended thinking 模式，都是同一套思路下的不同实现。
这篇文章不打算讨论”推理时扩展是否代表 Scaling 的第二章”这类命题。那是研究视角的问题。从工程角度来看，它带来了一批具体的、已经在生产里遇到的问题。
它实际上是什么
推理时扩展（Test-Time Compute Scaling）的核心是：在推理阶段投入更多计算，让模型产出质量更高的答案。
主要有三种实现路径：
Chain-of-Thought 和 Extended Thinking：模型在给出最终答案前，先生成大量中间推理步骤。这些”思维链”在某些实现里对用户可见，某些实现里是内部隐藏的。计算成本随生成 token 数线性增加。
Best-of-N 采样：对同一问题并行生成多个答案，通过另一个模型、规则或投票机制选出最优解。成本也是线性的，但并行度不同。
树状搜索：在推理过程中维护一棵搜索树，动态决定哪些分支值得继续展开。成本可以是超线性的，上限更难控制。
o1 类模型用的是第一种和第三种的混合。用户看到的”thinking”部分，是模型内部搜索过程的一个外露投影。
KV Cache 的压力
这个范式转变对推理服务基础设施最直接的冲击，是序列长度分布的变化。
传统语言模型推理，输入+输出的总 token 数通常在几百到几千范围内。推理时扩展的场景里，一次请求的 thinking token 可能就有几万到十几万。
这对 KV Cache 的压力是量级上的变化。现有的 KV Cache 管理策略——PagedAttention 是典型实现——在设计时的主要考量是并发请求的内存利用率。当单个请求的序列长度从 4K 扩展到 128K，同样显存能支撑的并发数就急剧下降。
Prefill 阶段的计算量也随之暴增。长序列的 Prefill 是 O(n²) 的注意力计算，而 Decode 阶段是 O(n) 的。当 thinking 产生的序列很长时，整个请求在 Prefill 上消耗的 GPU 时间大幅上升，影响其他请求的排队延迟。
vLLM 和 SGLang 这两年都在应对这个问题：chunk prefill、prefix caching、KV Cache 压缩。但这些优化的前提是流量特征相对稳定可预期。如果你的服务混合了普通请求和 extended thinking 请求，调度策略会变得相当复杂——两种请求的资源占用特性差异太大，单一的静态策略很难兼顾。
延迟的性质变了
普通推理的延迟模型相对简单：TTFT（首 token 时间）加上解码速度。用户对体验的感知，和 token 生成速度强相关。
推理时扩展的场景里，thinking 阶段可能持续几十秒甚至几分钟。这段时间如果用户看不到任何反馈，体验是灾难性的。所以几乎所有推理时扩展的产品实现，都需要某种流式输出——把 thinking 过程实时流给用户，让等待时间变得”可见”和”可理解”。
这要求基础设施层有完整的流式支持，从模型服务到 API 网关再到前端，任何一层的缓冲都会破坏体验。对于已有的推理服务平台，这不是一个小的改动——很多系统在设计时没有把”一次请求持续几分钟”纳入考量。
超时配置、连接保活、流式反压（backpressure）处理，这些细节在普通推理里不是问题，在 extended thinking 场景里都需要重新审查。
成本模型的直觉失效
传统推理的成本估算相对直观：token 数乘以单价，再做一个请求量的预测，账单大概能算清楚。
推理时扩展的问题在于：thinking token 的数量是不受调用方控制的。用户发一个问题，模型自己决定”想多久”。对于同一个问题，不同的采样结果可能产生差异悬殊的 thinking token 数。
这让基于请求的成本预算变得困难。P90 和 P99 的成本会比 P50 高出几倍，极端情况下高出一个数量级。如果你的服务是 B2B 场景，给下游客户做成本估算或者承诺 API 账单上限，这是一个新引入的变量。
有些模型支持设置 thinking budget——限制模型最多能”想”多少 token。这个机制能控制上限，但并不保证质量：被截断的推理链，有时会产生比没有 thinking 更差的结果，因为模型在一个不完整的推理基础上强行给出了答案。
什么任务适合，什么任务不适合
推理时扩展在特定类型的任务上效果显著，在另一些任务上收益有限。
有明确正确答案的任务（数学推导、代码生成、逻辑推理、形式化验证）受益最大。”想更久”的过程有清晰的评价标准，搜索策略也有明确的终止条件。
开放式生成任务的收益更模糊。写一篇文章”想更久”不一定更好，有时候反而引入更多的犹豫和自我修正，输出反而变得臃肿。这类任务里，改进上下文工程通常比增加推理预算更有效。
一个值得关注的模式是：推理时扩展对困难任务的提升，远大于对简单任务的提升。这意味着在生产里一刀切地给所有请求开 extended thinking，是在浪费资源——合理的做法是做任务难度路由，只在判断为高复杂度的请求上投入更多推理预算。
但任务难度的自动判断本身就是一个工程问题，轻量但准确的分类器不好做。这是一个新开放的设计空间。
可重复性的问题
extended thinking 的输出不是确定性的，同一问题两次运行可能走完全不同的推理路径，最终给出不同的答案。
这在研究场景里不是大问题——多次采样取最优本来就是标准做法。但在生产场景里，如果你需要一致性——比如文档处理流水线、合规判断、规则解释——这是一个需要正视的风险。
Temperature 设为 0 能降低但消除不了这个不确定性，因为 extended thinking 的搜索过程在部分实现里是内在随机的。
评估也变得更复杂。传统模型的能力评估相对标准化——跑几个 benchmark，看平均分。推理时扩展的模型，因为每次运行结果可能不同，benchmark 的方差更大，结论需要更多次重复运行才能稳定，评估成本随之上升。
这给基础设施提了什么要求
总结下来，推理时扩展让 AI 系统的计算行为变得更动态、更难预测：
- 单个请求的资源占用从相对稳定变成宽幅波动
- 请求延迟从秒级变成分钟级成为正常情况
- 成本的 P99 和均值之间的差距大幅扩大
- 并发模型需要应对大小差异悬殊的请求混合流量
这些对推理服务平台提出的要求，和之前”预估 token 数、配资源、跑推理”的相对静态模型有本质区别。
如何在动态计算预算下仍然提供稳定的 SLA，如何在混合流量下做公平的资源调度，如何设计成本可控的 thinking budget 策略而不大幅损失质量——这大概是推理服务工程接下来的几个核心命题，答案还在形成中。
推理时扩展不是银弹，但它确实把一类此前无法解决的问题变得可解了。账单是真实的，能力也是真实的。工程决策需要两者都看清楚。