一、第 19 讲的账单

第 19 讲讲了一件好事：让模型在回答前多写一些中间步骤，或者多生成几个答案再挑，结果会更好。那一讲的结尾说：“对一个简单问题也写上几千字推理，就是纯粹的浪费。这笔账第 24 讲会详细算。”

这一讲就来算。算账需要一套统一的数字，沿用第 22 讲的示意参数：

模型权重：                14 GB
显存读取速度：            1 TB/秒
每个 token 的 KV Cache：  0.5 MB

第 22 讲由此得出：解码阶段受内存带宽限制，每生成一个 token 都要把 14 GB 权重读一遍，约 14 毫秒；上下文越长，还要多读一份越来越大的缓存（第 23 讲）。这些数字只是示意，真实系统会因硬件和模型而不同，但它们之间的比例关系是可靠的，这一讲关心的正是比例。

同一个问题（输入 100 个 token），三种回答方式：

  • A 直接回答：生成 200 个 token 的回答。
  • B 先推理再回答：先写 4000 个 token 的推理过程，再写 200 个 token 的回答，共 4200 个。
  • C 并行采样再投票：像 A 一样回答，但同时独立生成 8 份，取多数（第 19 讲）。

二、打个比方：请工人干活

一项工作，有两种加大投入的方式：

请 8 个工人同时干一天：花 8 倍的工钱，一天就完工。

请 1 个工人连续干 21 天：花 21 倍的工钱，还要等 21 天。

还有一笔容易漏掉的开销：工位。每个工人干活期间都要占一个工位，而且活干得越久，他堆在工位上的材料越多，占的地方越大。一个干了 21 天的工人，最后几天占的地方，比第一天大得多。

C 是第一种，B 是第二种，而"工位"就是 KV Cache。

三、手算三本账

等多久

每生成一个 token，要读一遍 14 GB 权重，加上当前上下文长度对应的缓存。把每一步的时间加起来：

方式 生成的 token 用户等待时间 相对 A
A 直接回答 200 约 2.8 秒 1 倍
B 先推理再回答 4,200 约 63 秒 约 22 倍
C 并行 8 份 1,600（8 × 200） 约 3.0 秒 约 1.05 倍

B 比 token 数的 21 倍还多出一点，是因为推理越写越长，后面每一步要读的缓存越来越大（第 23 讲的第二堵墙）。

⭐ C 生成的 token 是 A 的 8 倍，等待时间却几乎一样。原因是第 22 讲讲的批处理：8 份答案互相独立，可以作为一批同时生成。每一步读一遍权重，8 份各得到一个 token。解码受内存带宽限制时，读权重才是主要开销，同一批里多算几份几乎不额外花时间。

B 没有这个便宜可占：第 4000 个推理 token 依赖第 3999 个，必须一个接一个地生成，这是第 13 讲"推理串行"最直接的代价。

花多少钱

服务商通常按 token 计费（第 7 讲），背后的实际成本大致跟生成的 token 数成正比，上下文越长的 token 还更贵一些：

方式 生成的 token 相对 A
A 200 1 倍
B 4,200 21 倍
C 1,600 8 倍

⭐ 合起来看就是二节那个比方：并行花钱不花时间，串行既花钱又花时间。

C 还有一个可以省的地方：8 份答案的输入完全相同，那 100 个 token 的预填充只需要做一次，算出的 KV Cache 可以让 8 份共用。

占多少服务器

第 22 讲说过：一台机器能同时服务多少人，取决于显存里放得下多少份 KV Cache。所以一个请求对服务器容量的真正占用，不只是它占了多少显存，还要乘上占了多久：

容量占用 = 每一刻占的缓存大小，在整个生成时间里累加起来（单位：GB·秒）
方式 缓存最大时 持续时间 容量占用 相对 A
A 约 0.15 GB 2.8 秒 约 0.28 GB·秒 1 倍
B 约 2.1 GB 63 秒 约 69 GB·秒 约 250 倍
C 8 份共约 1.2 GB 3.0 秒 约 2.3 GB·秒 约 8 倍

⭐⭐ B 的 token 数只是 A 的 21 倍，占用的服务器容量却是 A 的约 250 倍。 原因是两个"随长度增长"乘在了一起：推理写得越长，缓存越大（工位上的材料越堆越多）；推理写得越长，占用的时间也越长（工人干得越久）。一个大小随长度增长，一个时长随长度增长，两者相乘，容量占用随推理长度近似平方增长。

这就是推理模式真正昂贵的地方：它不只是让一个用户多等、多付钱，还挤占了原本可以同时服务几十、上百个普通请求的位置。

