硬核拆解：GPT-5、Claude和Gemini是如何訓練和推理的？

一塊黑板、幾個方程式，芯片工程師Reiner Pope用這些工具，拆解了GPT-5、Claude和Gemini背后的訓練與推理邏輯，并從公開的API定價中，反推出大模型不愿公開的架構細節。

近日，知名科技播客主持人Dwarkesh Patel與芯片創業公司MatX的CEO Reiner Pope進行了一場罕見以黑板推演為形式的深度對話。Pope此前在谷歌負責TPU架構與編譯器優化，被認為是少數真正貫通AI全棧——從芯片設計到模型架構——的工程師之一。

Pope在黑板前用方程和圖表，系統拆解了前沿大模型從訓練到推理的底層邏輯。在Dwarkesh看來，這些細節“一旦理解，AI為何是今天這個樣子——架構、定價、進步速度——就全都說得通了”。

核心結論包括：如果不批量處理用戶請求，單次推理成本可能高出1000倍。而GPT-5的預訓練數據量，是理論最優解的100倍。此外，DeepSeek V3擁有256個專家，每次推理只激活其中一小部分（32個）。MoE（混合專家）架構被限制在一個機架72塊GPU以內，這是制約模型規模擴展的核心物理瓶頸之一。

一塊GPU機架，決定了模型有多大

要理解頂級大模型為何是現在這個樣子，得先從硬件說起。

現代大模型推理跑在GPU集群上。英偉達Blackwell NVL72是目前主流的部署形態——一個機架塞了72塊GPU，通過NVLink高速互聯，任意兩塊GPU之間只需兩跳（經過中間交換機），通信帶寬極高。

但一旦跨出這個機架，通信速度就慢了8倍。

這個"8倍差距"，直接決定了MoE（混合專家模型）的部署上限。

DeepSeek V3擁有256個專家，每次推理只激活其中一小部分（32個）。Pope解釋，最自然的部署方式是"專家并行"——不同專家放在不同GPU上。任何GPU都可能向任何其他GPU發送token，這是一種"全對全"（all-to-all）通信模式，和機架內NVLink的拓撲結構完美契合。

但一旦專家分布到兩個機架，問題就來了：跨機架的token有一半要走慢8倍的網絡，直接成為瓶頸。

"一個機架的大小，限制了你能做多大的專家層。" Pope說。

這就解釋了一個市場上長期困惑的問題：為什么Gemini看起來比其他實驗室更早取得大模型預訓練的成功？Pope的推斷是，谷歌的TPU系統長期擁有更大的scale-up域，能在更大范圍內做全對全通信，這讓它可以部署更高稀疏度的MoE模型，同時維持推理效率。

批處理：省1000倍成本的秘密

訪談還提及一個市場常見現象：Claude、Codex等產品提供“快速模式”，價格高出6倍，速度卻只快2.5倍。為什么？能不能反過來，用“慢速模式”換取更低價格？

Pope的回答直接：核心變量是批處理規模（batch size）。他用一個"發車時刻表"的比喻解釋了背后的邏輯。

GPU每隔約20毫秒發出一班"列車"（執行一次批處理推理）。每班列車能搭多少乘客，就是批處理大小（batch size）。

核心結論是：推理的單位成本，在批處理量小的時候極高，隨著批處理增大會急劇下降，最終趨于一個下限。

原因是權重加載成本的攤銷。每次推理都要把模型權重從內存（HBM）讀入芯片。這個成本是固定的，不管服務1個用戶還是2000個用戶，權重只讀一次。如果只服務1個用戶，這個固定成本就全壓在他身上；服務2000個用戶，成本均攤后幾乎可以忽略不計。

Pope估算，如果不做批處理，成本可以高出1000倍。

那最優批處理規模是多少？Pope給出了一個簡潔的公式：約等于300乘以模型稀疏度。對DeepSeek這類激活1/8專家的模型，大約是2400個并發序列。這個數字與模型總參數量無關，只取決于硬件特性和稀疏度——這是一個"反直覺"的結論。

所以，"慢速模式"真的能便宜很多嗎？從數學上看，不太行。KV緩存（存儲每個用戶歷史對話的內存）無法在不同用戶之間共享攤銷，因此讓用戶多等并不能顯著降低成本。Pope說："（慢速模式）節省不了太多，因為KV緩存是每個用戶獨立的，計算量也是獨立的。"

從API定價，反推模型架構

Pope展示了一個讓人印象深刻的推理過程：通過公開的API定價，可以反推出模型的內部架構參數。

線索一：Gemini在20萬 token處漲價50%，為什么恰好是50%？為什么恰好在20萬Token這個節點？

Gemini 3.1的定價在超過20萬 token后上漲50%。Pope解釋，這對應著KV緩存的內存帶寬成本超過權重矩陣計算成本的臨界點——也就是模型從"計算瓶頸"切換到"內存帶寬瓶頸"的轉折點。

他進一步用這個數字反算：假設激活參數約1000億，臨界點在20萬 token，可以推算出每個token的KV緩存大約占2KB。這與Character AI等公開論文中描述的注意力機制參數（8個KV頭，維度128）高度吻合。

"他們通過API定價泄露了相當多的信息。" Pope說，"當然，他們有動力把價格定得接近成本，否則競爭對手可以搶走用戶。"

線索二：輸出比輸入貴5倍

大多數模型的輸出token（decode）比輸入token（prefill）貴約3-5倍。原因在于：

• Prefill階段：一次性并行處理大量輸入token，計算效率高，接近"計算瓶頸"

• Decode階段：每次只生成一個token，要讀取全部模型權重和KV緩存，極度受內存帶寬瓶頸制約

這個價格差，實際上量化了當前頂級模型推理時的內存帶寬瓶頸程度。

線索三：緩存命中為何便宜10倍

API通常對"緩存命中"的token大幅打折。Pope解釋，這對應的是存儲KV緩存在不同內存層級的成本差異：重新計算一次（從token ID從頭生成KV緩存）versus從HBM/DDR/閃存中直接讀取。

