本文整理自 YouTube 视频《How GPT, Claude, and Gemini are actually trained and served – Reiner Pope》,由有道龙虾总结和发布。

现在很多 AI 产品都开始提供“快速模式”。Claude、Codex、Cursor 这类工具里,用户可以多付几倍的钱,换来更快的 token 输出速度。

这个现象表面上像是商业定价,背后其实是芯片、内存、模型架构和集群调度共同决定的结果。

MatX CEO Reiner Pope 很适合讲这件事。他以前在 Google 做过 TPU 架构,如今创业做 AI 芯片。和常规访谈不同,这次他几乎是站在黑板前,从 transformer 在一整架 GPU 上怎么跑开始,一步步推导出:为什么 AI API 会这么定价,为什么模型越来越稀疏,为什么长上下文这么贵,以及为什么 AI 进展看起来会被硬件形态牵着走。

Fast Mode 贵在哪里:核心不是“算得更快”,而是 batch size

访谈一开始的问题很直接:为什么用户多付 6 倍价格,模型就能以 2.5 倍速度输出?能不能继续加钱,100 倍价格换 100 倍速度?反过来,如果我愿意等很久,能不能有一个“Slow Mode”,价格便宜很多?

Reiner 的答案很干脆:最大的因素是 batch size

大模型推理不是一个用户来一次就单独跑一次。服务商会把很多用户的请求攒成一个 batch,一起送进 GPU 集群。这样做的原因也很朴素:模型权重太大了,每次推理都要从内存里把权重读出来。如果只服务一个用户,这次权重读取成本完全由一个 token 承担;如果同时服务两千个序列,这个成本就被两千份摊掉。

Reiner 用 roofline analysis 来估算推理时间。粗略说,推理时间由两个下限共同决定:

  • 计算时间:batch size × active parameters ÷ 芯片 FLOPs
  • 内存时间:读取模型总参数的时间 + 读取 KV cache 的时间

这里有一个很重要的区分:MoE 模型里,总参数激活参数不是一回事。比如 DeepSeek V3 大约有 700B 总参数,但单个 token 实际激活的参数约 37B。计算成本主要看 active parameters,内存容量和权重读取则会被 total parameters 影响。

batch size 小的时候,成本主要被“读权重”支配;batch size 大起来之后,权重读取被摊薄,成本慢慢接近一个由计算决定的下限。

这也解释了为什么“慢模式”并不会无限便宜。等得更久确实能让系统攒更大的 batch,但到某个点之后,权重读取已经摊得差不多了,剩下的 KV cache 和计算成本都是每个序列自己要付的,没法继续摊。

“火车每 20 毫秒发一班”:低延迟服务是怎么调度的

Reiner 用了一个很形象的比喻:推理服务像一列定时发车的火车。

假设系统选择了一个 batch size,每次 forward pass 大约 20 毫秒。那 GPU 就像每 20 毫秒发一班车:

  • 请求到了,能上当前这班车就上;
  • 车满了,就等下一班;
  • 没坐满,车也照样发。

最差情况下,一个请求刚好错过上一班车,要等 20 毫秒,再花 20 毫秒跑完这一班,所以排队加执行大约 40 毫秒。

这个 20 毫秒也不是拍脑袋来的。它和 HBM 的“drain time”有关,也就是 内存容量 ÷ 内存带宽。例如 Rubin 一代可能是 288GB HBM、20TB/s 带宽,读完整个 HBM 大约 15 毫秒。很多代硬件都会落在十几到二十毫秒这个量级。

换句话说,AI 推理延迟不是简单由“GPU 快不快”决定,而是由 GPU 算力、HBM 带宽、HBM 容量、batch 调度共同决定。

最优 batch 有多大?答案小得有点意外

如果只看权重读取和权重计算的平衡点,Reiner 给出了一个很简单的近似:

batch size ≈ 300 × sparsity

这里的 300 来自硬件的 FLOPs / memory bandwidth 比值,在 A100、H100、B100 等几代 GPU 上相对稳定。sparsity 则是总参数和激活参数之间的比例。

以 DeepSeek 这类 MoE 模型为例,假设 256 个专家里激活 32 个,稀疏比例约为 8,那么平衡 batch size 大概就是 2400。现实系统会考虑 roofline 模型没有覆盖的损耗,通常再放大两三倍。

这不是 2000 个 token 的上下文,而是 2000 个正在生成下一个 token 的序列