首个 token 的等待

用户对等待的感受，不只取决于总时间，还取决于多久看到第一个字。

A 的第一个回答字几乎立刻出现，之后以每秒约 70 个 token 的速度往外流。B 在写完 4000 个推理 token 之前，一个回答字都给不出来——用户要先干等将近一分钟。这就是为什么推理类产品常常把推理过程（或者它的摘要）实时展示出来：总时间没有变短，但用户知道系统在工作。

⚠️ 关于时效性：有一类技术专门针对"解码只能一个一个来"这件事。它的思路是：先用一个小得多、快得多的模型连续猜出后面几个 token，再让大模型一次前向传播同时检查这几个猜测（这一步可以像预填充一样并行），猜对的直接收下，从第一个猜错的地方重新开始。因为解码受带宽限制，大模型一次检查几个 token 和生成一个 token 的耗时差不多，猜对得越多，就越快。这类方法通常称为投机解码（speculative decoding），具体实现还在快速演进，但它利用的正是第 22 讲的那个事实：解码阶段，计算单元大部分时间在空等。

四、这笔钱什么时候值得花

简单题和难题

同样的投入，放在不同的问题上，回报完全不同。用一组示意的正确率：

直接回答 A 先推理 B B 多花
简单题 98% 99% 21 倍 token、250 倍容量，换 1 个百分点
难题 10% 70% 同样的代价，换 60 个百分点

⭐ 同一笔开销，在难题上是必须花的钱，在简单题上几乎是纯浪费。问题不在于要不要多想，而在于在哪道题上多想。

并行采样：投票和验证不一样

难题上，能不能用更便宜的 C 代替 B？这取决于怎么从 8 个答案里挑。

多数投票：第 19 讲算过，它只在单次正确率高于一半时才有帮助。难题的单次正确率是 10%，生成 5 个取多数，正确率会降到约 0.9%——投票放大的是模型本来的倾向，而它本来的倾向是错的。

有验证器：如果答案能被程序检查（第 19 讲的数学题、编程题），就不需要多数正确，只要 8 个里有一个对，验证器就能把它挑出来：

8 个全错的概率 = 0.9⁸ ≈ 0.43
至少一个对的概率 = 1 − 0.43 ≈ 57%

从 10% 提升到 57%，只花 8 倍的钱、几乎不多等。⭐ 并行采样在难题上有没有用，取决于有没有一个可靠的验证器——这和第 19 讲 RLVR 依赖验证程序是同一件事的两面。

按难度分配

既然回报取决于题目难度，最合理的做法就是先判断难度，再决定花多少：简单问题直接回答；难题允许长推理；能验证的难题，考虑并行多试几次。

⚠️ 关于时效性：实际产品里已经出现了各种形式的"思考预算"：让用户或系统选择推理的力度，或者由一个小模型先判断问题难度、再决定交给快速模式还是推理模式，以及在推理过程中发现答案已经收敛时提前结束。具体做法各家不同，还在演变；但它们回答的都是这一节的问题——测试时计算应该花在哪里。

五、第 15 讲留下的账：训练最优不是部署最优

第 15 讲的 Scaling Laws 回答的问题是：“给定训练的计算预算，模型该多大、数据该多少，才能让训练损失最低。“那一讲结尾提醒过：这个最优没有把部署之后的推理成本算进去。

现在可以把两笔账放在一起。一个模型的总成本大致是：

总成本 = 训练成本（只付一次） + 每个 token 的推理成本 × 这个模型一生要生成的 token 总数

用一组示意数字比较两个训练到同样效果的模型：

  • 大模型：按第 15 讲的最优配比训练，训练成本 100；每生成一单位 token 花 2。
  • 小模型：参数少一半，但用多得多的数据训练更久才达到同样效果，训练成本 150；因为参数少，每生成一单位 token 只花 1。
大模型总成本 = 100 + 2 × 用量
小模型总成本 = 150 + 1 × 用量

用量 = 50 时，两者相等（都是 200）
用量超过 50，小模型更省；用量越大，省得越多

⭐ 一个要服务海量请求的模型，推理成本很快就会超过训练成本。所以实践中常常故意偏离第 15 讲的"训练最优”：把模型做小一点，用远超最优配比的数据训练得更久，多花一次性的训练成本，换来此后每一次推理都更便宜。

另一个常见的做法，是用一个大模型生成大量高质量的回答，再拿这些回答去训练一个小模型，让小模型学会大模型的行为，这叫蒸馏（distillation）。它就是第 14 讲讲的合成数据的一种具体用法，也带着那一讲讲过的风险。

