#模型时代##豆包 付费# GPT、Claude和Gemini到底是怎么训练和推理的：7个方程和API报价单背后的推导

今天的一个热搜是豆包付费。关于这件事，一个常见的讨论是，LLM衍生的Token经济学，和互联网经济学的关键区别，即免费的终结。因为token背后GPU（xPU）成本和互联网背后的CPU成本，不可同日而语。这期播客就特别值得一看了。

Dwarkesh Podcast用了全新的黑板讲座形式。请Reiner Pope（AI芯片创业公司MatX的联合创始人兼CEO），从两个最基础的硬件参数出发，一个是内存能读多快，一个是芯片能算多快，一步步推导出关于AI产业的一系列结论：为什么Claude Code的快速模式要贵6倍？为什么所有大模型的上下文长度都卡在200K左右？为什么前沿模型的训练数据量可能超出理论最优值100倍？

他用几个方程和几张报价单，解释了GPT、Claude和Gemini到底是怎么训练和推理的，以及背后的经济学计算。

Reiner Pope在创办MatX之前，他在谷歌担任PaLM推理效率负责人，参与设计了TPU v5e，拥有11项专利。2026年2月，MatX完成5亿美元B轮融资，由Jane Street和Leopold Aschenbrenner的Situational Awareness基金领投，估值达到数十亿美元级别。其首款芯片MatX One预计2027年出货。

一、运行一个大模型：两个瓶颈决定一切

要理解大模型怎么运行，需要先理解一件事：当你向Claude或GPT发一条消息，背后的GPU在做什么。大模型生成回复的方式是一个token一个token地往外吐。每吐一个token，模型都要完整地"跑一遍"，参考前面已经生成的所有词，然后决定下一个词是什么。这个过程叫自回归解码。

那么"跑一遍"要多久？Reiner的分析框架叫roofline分析，核心思想极简：每一步的耗时，取决于两件事中较慢的那个。整堂课从这一条出发：

> 方程① Roofline原则： T ≥ max(T_计算, T_内存)

1、瓶颈一：计算。芯片做乘法要花多长时间

大模型本质上是一堆矩阵乘法。每生成一个token，芯片要把输入和模型的"活跃参数"做一轮乘法。这里需要解释活跃参数。像DeepSeek V3这样的稀疏模型总共有约671亿个参数，但处理每个token时只调用其中约37亿个，其余参数静静躺在内存里不参与计算。256个专家中只激活一小部分，被调用的那部分叫活跃参数，全部参数叫总参数，两者的比值就是稀疏度。

计算时间的公式直觉。你要同时处理的token越多，活跃参数越多，计算量就越大。把计算量除以芯片每秒能做多少次浮点运算，这个指标叫FLOPS，就得到计算时间：

> 方程② 计算时间： T_计算 = batch × 活跃参数 / FLOPS

2、瓶颈二：内存读取。把数据从内存搬到芯片要花多长时间

算得再快，数据搬不过来也没用。GPU上最快的存储叫HBM，全称高带宽内存，它紧贴在芯片旁边，读写速度远高于普通内存。即便如此，把模型的全部参数从HBM读进计算单元，仍然需要时间。

内存读取又分两部分。第一部分是读权重：模型的全部参数都存在HBM里，每一步推理都要完整读一遍。第二部分是读KV缓存。KV缓存是什么？每生成一个新token，模型需要"关注"此前所有token的内部表示，也就是第一个词说了什么、第二个词说了什么。这些中间结果就存成了KV缓存。新token要和全部历史token做一次注意力计算，这一步主要是在读内存里的KV缓存，计算本身反而不重。把这两部分加起来：

> 方程③ 内存时间： T_内存 = 总参数/带宽 + batch × 上下文长度 × 每token字节数/带宽

3、两条线交叉，决定了延迟的形状

