這是我最初為該領域從業者編寫的私密文件——內容未經精雕細琢，也未針對大眾讀者進行優化。

但我還是決定公開，因為「推論驗證」（inference-verification）是一個新興且令人興奮的領域，而目前很少有從鳥瞰視角解釋其現狀與瓶頸的文章。

簡結（Tl;dr）： 若要讓我相信在現有的演算法下，推論驗證能顯著減緩訓練速度，至少需要實施以下措施之一：

• 佔總計算量 95% 以上的「工作量證明」（Proof of work）或「記憶體證明」（Proof of memory）。
• 每隔幾分鐘進行一次記憶體擦除（Memory wipes）。
• 輸出重算（Output re-computation），將隱蔽通道（covert channel）容量降低至 0.01% 以下。

據我所知，目前還沒有人開發出達到這些門檻的驗證原型；因此，快速部署推論驗證是否可行仍是一個懸而未決的問題。

1. 摘要

我認為強大的 AI 在未來某個時間點顯然會變得令人恐懼，公司或政府可能會希望減緩其發展，以爭取額外的安全研究或監管時間。這或許可以透過以下方式快速達成：

• 拔掉機架間的連接線以減緩梯度同步
• 使用簡單設備限制頻寬
• 定期擦除集群以刪除隱蔽的訓練檢查點（checkpoints）
• 對部分輸出進行重算，以確認它們確實是推論生成的內容

（見第 2 節）

這些方法真的有效嗎？更具體地說，如果這些方法被快速且正確地實施，是否能顯著減緩 AI 的開發速度？

我針對這個問題研究了大約一週，以下是我目前的觀點：

目前的推論驗證原型可能無效。 標準的推論驗證措施是透過限制伺服器間的通訊來減緩訓練（見第 2 節），因為訓練涉及在集體意識（hivemind）中傳輸龐大的梯度，而推論僅涉及文本交換。然而，通訊限制可能不會對 AI 訓練造成太大影響，特別是如果該訓練是強化學習（RL）。

RL 不需要太多通訊。RL 的很大一部分是推論——例如，生成代理行動的軌跡（rollouts）並對其評分——而推論在通訊受限的情況下仍可進行。開發者可以使用 95% 的算力（受驗證監控的算力）來生成 RL 軌跡，並在隱蔽的數據中心使用 5% 的算力來計算訓練更新。這可能允許訓練以與之前相近的效率繼續進行（見第 3 節）。

但現有的驗證提案會製造一些障礙，增加此策略的難度。例如，開發者需要頻繁向推論伺服器上傳新的檢查點，在頻寬限制下這可能會很慢。此外，開發者可能仍需將一部分軌跡通過驗證者的網路分流器（network taps）發送——即使這些軌跡實際上並不符合預期的模型輸出。但正如我在第 3.4 節中所討論的，考慮到現有推論驗證原型的寬鬆程度，這些限制可能是可以繞過的。

如果實施得夠早，更激進的措施可能可以爭取至少 1 年的時間。這些更激進的措施包括：

• 佔總計算量 > 95% 的工作量證明或記憶體證明， 這將防止開發者使用超過 5% 的算力來秘密生成 RL 軌跡。
• 每隔幾分鐘進行一次記憶體擦除， 這將在新的檢查點完全上傳到推論伺服器之前將其抹除（見第 4 節）。
• 輸出重算將隱蔽通道容量降低至 0.01% 以下， 這將防止開發者透過網路分流器外洩隱蔽的 RL 軌跡生成內容（見第 4 節）。

上述任何一項措施都可能使基於當前演算法的訓練變得不可行。我的猜測是，在缺乏快速 AI 驅動的研發情況下，開發繞過這些限制的演算法至少需要一年時間（如果繞過它們是可能的話）。

一年可能就足夠了。 在 AI 協議達成一年後，政府總共可能有兩年時間來開發驗證技術，因為上述措施可能需要大約一年來實施。在研究驗證機制兩年後，政府或許能夠實施更強大的通用晶片級安全功能。