他進一步推算，按照Gemini"5分鐘緩存"與"1小時緩存"的定價差異，可以推斷這兩個檔位對應的存儲介質分別是閃存和機械硬盤——后者讓Pope也感到驚訝："我沒想到機械硬盤會被用在這里。"

GPT-5過度訓練了多少？答案是100倍

這是整場講座最具震撼性的推算。

Pope從一個經濟學直覺出發：當預訓練成本、RL訓練成本、推理成本三者大致相等時，整體效率最優。

他把這三塊成本寫出來，發現激活參數量這個變量直接消掉了——也就是說，最優訓練量的推算與模型大小本身無關，只取決于推理流量。

然后他代入真實數字：

• 假設某前沿模型推理流量約5000萬token/秒（全部流量除以一個家族中的多個模型版本）

• 模型生命周期約2個月（在下一版本發布前）

• 合計推理token數約200萬億（2×101?）

Chinchilla最優解（基于約1000億激活參數）大約是2萬億token。

兩者之比：100倍。

也就是說，當前頂級模型的預訓練數據量，約是從純訓練效率角度出發所需數據量的100倍。

"我們知道這大概是對的，因為有傳言說GPT-5預訓練了約150萬億token，和我們算出的200萬億很接近。" Patel說。

Pope補充說，這個推算的核心邏輯是：你花在服務用戶上的計算，應該和你花在訓練上的計算大體相當。否則，就是在某一頭浪費錢。

用Patel的話說："如果GPT-5要被最優地訓練，那么所有用戶使用它產生的token總量，應該等于預訓練消耗的token總量——而預訓練數據，大約就是人類知識的總和。"

Pope對此回應："大致如此。"

流水線并行：聽起來很美，但大多數時候用不上

關于流水線并行（把模型的不同層分散到不同機架上串行執行），Pope的結論是：它能節省內存容量，但解決不了KV緩存問題，因此在推理場景價值有限。

直覺上，流水線并行需要同時保持多個"在途"的batch，這讓全局batch大小隨流水線級數成比例增長。雖然每個機架上的權重存儲減少了，但所有機架上的KV緩存總量并沒有減少——因為需要更多并發序列來填滿流水線。

"你無法跨pipeline階段攤銷KV緩存，就像你無法跨batch攤銷KV緩存一樣。" Pope總結道。

這也解釋了為什么Ilya Sutskever曾說"現在我們都知道，流水線并行是不明智的"——這句話在訪談中被Patel引用，而Pope的推演給出了工程層面的注解。

神經網絡與密碼學的“趨同進化”

訪談最后，Pope談到了他寫過的一篇博客觀點：神經網絡的架構與密碼學協議之間存在"趨同進化"。

兩者都需要把輸入信息在整個系統中充分混合——密碼學是為了讓輸出看起來像隨機噪聲，神經網絡是為了提取隱藏的高層結構。但目標恰好相反：密碼學努力破壞結構，神經網絡努力發現結構。

Pope提到了一個具體的技術遷移案例：Feistel網絡——一種密碼學中用于讓不可逆函數變得可逆的構造，在2017年被引入神經網絡，形成了"RevNets"（可逆網絡）。RevNets允許在訓練的反向傳播過程中，無需預先存儲所有層的激活值，而是邊反向傳播邊重新計算——用更多計算換取更少內存。

這與KV緩存的邏輯恰好相反：KV緩存是用更多內存換取更少計算。Pope說，"用內存換計算，在當前的硬件條件下通常是合算的。"

訪談全文如下：

GPT-5、Claude 和 Gemini 的訓練與推理機制——Reiner Pope 主講
主持人：Dwarkesh Patel 嘉賓：Reiner Pope（MatX 首席執行官）
節目說明： 本期采用了全新的黑板講座形式，由 Reiner Pope 系統講解前沿大語言模型的訓練與推理原理。內容涉及大量數據與數學推導，令人驚訝的是，僅憑幾個公式、公開的 API 價格和一支粉筆，就能推斷出各大實驗室正在做什么。內容略有技術性，但非常值得深入了解。
Reiner 是芯片創業公司 MatX 的 CEO（披露：主持人 Dwarkesh 是 MatX 的天使投資人）。他此前在 Google 從事軟件效率、編譯器和 TPU 架構工作，是極少數能夠貫通從芯片設計到模型架構整個技術棧的專家之一。


第一章：批量大小如何影響 Token 成本與速度Dwarkesh： 今天我采訪的是 Reiner Pope，他是新芯片創業公司 MatX 的 CEO。此前他在 Google 主導了 TPU 架構等多項工作。本期采用黑板講座的全新形式，我們專門為此打造了新的錄制空間。今天要聊的話題涵蓋模型架構、機器學習基礎設施等諸多方面。
我認為這個話題非常重要。一旦你理解了訓練和推理在集群中的運作方式，很多問題就會豁然開朗——為什么 AI 是現在這個樣子，為什么 AI 架構是現在這個樣子，為什么 API 價格是現在這個樣子，以及為什么 AI 進步是現在這個節奏。要真正理解這些，你需要深入細節，而深入細節就需要一塊黑板。Reiner，非常感謝你來參加。
首先，我想請你解釋一個現象。現在有幾家公司，比如 Claude、Codex 和 Cursor，都提供類似"快速模式"的選項——花費 6 倍的價格，可以獲得 2.5 倍的 Token 輸出速度。我有幾個問題：

1. 這背后的機制是什么？為什么付更多的錢就能獲得更低的延遲？
   
2. 這種模式能一直延伸下去嗎？比如付 100 倍的價格，能獲得更快的速度嗎？
   
3. 反過來是否也成立？比如推出"慢速模式"——如果用戶愿意等幾分鐘，能否獲得更低廉的價格？
   