把这两个瓶颈画成关于"同时处理多少个用户"的曲线。计算时间是一条从零开始的直线，用户越多计算量越大。内存读取时间是一条从高处出发、缓慢上升的线，因为不管有没有用户，权重都得读一遍，KV缓存随用户数增长。

两条线在某处交叉。交叉点左侧，内存读取更慢，它是瓶颈；右侧，计算更慢，它接管了瓶颈。关键信息是：左侧有一个延迟的硬下界，就是"把全部参数从HBM读一遍"的时间。以英伟达Nvidia Rubin一代GPU为例：288 GB的HBM容量除以约20 TB/s的读取带宽，约15毫秒。实际运行中，模型"跑一遍"生成一个token通常落在20毫秒左右。

4、GPU调度像火车发车：每20毫秒一班

这20毫秒意味着GPU按固定间隔启动推理。每20毫秒发一班"火车"，不管车上坐满没坐满都按时出发。新到的用户请求搭下一班。最差情况是你的请求恰好在上一班车刚走时到达，要等一个完整间隔再加一次执行时间，总共约40毫秒。

二、Batch的经济学：为什么快速模式贵，慢模式却省不了钱

上一章提到"同时处理多少个用户"，行业里叫batch size，字面意思是批量大小。当你调用Claude API时，你的请求不是独占一块GPU的，它会和成百上千个其他用户的请求被打包在一起，共同完成一次推理。batch越大，同一拨处理的用户越多。

Reiner在开场时提到，影响延迟和成本权衡的杠杆主要有两个：一个是batch size，另一个是speculative decoding，即让模型一次猜多个token再验证，用更多计算换更低延迟。这堂课聚焦在batch size这个更基础也更有解释力的杠杆上。

1、Batch对单个token的成本影响是千倍级的

> 方程④ 单token成本： 成本 = T / batch

把上一章的延迟除以batch size，就得到每个token的成本。权重读取是固定开销：无论是1个用户还是2000个用户，GPU都要把全部权重从HBM读一遍。1个用户独自承担这笔开销，和2000个用户均摊，差了2000倍。所以成本曲线随batch增大急剧下降。

但计算时间和KV缓存读取是每个用户独享的。你的KV缓存记录的是你这段对话的历史，别人用不了。所以这两项摊不掉，它们构成了成本的硬性下界。综合来看，batch为1时成本趋向无穷大，batch增大后迅速下降，最终收敛到这个下界。Reiner说，不做batch的推理经济性可以比充分batch差上1000倍。这个数字直接从方程读出来。

2、临界batch size只取决于硬件参数和稀疏度

令内存读取时间等于计算时间，也就是让两个瓶颈刚好平衡，解出来的临界batch size：

> 方程⑤ 临界batch size： ≈ FLOPS/内存带宽 × 总参数/活跃参数 ≈ 300 × 稀疏度

前半部分是硬件参数。FLOPS除以内存带宽在做FP4运算时约等于300。FP4是当前主流的推理精度格式，每个数字只占半个字节。这个比值在A100到B100等多代GPU上保持稳定。后半部分是模型的稀疏度。对DeepSeek V3来说稀疏度约为8，所以临界batch size ≈ 300 × 8 = 2400。实际部署一般再乘2到3倍。

一个令人惊讶的结论：临界batch size和模型大小无关，只取决于芯片特性和稀疏度。

3、2400个并发序列意味着什么？

这里的batch size指的是同时处理的序列数，每个序列对应一个用户的一次请求。换算成吞吐量：2400个序列 × 每秒约64步 ≈ 15万tokens/s。Gemini去年公开的全球流量在数亿tokens/s量级，所以一个这样的推理单元大约是Gemini全球流量的千分之一。对一个有规模的API服务来说，凑齐2400个并发序列并不困难。

4、为什么"慢模式"省不了多少钱

Claude Code如果推出"慢模式"，用户愿意等更久换更低价格。但从成本曲线看，一旦batch已经足够大让计算成为瓶颈，成本就到底了。再等更久、再塞更多用户进同一个batch，都改变不了每个用户独享的计算和KV缓存开销。反过来，"快速模式"用更小的batch换更低延迟，代价是权重读取无法被充分摊薄，成本显著上升。