但如果協議是在智能爆炸期間開始的，那就很難說了。 如果開發者擁有能快速創造新演算法的強大 AI，我看不出有什麼根本原因能說明頻寬限制、記憶體擦除等手段必然會減緩 AI 研究（見第 5 節），但它們仍有可能奏效。

因此，我認為驗證研究的主要重點應該放在降低這三種驗證措施的風險上（可靠的工作量/記憶體證明、頻繁的記憶體擦除，以及高精度的輸出重算）。如果沒有這些措施，我認為訓練幾乎不會減慢。有了它們，基於當前演算法的訓練可能會減慢，且在智能爆炸期間也有可能減慢（但這尚不明確）。

這些措施中沒有哪一項是顯然可以在短時間內實施的；因此，快速改裝的推論驗證是否可行仍是一個開放性問題。

接下來的章節將論證這些觀點。

註：在進一步思考並與更多人交流後，我認為在短時間內開發這些措施是可行的，其中一部分可能會在未來幾個月內產出原型。特別是「記憶體證明」和「輸出重算」可能是行得通的。

2. 透過限制通訊來快速且廉價地減緩訓練的方法

在訓練期間，模型在龐大的集體意識中分享學習成果。這涉及大量的通訊。

訓練的運作方式如下：

（圖示）

在推論期間，模型之間仍會對話，但通訊內容稀疏且量小：

（圖示）

政府是否可以利用這種通訊差異，在不影響推論的情況下減緩 AI 訓練？

以下是不同驗證方法的概述以及我對其可行性的看法：

| 方法 | 能否在 1 年的前置時間內安全實施？ |
| :--- | :--- |
| 移除互連（Interconnect） | 是 |
| 頻寬限制器 | 是（限制至 100 Kb/s） |
| 輸出重算 | 可能可以，但尚不清楚隱蔽通道是否能降至流量的 1% 以下 |
| 記憶體擦除 | 可能不切實際。必須擦除伺服器機架 99.99% 以上的記憶體才能可靠地抹除檢查點，考慮到開發者硬體、韌體不透明記憶體等不確定性，這可能無法達成。 |
| 工作量 / 記憶體證明 | 可能實用，但有很多障礙，且尚未展示過強健的版本（我很快會發布相關內容！） |

2.1. 方法 #1：斷開機架間的高速電纜

減少通訊的一種方法是斷開高速機架間網路，例如 InfiniBand 電纜。 這些電纜在伺服器機架之間以約 400 GB/s 的速度傳輸，可以更換為僅以網路速度（例如 100 MB/s）傳輸數據的銅線連接。

（圖示）

2.2. 方法 #2：經分流驗證的頻寬限制

今天的 AI 代理不需要串流影片。它們只需要輸出文本；因此開發者可能會安裝簡單的設備來分流電纜，並驗證數據傳輸速率是否甚至低於網路速度（例如 100 KB/s）。

（圖示）

補充：為什麼是 100 KB/s？ 頻寬限制在機架內電纜上執行最為實際——而非連接伺服器機架上 GPU 的密集銅質背板。支持推論需要多少數據流經這些電纜？目前伺服器機架大約容納 100 個 H100 等效晶片。截至 2025 年底，Google 擁有約 300 萬個 H100 等效晶片，每月處理 480 兆個文本標記（tokens）。這意味著每秒有 120 億個標記的輸入數據流經每個伺服器機架，相當於 20 KB/s 的輸入流量（輸出流量可能更小）；因此，每個伺服器機架 100 KB/s 的輸入和輸出限制已接近數據速率限制干擾當前推論工作負載的最小值。

2.3. 方法 #3：輸出重算

驗證者可以透過對伺服器輸出的樣本進行部分重算來進一步降低頻寬。

• 開發者首先聲明他們正在運行的程式，例如他們的推論模型。
• 然後，驗證者使用分流設備記錄進出每個伺服器的流量，對輸入輸出對進行採樣，並確認這些配對符合聲明模型的行為。

