GPT、Claude 和 Gemini 究竟如何训练与提供服务——Reiner Pope

摘要

• “Fast Mode”定价背后的主要变量是 batch size。 Pope 的 roofline 分析——时间下限取决于计算时间（batch × active params ÷ FLOPs）和内存时间（权重读取 + KV 读取 ÷ 带宽）中的较大者——揭示了硬性延迟下限（从 HBM 读取全部总参数）和硬性成本下限（计算曲线），而无批处理服务在经济性上会“差1000倍”。假设中的 Claude Code Slow Mode 几乎帮不上忙：超过交叉点 batch 后，KV 和计算都由每个用户独占，无法进一步摊薄。
• 最优 batch size ≳ 300 × sparsity ratio。 其中约300是大多数 GPU 上稳定的硬件常数（FLOPs/带宽，A100→B100基本不变），再乘以模型的专家稀疏度（DeepSeek 约为8），得到约2–3K条并发序列，以及每个系统约128K tokens/sec——约为 Gemini 全球流量的千分之一。推理确实存在规模经济，但幅度小于通常假设。
• Scale-up 域规模，尤其是聚合带宽，是限制模型规模的关键约束。 active params 受计算成本限制，total params 受 scale-up 域规模限制；流水线化可以解决模型权重容量问题。2022年 Hopper 的8-GPU scale-up 只有640GB；Blackwell 的10–20TB scale-up 足以容纳一个5T模型及其 KV cache，Rubin 则被讨论为约500多。Pope 认为，更大的 scale-up 域可能解释了 GPT-4 之后前沿模型参数量为何连续3年几乎没有增长，也可能助推了 Google 的 Gemini 预训练优势。
• 上下文长度的内存墙是真实存在的：过去两年，模型一直徘徊在100–200K，因为决定成本的是 KV cache 带宽而非计算，Pope 看不到“很好的解决路径。 HBM 就在那里”。 稀疏注意力的平方根扩展提供了一条出路，但这削弱了“上下文学习足以实现 AGI”的论点，因为后者需要1亿 token 的上下文。
• 相较 Chinchilla，前沿模型可能被过度训练了约100×，而且可以从第一性原理推导出来。 将预训练、RL 和推理成本拉平后，3者的 token 数大致相等（各约150–200T）；相比之下，一个约100B active 的模型按 Chinchilla 最优配置只需约2T。Dwarkesh 的框架是：“每个模型都应该在输出端生成它从输入端获得的人类知识总和。”
• API 定价会暴露架构。 Gemini 3.1 在超过200K上下文后加收50%，可以反推出计算/内存交叉点，并倒推每个 token 约2KB的 KV cache；输出与输入价格相差5×，说明 decode 受到“极其严重的内存带宽瓶颈”影响；而按5分钟与1小时计价的缓存存储层，可能对应闪存和机械硬盘的排空时间——“竟然还在使用机械硬盘，我多少有些震惊。”
• 值得记住 Dwarkesh 提出的悖论：据 Dylan 所说，超大规模云厂商约50%的资本开支花在内存上，但 Pope 的数学显示，机架对权重可能存在容量过剩——流水线化意味着权重不必装进单个机架。 对这个 scale-up 问题而言，稀缺资源是内存带宽，而不是权重容量；这一点对任何押注 HBM 超级周期的人都很重要。

精读

1. 两条曲线解释 fast mode、slow mode，以及中间的一切

• 将 Pope 的框架应用于 Blackwell NVL72 机架：推理时间的下限取计算时间和内存时间中的较大者——计算时间是 batch size × active params ÷ 芯片 FLOPs（例如 DeepSeek V3 在约700B total params 中只有37B active），内存时间则是读取全部 total params，再为 batch 中每个元素读取整个上下文的 KV cache，除以内存带宽。“即便是一个简单模型”，也能带来“非常强的预测能力”。
• 将延迟对 batch size 作图：计算时间从0开始线性增长，权重读取构成固定底线，KV 读取线性增长，因此给定硬件配置下存在延迟下限：“我必须把全部 total params 从内存读进芯片……如果已经用满内存带宽，就不可能做得更快。”这就是为什么多付100倍也买不到无限快的速度。
• 将所有项除以 batch，得到每 token 成本：权重读取变成衰减抛物线，KV 和计算变成常数。batch size为1时，成本“几乎趋于无穷大”，随后渐近于计算曲线，因此无批处理服务可能“差1000倍”。Claude Code Slow Mode 也“帮不上多少忙，因为无法把 KV 值摊薄到大得多的 batch 上。它们对每个 batch 都是独有的，计算也对每个 batch 都是独有的”。