5、稀疏度的回报递减：64倍专家只换来4倍质量

Reiner引用了一篇题为Unified Scaling Laws for Routed Language Models的论文。保持活跃参数不变、不断增加专家数量，模型质量确实持续提升，但回报递减严重：一个370M活跃参数、64专家的稀疏模型，质量仅持平于一个1.3B的稠密模型。总参数膨胀了64倍，才换来等效于4倍活跃参数的质量收益。

从推理经济学看，这仍然是划算的交易。稀疏模型多出来的参数只增加权重读取时间，而这恰好是被batch摊薄的那部分开销，多跑点用户就消化了。但从内存容量来看，它吃掉的是机架上宝贵的HBM空间。这个空间的争夺将在后面的章节反复出现。

三、2400个序列在物理硬件上怎么跑：MoE的机架布局

知道了临界batch size，下一个问题是：这2400个序列在硬件上如何分配？答案取决于模型的MoE层怎么铺在GPU机架上。MoE全称Mixture of Experts，混合专家模型，前面提到的"256个专家只激活少数几个"就是MoE的工作方式。路由器根据每个token的内容决定它去哪几个专家，其余专家不参与计算。

1、专家并行：每个专家住在不同的GPU上

以DeepSeek的256个专家为例，英伟达Blackwell NVL72机架有72块GPU，取64块方便整除，每块GPU放4个专家。路由器给每个token分配专家时，这些专家可能散布在任何GPU上，所以会出现一种叫all-to-all的通信模式，中文叫"全对全"：任意一块GPU都可能需要向任意其他GPU发送数据。

2、机架内部的全连接网络完美匹配这种通信

Blackwell机架的内部通信走Scale-up网络。Scale-up是指同一机架内GPU之间的高速互连：72块GPU都连到机架中间的NV Switch交换机上，任意两块GPU只需两跳就能通信。想象一个书架，GPU是两侧的书，中间有线缆通向每一本书，任何两本书之间传递东西都只要经过中间这一站。

离开机架后走的是Scale-out网络，即机架之间的数据中心网络，带宽大约只有Scale-up的八分之一。如果把MoE层跨两个机架部署，平均一半的token需要走机架间的慢速链路，这就成了瓶颈。结论：一个机架就是一个MoE层能铺开的物理边界。

3、扩大Scale-up域真正解决的是带宽问题，而非容量问题

Hopper一代只有8块GPU在一个Scale-up域内，总共约640 GB的HBM。Blackwell扩到72块GPU、约13.5 TB HBM。容量增长了20倍，但更重要的是带宽增长：读权重的时间 = 总参数量 / 整个Scale-up域的总带宽。域内所有GPU是并行读取的，从8块GPU扩到72块，总带宽直接乘了9倍，读权重的时间缩到原来的九分之一。

容量问题其实有别的解法。后面会讲到，pipeline并行可以把权重分到多个机架上分别存储。但带宽问题只有更大的Scale-up域能解决，因为pipeline并行的不同stage是先后执行、不是同时读取的。Reiner的原话是："Pipelining totally solves the capacity problem, but scale-up size helps solve the bandwidth problem."这两件事必须分开理解。

这也解释了一个产业之谜：GPT-4在2023年发布时据传已是万亿参数级别，但此后三年模型参数并没有大幅增长。原因之一是更大的稀疏模型需要更大的Scale-up域来提供足够的带宽，否则读权重太慢，推理延迟不可接受。Rubin一代将进一步推出NVL144甚至NVL576，576块GPU通过铜缆加光互连组成一个域。

扩大Scale-up域的障碍出乎意料地物理。从8块GPU到72块主要是产品形态的切换，从小型计算托盘tray换成整柜式机架rack。到576块则需要全新的物理设计来布更多线缆。限制因素是线缆弯曲半径、连接器密度、机架承重、散热空间。现代AI机架在这四个维度上都已推到物理极限。