如果這被完美地實施——沒有洩漏且具備完美的確定性——驗證者就能知道模型實例之間的通訊看起來像這樣：

（圖示）

這意味著：

• 模型在伺服器機架內部完全無法通訊。如果它們通訊，模型輸出就無法僅憑輸入進行重算。
• 此外，集群輸出不能從伺服器中秘密存儲的任何狀態計算得出。

模型實例只能透過低頻寬的模型輸出進行通訊。

乍看之下，這似乎解決了所有問題。這是在不破壞推論的情況下所能執行的最嚴格通訊約束。

但有一些重要的注意事項。

首先，開發者可能會在秘密數據中心隱藏一小部分算力（例如 5%）。歷史上，情報機構對隱蔽資產（如坦克、彈頭等）的估計中位誤差在 15% 以內。算力可能比（例如）導彈更容易核算。但我認為要確定（例如）中國政府是否將中國 5% 的算力轉移到秘密數據中心仍然很困難。

（圖示：歷史情報估計 vs 真實情況）
這給了作弊者非零的高頻寬操作預算。

（圖示）

其次，輸出重算可能無法涵蓋所有的伺服器流量。可能存在非確定性或側信道，允許推論伺服器上的隱蔽工作負載洩漏數據。

因此，輸出重算最終可能只是另一種降低頻寬的方法。假設隱蔽工作負載只能透過 1% 的輸出流量傳遞數據，這正是目前原型所允許的隱蔽通道大小。那麼，輸出頻寬將減少 100 倍，從 ~100 KB/s 降至 ~1 KB/s。

（圖示）

2.4. 方法 #4：記憶體擦除

如果輸出重算是「有洩漏的」，那麼開發者仍然可以在推論伺服器上累積隱蔽狀態。為了防止這種狀態累積太久，驗證者可以強制執行定期記憶體擦除。例如：

• 驗證者可以要求 GPU 使用預先確定的種子生成合成隨機數據，生成這些數據至少需要一定的計算成本。
• 然後，驗證者可以隨機抽查一部分 GPU，詢問存儲了什麼數據。由於這些數據體積龐大且即時生成非常耗時，GPU 只有在確實存儲了數據的情況下才能快速返回。
• 接著，驗證者可以根據共享種子自行計算數據以確保其正確。
• 這確認了 GPU 確實存儲了開發者聲稱的 >99.99% 的合成隨機數據（如果樣本量足夠大）。
• 如果這些數據佔據了伺服器幾乎所有的記憶體，即誤差低於 (1 GB 模型)/(100 B100s x 192 GB per B100) = 0.005%——那麼驗證者就知道伺服器沒有存儲隱蔽模型。
• 最後，開發者透過高頻寬通道重新上傳聲明的推論模型，該聲明模型位於白名單中，不計入頻寬限制。

（圖示）

2.5. 方法 #5：工作量證明 / 記憶體證明

驗證者可以透過一種稱為工作量 / 記憶體證明的方法進一步約束開發者。其核心思想是檢查聲明的推論是否確實佔據了開發者正在使用的絕大部分計算或記憶體。具體而言：

• 驗證者重算推論輸出（如前所述），以驗證大部分輸出流量確實是由聲明的推論模型生成的。
• 然後，驗證者估計處理這些請求所需的總計算量或記憶體，例如透過簡單地重新運行它們並記錄所使用的 GPU 小時數 / GB 記憶體。
• 最後，驗證者估計開發者伺服器的計算能力或記憶體，並檢查其絕大部分計算或記憶體是否已被聲明的推論工作負載所涵蓋。

現在，開發者只能將其伺服器的一小部分用於隱蔽工作負載——這一比例取決於驗證者估計值的誤差範圍。

（圖示）

3. 在這些約束下繼續高效訓練的方法

假設驗證者實施了前一節提到的「有洩漏的輸出重算」：

（圖示）

開發者如何在這些約束下繼續高效訓練？

