从芯片到模型，推导大模型训练与推理的真实成本

摘要

这场黑板课把大模型训练和服务拆成一组工程问题。核心不在模型名字，而在 GPU 集群、显存带宽、批量大小、MoE 布局、流水线并行、长上下文缓存和 API 价格之间的关系。Reiner Pope 用少量公式解释，为什么快模式更贵，为什么长上下文受限，为什么前沿模型的成本可以从公开价格反推出来。(Dwarkesh)

内容框架与概述

开头从推理服务的成本讲起。用户看到的是 token 生成速度和 API 价格，背后是批量大小、显存带宽和计算吞吐的平衡。快模式并不是魔法，它通常意味着系统把更多请求合批，让 GPU 更接近满负载，但延迟、成本和资源调度会一起变化。这里的关键是，推理成本常常受限于读取模型权重和 KV cache 的速度，而不只是算力本身。(Dwarkesh)

中段进入模型和集群布局。MoE 模型要把专家分布到不同 GPU 和机架中，流水线并行则把模型层切到不同设备上。这样可以解决容量问题，但会引入通信和延迟。规模更大的 scale up domain 带来的优势，不只是能放下更大的模型，还在于更高的带宽能降低每个 token 的等待时间。对智能体和长上下文任务来说，这类底层限制会直接影响产品体验。(Dwarkesh)

后段讨论训练数据、强化学习和长上下文成本。由于 RL 和实际服务需求，模型可能会远超 Chinchilla 意义上的最优训练 token 数。API 中输入、输出、缓存保存时间的价格差异，也能反推出系统在 HBM、DDR、flash 等存储层级上的成本结构。最后还延伸到神经网络和密码学的相似性，重点是现代 AI 系统正在被硬件、数据、算法和服务经济共同塑形。(Dwarkesh)

核心概念及解读

Batch Size，批量大小

批量大小就是一次喂给 GPU 处理的 token 或请求规模。批量太小，GPU 在等内存搬数据，算力吃不满。批量变大，权重读取成本被摊薄，单位 token 成本下降，但用户侧延迟和调度复杂度会上升。快模式和慢模式的价格差异，可以放到这个框架里理解。

Memory Bandwidth，显存带宽

显存带宽是数据从 HBM 进入计算单元的速度。大模型推理常常不是算不动，而是数据搬不够快。尤其在 decode 阶段，每生成一个 token 都要反复读取权重和上下文缓存，带宽就成了瓶颈。长上下文迟迟难以无限扩展，也和这个瓶颈有关。

MoE，专家混合模型

MoE 让每个 token 只激活一部分专家，而不是动用整个模型。好处是模型总参数可以很大，实际计算量相对可控。问题是专家要分布在不同 GPU 和机架中，路由、通信、负载均衡都会影响速度和成本。MoE 是算法设计，也是数据中心布局问题。

Pipeline Parallelism，流水线并行

流水线并行把模型的不同层放到不同设备上，像流水线一样接力计算。它能缓解单卡装不下模型的问题，但在逐 token 生成时，阶段之间的通信延迟会累积。模型越大，设备越多，调度越像一套工业系统，而不是单纯跑一段代码。

KV Cache，键值缓存

KV cache 是模型为历史上下文保存的中间状态。有了它，模型不用每次从头处理整段对话。但上下文越长，缓存越大，存储和读取成本越高。API 对缓存时长和输入输出 token 的不同定价，往往能暴露底层存储层级的成本差异。

文章基本信息

字段	内容
原标题	How GPT, Claude, and Gemini are actually trained and served – Reiner Pope
作者	Dwarkesh Patel，嘉宾 Reiner Pope
发布日期	2026 年 4 月 29 日 (Dwarkesh)

访谈的核心问题：大模型为什么会这样训练、这样服务

这场访谈把 GPT、Claude、Gemini 这类前沿大模型拆成一套工程系统来理解。模型能力不是只由参数规模决定，还被 GPU 集群、显存带宽、批量大小、通信拓扑、KV cache、MoE 路由、训练数据量、RL 生成成本、API 定价共同限制。理解这些底层约束后，很多现象就不再神秘：为什么快模式更贵，为什么长上下文贵，为什么 MoE 成为主流，为什么大模型公司越来越像数据中心公司。

批量大小决定推理成本和速度

Fast Mode 的底层逻辑

快模式的第一层解释是 batch size。服务商不是一次只服务一个用户，而是把许多用户的请求合成一批，一起跑一次前向计算。GPU 读取模型权重有固定开销，如果只有一个用户承担，单位 token 成本会非常高；如果几千个序列一起承担，读取权重的成本就被摊薄。

