第 1 章 — Token 生成的力學

發佈於: 2026-04-23 最後更新於: 2026-07-08 版本: 1
第 1 章 — Token 生成的力學

第 1 章 — Token 生成的力學

LLM Primer VI:擴展 AI 系統》章節走讀的第一篇。這一章主張:LLM 服務裡幾乎每一個困難的問題,都源於同一個事實 — 產生每個 token 的那個迴圈受制於記憶體頻寬,你花錢租來的昂貴運算有 99.7% 的時間都閒置著。


這一章為什麼存在

LLM 在運作時,是一個包在迴圈裡的下一個 token 預測器。token 進去,一個關於下一個 token 的機率分布出來,挑一個、附加上去,然後迴圈再跑一次。推論堆疊裡每一個有趣的性質 — 批次處理、量化、KV 快取、推測解碼、解耦式服務 — 都源自對那個迴圈的仔細觀察。這個迴圈藏了兩種工作量,它們共用同一段程式碼路徑,卻用相反的方式壓榨硬體。一種受制於運算。另一種受制於頻寬。在同一顆 H100 上、在同一次前向傳遞裡發生。把這個切分清楚地命名出來,是這本書的第一個動作,也是後面每一章都會回頭指涉的框架。

一句話總結:自回歸迴圈是被數學所強制的循序,而不是被軟體所強制的;它的 decoding 階段讓最先進加速器的運算單元幾乎完全閒置 — 這本書裡的每一項技術,都是對那些閒置時間的一種回應。

1.1 自回歸迴圈是被強制循序的

Token t+1 是「到 t 為止(含 t)每個 token」的函數。模型沒辦法在 t+1 還沒被取樣之前先預測 t+2,因為 t+2 的預測需要 t+1 成為輸入的一部分。沒有任何巧妙的 kernel 能替單一序列平行化兩個連續 token 的生成;這個循序特性是由計算本身的依賴結構所強制的。因此,一個 N 個 token 的完成的實際牆上時間成本,就是一個步驟的成本乘上 N,再加上固定開銷。書中後面每一個最佳化 — 更大的批次、沿著軌跡往前推測、更便宜的每步算術 — 都是在部分地回答同一個問題:「既然這個迴圈非得一次走一個 token 不可,我們要怎麼讓每一步變快,或讓每個批次變大?」模型也沒有外部草稿紙:它靠吐出 token 來思考。這個迴圈是模型唯一能讓自己思考更久的機制,這也是為什麼 chain-of-thought 與推測解碼都活在同一套會計裡。

1.2 Prefill 與 decoding 用相反的方式壓榨晶片

這個迴圈藏了兩個階段。Prefill 是第一次前向傳遞,它以 [batch, sequence_length, hidden_dim] 的形狀吃下使用者的提示詞。每一個矩陣乘法都同時在所有序列位置上運算;算術隨序列長度而擴張;權重從 HBM 讀一次然後套用在許多列的工作上。算術強度很高。Prefill 受制於運算,能用上 H100 的 989 BF16 TFLOP/s。Decoding 則是之後的每一次前向傳遞。輸入形狀塌陷成 [batch, 1, hidden_dim]。每一層的權重還是得從 HBM 串流過來,但只對它們做一列算術。算術強度跌了三個數量級。Decoding 受制於記憶體頻寬。在一顆 BF16 的 70B 模型上,對一段 2,000 token 提示詞做 prefill 幾乎跑到晶片的運算上限;就在下一次前向傳遞 — 也就是第一次 decode — 它會針對同樣的 140 GB 權重跑,只為了產生一個 token。晶片沒變。工作量變了。

1.3 一位使用者讓 H100 有 99.7% 是閒置的

結果就是,單一使用者的即時生成是最先進加速器的最差情況。一顆 H100 SXM 上的 BF16 70B 模型,每秒大約 decode 24 個 token — 對使用者來說是快速的閱讀速度,而晶片 3.35 TB/s 的 HBM3 頻寬則被完全飽和,每個 token 就得搬 140 GB 的權重。但在這個速率下,運算單元只跑出它有能力提供的 989 TFLOP/s 裡的大約 3.36 TFLOP/s。運算利用率是 0.34%。實體晶片沒有設定錯誤;每個 SM 都在以全速讀取與相乘,但 tensor cores 被設計來對每個權重 tile 消化許多列,而單一 token 的前向傳遞只給它們一列。運算容量以工作量產不出來的單位(每載入 byte 的運算次數)來計量。可是還是有人為整顆晶片每小時付四到八美元。因此 LLM 服務的經濟學,就是替停放在那裡的運算找工作的經濟學 — 靠批次處理、靠更便宜的每個 token 的頻寬、靠推測、靠平衡點對得上工作量的硬體。

值得記住:規格表上的 FLOP/s 數字在 decoding 期間大致上無關緊要。決定吞吐量的是 HBM 容量(裝得下多大的模型)以及 HBM 頻寬(權重能多快地串流過晶片)。用峰值 FLOP/s 買卡,就是買到錯的數字。

第 1 章鋪陳出來的東西

這本書的其餘部分,是對本章命名的這個不對稱性的回應。第 2 章拆開 KV 快取 — 那個讓 decoding 免於平方級重新運算的資料結構,同時在過程中變成服務叢集裡 VRAM 的最大單一消耗者。第 3、4 章用頻寬對比運算的視角走一遍硬體基底。第 5、6 章靠縮小權重來收斂每個 token 的頻寬負擔。第 7 章把批次處理當成系統級的槓桿,把受頻寬所困的浪費轉換成吞吐量。第 8、9 章用分頁式 KV 管理與推測解碼改變工作的形狀。每一個動作,都能被讀作對本章剛剛量測到的閒置運算的一種填補嘗試。


下一篇 — 第 2 章:KV 快取的挑戰那個讓 decoding 變得負擔得起的工作區,以及那條解釋為什麼服務叢集會先用光 VRAM、再用光運算的記憶體公式。

想看完整的全貌?書中章節包含 greedy 生成迴圈的可執行虛擬碼、讓數字在跑起來的系統上變得具體的 decode_regimemeasure_decode_utilization 工具,以及這篇文章只能摘要帶過的「In Plain English」邊欄。在 Amazon 查看 LLM Primer VI →

下田 昌平
下田 昌平
RECEIPTROLLER 的 CTO 與創辦人。專注於數據、驅動創新、始終保持好奇心。