2. Batch ≈ 300 × 稀疏度，而列车每20毫秒发车

• 令权重读取时间等于权重乘法时间，可以得到一个简洁结果：batch size ≥ ~300 × sparsity。其中约300是 FP4 下 FLOPs ÷ 内存带宽的结果，是一个“从 A100 到 B100 一直相当稳定”的无量纲硬件常数。DeepSeek 激活256个专家中的32个，稀疏度为8，因此结果约为2,400；实践中“把这个数乘以2或3”。关键在于，它只取决于稀疏度，“与规模无关”。
• 排队就像火车时刻表：“每20毫秒发一班新列车。凡是已经准备好的乘客都上车……即便列车没坐满，也照样发车。”最坏情况下的排队延迟是40ms。
• 20ms本身等于 HBM 容量 ÷ 带宽，也就是每次前向传播读取一遍全部内存所需的时间（Rubin：288GB ÷ 20TB/s ≈ 15ms），在“很多代 HBM”之间都相当稳定。Pope 说，在约30ms时，“我可以把全部 HBM 读两遍……但我不想把权重矩阵读两遍”。
• 换算为吞吐量：batch × ~64次/秒 ≈ 每个系统128K tokens/sec；相比之下，Gemini 曾公布的全球吞吐量是“每秒数亿 token”。Pope 的标准是：“要在规模上真正具备竞争力，至少要能服务 Gemini 的千分之一。”

3. 稀疏度在质量曲线上显得低效，但在系统层面仍是纯收益

• 从《Unified Scaling Laws for Routed Language Models》论文的质量结果看，收益并不突出：一个64专家、370M active 的模型可以匹配一个稠密1.3B模型——“64倍换来4倍（64x for 4x）”，参数量大幅增加，效率却只小幅提升；结果还“高度依赖具体的 mixture of experts 选择”，DeepSeek 更细粒度的 MoE 是“一次重大变化”。
• 但从 roofline 视角看，只要 batch 同步扩大，稀疏度翻倍就是“纯收益。只要继续做，直到没有更多可用用户”为止：新增 total params 的读取可以摊薄到更大的 batch 上。真正的成本是需要更多并发需求和更大的内存容量，而这会把问题整体推向机架架构。

4. MoE 布局由机架塑造：机架内 all-to-all，机架外慢8倍

• 标准做法是专家并行：DeepSeek 的256个专家分布在 NVL72 的72张 GPU 中向下取整后的64张上，形成 all-to-all 流量模式，这与 Blackwell 机架的布线方式“完美匹配”：每张 GPU 都能通过中央 NVSwitch，在两跳内访问其他 GPU。跨越两个机架后，一半 token 会进入 scale-out 网络，通常慢约8×，“这就成了瓶颈”。
• 为什么不使用一个巨型交换机？因为物理布线。机架内 GPU 数量翻倍，意味着“电缆密度确实翻倍”，同时受到连接器密度、背板限制和弯曲半径约束。Dwarkesh 的惊讶很有代表性：“机架已经这么大了，我们不能就这样再塞更多电缆……我完全没想到。”机架把空间、重量、电力和散热推到了极端的物理上限。
• 发展路径是：Hopper 的8张 GPU 到 Blackwell 的72张，“主要只是决定从托盘切换到机架——这是一个产品决策”；Blackwell 到 Rubin 的约500张，则包含“一点 Jensen 式数学”，但也来自机架设计真正的4×提升。“一个机架决定了你能做多大的专家层。”

5. GPT-4之后模型规模停滞的一个可能原因

