Fast 模式为什么更快也更贵：从 Prefill/Decode 到 Batch 经济学

在 Claude Code 里敲一下/fast输出速度大约提升 2.5 倍价格变成 2 到 6 倍。OpenAI 那边也有对应的 Fast 档位逻辑一样。第一反应容易想歪是不是切到了一个更小、更快、但更笨的模型不是。Anthropic 的说法很直接——Fast mode is not a different model。同一份权重同样的智力同样的采样逻辑它给出的答案就是它本来会给出的答案。唯一变的是 token 吐出来的速度以及你为此付的钱。而这两件事之所以绑在一起得从「模型是怎么生成一个回答的」讲起。一次生成的两个阶段任何一次 LLM 响应都分成两个阶段物理特性完全不同。Prefill提示处理把你发过去的所有东西——这轮消息、读进上下文的文件、整段对话历史、系统提示——做一次前向传播。所有输入 token 可以并行推进这一步相对快而且规模化得不错。Decode逐 token 生成自回归地一个 token 一个 token 往外吐每个新 token 都要以前面所有 token 为条件。它是严格串行的而且几乎所有的等待时间都花在这里。一句话概括Prefill 决定你等多久看到第一个字TTFTtime-to-first-tokenDecode 决定后面的字流得多快OTPSoutput tokens per second。Decode 慢在哪它卡的是显存带宽不是算力这是整件事最反直觉的一环。每生成一个 tokenGPU 都要把整套模型权重从 HBM高带宽显存搬到计算单元里过一遍算完这一个 token下一个 token 再搬一遍。对一个前沿规模的模型来说这是每个 token 搬动几百 GB 的量级。而单个 token 需要的算术运算量跟搬这些权重的开销比起来微不足道。于是 Decode 阶段的真实画面是GPU 的计算单元大部分时间在空转等数据。这个阶段是 memory-bandwidth-bound显存带宽受限不是 compute-bound算力受限。Prefill 恰好相反——它用一次权重加载把你成千上万个输入 token 一起推过去把 FLOPs 吃得很满。Decode 时那段闲置的算力就是所有推理服务商赖以生存的那块余量。解法批处理Batching一条序列喂不饱 GPU。所以服务商的做法是把很多用户的请求塞进同一次前向传播——权重只加载一次同时作用在几十条序列上。这就是连续批处理continuous batching。最贵的那部分开销搬权重被整个 batch 摊薄了。这就是前沿模型能被负担得起的全部经济学batch 越大 → 一次权重加载服务的 token 越多 → 系统总吞吐越高 → 单 token 成本越低但批处理是拿延迟换吞吐。你的 token 是按整个 batch 共享的节奏挤出来的而且 batch 越大每一步要 attend 的序列越多、要搬的内存越多任何单个用户感受到的速度就越慢。标准档的 Opus 跑的是大 batch便宜、高吞吐、对你个人来说慢。Fast 模式做了什么反向操作就这么简单把你的请求放进一个小得多的 batch很可能还落在预留容量reserved capacity或更高优先级的推理路径上。每次前向传播里分摊权重加载的序列少了你的序列每一步能拿到更多的 GPU 时间和带宽OTPS 最高提升约 2.5 倍。成本是同一根杠杆的另一头。那次权重加载现在只由少数几条序列分摊所以你在每个 GPU-second 里占的份额陡然上升。注意你买的不是「更多的计算」——生成出来的 token 跟标准档一模一样。你买的是一块更少人共享的 GPU 切片。这就是溢价的来源Opus 4.8 上 2×4.7 上 6×。标准模式Fast 模式模型权重同一份同一份答案质量—不变Batch 大小大小 / 预留容量OTPS输出速度基准最高 ~2.5×TTFT首字延迟基准基本不变单 token 价格基准2×4.8/ 6×4.7需要说清楚的是2.5× 是 Anthropic 自己给的数字不是第三方独立测量的「更小 batch」是最符合实测特征OTPS 上升、TTFT 持平的机制推断Anthropic 没有公开确认内部实现。关键的坑之一它让你更早结束不是更早开始Fast 模式加速的是 Decode。它完全不碰 Prefill所以第一个 token 出来之前的那段等待TTFT没有变化。缩小 batch 让解码变快首字延迟原地不动。推论很直接只有输出量大的时候 Fast 才有意义。短回复两种模式几乎同时结束你付了 2~6 倍的钱省下一个眨眼的时间长生成Fast 明显拉开差距输出越长溢价买到的时间越多什么时候开什么时候别开建议开Decode 占主导的长输出——大规模重构、脚手架生成、动辄几千 token 的产出你人在旁边盯着等结果你自己的时间是更贵的那个成本项有时间盒的活儿早完成能换成真金白银建议关短交互——提问、确认、一行回答这些是 TTFT-boundFast 帮不上什么忙后台或自主运行的任务反正没人盯着批处理作业和 CI本来也用不了关键的坑之二别在会话中途打开这个坑最贵而且不容易想到。Fast 和标准档各自维护独立的 prompt cache。你一切换那份已经预热好的标准档缓存对 Fast 路径就完全无用了——整段对话前缀会被当成一次 cache write 重新处理按 Fast 的费率计价而且这发生在 Claude 写出第一个 token 之前。切得越晚一次性代价越大切换时的上下文量重新计费Opus 4.8重新计费Opus 4.750K tokens$0.62$1.88100K tokens$1.25$3.75200K tokens$2.50$7.50260K实测$3.26$9.77原文作者实测了最后一行在一个 260K token 的会话里敲/fast260,591 个 token 被作为 Fast 费率的 cache write 重新计费在产出任何有用内容之前先付掉约 $3.15 的一次性溢价。正确做法在会话开始时就决定要不要开 Fast而不是在第 80 轮。好消息是关掉再开不会重复扣这笔钱——Fast 那份缓存已经建好了。几个边角情况订阅制下Fast 模式只从 usage credits 扣从第一个 token 起就按 Fast 费率计撞到 Fast 的速率限制它会静默回落到标准速度和标准价格Fast 模式目前是 research preview定价和可用性都可能变小结Fast 模式的本质用一句话说完同一个模型跑在一块更少人共享的 GPU 切片上。「更快」和「更贵」不是两个独立的事实是同一个事实的两种表述——你没有买到更多的计算你买到的是更少的共享。所以它的适用判断也很清晰看输出长度。输出短Fast 的收益被 TTFT 吃掉了看有没有人在等。没人等就没有值得用钱买的时间看什么时候开。会话开头开别在中途开顺带一个更通用的收获理解 Prefill/Decode 的分野和显存带宽瓶颈能解释的不止 Fast 模式——为什么长上下文的首字延迟高、为什么流式输出的速度会随负载波动、为什么 prompt caching 能省那么多钱底下都是同一套物理。参考How Claude Code Fast Mode Works