Reiner： 直接說結論：最大的影響因素是批量大小（batch size）。接下來我們會精確量化這一點，分析它對延遲和成本的影響。另外還有一個效應，叫做推測解碼（speculative decoding）或多 Token 預測（multi-token prediction），我們之后可以回頭討論，但首先要講的是批量大小。
我想引入兩個分析原則：
第一，屋頂線分析（roofline analysis）。 我們來分析如何在一個芯片集群上運行 Transformer 模型。以 Blackwell NVL72 集群為例，也就是一個 72 塊 GPU 的機架。屋頂線分析關注的是內存帶寬和計算性能這兩個維度。
第二，只關注模型的兩個簡單因素： 操作權重的時間，以及操作上下文（即 KV 緩存）的時間。
我們嘗試估算運行某種形狀的推理所需的時間。這不是精確預測，而是近似——我們會說"時間大于等于某個量"。我們考慮兩個方面：內存讀取所需時間，以及計算所需時間。這個簡單模型能給我們非常強的預測能力。
計算時間（t_compute）如何估算？
需要做兩件事：一是乘以所有活躍參數；二是做注意力計算。
對于權重矩陣乘法的計算時間，公式如下：
tcompute=B×NactiveFLOPstcompute=FLOPsB×Nactive

【注：B 為批量大小，N_active 為活躍參數數量，FLOPs 為芯片的浮點運算吞吐量。注意力計算部分相對較小，可忽略。】

內存時間（t_mem）如何估算？

需要取出所有權重，以及讀取 KV 緩存：

tmem=Ntotal內存帶寬+B×Lcontext×bytes_per_token內存帶寬tmem=內存帶寬Ntotal+內存帶寬B×Lcontext×bytes_per_token

【注：N_total 為總參數量（不只是活躍參數），第二項是 KV 緩存讀取時間，與批量大小和上下文長度成正比。】

Dwarkesh： 批量指的是同時服務多個用戶，對吧？

Reiner： 對。批量的意義也正在于此——如果不把多個用戶合并成一批，成本和經濟性可能比合并處理差一千倍。我們稍后會清楚地看到這一點。

以 DeepSeek V3 為例，它有約 370 億活躍參數，總參數約 7000 億。我們關注的是處理單個 Token 時用到的活躍參數。

關于 KV 緩存，簡單解釋一下：

在自回歸推理的解碼階段，已有一批文本 Token，模型要生成下一個 Token。這一步需要對模型中所有層的權重矩陣做完整的前向傳播，同時通過注意力機制，讓當前 Token 關注所有歷史 Token——它關注的是模型對歷史 Token 生成的內部表示，這就是 KV 緩存。

這個"單 Token 關注全部歷史"的過程主要由內存讀取主導，而非矩陣乘法。因此，內存讀取時間由以下公式給出：

tmem=Ntotal+B×Lcontext×bytes_per_token內存帶寬tmem=內存帶寬Ntotal+B×Lcontext×bytes_per_token

而總時間為：

t=max?(tcompute, tmem)t=max(tcompute, tmem)

批量大小 vs. 延遲（latency）圖像分析：

我們先畫批量大小與時間的關系圖。

• t_compute（計算時間）：與批量大小線性正比，無偏移量，是一條過原點的直線。

• t_mem（內存時間）：由兩部分組成。

  • 權重讀取：是一個與批量大小無關的常數（基礎偏移）。

  • KV 緩存讀取：與批量大小近似線性正比。

  • 兩者之和形成一條向上傾斜的曲線。

總時間 t = max(t_compute, t_mem)，取兩條曲線的上包絡線。

這意味著什么？ 這是一張延遲圖。隨著批量大小增大，最初延遲對批量大小的依賴較弱，存在一個延遲下界。這已經部分回答了你的問題：對于給定的硬件配置，延遲存在下界，即把所有參數從內存讀取到芯片所需的最短時間。即便利用全部內存帶寬，也無法比這更快。

Dwarkesh： 從你畫的斜率來看，如果計算時間的斜率始終高于 KV 緩存對內存時間的貢獻斜率，是否意味著批量足夠大時，內存永遠不是瓶頸？

Reiner： 這對上下文長度非常敏感。隨著上下文長度增加，KV 緩存讀取時間會不斷上升，最終會從計算受限（compute-limited）切換到內存受限（memory-limited）。當兩條曲線斜率恰好相等時，意味著系統同時處于內存受限和計算受限的平衡點，這是理想狀態。

以一個簡單的代數例子說明：假設最優上下文長度是 10 萬 Token，如果切換到 20 萬 Token，MFU（模型浮點利用率）會降至約 50%。稍微偏離最優區間，對 MFU 的影響是顯著的。

Dwarkesh： 稀疏注意力（sparse attention）是否能解決這個問題？

Reiner： 我對稀疏注意力很感興趣。Dense（密集）注意力的內存讀取時間與上下文長度成線性關系，而稀疏注意力的擴展性要好得多。DeepSeek 已經發布了稀疏注意力機制的論文，在 KV 緩存這一項中引入了平方根關系，大幅改善了擴展性。至于各大實驗室在實踐中用的是什么，外部很難確定。

批量大小 vs. 成本（cost per token）圖像分析：

成本的含義是：運行這次推理需要占用 GPU 若干毫秒，按小時租用費（例如 2 美元/小時/GPU）換算成成本。而這次推理處理了多少 Token？就是批量大小 B。所以：

每 Token 成本=tB每 Token 成本=Bt

我們把前面三條曲線都除以 B：

• 計算時間曲線：原本與 B 線性正比，除以 B 后變為常數。

• KV 緩存讀取曲線：原本與 B 線性正比，除以 B 后也變為常數。

• 權重讀取曲線：原本是常數，除以 B 后變為雙曲線（parabola），隨 B 增大而下降。

取最大值后，整體形狀如下：在批量大小為 1 時，成本極高（權重讀取無法被攤銷）；隨著批量增大，權重讀取成本被攤銷，趨近于下界，最終由計算時間主導，形成成本下界。