Reiner还提到，谷歌的TPU较早就拥有大Scale-up域，这可能是Gemini在预训练上比其他实验室更成功的原因之一。但他也说，模型架构、训练数据等因素和硬件拓扑纠缠在一起，难以拆开归因。

4、全球缺内存，但单个机架内存过剩

Reiner引用了一个数据：超大规模数据中心今年的资本开支有大约一半花在了内存上，总额可能达到数千亿美元。这直接导致消费电子的内存供应紧张。但与此同时，单个Blackwell机架有13.5 TB的HBM，而一个万亿参数的模型只需要约1 TB来存权重。内存容量在单机架层面其实是富余的。

矛盾在于：不是每块GPU上都缺内存，而是全球需要的GPU总量太大了。每块GPU自带的HBM容量足够甚至过剩，但全世界同时需要几百万块这样的GPU，HBM的总产能跟不上。这说明当前的瓶颈不在单机架的硬件设计上，而在半导体供应链上。

四、跨越机架的边界：流水线并行和它帮不了的事

前三章分析的都是推理发生在单个机架内部的情况。但如果模型大到一个机架放不下，或者想用更多机架来加速呢？这就引出了另一种并行策略，流水线并行。理解它需要短暂进入训练的视角，因为它在训练中的限制恰好解释了它为什么在推理中反而简单。

1、流水线并行：把不同的层放在不同的机架上

一个大模型有上百层。流水线并行把这些层分段，第1到25层放在机架A，第26到50层放在机架B，以此类推。数据像流水线一样依次通过每个机架。

机架间的通信量远小于机架内的全对全。专家并行时，机架内的数据量是batch × 激活专家数 × 层数 × 2（数据一进一出两趟）；流水线并行时，机架间只需传一份激活值，数据量等于batch大小。两者的比值容易超过8，也就是Scale-up与Scale-out的带宽比，所以跨机架通信不是瓶颈。

Reiner指出：最优的并行方式恰好和模型本身的结构一一对应。专家放在不同GPU上，层放在不同机架上。没有什么精巧的切法，就是最直觉的映射。过去还有一种叫tensor parallelism的做法，把单个专家的矩阵切开分到多块GPU上，但随着MoE中单个专家越做越小，这种做法已经不划算了。

2、训练中的pipeline bubble：为什么流水线并行有代价

训练和推理有一个关键区别。训练分两步：前向传播是把数据送进模型算出预测；反向传播是根据预测和答案之间的差距往回调整参数。训练时有一个固定大小的全局batch，要先做完所有样本的前向传播，再统一做反向传播。

如果用流水线并行，全局batch必须拆成更小的micro-batch来填满流水线的各个stage（每个stage就是一个机架上的一段层）。拆的原因是：如果整个batch一口气从第一个stage走到最后一个stage，中间那些stage在等前面算完，全程空转浪费。拆成小块后可以"错峰通行"，但前向阶段和反向阶段之间仍然会出现一段空闲期，叫pipeline bubble。

Reiner提到，Ilia Sutskever曾说过"今天我们知道不该做pipeline并行"。原因除了bubble之外，还有一层：pipeline并行给模型架构带来硬约束。比如Kimi的模型使用了跨层残差连接，让注意力可以关注好几层之前的信息，这在pipeline切分下难以实现，因为那几层可能分布在不同机架上。架构自由度的损失有时比bubble本身更严重。

3、推理中的流水线并行：吞吐免费，但有延迟代价

推理时不存在训练那种"前向完了要统一反向"的约束。一个batch在第一个stage完成后，下一个batch立刻进入，不会产生空闲。从吞吐量角度看，流水线并行在推理中既不改善也不恶化性能，它只是把同样的计算分到了不同机架上。