以下是幾種通訊高效訓練的方法，以及我對其有效性的看法：

| 方法 | 性能顯著下降前的頻寬減少倍數 | 這種技術能否用於在「有洩漏的輸出重算」下繼續維持近前沿的效率？ |
| :--- | :--- | :--- |
| 更大的批次大小（Batch sizes）+ 不頻繁的 SGD 步驟 | 非常小 (< 10x) | 否。 |
| 定期合併獨立的訓練運行（即不頻繁的全域步驟，但頻繁的局部步驟） | 至少 1000x，可能更多。 | 即使使用目前的演算法，也有可能。 |
| 壓縮梯度 / 權重 | 至少 100x。 | 透過額外的研發，有可能。 |
| 將所有聲明的算力用於 RL 軌跡生成。在隱蔽算力上進行訓練。 | 極端的頻寬減少。 | 是，即使使用目前的演算法，也很有可能。 |

3.1. 方法 #1：更大的批次大小 + 不頻繁的 SGD 步驟

結論： 無效。

推論： 在 1 kb/s 的頻寬下，上傳一個 10 GB 的梯度需要 6 個月，且需要多次上傳。目前的數據顯示，損失函數曲面（loss landscape）的曲率足以使得至少需要數千個序列訓練步驟才能達到強大的性能，這意味著近前沿的訓練運行將需要 6 個月 x 1000 = 數百年才能完成。

（圖示說明：批次大小與達到特定損失所需的訓練步數之間的關係。超過某一點（「臨界批次大小」）後，加大批次不再有益。）

（圖示說明：「臨界批次大小」的增長速度慢於開發者擴展 AI 訓練的速度，這意味著開發者將始終處於增加批次大小無法減少所需同步次數的狀態。）

3.2. 方法 #2：定期合併獨立的訓練運行

結論： 將頻寬需求降低至少 1000 倍，甚至更多。

推論： 合併獨立訓練的模型可以降低損失，因為損失函數曲面是凸的；因此，模型的平均值所達到的損失低於模型損失的平均值。

（圖示說明：為什麼合併獨立訓練的模型有效。）

Google 顯示這種技術可以將梯度同步的頻率降低約 2000 倍，而性能損失極小（見 https://arxiv.org/abs/2501.18512 和 https://arxiv.org/abs/2311.08105）：

（圖示說明：不同同步頻率下的訓練損失。）

然而，超過某一點後，降低同步頻率會開始損害性能。但 Li 等人表明，透過在不同且獨立的數據子集上訓練模型可以減輕此問題。例如，學習 pytorch 的模型不需要頻繁與學習遊戲開發的模型同步。pytorch 模型的學習成果與遊戲開發模型的學習成果之間沒有序列依賴關係；因此，訓練可以並行化到數據可以被分割成孤立領域的程度。

然而，模型從泛化中獲得顯著收益；那麼在什麼同步頻率下性能成本會爆發？一篇論文在合併前對專家模型進行了 ~10,000 H100 小時的訓練並保持了高性能；因此，如果我們假設每台伺服器訓練一個模型，且一台伺服器有 100 個 GPU，那麼開發者可以每 10,000 / 100 / 24 = 4 天同步一次模型，並維持前沿效率。

3.3. 方法 #3：壓縮梯度和權重

結論： 將頻寬需求降低至少約 100 倍，甚至更多。

推論： 開發者可以減小 (1) 梯度 (2) 偽梯度（pseudo gradients）和 (3) 模型權重的大小，從而縮短在頻寬受限通道上發送這些對象所需的時間。

• 梯度可以被壓縮，因為它們是稀疏的（大部分為零）且低秩的。壓縮可以將梯度大小減少約 100 倍，且性能下降極小。
• 開發者還可以壓縮偽梯度——即獨立訓練模型產生的模型增量（如前一節所述）。偽梯度同樣可以壓縮約 100 倍。
• 最後，開發者可以使模型權重變小且易於傳輸。一種方法是將模型權重拆分為許多微型專家（tiny experts），每個專家託管在單個伺服器上；這樣在頻寬限制下上傳每個專家所需的時間就很短。這篇論文將模型拆分為 32 個完全獨立的專家，因此一個 100 GB 的模型可以被分成 ~3 GB 的專家，對性能的影響微乎其微。