"慢速模式"（Slow Mode）有沒有用？ 基本沒有。因為 KV 緩存和計算對每個批次都是獨一無二的，無法通過更大的批量來攤銷這兩項成本。"慢速模式"只是讓請求在這條成本曲線上停留更久，無法突破那條下界。

最優批量大小的計算：

我們關注的是權重讀取時間等于權重計算時間的那個點（忽略 KV 緩存項以簡化分析）：

Ntotal內存帶寬=B×NactiveFLOPs內存帶寬Ntotal=FLOPsB×Nactive

整理后：

FLOPs / 內存帶寬 = B × (N_active / N_total) 內存帶寬FLOPs=B×NtotalNactive

左邊是一個硬件參數，稱為算術強度比。以 FP4 精度為例（每次乘法 0.5 字節），這個比值在大多數 GPU 上約為 300（無量綱）。右邊的 NactiveNtotalNtotalNactive 是稀疏度參數。因此：

B≥300×NtotalNactive=300稀疏度B≥300×NactiveNtotal=稀疏度300

以 DeepSeek 為例，激活 256 個專家中的 32 個，稀疏度為 1/8，因此：

B≈300×8=2400B≈300×8=2400

這個估算與實踐中的數值非常接近。實踐中通常會取 2 到 3 倍的余量，因為實際效率不如屋頂線分析理想。所以最優批量大小大約是 2000 到 3000 個 Token。

【注：這里的"Token"指的是并發推理序列數——大約 2000 條獨立的對話序列同時做單步解碼，而非一條長序列中的 Token 數。】

Dwarkesh： 加入 KV 緩存后，最優批量大小會有什么變化？

Reiner： 如果加入 KV 緩存，它會消耗更多內存帶寬，權重加載可用的帶寬就減少了，因此需要更大的批量來補償，最優批量大小會增大。

Dwarkesh： 這個數字和 GPU 個數是無關的？

Reiner： 對。結論非常有趣——最優批量大小只取決于稀疏度，與模型規模本身無關（稀疏度本身蘊含了模型規模的信息）。

每秒 Token 數（吞吐量）估算：

每秒 Token 數=BΔt=B×64≈2000×64=128,000 tokens/s每秒 Token 數=ΔtB=B×64≈2000×64=128,000 tokens/s

【注：Δt ≈ 15~20 毫秒，取倒數約為 64/s。】

Dwarkesh： Gemini 去年公布的全球流量是每秒數億 Token，這只是其千分之一左右。

Reiner： 是的。這說明一個系統至少需要達到 Gemini 千分之一的規模才能在市場上有競爭力。這是一個有意思的下界。

關于稀疏度與模型質量的權衡：

論文《Unified Scaling Laws for Routed Language Models》研究了在保持活躍參數量不變的情況下，增加稀疏度對模型質量的影響。根據舊版 MoE 技術的實驗結果，64 個專家、3.7 億活躍參數的模型，質量與 13 億參數的 Dense 模型相當。也就是說，總參數量擴大了 64 倍，才換來了相當于 4 倍活躍參數的效果——代價相當大。

Dwarkesh： 稀疏度增大一倍，總參數量就要擴大 8 倍，這到底是合算的嗎？

Reiner： 從我們的分析框架來看，這是純粹的凈收益——因為更大的總參數量可以通過更大的批量來攤銷，所以只要你有足夠多的用戶，就盡量增加稀疏度。唯一的限制是內存容量：更多的總參數意味著需要更多的內存來存儲權重。

Dwarkesh： 關鍵點是：稀疏度增加，需要的批量也更大，而更大的批量需要更大的內存容量來存儲 KV 緩存，這是內存容量而非內存帶寬的問題。

Reiner： 完全正確。這是個很好的切入點，下面我們可以來聊聊 MoE 層在 GPU 機架上的物理布局。

第二章：MoE 模型在 GPU 機架上的布局方式

Reiner： 我們先放大看 MoE（混合專家）層的結構。一個典型的 MoE 層包括：

1. 路由層（Router）：接收輸入 Token，決定將其路由到哪些專家。

2. 多個專家（Experts）：路由層選擇一小部分專家，例如 256 個中選 1/32。每個專家本身是一個標準 MLP，包含上投影（up projection）、非線性激活和下投影（down projection）。

3. 匯聚與殘差連接：各專家的輸出匯聚求和后，加上輸入 Token 的殘差連接，輸出最終結果。

如何將 MoE 映射到 GPU 機架？標準做法是使用專家并行（expert parallelism）：不同的專家放在不同的 GPU 上。

以 DeepSeek 的 256 個專家為例，在 Blackwell 機架的 72 塊 GPU 上部署：為簡化計算，只用其中 64 塊（忽略其余 8 塊），每塊 GPU 存放 4 個專家。

Token 需要從路由層分發到各個專家所在的 GPU，然后再匯集回來——這產生了全互聯（all-to-all）通信模式：任意 GPU 都可能向任意其他 GPU 發送數據。

Blackwell 機架內的 NVLink 網絡天然支持全互聯通信——每塊 GPU 通過 NVLink 電纜連接到機架內部的 NVSwitch，任意兩塊 GPU 只需兩跳即可通信（GPU → NVSwitch → GPU）。因此，單個機架是 MoE 專家并行的完美場景。

跨機架的問題：

當我需要擴展到兩個機架時，麻煩來了。機架間通信使用的是規模擴展網絡（scale-out network），其帶寬約為機架內 NVLink（scale-up network）的 1/8。這意味著：跨機架部署 MoE 時，約有一半的 Token 需要走這條慢速通道，成為嚴重瓶頸。因此，單個機架限定了 MoE 專家層的規模上界。

這也正是行業一直在推動更大互聯域（interconnect domain）的動力。

機架的物理結構簡介：

機架是一個物理結構，通常高約數米、寬約一到兩米，容納約 64 塊 GPU，受限于供電、重量和散熱能力。Nvidia 的 Blackwell 機架將 GPU 置于機架外側，NVSwitch 置于內部，通過大量電纜連接。