这也回答了第 13 讲思考题 4 留下的问题：训练的开销只付一次，推理的开销随请求次数不断累积，而每一次推理的耗时又随生成长度增长——对序列长度更敏感、并且要一直付下去的，是推理。

六、代价与局限

⚠️ 这一讲的数字是示意的。真实系统有批处理调度、投机解码、缓存共享、不同的硬件，绝对数字会差很多。但几个比例结论是稳的：串行推理的延迟随长度线性增长；容量占用随推理长度近似平方增长；并行采样主要花钱和显存，不太花时间。

⚠️ 更准确不一定更有用。对用户来说，一个 3 秒内给出、正确率 90% 的回答，和一个 60 秒后给出、正确率 95% 的回答，哪个更好，取决于场景。聊天时用户可能等不了一分钟；写一份要交给客户的分析报告，多等一分钟完全值得。

⚠️ 判断难度本身也会出错。按难度分配算力，前提是能在回答之前判断出难度。一道看起来简单、其实暗藏陷阱的题，被分到了快速模式，就会以很快的速度得到一个错误答案。

⚠️ 算力之外还有别的代价。服务器容量、电力、用户等待的时间，都是真实的开销。第 19 讲描述的"模型自发地为难题写更长的推理”，在这一讲的视角下，也意味着模型自己在决定花掉多少资源——而它在训练时，并没有为此付过任何代价。

七、和后面课程的关系

Unit 6 到这里结束。四讲合起来回答了"模型训练好之后，怎么把它跑起来"：第 21 讲怎么挑词，第 22 讲怎么省掉重复计算、怎么让模型变小、怎么同时服务很多人，第 23 讲为什么长上下文难，这一讲这些选择各要付多少代价。

  • 第 25 讲（RAG）：检索回来的文档会被塞进输入，增加的是预填充的 token。预填充是并行的，每个 token 比解码便宜得多，但它会让之后每一个解码步骤要读的缓存变大（第 23 讲）。
  • 第 28 讲（多步推理与规划）：一个 Agent 完成一项任务，可能要连续调用模型十几次、几十次，每一次都付这一讲算的全部代价，而且上下文一次比一次长。

八、本讲小结

  • 沿用第 22 讲的示意参数，对同一个问题手算三种方式：直接回答 200 个 token；先推理 4000 个 token 再回答；并行生成 8 份再投票。
  • 延迟：直接回答约 2.8 秒，先推理约 63 秒（约 22 倍），并行 8 份约 3.0 秒——批处理让并行几乎不多等。并行花钱不花时间，串行既花钱又花时间。
  • ⭐⭐ 容量占用：推理模式 token 数是直接回答的 21 倍，占用的服务器容量（缓存大小 × 占用时间）却是约 250 倍，因为两者都随推理长度增长，相乘后近似平方增长。
  • 首个 token：推理模式要写完全部推理才能开始回答，用户要先等将近一分钟。
  • ⭐ 值不值：同样的开销，在简单题上换 1 个百分点，在难题上换 60 个百分点。多数投票只在单次正确率超过一半时有用（难题上会从 10% 降到约 0.9%）；有验证器时，只要有一个对就行，8 次采样把 10% 提到约 57%。
  • ⭐ 训练最优不是部署最优：总成本 = 训练成本 + 单位推理成本 × 用量。用量够大时，训练得更久的小模型更省，这是实践中偏离第 15 讲最优配比的原因；蒸馏是另一种做法。
  • ⚠️ 数字是示意的，但比例结论稳定；更准确不一定更有用；判断难度本身会出错。

思考题

  1. 用第三节的方法估算：如果推理过程从 4000 个 token 增加到 8000 个，用户等待时间大约变成多少？容量占用大约是原来 4000 个时的几倍（提示：近似平方增长）？
  2. 第三节说并行 8 份几乎不多等。如果并行 64 份呢？结合第 22 讲，批次越来越大时，会先碰到什么限制，使得"几乎不多等"不再成立？
  3. 用第四节的方法算：单次正确率 10%、有验证器时，要生成多少份，才能让"至少一个对"的概率超过 90%？这时的花费是直接回答的多少倍？
  4. 在第五节的例子里，如果小模型的训练成本是 300 而不是 150，用量达到多少时两者成本相等？如果一个模型预计只会被少量使用，你会选哪一个？
  5. 请分别设计一个场景：一个里你会选直接回答（A），一个里选先推理（B），一个里选并行采样加验证（C）。说明你在每个场景里最看重的是延迟、成本还是正确率。