在極限情況下，梯度可以壓縮到什麼程度而不減慢訓練？理論上：天下沒有白吃的午餐。在某個門檻下，壓縮 10 倍會使訓練減慢 10 倍。但這個門檻在哪裡？原則上，梯度可以無損壓縮到生成它們的訓練數據的大小。如果訓練數據比梯度小約 100 萬倍（~100 GB / 100 KB），那麼梯度可以壓縮約 100 萬倍。此外，訓練數據本身也是相當可壓縮的，因此梯度可能可以壓縮超過 100 萬倍而性能不減。梯度目前還沒有這麼高的可壓縮性，但開發者或許可以透過「針對可壓縮性進行訓練」或其他方法使其更易壓縮。

3.4. 方法 #4：將更多算力用於推論軌跡，減少訓練算力

RL 訓練的大部分工作涉及生成行動軌跡並對其評分。這本質上就是推論，因此開發者可以使用其聲明的推論伺服器進行軌跡生成，並使用秘密數據中心進行訓練。

如果秘密數據中心佔開發者算力的 ~5%，那麼開發者可以使用這 5% 進行訓練，95% 用於軌跡生成。這種不對稱的算力分配會減慢 RL 訓練嗎？多篇 論文顯示不會：絕大多數軌跡並非非常有價值。因此，如果開發者僅針對最有價值的 5% 軌跡進行訓練，RL 仍以相近的速度收斂。[而且，或許梯度根本不是必需的，基於推論的演化（evolution）效果也很好]

然而，這一策略仍需克服幾個挑戰：

首先，必須定期向推論伺服器上傳新的檢查點。 RL 使用正在訓練的模型來生成軌跡。因此，在訓練期間需要不斷向推論伺服器上傳新模型。但頻寬限制可能會使上傳過程變得緩慢。

在 100 KB/s 的速度下，上傳一個 3 GB 的專家模型需要幾個小時。目前，強化學習期間的模型每隔 ~幾分鐘（生成軌跡所需的時間）就會更新一次；因此，這將比典型的更新頻率慢 ~100 倍。

然而，由於軌跡生成時間變長，模型更新頻率預設正在降低。此外，更新可以顯著延遲而不損害性能；因此，幾小時一次的更新頻率可能不是問題。

此外，軌跡數據必須通過驗證者分流器發送，即使它們不是由聲明的模型生成的。 我們假設驗證者使用輸出重算來驗證輸出是由「聲明的」推論模型生成的。但為 RL 生成軌跡的模型與「聲明模型」不同且不斷變化；因此 RL 軌跡必須設法逃離伺服器，即使它們無法被驗證者重算。

開發者可能會利用推論的非確定性來外洩 RL 軌跡。輸出重算自然存在一些誤差，因為推論並非完美確定的。即使是硬體層面的不規則性也會導致一些偏差。在目前的原型中，輸出重算的「不引起懷疑的誤差」（即非確定性水平）為 1%；因此，1% 的伺服器輸出可以由我們未聲明的 RL 模型生成而不會引起懷疑。

如果生成的 RL 軌跡中只有約 1% 能真正發送回訓練伺服器，這會是一個很大的限制嗎？伺服器本來就需要篩選出前 5% 的軌跡，因為這是訓練集群能消化的最大量（記住我們假設隱蔽數據中心佔總算力的 5%）；因此，將篩選門檻進一步收緊到前 1% 可能不是大問題。

因此，開發者有可能透過將聲明的伺服器用於 RL 軌跡生成來規避推論驗證。

4. 但更激進的驗證方法可能會使當前演算法下的訓練變得不切實際

如果我們結合上一節中最有前景的通訊高效訓練方法，開發者可能會這樣做：