• 機架內（scale-up）： 全互聯，高帶寬，低延遲。

• 機架間（scale-out）： 通過數據中心交換機連接，帶寬約為機架內的 1/8。

從 Hopper 到 Blackwell，scale-up 域的規模變化：

• Hopper：8 塊 GPU 的 scale-up 域（NVLink 域）

• Blackwell：72 塊 GPU（約 64）

• Rubin（下一代）：約 500 塊 GPU

從 Hopper 到 Blackwell 主要是從"托盤"形態切換到"機架"形態的產品決策。從 64 到 500 則需要更復雜的物理機架設計，核心挑戰是電纜密度——隨著 GPU 數量翻倍，電纜密度也要翻倍，受限于機架內的物理空間、電纜彎曲半徑、背板連接器密度以及重量和散熱等多方面約束。

為何不直接建一個超大交換機把所有 GPU 都互聯？ 主要原因是布線擁塞——需要鋪設的電纜數量極其龐大，物理上難以實現。

更大 scale-up 域對 AI 進展的影響：

GPT-4 據傳擁有超過一萬億參數，但直到近半年才有更大規模的模型發布——這是否因為我們一直在等待足夠大的內存來容納一個五萬億參數模型？

Reiner： 是的，這正是關鍵所在。以 Hopper 為例，8 塊 H100 有約 640 GB 顯存（截至 2022 年）。而 Blackwell 的 scale-up 內存終于達到 10~20 TB 量級，足以容納一個五萬億參數模型及其 KV 緩存。更大的 scale-up 域是一次重大解鎖。

Google 的 TPU 部署長期擁有較大的 scale-up 域，這也解釋了為何 Gemini 似乎在預訓練方面領先更早。活躍參數受計算成本限制，總參數受 scale-up 域規模限制——這兩者共同界定了可行的模型設計空間。

第三章：流水線并行如何跨機架分布模型層

Dwarkesh： 我們討論的單 scale-up 域內操作，是特別適用于某種具體工作負載，還是普遍適用——無論是前向傳播還是后向傳播，無論是預填充（prefill）還是解碼（decode），無論是預訓練、RL 生成還是用戶推理？

Reiner： 要回答這個問題，我們需要討論其他通信模式。除了專家并行（all-to-all），還有張量并行（tensor parallelism）和數據并行（data parallelism），以及流水線并行（pipeline parallelism）。隨著專家粒度越來越細，張量并行已不再那么重要，但流水線并行和數據并行非常適合跨多個機架使用。

流水線并行（Pipeline Parallelism）：

設想我們有一個 MoE 層，上面還有一百多個這樣的層。我可以在某一層切換到另一個機架，讓不同機架負責不同的層。

關鍵問題：切換機架會成為通信瓶頸嗎？

我們比較 scale-out 帶寬需求與 scale-up 帶寬需求之比：

tscale-uptscale-out=18×Nactivated experts×2×Nlayers per stagetscale-outtscale-up=81×Nactivated experts×2×Nlayers per stage

【注：1/8 來自 scale-up 比 scale-out 快 8 倍；×2 來自 all-to-all 的雙向通信（上行和下行）；N_activated experts 是每個 Token 激活的專家數；N_layers per stage 是每個流水線階段的層數。】

我們希望這個比值 ≥ 1，即 scale-up 時間 ≥ scale-out 時間——這意味著 scale-up 不是瓶頸（它速度更快，處理完數據時 scale-out 尚未完成）。

需要克服的只是 8 倍的因子。由于激活專家數通常就在 8 左右，再適當增加每流水線階段的層數，就能輕松滿足這一條件。

實踐含義： 可以構建一條由多個機架組成的流水線，每個機架負責幾層，然后順序傳遞到下一個機架。這種切分方式天然地對應模型架構本身——專家切分在 GPU 之間，層切分在機架之間，非常直觀。

Dwarkesh： Ilya 曾說"眾所周知，流水線并不明智"，Horace He 也提到流水線會帶來架構約束（比如 Kimi 那種跨層殘差連接就很難實現）。流水線的好處是什么？

Reiner： 流水線本身帶來很大的工程麻煩，但確實有好處：節省內存容量。它不降低運行時間或計算量——只是把一部分內存壓力從一個機架轉移到另一個機架。如果單個機架的內存成為瓶頸，流水線可以大幅緩解這個問題，讓模型參數分散在多個機架上存儲。

流水線氣泡（Pipeline Bubble）與微批次（Micro-batch）：

讓我們畫出推理時的流水線時序圖。假設有 4 個機架（流水線階段）：

時間 →機架 1: [批次0][批次1][批次2][批次3][批次0][批次1]...機架 2:    [批次0][批次1][批次2][批次3][批次0]...機架 3:       [批次0][批次1][批次2][批次3]...機架 4:          [批次0][批次1][批次2]...

在推理時，我們讓批次 0 一進入機架 1，機架 1 就立刻開始處理批次 1——無需等待。這完全填滿了時間軸，沒有氣泡。此時"微批次"和"批次"的區別并無實質意義，只是叫法不同。

在訓練時，情況更復雜。需要先完成前向傳播，再做反向傳播，且反向傳播需要完整的全局批量才能做權重更新。為了避免氣泡，各種方案（如 Zero Bubble、One-Forward-One-Backward）會將前向和反向交織起來，但這帶來相當的工程復雜性。

流水線對推理延遲有影響嗎？ 沒有。延遲與不使用流水線相同——只是把各機架的工作排列在一條時間線上，總時間不變。流水線唯一的好處是降低每個機架的內存容量需求。

Dwarkesh： 那為什么推理時不常用流水線？

Reiner： 因為 Blackwell 機架已經有幾十 TB 的內存，而一個萬億參數的模型只需約 1 TB，內存本來就相當富裕，流水線降低的是已經不大的數字，收益有限。

流水線與 KV 緩存的內存分析：

系統內存需求：