这也解释了为什么花更多钱可以买到更快的 token 流，但不能无限加钱换无限速度。因为底层存在一个延迟下界：模型权重和 KV cache 必须从显存中读出来，读完这些数据需要物理时间。钱可以买更优先的调度、更高的批处理资源、更少的排队等待，但不能让显存带宽突破硬件极限。

Slow Mode 为什么省不了太多

慢模式听起来合理：用户愿意等更久，服务商就可以攒更大的 batch，从而更便宜。但访谈里给出的判断是，成本下降有下限。权重读取可以靠更大的 batch 摊薄，可每个用户自己的 KV cache 和计算仍然是独立的，不能被别人的请求共享。等到权重读取成本已经摊薄之后，再等更久，收益就很有限。

推理像一列固定发车的列车

推理调度可以想成一列列车。系统每隔大约 15 到 20 毫秒发一次车，准备好的请求上车。请求刚错过一班车，就等下一班；请求太多，就排到下一班。这个类比解释了排队延迟：不是每个请求单独启动一次 GPU 任务，而是进入一个固定节奏的批处理系统。

Roofline Analysis：用算力和带宽估算大模型服务

两个硬件瓶颈：计算吞吐和内存带宽

Roofline analysis 的核心做法很朴素：一次推理至少要花两类时间，一类是计算时间，一类是内存读取时间。计算时间主要来自活跃参数的矩阵乘法，内存时间主要来自读取全部权重和读取 KV cache。用这两个量取最大值，就能粗略估算推理延迟。

这个模型很粗，但有很强的解释力。它能解释为什么 batch size 小的时候成本离谱，因为每次都要读一遍权重；也能解释为什么 batch size 变大后成本下降，直到计算吞吐成为新的下限。到了这个阶段，继续扩大 batch 也不能让单位 token 成本无限降低。

GPU 的一个关键比例：FLOPs 和内存带宽

访谈里提到一个经验比例：多数 GPU 上，计算吞吐和内存带宽换算后大约形成一个 300 左右的硬件常数。从 A100 到 H100 再到 B100，FLOPs 提升了，内存带宽也提升了，所以这个比例相对稳定。

这个比例可以用来估算合适的 batch size。对于 MoE 模型，batch size 大约要超过 300 乘以稀疏度。以 DeepSeek 这类模型为例，如果 256 个专家中激活 32 个，稀疏度约为 8，合理 batch 规模就在几千个序列的量级。

KV Cache 是长上下文的关键成本

KV Cache 保存了历史上下文的中间表示

自回归生成每次只生成下一个 token，但这个 token 要注意到此前所有 token。模型不会每次从头计算全部历史，而是保存历史 token 的内部表示，这就是 KV cache。它让生成可以继续向前推进，但也带来巨大的内存读取和存储压力。

生成阶段的 attention 很多时候受限于内存读取，而不是矩阵乘法。上下文越长，每个新 token 需要访问的 KV cache 越大。长上下文的成本不是简单多算一点，而是反复搬运大量历史状态。

Decode 更受内存带宽限制，Prefill 更偏计算限制

decode 是模型一个 token 一个 token 往外吐。每吐一个 token，都要读模型权重，也要读历史 KV cache。因为单次处理的 token 数很少，很多成本无法摊薄，所以 decode 容易被内存带宽卡住。

prefill 是处理用户输入、文件、工具调用结果这类已有文本。它一次处理较长片段，计算量更集中，单位 token 的内存成本会被长片段摊薄，所以更偏计算限制。这个差异解释了为什么输入 token、输出 token、缓存命中 token 的 API 价格会有明显差别。

API 定价透露了底层存储结构

缓存命中便宜，因为不用重新生成 KV Cache

缓存命中价格低，本质上是因为系统之前已经把 KV cache 生成出来并存在某个存储层里。缓存未命中时，只剩原始 token ID，系统必须重新跑模型，把 KV cache 再算一遍，这就贵。

不同缓存时长对应不同存储层

访谈里把缓存存储拆成几层：HBM、DDR、flash，甚至更慢的存储。HBM 快但贵，适合短时间保留；DDR 慢一些但便宜，适合更长时间；flash 更慢但容量更大。API 中五分钟缓存和一小时缓存的不同价格，可以被理解为不同存储层的成本反映。

这里有一个很工程化的判断：如果只保存很短时间，可以用高速昂贵内存；如果保存很久，就要转移到更便宜的层级。保存成本和取回成本此消彼长，API 价格就是这种权衡的外部表现。

MoE 模型：用稀疏激活换计算效率

总参数很多，活跃参数较少

MoE 的关键是，模型可以有大量专家，但每个 token 只激活其中一小部分。这样总参数规模可以很大，表达能力更强，而每次生成 token 的计算量仍然可控。DeepSeek V3 这类模型就是典型例子：总参数很多，但每个 token 只使用一部分活跃参数。