• 開發者可能會使用其所有聲明的伺服器來生成 RL 軌跡，並使用未報告的算力進行 AI 訓練。
• 他們可能會將 RL 軌跡篩選至前 1%，並透過推論噪聲外洩這一小部分數據。
• 最後，開發者可能會透過傳輸 ~3 GB 的專家模型，定期向推論伺服器上傳新檢查點。

為了擊敗這種策略，驗證者可以實施以下任何一項：

• 佔總計算量 > 95% 的工作量證明或記憶體證明。 如果驗證者能確認推論伺服器中 >95% 的算力正用於運行聲明的模型，那麼開發者只能使用 < 5% 的算力來隱蔽地生成 RL 軌跡。~5% 是一個重要的門檻，因為低於此點，相對於在已佔總算力約 5% 的隱蔽數據中心上運行推論，開發者從秘密推論中獲得的收益並不多。
• 每隔幾分鐘進行一次記憶體擦除。 每次驗證者擦除伺服器時，開發者都需要重新上傳 3 GB 的專家模型。但在 100 KB/s 的速度下上傳 3 GB 需要 8 小時；因此，如果每隔幾分鐘擦除一次記憶體，開發者就無法在所有進度被抹除前完成一個完整專家的上傳。

為了在 1 分鐘的記憶體擦除窗口內完成上傳，模型專家的大小需要約為 ~5 MB。我不知道有任何研究能將一個近前沿的 100 GB 模型拆分為 20,000 個不同的獨立 5 MB 專家並保持高性能。我不確定這是否可行。

• 輸出重算將隱蔽通道容量降低至 0.01% 以下。 當下採樣至 1/16 的軌跡數據時，RL 的性能就已經開始下降（見 https://arxiv.org/pdf/2504.13818 的圖 4）。如果輸出重算的隱蔽通道容量 < 0.01%，那麼軌跡需要下採樣 10,000 倍才能透過推論噪聲外洩。這比我在任何已發表的 RL 實作中看到的下採樣都要極端得多。

上述任何一種推論驗證方法都可能在現有演算法下顯著減緩訓練速度。

5. 然而，如果開發者（或 AI）有大量時間研究更好的演算法，那就很難說了

上述所有的推論驗證方法歸根結底都是限制伺服器間的通訊。這之所以奏效，是因為目前的訓練涉及的通訊比推論多得多。 但我看不出有什麼理由說明必須是這種情況。

例如：

• 頻繁的記憶體擦除可以透過訓練數千個微型專家來擊敗。 這將允許微小的 10 MB 專家在記憶體擦除抹除進度前被快速上傳。我沒有看到強而有力的論據說明模型不能被細分為許多 10 MB 的專家。
• 頻寬限制可以透過極端的梯度壓縮來擊敗。 原則上，梯度可以壓縮到比生成它們的數據還要小。例如，考慮人類學習的可壓縮性。我可能被鞋帶絆倒，整個過程需要大量存儲空間來錄影。但我吸取的教訓僅僅是「下次記得繫好鞋帶」這幾個字。或許模型可以分享捕捉了梯度更新大部分價值的微小信息片段。
• 頻寬限制可以透過不頻繁的同步來擊敗。 訓練期間通訊之所以重要，核心原因是許多領域具有序列依賴性：一項技能需要在另一項技能之前學習。但沒人確切知道這些依賴性有多強。序列依賴性可能僅在特定子領域（如「使用 pytorch 編碼」）內最強，而在不同子領域之間可能非常弱；因此，AI 代理可以在小型、孤立的伺服器上序列化地訓練數千個子領域專家，並不頻繁地（例如每幾週）進行合併，且仍能保留正常訓練的大部分性能。
• 即使「前沿訓練」很慢，AI 研究也可能不會慢。 開發者仍可能透過並行訓練數千個小模型來取得快速的演算法進展，例如在每個擁有 ~100 個 GPU 的伺服器機架上，每隔幾小時訓練一個 ~gpt-3 大小的模型。然後，開發者只需要透過頻寬限制傳輸實驗結果，而不是梯度。或許訓練大量小模型是改進 AI 軟體的好方法。