Ctotal=Ntotal+B×Lcontext×bytes_per_tokenCtotal=Ntotal+B×Lcontext×bytes_per_token

引入專家并行度 E（機架內 GPU 數，例如 64）和流水線并行度 P（機架數，例如 4），每 GPU 內存需求為：

Cper GPU=NtotalE×P+Bglobal×Lcontext×bytes_per_tokenE×PCper GPU=E×PNtotal+E×PBglobal×Lcontext×bytes_per_token

但是，引入 P 級流水線時，全局批量 Bglobal=P×bmicroBglobal=P×bmicro（P 個微批次，每個大小為 b_micro）。代入后：

Cper GPU=NtotalE×P+bmicro×Lcontext×bytes_per_tokenECper GPU=E×PNtotal+Ebmicro×Lcontext×bytes_per_token

關鍵結論：流水線階段數 P 只能減少權重占用的內存，對 KV 緩存占用的內存沒有幫助！ P 的增大使全局批量增大，兩個效應恰好抵消。

這類似于之前的結論：KV 緩存無法通過大批量來攤銷，現在又發現它也無法通過流水線分擔。

Dwarkesh： 所以前沿實驗室做推理時，基本上都在單個 scale-up 域內？

Reiner： 是的。對于大多數模型，最優策略是：盡可能多地使用專家并行（最多用滿整個 scale-up 域），流水線并行只用極少的級數（0 到 2 級，主要是為了控制權重內存）。張量并行由于專家越來越細，已不再適用。

如果模型極大、極稀疏，超出單個機架的內存，則可以適當增加流水線級數。

更大的 scale-up 域為何重要？

有人會問：既然流水線能解決內存容量問題，更大的 scale-up 域有什么額外價值？

關鍵在于內存帶寬，而非內存容量：

tmem（權重）=Ntotalscale-up 域內所有 GPU 的總內存帶寬=NtotalS×單 GPU 帶寬tmem（權重）=scale-up 域內所有 GPU 的總內存帶寬Ntotal=S×單 GPU 帶寬Ntotal

【注：S 為 scale-up 域內 GPU 數量。流水線中不同階段不能并行加載，但同一 scale-up 域內的所有 GPU 可以并行加載各自負責的權重，總帶寬是單 GPU 的 S 倍。】

從 Hopper 到 Blackwell，單 GPU 內存帶寬提升約 1.5~2 倍，但 scale-up 域大小提升了 8 倍（從 8 到 64），總帶寬因此大幅提升。這帶來的收益是：

1. 更低的推理延遲；

2. 支持更長的上下文（因為 KV 緩存讀取速度更快）——這對日益強調智能體（agentic）能力的模型尤為重要。

第四章：Ilya 為何說"眾所周知，流水線并不明智"

Dwarkesh： 現在大家都在談論"內存墻"——內存變得極其昂貴，供應不足。據說超大規模數據中心今年有 50% 的資本開支花在內存上，這意味著消費類設備（手機、筆記本）也受到沖擊，產量下降。

但同時，你剛才說 Blackwell 機架內存已經相當富裕。既然流水線能進一步降低內存需求，Jensen Huang 為什么還要把這么多內存堆進這些系統里？

Reiner： 讓我們來分析內存容量的實際需求。

系統總內存需求：

Ctotal=Ntotal+B×Lcontext×bytes_per_tokenCtotal=Ntotal+B×Lcontext×bytes_per_token

流水線可以減少權重部分的需求，但 KV 緩存部分無法被流水線分擔。這就是關鍵所在：當流水線級數 P 足夠大，權重項變得微不足道，KV 緩存成為內存占用的主導項。

進一步的分析表明：增加流水線級數會相應增加同時在途的序列數（in-flight sequences），兩個效應精確抵消，每 GPU 的 KV 緩存內存并不減少。所以，流水線對于 KV 緩存根本沒有幫助。

Dwarkesh： 那推理時實際上用什么并行策略？

Reiner： DeepSeek 的論文里有記載：大量使用專家并行，極少甚至不用流水線（最多用 1~2 級來控制權重存儲，不再多了）。張量并行在專家越來越細的今天已幾乎沒有意義。

為什么超大 Scale-Up 域對 AI 進展如此重要：

總結一下，scale-up 域大小影響 AI 進展的兩個核心路徑：

1. 內存帶寬：更大的 scale-up 域意味著更多 GPU 并行加載權重，總帶寬成倍提升，直接降低推理延遲，支持更長上下文。

2. 內存容量：容納更多總參數、更多 KV 緩存，支持更大規模的模型部署。

流水線解決了內存容量問題（至少對于模型權重），但只有更大的 scale-up 域才能解決內存帶寬問題。

第五章：由于強化學習，模型可能比 Chinchilla 最優訓練量多 100 倍

Dwarkesh： 現在有了 Chinchilla 擴展律（Chinchilla scaling laws），它告訴你模型大小相對于訓練數據量應當如何匹配。但現在的目標不只是用訓練算力最大化模型質量，而是最小化訓練和推理的綜合成本，同時達到某個性能目標。此外，有了強化學習（RL），還要考慮預訓練、RL 生成和用戶推理這三者之間的計算分配。

具體問題是：現在的模型比 Chinchilla 最優多訓練了多少？RL 的引入是否改變了這個數字？

Reiner： 這需要一些推測，因為最新的擴展律和模型流量數據并未公開。但我們可以用一個啟發式框架來估算。

基本思路：當總成本是兩項成本之和時，最小化總成本的最優點往往在兩項成本相等處。 這對形如 1/x 與 x 的函數對成立，對指數函數對也成立，對冪律函數通常也成立。因此，我們的啟發式假設是：預訓練成本、RL 成本和推理成本應當大致相等。

成本公式：

• 預訓練計算量（FLOPs）= 6×Nactive×Dpretrain6×Nactive×Dpretrain（著名的 6ND 公式，前向 + 反向 = 6 倍參數乘數據量）