听起来并不大,但换成吞吐量就明显了。如果一次 batch 约 2000 个序列,每 15 到 20 毫秒跑一次,一套系统大概能服务十几万 token/s。相比 Gemini 这类全球服务曾公开提到的“数亿 token/s”量级,这大约是千分之一。要在前沿模型推理上真正有规模优势,至少得有类似这样的流量基础。

这也是推理经济学里的一个微妙中心化力量:流量越大,越容易维持高 batch,越容易把硬件吃满。

KV cache:长上下文真正贵的地方

如果只看模型权重,batch 可以很好地摊薄成本。但 KV cache 不一样。

自回归生成时,模型每生成一个新 token,都要看前面所有 token 的表示。为了不每次重算历史 token,系统会把历史 token 在 attention 里用到的 key/value 表示存下来,这就是 KV cache。

它有两个麻烦:

  1. 它跟上下文长度线性增长。上下文越长,每个新 token 要读取的 KV 越多。
  2. 它不能像权重一样跨用户摊薄。每个用户的上下文不同,KV cache 也是独有的。

这就是长上下文贵的根源。

Reiner 提到,如果是 dense attention,KV cache 的内存读取基本随 context length 线性增长。Sparse attention 可以改善这个斜率,DeepSeek 公开过的某些稀疏注意力机制能把相关项变成平方根级别,但这不是免费午餐。注意力太稀疏,质量会掉。

这也解释了为什么大模型上下文长度从早期 8K 快速冲到 100K、200K 后,最近一两年反而没有继续狂飙。不是大家不想做百万、千万、甚至上亿 token 上下文,而是 memory bandwidth 和 memory capacity 会迅速把账单推爆。

如果有人相信“AGI 不需要持续学习,in-context learning 就够了”,那就必须面对一个硬问题:一个能陪你工作一个月的 AI 员工,可能需要上亿 token 的工作记忆。以现在的内存墙来看,这不是简单把 context window 参数调大就能解决的。

Gemini 长上下文加价,可能泄露了什么

访谈里还讨论了 API 定价能透露多少系统信息。

比如 Gemini 在超过 200K token 后价格上调约 50%。从成本曲线看,这很可能意味着 200K 附近接近一个平衡点:在这之前,计算或权重读取还能覆盖不少成本;过了这个点,KV cache 的内存带宽成本开始明显抬头。

Reiner 进一步反推,如果把 200K 当作 memory time 和 compute time 的交叉点,并假设 active parameters 在 100B 量级,那么每个 token 的 KV cache 可能在几 KB 左右。这个数并不离谱。它可以来自较少的 KV heads、共享长上下文层,或者来自某种 sparse attention。

同样,输入 token 比输出 token 便宜很多,也能用 prefill 和 decode 的区别解释。

  • prefill:一次处理一长段输入,可以并行,内存读取成本能被多个 token 分摊;
  • decode:一次只生成下一个 token,串行推进,更容易被 memory bandwidth 卡住。

所以输出 token 贵,不只是产品想多赚钱,而是 decode 阶段确实更“别扭”:它顺序依赖强,KV cache 读得多,内存带宽更容易成为瓶颈。

MoE 怎么放进一架 GPU:专家并行与 all-to-all 通信

大模型越来越喜欢 MoE,原因很直接:总参数可以很大,但每个 token 只激活一部分专家,从而降低计算成本。

一个典型 MoE 层里,会先有 router 决定 token 送到哪些 expert。每个 expert 本质上是一个普通 MLP,有 up projection、非线性和 down projection。最后再把专家输出合并,并通过 residual connection 加回原路径。

问题来了:这些 expert 应该怎么放到硬件上?

常见做法是 expert parallelism:把不同专家放到不同 GPU 上。以 DeepSeek 的 256 个专家为例,如果放在一个 Blackwell NVL72 rack 上,可以简化成用 64 张 GPU,每张 GPU 放 4 个专家。

这带来一种典型通信模式:all-to-all。任意 GPU 上的 token,都可能被 router 发到任意其他 GPU 上的专家。

这正好适合 Nvidia Blackwell rack 内部的 NVLink/NVSwitch 结构。在一个 rack 内,GPU 可以通过高速 scale-up network 互联。但如果跨 rack,事情就麻烦了。跨 rack 通常走 scale-out network,带宽可能比 rack 内慢 8 倍左右。一个 MoE 层如果硬切到两个 rack,平均一半 token 要跨 rack,all-to-all 通信马上会撞上瓶颈。

所以 Reiner 给出一个很关键的判断:

一个 scale-up domain 的大小,会限制你能高效运行多大的 expert layer。

这也是为什么硬件厂商不断把 scale-up 做大。从 Hopper 时代 8 卡,到 Blackwell NVL72,再到 Rubin 计划中更大的规模,背后不是“数字越大越好看”,而是模型结构真的需要更大的高速互联域。

为什么不能把 scale-up 做到一百万张卡?答案有点土:线缆

访谈里有个很有趣的细节:为什么不直接做一个超大的 scale-up 网络,把几百、几千、几万张芯片都接成高速互联?

答案不是只有抽象的网络理论,还有非常物理的约束:线缆。

现代 rack 里,GPU、交换芯片、背板、电源、冷却系统都塞得很满。想增加 GPU 数量,就要增加线缆密度,还要考虑连接器密度、线缆弯折半径、机柜重量、供电、液冷、结构强度。rack 不是一个可以随便往里塞线的空箱子。

从 Hopper 到 Blackwell,部分变化是产品形态从 tray 走向 rack。再往 Rubin 的更大 scale-up domain 走,就涉及更复杂的物理设计和布线能力。

AI 集群听起来像云端的抽象算力,落到最后,常常卡在“这根线到底能不能塞进去”。

Pipeline parallelism:模型很大时可以跨 rack,但它解决不了所有问题

如果一个 MoE layer 最好放在一个 rack 里,那多个 rack 怎么用?

答案之一是 pipeline parallelism:一部分层放在第一个 rack,下一部分层放在第二个 rack,再下一部分放在第三个 rack。模型本来就是一层一层堆起来的,所以这种切法在物理上很自然。

专家并行是“不同 expert 放不同 GPU”,流水线并行是“不同 layer 放不同 rack”。这很像模型结构直接映射到硬件结构上。

pipeline 的好处主要是省 内存容量。如果模型太大,一个 rack 放不下所有权重,就可以把层切到多个 rack 上。

但它不一定能改善延迟。decode 是顺序的,每个 token 要依次走过这些 pipeline stage。跨 rack 的 hop 会累加,可能每跳几毫秒。对每 token 20 毫秒级别的系统来说,多出来 10 毫秒已经很明显。

更麻烦的是 KV cache。pipeline 虽然把模型层切开了,但为了让所有 pipeline stage 忙起来,系统中同时在飞的 micro-batch 也会增加。结果是:权重内存可以被 pipeline 分摊,KV cache 的每 GPU footprint 却不一定下降,很多时候正好抵消。

这也是 Reiner 对推理部署的判断:现实中通常会尽量把 expert parallelism 做到 scale-up domain 的大小,pipeline 则少用,可能不用,或者只用两段来缓解权重容量问题。

大 scale-up 重要的不是容量,而是带宽

很多人会以为,更大的 rack 重要,是因为能装下更大的模型。

Reiner 的看法更精确:pipeline 已经能缓解模型权重的容量问题。真正大的提升在于 内存带宽并行化

读取模型权重的时间大致是:

total parameters ÷ 总内存带宽

如果一个 scale-up domain 里有更多 GPU,就能并行读取更多 HBM。单张 GPU 的 HBM 带宽每代可能只涨 1.5 到 2 倍,但 scale-up size 从 8 到 72,直接把并行带宽放大了一个数量级。

这会显著降低推理延迟,也让更大、更稀疏的模型更现实。

换句话说,Blackwell 这类大 rack 的意义,不只是“能放下五万亿参数”,而是“能更快把这些参数读出来”。

训练、RL、推理:为什么模型会被严重 over-train

访谈后半段讨论了一个更宏观的问题:如果 Chinchilla scaling law 告诉我们,给定模型大小有一个训练 token 的最优比例,那为什么现实中的前沿模型似乎远远超过这个比例?

答案要把推理成本也算进去。

如果只优化训练,一种模型大小可能最优;但如果模型要服务海量用户,训练多一点、模型小一点,可能让每次推理便宜很多。训练成本是一次性的,推理成本会随着用户使用不断发生。

Reiner 给了一个很有用的启发式:当总成本是几项相加时,最优点往往出现在这些成本大致相等的位置。

可以粗略把成本分成三块:

  • pre-training 成本:约 6 × active parameters × pre-training tokens
  • RL 成本:介于 forward 和 forward+backward 之间,还要考虑 rollout 和效率损耗
  • inference 成本:约 2 × active parameters × inference tokens

在这个框架下,前沿实验室会倾向于让预训练、RL、线上推理在总成本上达到某种平衡。