• Dwarkesh 的前提是：GPT-4（2023年，据传参数超过1T）直到大约最近6个月才被真正意义上地超越。Pope 提出的可能机制是：2022年8张 Hopper 提供了640GB；只有 Blackwell 的机架级10–20TB，才足以容纳一个5T模型及 KV cache。“部署在更大的 scale-up 域中，是一个巨大的解锁。”
• 对于 Gemini 看似领先的预训练表现，Pope 指出 Google “很早就拥有非常大的 scale-up 域”，但也保留了谨慎判断：“我当时不在现场，不确定其中有多少来自成功部署更高的稀疏度……也可能主要是大量真正的建模因素。”更广泛的结论是，更大的 scale-up 域可能有所贡献，但很难将其与建模和数据改进拆分开。清晰的判断是：active params 受计算成本限制，total params 受 scale-up 域规模限制。

6. 流水线化能节省权重，不能节省 KV，因此推理发生在单个 scale-up 域内

• 流水线并行（将不同层放在不同机架上）可以轻松跨过 scale-out 带宽门槛：scale-up 流量相对 scale-out 高出（激活专家数 × 每个 stage 的层数 × 2），而后者只有8×的带宽劣势。Pope 对专家并行加流水线并行为何胜出的总结是：“模型是沿哪些不同维度扩展的？……每一个数字都可以选择切在哪里。”而 tensor parallelism 变得不那么重要，是因为“现在专家太小了”。
• Dwarkesh 从 Jane Street 的 Axel 那里引入了一个限制：流水线化会迫使系统使用 micro-batches。代数推导显示，随着流水线 stage 数 P 增加，每张 GPU 的权重占用会下降，但 KV 项中的 P 会相互抵消；要让所有机架保持繁忙，就必须让更多序列同时在途，“两者恰好抵消，最终每张 GPU 都省不下什么”。KV cache 从两个角度看都很棘手：既无法跨 batch 摊薄，也无法跨 stage 分片。
• DeepSeek 论文给出的实践结论是：先将专家并行扩展到 scale-up 域的上限，然后“尽量少做流水线化。可能完全不做，也可能只做两级”。因此，对典型模型而言，前沿实验室通常在单个 scale-up 域内运行推理。推理阶段流水线化对延迟基本中性（每次机架跳转几毫秒，4个 stage 累计可能达到每 token 10ms——当基础延迟只有20ms时，“其实已经很多了”），而且它节省的内存本来就是过剩的：“1T参数模型只需要1TB，所以本来就装得下。”
• 历史细节也值得保留：Ilya 说“现在我们知道不该做流水线并行”；Horace He 则反驳称，流水线化会施加架构约束，例如 Kimi 的跨层注意力残差。Pope 承认：“这些复杂性是真实存在的。流水线化是个巨大的麻烦。”气泡图解释了为什么训练需要 zero-bubble/1F1B 等技巧——“你可以在这个气泡里挖 Bitcoin。——对，更有用的是，你可以在那里做权重梯度更新。”

7. 内存悖论：资本开支的50%投向了一个机架可能已经过剩的资源

• Dwarkesh 的质疑值得完整保留：“Dylan 说，超大规模云厂商今年把50%的资本开支花在内存上……所以今年我们不会有新的笔记本和手机。但与此同时，我们的内存又太多了？如果不需要这些内存，Jensen 为什么还要把这么多内存塞进这些机架？”
• Pope 的解释是：大型 scale-up 域买到的不是容量，而是聚合内存带宽——权重加载可以在域内的每张 GPU 上并行执行；这一项相较 Hopper“增加了8倍”，而单 GPU 带宽每代只增长1.5–2×。“流水线化彻底解决容量问题，但 scale-up 规模有助于解决带宽问题”，这正是低延迟和更长、更具 agentic 特征的上下文成为可能的原因。
• 对上下文扩展的悲观推论是：从 GPT-3 到 GPT-4 等早期模型，上下文长度从约8K跃升至100–200K，尽管 Pope 记不清具体发生在什么时候；而“过去一两年，它们都一直徘徊在那里……我认为这是因为这里没有解决内存墙的办法”。稀疏注意力（DeepSeek 发布的平方根变体）“肯定提供了一条出路……但并非无限改善，因为过于稀疏会损失太多质量”。针对 Dario 所说、需要约1亿 token 上下文的“上下文学习就足够了”，Pope 表示：“我确实看不到很好的解决路径。”

8. 第一性原理下的训练预算：一切趋于均衡，相较 Chinchilla 过度训练约100倍