【注：每個參數每個 Token 的前向傳播約 2 FLOPs，反向傳播約 4 FLOPs，合計約 6 FLOPs。】

• RL 計算量 = α×Nactive×DRLα×Nactive×DRL，其中 α 在 2~6 之間（2 表示只做生成不做反向傳播，6 表示每條軌跡都做完整的前向+反向；實際上還要扣除 decode 的 MFU 低于訓練 MFU 的低效因子，約 30%，因此有效 α ≈ 1/10）

• 推理計算量（FLOPs）= 2×Nactive×Dinference2×Nactive×Dinference（只有前向傳播，系數為 2）

【注：前向傳播 = 2 × 參數量 × Token 數，這就是推理的 FLOPs 來源。】

令三者相等（系數約 1/10 和 1/10），活躍參數量可約去，得到：

Dpretrain≈Dinference≈DRL×110Dpretrain≈Dinference≈DRL×101

即：RL Token 數應約為預訓練 Token 數的 10 倍（因為 RL 每個 Token 的成本更高，要花同樣多的錢就需要更少的 Token）。預訓練 Token 數與推理 Token 數大致相當。

實際數值估算：

• 推理 Token 總量：約 5000 萬 tokens/秒（假設某單一模型的流量） × 2 個月 ≈ 200 萬億 Token。

• 前沿模型的預訓練 Token 數：據估算約 150 萬億 Token（與推理量大致相當，符合我們的框架）。

• 活躍參數量：約 1000 億參數（估算）。

• Chinchilla 最優 Token 數 DChinchilla≈20×Nactive≈2DChinchilla≈20×Nactive≈2 萬億 Token。

【注：Chinchilla 規律建議訓練 Token 數約為參數量的 20 倍。】

結論： 實際訓練 Token 數（約 200 萬億）是 Chinchilla 最優值（約 2 萬億）的 100 倍。即當前前沿模型的過訓練程度約為 Chinchilla 最優的 100 倍。

Dwarkesh： 這意味著，為了優化訓練與推理的綜合成本，GPT-5 之類的模型接受用戶使用時產生的全部 Token 量，應當與預訓練 Token 總量大致相當——而預訓練 Token 量大約等于人類知識的總和。

Reiner： 這就是這個框架給出的推論。當然，如果你的模型預測能力不完美，或者模型最終被放棄而沒有部署，推理端的 Token 價值要打折扣，因此實際上可能會更傾向于多訓練一些。

Dwarkesh： 僅憑公開信息就能首先原理地推算出這種量級的數字，確實令人嘆服。下面，我們可以從公開的 API 價格中再推斷一些有趣的信息。

第六章：從 API 定價推斷長上下文的內存成本

Dwarkesh： Gemini 3.1 Pro 的定價是：超過 20 萬 Token 的上下文比 20 萬以下貴 50%。為什么恰好是 50%？為什么恰好在 20 萬 Token 這個節點？

Reiner： 先回顧一下成本與上下文長度的關系圖。以上下文長度為橫軸，每 Token 成本為縱軸：

• 計算時間（compute time）：對上下文長度幾乎無依賴，是一條水平線。（理論上存在二次項，但在百萬 Token 量級以下可以忽略。）

• 內存讀取時間（mem time）：從權重基礎值出發，隨上下文長度線性增加（因為 KV 緩存隨上下文增大）。

兩者取最大值，在某個臨界點會從"計算受限"切換到"內存受限"，出現拐點。這個拐點大致對應提價的 20 萬 Token 節點。 兩段式定價結構（低于 20 萬一個價，高于 20 萬一個價）是應對這一成本結構的合理商業策略。

從定價推算 bytes_per_token（每 Token 的 KV 緩存大小）：

令內存時間等于計算時間的斷點在 200K Token 處（忽略權重讀取項，僅考慮 KV 緩存讀取項）：

B×Lcontext×bytes_per_token內存帶寬=NactiveFLOPs內存帶寬B×Lcontext×bytes_per_token=FLOPsNactive

B 約去，整理得：

bytes_per_token=NactiveLcontext×內存帶寬FLOPs=NactiveLcontext×1300bytes_per_token=LcontextNactive×FLOPs內存帶寬=LcontextNactive×3001

代入 Nactive≈1000Nactive≈1000 億，Lcontext=200,000Lcontext=200,000：

bytes_per_token=10112×105×1300≈1066≈1667 字節≈2 KBbytes_per_token=2×1051011×3001≈6106≈1667 字節≈2 KB

2 KB/token 是否合理？ 完全合理。可以通過以下兩條路徑實現：

• 密集注意力 + 跨層共享： 如 Character.AI 和 Gemma 模型中的架構，全局 KV 緩存只有 1 層，共享給所有層使用。計算：1×2×dhead×NKV heads=1×2×128×8=20481×2×dhead×NKV heads=1×2×128×8=2048 字節。

  • 其中 dhead=128dhead=128（注意力頭維度，典型值）；NKV headsNKV heads 通常在 1~8 之間。

  • KV 頭（存儲歷史 Token 表示，留在內存中）與 Q 頭（只在當前 Token 的注意力計算中臨時使用）不同。

• 稀疏注意力： 使用更多層和更多頭，但引入一個稀疏因子（1/sparsity）來降低等效的 bytes_per_token。

這進一步說明，API 定價實際上泄露了大量模型架構信息。

從輸出價格比輸入價格貴推斷 decode vs. prefill 的成本差異：

通常輸出（decode）的價格比輸入（prefill）貴約 5 倍。為什么？

我們畫"pass 長度（len_pass）vs. 每 Token 成本"的關系圖：

• decode 是 len_pass = 1 的特殊情況。

• prefill 對應較大的 len_pass。

每 Token 成本 = t / len_pass：

• 計算成本（t_compute / len_pass）： 計算時間本身不隨 len_pass 變化，除以 len_pass 后是一條常數線——這意味著 prefill 的每 Token 計算成本與 decode 相同。