所有這些都是為什麼即使是極端的通訊限制也可能不會顯著減緩 AI 開發的合理解釋。然而，我也認為通訊約束完全有可能導致重大減速——即使在 AI 研發的極限情況下。這完全取決於 AI 開發和學習的本質。AI 開發可能本質上更受限於算力而非通訊。也可能不是。我們不知道。

6. 結論

需要更多的工作才能確信推論驗證可以在短時間內有效實施。

如果你有興趣參與這項工作，請告知，我可以嘗試為你引薦相關人員。

聯繫我的最佳方式是電子郵件：joshuamclymer@gmail.com

附錄

我們是否處於序列瓶頸訓練體制？由 Claude 進行的概算（BOTEC）

設定

存在一個臨界批次大小（B_crit），超過此大小後，增加更多數據並行（data-parallel）工作者所產生的收益會遞減。在 B_crit 以下，將批次大小翻倍大約會使所需的訓練步數減半——這是完美的並行化。在 B_crit 以上，你仍然需要大約相同數量的序列步驟，但你是在浪費額外的標記（tokens）而沒有收益。

如果一個訓練集群的數據並行能力可以填滿 B_crit，它就是**序列瓶頸（serial-bottlenecked）的——更多 GPU 也無濟於事。如果它無法達到 B_crit，它就是硬體瓶頸（hardware-bottlenecked）**的——更多 GPU 將直接加速訓練。

本概算探討：在 10 萬和 100 萬個 H100 等效晶片的規模下，我們處於哪種體制？

關鍵公式

來自 Bergsma 等人 2025 年的 "Power Lines"，基於 SlimPajama 數據集上高達 33 億參數的 GPT-2 風格模型訓練得出：

$$B_{crit} = 0.471 \times D^{0.462}$$

其中 B 的單位是 2048 個標記的序列，D 是總訓練標記數。這是根據高達 ~1430 億標記的數據集擬合的；我們正在將其外推到擬合範圍之外的 100–400 倍。

前沿規模下的 B_crit

| 數據集大小 (D) | B_crit (標記/批次) | S_min (步數) | B_crit 下的實際時間 (2秒/步) |
| :--- | :--- | :--- | :--- |
| 15T (DeepSeek-V3 規模) | 1.18億 | 12.7萬 | 5.9 天 |
| 30T (Llama 4 規模) | 1.62億 | 18.5萬 | 8.5 天 |
| 60T (下一代前沿) | 2.24億 | 26.8萬 | 12.4 天 |

在 B_crit 下，訓練步數為 2 × S_min，消耗的總標記數為 2 × D_min。實驗室支付 2 倍的標記開銷以換取最短的實際時間。

每個模型副本需要多少 GPU？

不同的架構消耗的模型並行量大不相同，留給數據並行的空間也不同：

| 架構 | TP | PP | EP | GPU/副本 |
| :--- | :--- | :--- | :--- | :--- |
| 稠密 (Dense) ~300B | 8 | 16 | — | 128 |
| 稠密 ~600B | 8 | 32 | — | 256 |
| MoE 671B (DeepSeek-V3 風格) | 1 | 16 | 64 | 1,024 |
| MoE ~2T (巨獸風格) | 1 | 16 | 256 | 4,096 |

可實現的批次大小 vs. B_crit

假設序列長度為 8192，梯度累積為 8，且 D = 15T 標記 (B_crit ≈ 1.18億標記)：