• Pope 的启发式判断是：对于幂律型曲线，成本总和“往往在各项成本相等时最小”。令预训练成本（6ND）、RL 成本（2–6× N×D_RL——其中的2是因为 rollout 不参与训练，只需一次前向计算，且 decode 的 MFU 更差）和推理成本（2ND）相等后，active params 会消掉：预训练 token ≈ RL token ≈ 推理 token，“只差一些我们无法推理的系数”；由于 RL 对机器时间的利用效率较低，RL token 会略少。（现场推导中还抓到了一次代数错误：“数十亿美元的算力刚刚流向了相反方向……如果用电子表格算一遍，或许会发现钱正在被倒进沟里。”）
• 代入具体数字：全球吞吐量或许为每秒500M token，除以特定模型的5–10倍，再乘以部署2个月，约得到~200T推理 token；这与 Pope 听到的某个前沿模型约150T预训练 token 相当接近。对于约100B active params，Chinchilla 最优值约为2T，因此这一估算意味着模型可能被“过度训练了100倍”。
• Dwarkesh 的总结是：“即使偏差50%之类的，能够用第一性原理估出这类数字，仍然很疯狂。”Pope 补充了折损因素：需求预测并不完美，而且废弃一个非前沿模型的风险意味着“应该对推理 token 做一定程度的折减”。

9. 从实验室的价目表反推内部架构

• 上下文加价：Gemini 3.1 对超过200K token 的请求比低于该门槛的请求贵50%，可能标记了成本—上下文曲线上的计算/内存交叉点，形成一个确保两侧都能盈利的双层价格。假设 active params 约100B，并采用1/300的硬件常数，反推交叉点可得到每个 token 约1,667字节的 KV cache——“接近2KB……如果略显偏小，但仍然合理”。这与8个 KV heads × d_head 128，再配合 Character-AI/Gemma 风格的跨层共享相符；也可能是原始数值更大、但使用了稀疏注意力。Dwarkesh 说：“他们竟然会通过 API 定价泄露这么多信息，挺有意思。”
• 输入与输出：prefill 会把权重读取摊薄到整个 pass length 上，而 decode 每次只处理一个 token，因此输出价格高出3–5×，意味着 decode 的定价约为计算成本的5倍，也说明服务栈“确实受到极其严重的内存带宽瓶颈影响”。
• 缓存层：按5分钟和1小时计价的 cache-write 可能反映某个内存层的排空时间，即容量 ÷ 带宽。HBM 的排空时间是20ms，太快；DDR 是几秒；闪存约1分钟；机械硬盘约1小时。因此这些层“可能是闪存和机械硬盘”，而不是 Dwarkesh 最初猜测的 HBM/DDR。Pope 说：“这是一种非常不讨喜的技术，但在某些地方有用。”
• 这套分层逻辑值得保留，因为它具有普适性：从头重新生成 KV 需要计算，存储 KV 只需付出设备成本的一小部分；最优策略是让一个条目“在其中存放的时间，恰好等于把全部条目放进去再取出来所需的时间”。

10. 密码与神经网络：相同的混合机制，相反的目标

• 根据 Pope 的博客文章，两类架构都必须把信息在全部输入之间打乱，但“它们实际上在做相反的事情”：密码要让结构与随机性无法区分，神经网络则要从表面随机的信息中提取结构。区别在于可微性：残差连接和 LayerNorm 有助于让导数保持受控且简单；而“设计良好的密码，其全部任务就是让输出差异变得非常大”——差分密码分析从字面上说，就是在2元素域上对密码求导的攻击。对抗性图像攻击展示了密码的雪崩效应；在后门例子中，隐藏输入进入的是反向传播。
• 不要把神经网络当作密码使用——“如果它没有经过10年的审查，基本就已经坏了”。但反向借鉴是成功的：Feistel 密码结构把不可逆的 f(x) 变成可逆的双输入层（输出为 x、y+f(x)；通过 z − f(x) 反转），后来发展成 RevNets，使整类类似 Transformer 的网络具备可逆性；这样，激活值可以在反向传播时重新计算，而不必全部存储。Dwarkesh 最后的对称总结是：RevNets 用计算换内存，“正好与 KV cache 相反”。Pope 说：“考虑到当前硬件的成本结构，用更多内存换计算通常更划算。”