• 內存成本（t_mem / len_pass）： 內存時間隨 len_pass 的增加而…其實幾乎不變（權重讀取是主要項，KV 緩存讀取在 flash attention 下幾乎是臨時的）。但除以 len_pass 之后，反而隨 len_pass 增大而降低。

這說明：prefill 實際上比 decode 便宜，因為 decode 極度受限于內存帶寬，而 prefill 可以更高效地利用計算能力。 decode 是內存帶寬受限的，prefill 是計算受限的。

從"output 比 input 貴 5 倍"這一定價，可以讀出：decode 時內存帶寬利用率約是計算利用率的 5 倍——即系統極度受內存帶寬瓶頸制約。

提示詞緩存（Prompt Cache）的定價分析：

以 Gemini 2.5 Pro 的定價為例（非精確）：

• 基礎輸入 Token：$5/百萬 Token（相當于重新計算 KV 緩存的成本）

• 寫入緩存（5 分鐘）：略貴于基礎價格

• 寫入緩存（1 小時）：更貴

緩存的成本有兩個維度：

1. 檢索成本（一次性）： 從存儲位置讀取 KV 緩存到 HBM 的帶寬成本。

2. 持有成本（每秒）： 占用存儲空間的機會成本（若占滿該存儲，GPU 無法處理更多請求）。

不同內存層級的"排空時間"（capacity / bandwidth）：

• HBM：≈ 20 毫秒（排空時間極短，不適合長時間持有）

• DDR：≈ 秒級（1~10 秒）

• Flash（NVMe SSD）：≈ 分鐘級（約 1 分鐘）

• 機械硬盤（HDD）：≈ 小時級（約 1 小時）

5 分鐘緩存 vs. 1 小時緩存恰好對應 Flash 和 HDD 兩個層級。 令人意外的是，機械硬盤這種古老技術仍在數據中心中被使用，其排空時間約為 1 小時，成本極低但速度極慢。

第七章：神經網絡與密碼學的趨同演化

Dwarkesh： 你有一篇非常有趣的博文，討論了密碼協議的結構與神經網絡的相似性——兩者都需要將信息混合到所有輸入中（前者是為了防止哈希函數被預測，后者是為了建模輸入之間的相互影響），這是一種趨同演化。但從高層次看，它們其實在做相反的事情：密碼協議把有結構的信息變得像隨機數，神經網絡則從看似隨機的數據（蛋白質序列、DNA、自然語言）中提取高層結構。

Reiner： 是的，這個對比很有意思。相似機制用于相反目的。我們也能在其他地方看到"混合與擾亂"的模式，比如做蛋糕時攪拌面糊——先這個方向攪，再那個方向攪，確實是不錯的混合策略。

不過，兩者有一個深刻的區別：神經網絡是可微分的，而密碼算法努力避免可微分。

• 可微分性使神經網絡可訓練。 殘差連接和 LayerNorm 等設計都是為了保持梯度的簡潔可計算性。

• 密碼分析中的差分密碼分析（differential cryptanalysis） 恰恰是通過對密碼算法"求導"來攻擊它：對輸入做微小擾動，觀察輸出變化。一個好的密碼算法應該使得輸入的微小差異導致輸出的巨大差異（雪崩效應），而神經網絡恰恰需要保持梯度的連續性來避免雪崩。

兩者的目標在這一維度上截然相反。

Dwarkesh： 神經網絡真的被用于密碼學了嗎？

Reiner： 用神經網絡來做密碼算法是非常危險的。99% 的新密碼算法都是被攻破的。

但反方向——密碼學的思想被引入神經網絡——至少有一個非常成功的例子：Feistel 密碼（Feistel Cipher / Feistel Network）。

Feistel 網絡原理： 給定一個不可逆函數 f，如何構造一個可逆層？方法是使用兩個輸入：

輸入: (x,y)→輸出: (x, y+f(x))輸入: (x,y)→輸出: (x, y+f(x))

• 加密（前向）： 計算 z=y+f(x)z=y+f(x)，輸出 (x,z)(x,z)。

• 解密（逆向）： 已知 (x,z)(x,z)，恢復 xx（直接讀取），恢復 y=z?f(x)y=z?f(x)（已知 x，可以重新計算 f(x)）。

整個構造是可逆的，即使 f 本身不可逆。這在密碼學中被廣泛用于構建加密層，也是許多對稱加密算法的基礎。

被引入神經網絡的應用——可逆網絡（RevNets）：

2017 年的論文《Reversible Residual Networks》（RevNets）將 Feistel 思想引入 Transformer 等神經網絡：

兩個輸入: (x, y)網絡層 f（例如 Transformer 層）前向:   output_x = x  output_y = y + f(x)逆向:   x = output_x  y = output_y - f(output_x)

這實際上是將殘差連接從 1 層變成了跨 2 層的連接（y 來自上一層的殘差）。

好處：徹底消除激活值內存占用。

• 普通訓練： 前向傳播時需要將每一層的激活值寫入 HBM，反向傳播時再讀出（內存占用隨層數線性增加，往往是訓練中最大的內存開銷）。

• RevNets 訓練： 因為網絡可逆，前向傳播時可以不保存激活值；反向傳播時，同步地從前向傳播的最終狀態逆向重構出所需的激活值（重算，rematerialization）。

代價是：需要額外的計算（重算一遍前向傳播），換來了大幅減少的內存占用。

Dwarkesh： 有趣——這和 KV 緩存的邏輯正好相反：KV 緩存是用更多內存來節省計算，而 RevNets 是用更多計算來節省內存。

Reiner： 完全正確。鑒于當前硬件的內存與計算成本比，"花內存省計算"（如 KV 緩存）通常是更合算的；但 RevNets 展示了反過來也可以有價值。

Dwarkesh： 太精彩了，Reiner，非常感謝你！這場黑板講座完全實現了我們建造這個新錄制空間的初衷。

Reiner： 非常感謝，很高興能來！

視頻地址：https://www.youtube.com/watch?v=xmkSf5IS-zw