但延迟有代价。每跨一次机架，数据要从GPU到网卡、到机架顶交换机、到对面机架，再反向走一遍。每一跳大约增加几毫秒。如果有4个pipeline stage，每个token的生成可能从20毫秒增加到约30毫秒，延迟增幅达50%。对于需要快速响应的应用场景，这不是可以忽略的开销。

它真正的好处是降低每个机架需要存储的权重量。但Blackwell NVL72一个机架有约13.5 TB的HBM，而一万亿参数的模型只需约1 TB来存权重，容量其实富余。所以实际推理中，流水线并行只做到2个stage甚至不做。

4、KV缓存：唯一无法被任何并行策略分摊的开销

这是全文最关键的推导之一。数学结论是：增加pipeline stage数后，权重的单GPU内存占用按stage数等比下降，但KV缓存的单GPU占用纹丝不动。

原因是这样的：如果pipeline有4个stage，你就需要同时维护4个micro-batch来填满流水线防止空转。每个micro-batch对应一批不同的用户，每批用户都有自己独立的对话历史，因此都带着自己的KV缓存。stage数翻倍，同时在飞的micro-batch也翻倍，总KV缓存量不变。

再回忆第二章的结论：KV缓存在batch维度也摊不掉，因为每个用户的对话历史是独享的。所以KV缓存在batch维度摊不掉，在流水线维度也分不掉。这就是为什么DeepSeek论文中报告的推理方案主要依赖专家并行，把它扩到整个Scale-up域，几乎不做流水线并行。

KV缓存是AI推理中最顽固的成本项。后面两章会反复回到这个主题。

五、从API报价单反推模型架构

前四章建立了一套分析框架。现在Reiner用它来做一件事：拿着各家公开的API报价单，反推他们背后的硬件和模型配置。

1、长上下文涨价50%，泄露了每个token的KV缓存大小

Gemini 3.1在超过200K token时价格上涨50%。为什么恰好在这个长度涨价？因为200K附近是第一章那两条线的交叉点：短于200K时瓶颈是计算，长于200K时KV缓存的内存读取超过了计算，成了新的瓶颈。涨价50%对应的是内存读取时间追上了计算时间，总成本增加约一半。

利用这个交叉点可以解一个方程。令KV缓存的内存读取时间等于计算时间：

> 方程⑥ 从定价反推KV缓存： 每token字节数 = 活跃参数 / (FLOPS/带宽 × 上下文长度)

代入活跃参数约1000亿、上下文200K、FLOPS与带宽之比约300，解出每个token在KV缓存中占约2 KB。

2 KB可以由两种注意力架构实现。一种是Character AI和Gemma式的层间共享方案：每个注意力头的向量维度d_head为128，配8个KV head，K和V各一份，所有层共享同一份KV缓存，合计8×128×2 = 2048字节 ≈ 2 KB。另一种是稀疏注意力：每层各有独立的KV缓存，但只关注部分历史token而非全部，总量也落在同一量级。

API定价为什么会泄露这些信息？因为定价必须高于成本，否则会被套利。价格贴着成本走，成本的形状就映射到了价格上。

2、输出比输入贵5倍，说明GPU大部分时间在等数据

处理输入时叫prefill，预填充：用户发来的整段文本被一起送进模型，多个token同时做矩阵乘法，计算量随输入长度线性增长，但内存读取几乎不变。一万个token分摊同一次权重读取和已有KV缓存读取，单个token的成本极低。

生成输出时叫decode，解码：每一步只生成一个token，但全部权重和KV缓存照读不误。decode等于读了一大堆内存只处理了1个token，prefill同样读这么多内存却处理了成千上万个token。

如果GPU是计算受限的，输入和输出价格应该一样。5倍差价直接说明decode端的GPU大部分时间在等数据从HBM搬进来，而非在做乘法。

3、缓存定价的三种选项：重算、短存、长存

当一段对话暂时中断，KV缓存怎么处理？有三种选项。

