跳到主要内容

6.1 训练 vs 推理：两种完全不同的负载

备考一次，营业终身​

训练一个大模型像备考：几个月闭关、烧掉几个亿，但只发生一次。

推理则像营业：模型上线后 7×24 小时接客，头部产品每天要处理几十亿次请求——而且只要产品活着，这笔账单就永远付下去。到 2025 年，头部大模型产品的推理总开销早已超过训练。

所以「训练完就万事大吉」是个错觉。真正决定产品体验和毛利的，是营业环节的两个问题：快不快，省不省。

为什么生成这么慢​

先回忆 3.5 节那个循环虚线箭头：自回归生成一次只产出一个 token，产完拼回输入、再来一圈。一个 500 字的回答，就是这个循环转几百圈——圈与圈之间没法并行，因为第 301 个字必须等第 300 个字出来才能算。

更细看，一次请求其实分成两个阶段，性格完全不同：

  • 预填充（prefill）：把你输入的整段提示词一次性并行读完。这一步是巨大的矩阵乘法，算力火力全开——它的耗时决定你等多久看到第一个字。
  • 解码（decode）：之后逐字往外蹦。奇怪的是，这一步 GPU 的算力大量闲置——瓶颈换成了显存带宽。

大车拉小货​

解码为什么卡在带宽？因为每生成一个 token，都要把整个模型的权重从显存搬进计算单元过一遍——几百 GB 的搬运量，换来的计算却少得可怜（每个参数只做两次乘加）。这就像开一辆 40 吨的大卡车，跑一整趟只送一个包裹：车（算力）根本没吃饱，路（带宽）却跑满了。

这个洞察是整章的钥匙：

推理优化的总纲

解码阶段，「搬运」远贵于「计算」。所以一切优化都围绕两个思路展开——少搬（KV Cache 复用旧结果、量化把权重变小）和一趟多送（批处理让一次搬运服务多个请求）。

快和省，不可兼得​

「一趟多送」引出最后一个取舍。把很多用户的请求攒成一批同时解码，一次权重搬运就能产出一批 token——服务器的吞吐量直线上升，每个 token 的成本直线下降。但攒批要等人齐，单个用户的延迟就变差了。

个人用户在乎「首字快」（延迟），服务商在乎「总产出高」（吞吐）——这对矛盾怎么调和，正是 6.4 节推理框架的主战场。

术语撞车预警

中文里的「推理」有两个来源：本章的 inference（跑模型，让训练好的模型干活）和第 5、8 章的 reasoning（逻辑推理，模型「多想一会儿」的能力）。它们毫无关系，英文是两个词，中文不幸撞车。本书说「推理服务 / 推理部署」时一律指前者。另外，「prefill 算力密集、decode 带宽密集」是主流架构下的一阶近似——批次极大或上下文极长时，瓶颈还会转移。

小结​

本节要点
  • 训练一次性，推理永续：2025 年头部产品的推理开销已超过训练，快与省决定生死。
  • 一次请求分两段：预填充（并行读提示词，算力密集，决定首字延迟）+ 解码（逐字生成，带宽密集）。
  • 解码是「大车拉小货」：每个 token 都要搬全部权重，计算却极少——一切优化围绕「少搬」和「一趟多送」。
  • 吞吐与延迟互相牺牲：攒大批省钱，单用户等更久。
📝 动手自测0/3
1. 聊天时你等了 2 秒才看到第一个字，之后每个字都蹦得很快。「等 2 秒」主要花在哪个阶段？
2. 解码阶段 GPU 算力大量闲置，真正的瓶颈是什么？
3. 服务商把很多用户的请求攒成大批一起解码，结果是？

延伸阅读​