这套结构让模型在计算上更省，但代价是内存和通信更复杂。总参数越多，就越需要足够大的 scale up domain 来放下模型权重和 KV cache；激活专家越分散，就越依赖高速互联。

稀疏度提高后，batch 需求也提高

稀疏模型减少了每个 token 的计算量，但总参数仍要放在设备上，权重读取和通信不能凭空消失。稀疏度越高，越需要更大的 batch 来摊薄权重读取成本。换句话说，MoE 的经济性依赖足够大的用户流量。没有足够请求量，稀疏模型的服务效率就发挥不出来。

模型质量的收益是经验问题

稀疏度能不能一直提高，没有简单公式。更多专家、更少活跃参数，未必总能带来等比例质量收益。早期 MoE 论文和后来的 DeepSeek 式架构差异很大，具体效果取决于路由、专家粒度、训练方式和数据。这里不能只靠硬件公式，还要靠实际训练结果。

专家并行和 GPU 机架布局

MoE 天然需要 all to all 通信

MoE 层里有 router，负责把 token 分配给不同专家。专家通常分布在不同 GPU 上，所以每个 GPU 都可能把 token 发给任意另一个 GPU。这就是 all to all 通信模式。

这类通信最适合在一个高速互联域里完成。Nvidia Blackwell NVL72 这类 rack 通过 NVLink 和 NVSwitch 让机架内 GPU 高速互联，适合承载 MoE 的专家并行。出了机架之后，通信通常要走更慢的 scale out 网络，带宽可能低很多，MoE 的通信就容易成为瓶颈。

机架大小受物理世界约束

scale up domain 不能无限变大。限制它的不是一个抽象算法问题，而是电力、散热、重量、线缆密度、连接器密度、线缆弯曲半径这些物理问题。机架越大，越难塞下更多线缆，也越难保证供电和冷却。

这解释了为什么 AI 基础设施越来越像重工业。模型结构需要的通信模式，最终要落实到机架、线缆、交换芯片、冷却系统和数据中心布局上。模型架构和硬件形态开始互相塑造。

Pipeline Parallelism：把层切到不同机架

流水线并行主要节省内存容量

流水线并行把模型不同层放到不同 GPU 或不同机架上。它在推理中不一定节省运行时间，因为只是把内存读取从一个设备挪到另一个设备；真正节省的是单个设备或单个机架需要承载的模型权重容量。

如果一个模型太大，一个 rack 放不下，pipeline parallelism 就有价值。它把模型层切开，让每个 rack 只负责一段层。这样可以服务更大的模型，但代价是引入更多调度复杂度和跨阶段通信。

微批次和 pipeline bubble

流水线如果不填满，会出现 pipeline bubble，也就是某些阶段空闲。为了避免空转，需要使用 micro batch，让多个小批次连续进入流水线。推理里这个问题相对直接，因为只要前向传播；训练里还要处理反向传播和梯度累积，复杂度更高。

微批次有一个代价：它削弱了大 batch 摊薄权重读取的能力。正面效果是省内存，负面效果是成本摊薄变差。因此流水线并行不是免费午餐，它是在内存容量、延迟、吞吐、实现复杂度之间做取舍。

为什么有人反对流水线并行

Ilya 曾经说过现在知道不该做 pipelining。这里的原因不只是 pipeline bubble，还有架构约束。比如某些模型结构会跨层引用中间状态，或者让注意力依赖前几层输出，这会让简单的层切分变得麻烦。

所以流水线并行不是绝对好坏的问题。它适合模型太大、内存容量紧张、层结构适合切分的场景；不适合结构复杂、跨层连接多、调度成本高的场景。

Scale Up Domain 是前沿模型能力的重要限制

总参数受 scale up 容量限制

活跃参数主要受计算成本限制，总参数主要受 scale up domain 容量限制。一个模型可以有多少总参数，取决于一组高速互联设备能不能装下权重，并且还能留出足够空间给 KV cache 和服务批次。

这解释了为什么更大的 scale up domain 是大模型部署的重大解锁。从 Hopper 的小规模互联，到 Blackwell 的 rack 级互联，再到 Rubin 更大的互联域，硬件形态的变化会直接影响可服务模型的规模。

Gemini 的早期优势可能和大规模互联有关

访谈里提到，Google 的部署长期拥有较大的 scale up domain，这可能帮助 Gemini 更早支持更大规模、更高稀疏度的模型。当然，这里面也可能有模型架构、MoE 设计、训练数据、工程系统等多重因素。硬件不是唯一原因，但它是一个重要边界条件。

训练为什么可能远超 Chinchilla 最优

Chinchilla 最优只看训练计算，不看服务成本