第一种是完全丢弃，用户回来时从头重算。重算的成本就是对整段对话重新做一次前向传播。这适合极少复用的场景，相当于用计算换存储空间。

第二种和第三种是存下来，区别在于存在哪一层。API上提供两种缓存保留选项，分别是5分钟和1小时，价格不同。这两个档位对应的是不同的物理存储层级。

Reiner用一个叫"排空时间"的概念来判断：排空时间 = 存储容量 / 带宽，即把整块存储从头读到尾需要多久。HBM的排空时间约20毫秒，服务器主内存DDR在秒级，闪存在分钟级，机械硬盘在小时级。5分钟和1小时分别落在闪存和机械硬盘的区间内。

背后的经济学是两类成本的平衡。持有成本是KV缓存占了多大比例的存储空间乘以占用时间，这段时间里这块空间不能给别的用户用。取回成本是重新使用时从该存储层级搬回HBM需要的时间，这段时间GPU也在等。存储越慢越便宜，持有成本低但取回成本高。当两者相等时，就找到了该层级最适合的保存时长。加上"完全不存、从头重算"这个选项，就构成了一条从纯计算到纯存储的完整光谱。

4、为什么所有模型的上下文长度都卡在200K左右

前面的分析指向一个硬约束：上下文越长，KV缓存越大，内存带宽消耗越高。而HBM带宽的演进速度远慢于算力增长。稀疏注意力是目前最有希望的缓解方案，比如DeepSeek发表的方案把KV缓存的读取量从和上下文长度成正比降到和平方根成正比。但稀疏到一定程度，模型不再能有效关注远处的信息，质量会下降。

Reiner直接说："I actually don't see a very good path to solving that."从一个硬件架构师嘴里说出"我看不到解法"，意味着上下文长度的停滞不是缺乏工程努力，而是一堵物理上的墙。

六、训练的经济学：为什么前沿模型被过度训练了100倍

前五章聚焦于推理，也就是模型上线给用户提供服务的过程。但训练和推理的成本加在一起才是完整的图景。Reiner提出的问题是：给定一个固定的总预算，应该怎么分配在预训练、RL和推理之间？RL即强化学习，近年来在大模型训练后期用来提升推理能力。

1、三类成本的等分原则

Reiner用了一个启发式法则：当总成本等于几项成本之和，而每一项都随某个变量单调变化时，最优点往往在各项成本相等处。这在经济学和物理学中反复出现，比如运输成本和库存成本的平衡。

预训练成本遵循经典的6ND公式，6 × N × D，N是活跃参数数，D是训练数据的token总量。6这个系数来自训练的两步。前向传播把数据送进模型算出预测，反向传播根据误差调整参数。每个参数在这两步中总共涉及6次浮点运算。

RL成本结构类似但效率更低。生成rollout，也就是模型尝试回答问题的完整推理轨迹，只需要前向传播，对应2ND。但RL不是每条轨迹都拿来训练，表现差的会丢弃。加上decode阶段的硬件利用率MFU远低于训练。MFU衡量的是芯片实际算力占理论峰值的比例，decode因为内存瓶颈严重，利用率偏低。综合下来效率因子约为0.2。推理成本 = 2 × N × D_inference。

令三项成本相等后，N完全消掉：

> 方程⑦ 训练/推理均衡： D_预训练 ≈ D_RL ≈ D_推理

结论是：预训练数据量 ≈ RL数据量 ≈ 推理token总量，在数量级上相当。

2、用公开数据验证：推理token总量约200万亿

假设一个Gemini级别的单一模型全球流量约5000万tokens/s，模型存活期约2个月后被新版本替代，计算得到约200万亿个token。有传言前沿模型的预训练数据已达150万亿token，与推理token在同一数量级，和"三等分"的推导吻合。

3、对比Chinchilla最优：过度训练约100倍

Chinchilla scaling law是DeepMind在2022年提出的经验法则：如果只考虑预训练效率而忽略推理成本，最优训练数据量约为活跃参数量的20倍。活跃参数约1000亿的话，Chinchilla最优约2万亿token。

