在 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 决定你等多久看到第一个字（TTFT，time-to-first-token），Decode 决定后面的字流得多快（OTPS，output tokens per second）。
Decode 慢在哪：它卡的是显存带宽，不是算力
这是整件事最反直觉的一环。
每生成一个 token，GPU 都要把整套模型权重从 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-bound，Fast 帮不上什么忙）
- 后台或自主运行的任务，反正没人盯着
- 批处理作业和 CI（本来也用不了）
关键的坑之二：别在会话中途打开
这个坑最贵，而且不容易想到。
Fast 和标准档各自维护独立的 prompt cache。
你一切换，那份已经预热好的标准档缓存对 Fast 路径就完全无用了------整段对话前缀会被当成一次 cache write 重新处理，按 Fast 的费率计价，而且这发生在 Claude 写出第一个 token 之前。
切得越晚，一次性代价越大：
| 切换时的上下文量 | 重新计费（Opus 4.8） | 重新计费（Opus 4.7） |
|---|---|---|
| 50K tokens | $0.62 | $1.88 |
| 100K tokens | $1.25 | $3.75 |
| 200K tokens | $2.50 | $7.50 |
| 260K（实测） | $3.26 | $9.77 |
原文作者实测了最后一行：在一个 260K token 的会话里敲 /fast，260,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 能省那么多钱，底下都是同一套物理。