Chinchilla scaling law 给出的是在训练计算预算下，模型大小和训练 token 数之间的平衡。但真实商业系统要优化的不只是训练成本，还要优化后续海量推理成本。一个模型如果训练得更久、体积更小，可能训练时更贵，但长期服务用户更便宜。

因此，前沿模型可能会被大幅 over train。访谈中用估算方式把服务流量、模型生命周期、活跃参数和 Chinchilla 推荐 token 数联系起来，得到一个量级判断：某些前沿模型可能比 Chinchilla 最优多训练约百倍 token。这个数字误差很大，但推理框架有启发性。

RL 让过度训练更有意义

RL 阶段需要大量生成。预训练模型不只是最终面向用户服务，还要为 RL 过程提供大量样本生成。如果预训练模型更小、更便宜，它在 RL 生成阶段也能节省计算成本。于是，训练多一点、服务便宜一点，可能在系统总成本上更划算。

这里的核心取舍是训练 compute 和 inference compute 的总和。只看训练，会倾向更大模型、更少 token；把服务和 RL 生成也算进去，就可能倾向更小模型、更多训练 token。

长上下文的上限来自内存墙

上下文长度越长，KV Cache 越贵

长上下文看起来像产品功能，底层是 KV cache 的存储和读取问题。上下文越长，每个新 token 要读的历史状态越多，显存带宽压力越大。即使 sparse attention 能改善情况，也不能让成本消失。

访谈中提到，主流长上下文长度在一段时间内没有继续大幅增长，这可能反映了一个现实：显存带宽没有足够快地改善，memory wall 仍然存在。继续拉长上下文会让价格和延迟变得难以承受。

Sparse Attention 有帮助，但不是无限解法

稀疏注意力可以减少每个 token 关注的历史范围，从而降低 KV cache 读取压力。DeepSeek 等模型公开过相关机制，一些方法能把线性增长改得更温和。

问题是，太稀疏会损失质量。模型如果只看很少一部分历史 token，就可能错过关键上下文。长上下文能力不是单纯把窗口开大，还要在质量、成本和带宽之间找一个能服务用户的点。

从 API 价格反推模型系统

公开价格能透露内部成本

访谈里反复使用一种方法：用公开 API 价格、公开硬件规格、公开模型参数传闻，反推出内部系统的成本结构。比如输入输出 token 的价格差异，可以反推 prefill 和 decode 的瓶颈；缓存价格可以反推 KV cache 存储层；上下文价格可以估计每 token 的 KV cache 字节数。

这种方法不会给出精确答案，但能给出量级判断。只要量级对，就足够解释很多产品现象。大模型行业表面上封闭，内部细节不公开，但价格、速度、上下文长度、硬件规格会泄露很多信息。

工程系统比单个模型名更重要

GPT、Claude、Gemini 这些名字只是用户看到的产品入口。背后真正决定体验的是集群调度、显存层级、模型切分、专家路由、缓存策略和定价策略。模型服务已经不是单机程序，而是一套持续运行的工业系统。

神经网络和密码学的相似性

两者都在混合信息

神经网络和密码学都需要把输入信息充分混合。密码学要把有结构的信息打散成看起来随机的输出；神经网络反过来，要从看似混乱的输入中提取结构。方向不同，但都会用到层层混合、扰动扩散、全局依赖这些机制。

Avalanche Property 在两个领域含义不同

密码学里，avalanche property 是好事：输入轻微变化，输出剧烈变化，攻击者难以反推。神经网络里，类似现象常常是坏事，比如图像分类中的对抗攻击，小扰动让模型输出完全改变。同一种数学性质，在不同目标下会变成优势或风险。

Feistel Network 被神经网络借用

访谈中举了 Feistel cipher 的例子。它来自密码学，可以把不可逆函数构造成可逆层。神经网络中的 RevNets 借用了类似结构，让训练时不必保存所有激活值，而是在反向传播时重新计算，从而大幅降低内存占用。

这个方向比用神经网络做密码更稳妥。新密码算法很容易被攻破，需要长期审查；但把密码学里的可逆结构引入神经网络，已经有清晰的工程价值。

这场访谈背后的方法论

用一阶近似理解复杂系统

整场讨论不是追求精确模拟，而是用最少变量建立可解释模型。先抓住计算吞吐、内存带宽、batch size、KV cache、活跃参数、总参数这些核心量，再做数量级估算。很多结论不需要知道实验室内部细节，也能从公开信息中推出来。

这种方法适合理解 AI 基础设施。因为系统太复杂，细节永远不完整，但只要抓住最贵、最慢、最难扩展的部分，就能判断大方向。对大模型来说，最关键的往往不是某个单点技巧，而是算力、带宽、内存、通信、流量和价格之间的配平。