但实际训练数据量在100到200万亿量级，超出Chinchilla最优约100倍。这不是浪费。推理经济性驱动的逻辑是：缩小模型的活跃参数让每次推理更便宜，同时灌入更多训练数据弥补模型变小带来的质量损失。当推理流量足够大时，省下的推理成本远超多花的训练成本。100倍的过度训练，是训练和推理联合优化的产物。

4、模型过时风险会把天平推向更少的训练

上面的分析假设模型训完就能上线服务用户。但如果你训完发现它不是最好的呢？Reiner指出，应该按"模型成功上线"的概率来折减推理token数。如果你判断自己的模型只有50%概率成为最佳选择，那推理token的期望值就减半，对应的预训练数据量也应该减少。这意味着"三等分"法则在实践中会偏离，偏离的方向是训练占比更小、推理占比更大。实验室对自身竞争力的判断直接影响训练规模的决策。

七、神经网络与密码学：一个意想不到的交汇

1、共同的底层需求：把信息充分混合

密码学和神经网络看起来是完全不同的领域，但Reiner指出它们共享一个底层机制：把信息在各个维度上充分搅拌。密码学要把有结构的输入搅成不可区分的随机噪声用于加密，神经网络要从看似杂乱的输入中提取高级结构用于理解。方向相反，搅拌的手法相似。

这个相似性不只是类比。密码学中攻击cipher的经典方法叫差分密码分析，本质就是对cipher求导：给输入做一个微小扰动，观察输出变化多大。一个好的cipher必须具备"雪崩效应"，即输入的微小变化会导致输出的剧烈变化。

同样的雪崩效应在神经网络中却是灾难。对抗攻击，即在图像中加入人眼不可见的微小扰动就让分类器完全出错，利用的正是这个性质。cipher把它当成目标去追求，神经网络把它当成漏洞去修补。

2、Feistel网络：从密码学直接移植到深度学习

密码学中有一个经典构造叫Feistel网络，它能把任何不可逆的函数变成可逆的。方法是：把输入拆成两半(x, y)，让x通过函数f后加到y上，输出为(y, x + f(x))。恢复时x直接读出，y通过z - f(x)算回来。这个构造至今仍是对称加密的核心机制。

2017-2018年的RevNets论文把完全相同的构造搬进了Transformer。RevNets是可逆网络的缩写。输入分成两路，一路通过Transformer层后加到另一路上，两路交叉前进。效果是残差连接实际上跨了两层，整个网络变成可逆的。残差连接是深度学习中让输入跳过某一层直接加到输出上的快捷通道，有了它网络才能堆到上百层。

3、可逆网络的实际用途：用计算换内存

正常训练中，前向传播每一层都会产生中间结果叫激活值，这些激活值要存进HBM留给反向传播用。激活值的内存占用随层数线性增长，可以是训练中最大的内存开销。

RevNets因为整个网络可逆，反向传播时可以一边回退一边从当前状态重新算出前面的激活值，不需要提前存储。代价是多做一遍计算。

4、两个领域真正交汇的地方：后门

Reiner认为密码学和神经网络真正共享的深层概念是后门。在密码学中，后门是设计者预埋在cipher里的秘密入口，让特定的人可以绕过加密。在神经网络中，后门攻击是在训练数据或训练过程中植入隐蔽的触发器，让模型在特定输入下产生攻击者想要的输出。

两者的共同点在于：后门都是在一个看似随机的系统中隐藏了结构化的信息。密码学花了几十年研究如何检测和防御后门，神经网络的后门防御还处于早期阶段。

Reiner点出一个贯穿全文的对称性：KV缓存是"花内存省计算"，把中间结果存起来避免重算；RevNets是"花计算省内存"，每次重算避免存储。在当前硬件条件下内存昂贵而计算相对充裕，"花内存省计算"通常更划算。 http://t.cn/AXJC2EVM