| 集群 | 架構 | DP 副本 | 批次大小 | 與 B_crit 之比 | 體制 |
| :--- | :--- | :--- | :--- | :--- | :--- |
| 100K | 稠密 ~300B | 781 | 51M 標記 | 0.4× | 硬體瓶頸 |
| 100K | 稠密 ~600B | 390 | 26M 標記 | 0.2× | 硬體瓶頸 |
| 100K | MoE 671B | 97 | 6M 標記 | 0.05× | 硬體瓶頸 |
| 100K | MoE ~2T | 24 | 2M 標記 | 0.01× | 硬體瓶頸 |
| 1M | 稠密 ~300B | 7,812 | 512M 標記 | 4.3× | 序列瓶頸 |
| 1M | 稠密 ~600B | 3,906 | 256M 標記 | 2.2× | 序列瓶頸 |
| 1M | MoE 671B | 976 | 64M 標記 | 0.5× | 硬體瓶頸 |
| 1M | MoE ~2T | 244 | 16M 標記 | 0.1× | 硬體瓶頸 |

關鍵結論

在 10 萬個 H100 規模下，每種架構都處於硬體瓶頸。 即使是相對較小的稠密模型也只能達到 ~0.4× B_crit。更多 GPU 將直接加速訓練。MoE 模型距離 B_crit 特別遠，因為專家並行（expert parallelism）消耗了大部分 GPU 預算。

在 100 萬個 H100 規模下，稠密模型進入序列瓶頸，但 MoE 模型則不然。 一個稠密的 300B 模型會超過 B_crit 4 倍，在冗餘梯度信息上浪費大量計算。但 DeepSeek-V3 風格的 MoE 仍僅達到 0.5× B_crit，而 2T 參數的 MoE 僅達到 0.1×。MoE 架構將過剩的 GPU 能力吸收進模型並行中，使數據並行維度保持較小，並維持訓練的計算效率。

這是大規模下採用 MoE 的結構性論據。 隨著集群增長，稠密模型會首先撞上序列化牆。MoE 提供了一種有效利用額外 GPU（持有更多專家參數）的方法，而不會將批次大小推過 B_crit。它將過剩的並行能力轉化為模型質量，而非浪費的數據並行。

如果 Power Lines 的外推成立，序列實際時間短得令人驚訝。 在 B_crit 下以 2秒/步計算，15T 標記的運行在 ~6 天內即可完成。實際的前沿訓練運行需要數月，這表明實驗室運行的批次遠低於 B_crit——以實際時間換取計算效率——或者在這些配置下每步時間遠長於 2 秒。

注意事項

這些估計基於幾個不穩定的假設：

• 外推。 Power Lines 標度律是基於 ≤33 億參數的模型和 ≤1430 億標記的數據集擬合的。外推到 15–60T 標記是 100–400 倍的外推。指數 (0.462) 在前沿規模下可能不同。
• MoE。 標度律是針對稠密模型擬合的。MoE 架構可能具有不同的 B_crit 標度——當每個標記只有一部分參數處於活動狀態時，梯度噪聲結構可能不同。目前尚無已發表的研究測量大型 MoE 模型的 B_crit。
• 並行開銷。 模型並行估計（TP, PP, EP）是粗略的。實際配置取決於互連拓撲、記憶體容量和工程選擇。某些實驗室可能透過巧妙的並行策略實現更高的 DP。
• 每步時間。 我們假設每步 2 秒，這是一個粗略估計。在大規模 DP 和大型模型下，通訊開銷可能將每步時間推向 5–10 秒以上，顯著增加實際時間。
• 批次大小預熱（Warmup）。 B_crit 在訓練期間並非恆定——它從接近零開始增長。無論集群大小如何，早期訓練總是高度序列化的。

來源

• Bergsma et al. 2025, "Power Lines: Scaling Laws for Large Language Model Training" (arxiv.org/abs/2505.13738)
• McCandlish et al. 2018, "An Empirical Model of Large-Batch Training" (arxiv.org/abs/1812.06162)
• Merrill et al. 2025, "Critical Batch Size Revisited" (arxiv.org/abs/2505.23971)
• Epoch AI, "Data Movement Bottlenecks: Scaling Past 1e28 FLOP" (epoch.ai/blog/data-movement-bottlenecks-scaling-past-1e28-flop)
• DeepSeek-V3 Technical Report (arxiv.org/abs/2412.19437)