访谈里还做了一个粗算:如果某个具体模型每秒服务 5000 万 token,生命周期两个月,那么线上推理 token 总量大约是数百 trillion 级别。这个数和传闻中前沿模型预训练 token 数量相近。

如果 active parameters 约 100B,而 Chinchilla 推荐 token 数大概是 active parameters 的 20 倍,也就是 2T token,那么现实训练数据可能达到推荐值的 100 倍量级。

这个数字不一定精确,但方向很有意思:前沿模型不是只为训练效率而训练,它们是为训练、RL、推理的整体账本而训练。

KV cache 的缓存价格:HBM、DDR、Flash,甚至硬盘

API 里常见的 prompt caching 也能用这套框架解释。

同一段长 prompt,如果缓存命中,价格会低很多。原因是系统不用从 token ID 重新跑一遍 prefill 来生成 KV cache,而是直接取出之前保存过的 KV。

问题在于,KV cache 存在哪里?

  • 存在 HBM,取用最快,但 HBM 太贵,占着就影响 GPU 干别的活;
  • 存在 DDR,保存便宜一些,但取回 HBM 需要时间;
  • 存在 Flash,更便宜也更慢;
  • 甚至可能存在传统硬盘,极慢但单位容量便宜。

Reiner 用“drain time”解释不同缓存时长的定价。HBM 的容量/带宽只有几十毫秒,DDR 可能是秒级,Flash 可能到分钟级,硬盘甚至可能到小时级。

所以当 API 提供“缓存 5 分钟”和“缓存 1 小时”这类不同价格时,背后很可能对应不同存储层级。你看到的是一个简单的计费选项,服务商看到的是:这段 KV 该占哪层内存,存多久才划算。

神经网络与密码学:都在“搅拌信息”,但目标相反

访谈最后转向一个更轻松但很有启发的主题:神经网络和密码学协议为什么在结构上有点像。

两者都需要把信息充分混合。密码学希望把有结构的信息打散,让输出看起来像随机;神经网络则反过来,要从看似混乱的文本、蛋白质序列、DNA 里提取结构。

Reiner 提到,随机初始化的神经网络可能也会把输入搅得很复杂,但神经网络真正可训练的关键在于 梯度下降。残差连接、LayerNorm 这些设计,本质上也在让导数不要变得太混乱。

密码学里也有“微分”的攻击方式,叫 differential cryptanalysis。优秀的密码希望输入一点小变化,输出就完全大变,也就是 avalanche property。神经网络通常希望相反:小扰动不该轻易毁掉输出。图像分类里的 adversarial attack,恰好就是神经网络里出现了密码学希望拥有、但模型任务并不希望拥有的那种性质。

还有一个真正从密码学进入神经网络的例子:Feistel network。它可以把不可逆函数包装成可逆结构。RevNets 这类可逆网络借鉴了这个思想,让训练时不必保存所有 activation,而是在反向传播时把它们重新算出来。

这和 KV cache 的取舍正好相反:

  • RevNets 是 多花计算,省内存
  • KV cache 是 多花内存,省计算

而现代 AI 硬件的现实是:很多时候,多花一点内存来省计算是值得的;但当所有人都这么做,内存墙就成了下一道门槛。

这场黑板课真正讲的,不只是芯片

Reiner Pope 这场讲解最有价值的地方,是把很多看似分散的 AI 现象放到同一张账本里:

为什么 Fast Mode 更贵?因为低延迟意味着更小 batch,权重读取摊得少。

为什么 Slow Mode 不能无限便宜?因为 KV cache 和计算不能跨用户摊。

为什么 MoE 重要?因为它用更多总参数换更少激活计算,但需要更大的高速互联域。

为什么长上下文贵?因为每个新 token 都要读更长的 KV cache,memory bandwidth 很快变成瓶颈。

为什么大 scale-up domain 会改变模型形态?因为它不仅带来容量,更带来并行读取 HBM 的带宽。

AI 进展当然有算法、数据、产品、用户反馈这些因素。但到了前沿模型这一层,很多问题都会落回非常朴素的东西:一张卡有多少 HBM,带宽是多少,一架 rack 能接多少卡,线缆能不能塞下,跨 rack 要跳几次,每 20 毫秒能发多少“车”。

理解这些细节之后,AI API 的价格表、模型架构的选择、上下文窗口的上限,都会少一点神秘感。它们不是凭空出现的商业策略,而是硬件和模型一起算出来的结果。