《深入理解 AI Infra》(ai-infra-book) 研究筆記¶

資料來源¶

項目	連結
GitHub repo	https://github.com/bojieli/ai-infra-book
書名	《深入理解 AI Infra：量化分析與系統設計》
作者	李博杰（Bojie Li） — 前華為首批「天才少年」、Pine AI 首席科學家
線上閱讀	https://bojieli.github.io/ai-infra-book/
最新 PDF（每次 push 自動建置）	releases/latest/download/AI-Infra-Book.pdf
姊妹作（本站已有筆記）	《深入理解 AI Agent》（47.1K★）

Metadata（2026-09-15 抓取）：2,654 stars / 189 forks / 0 open issues · Apache-2.0 · 建立於 2026-08-22、最後 push 2026-09-15（也就是開站只有 3.5 週就衝到 2.6K★，而且今天還在 commit）· repo 含 Git LFS 約 20 GB · 主語言標 Python（實際是計算工具與實驗腳本）。

一句話定位¶

《深入理解 AI Agent》教你怎麼寫 Agent；這本教你 Agent 底下那台機器為什麼慢、為什麼貴。

作者在 README 講得很直接：寫完 Agent 那本之後，跟讀者交流時越來越覺得——要開發好基於模型的應用，還需要理解它賴以運行的基礎設施。大多數軟體工程師不必親自開發作業系統、編譯器和晶片，卻仍要學作業系統、編譯原理和計算機體系結構，因為申請記憶體、讀檔案、呼叫函式背後都有資源與時間代價。基於模型開發應用也一樣：延遲差幾倍，產品體驗可能完全不同；成本差一個數量級，能支撐的商業模式也跟著變。

核心命題：模型是新的作業系統，AI Infra 是新的體系結構¶

這本書真正的論點藏在前言裡，值得完整引一次：

傳統的作業系統、編譯器和硬體要為事先未知的各種程式提供通用能力，系統優化總要在可程式性與效能之間取捨。如今 LLM 成了最重要的應用，從算子執行到分散式調度，都可以針對特定的模型和加速器架構優化；模型設計也開始反過來適應硬體，DeepSeek V4/V4.1 重新設計長上下文的表示方式就是一例。

從某種意義上說，模型成了 LLM 時代的作業系統，AI Infra 成了 LLM 時代的計算機體系結構。

而且他明講寫作動機是對標一本經典：《計算機體系結構：量化研究方法》（Hennessy & Patterson）是他在體系結構領域的入門書，而 AI Infra 領域還缺少一本從硬體約束和模型架構出發、量化推導系統設計的書。

貫穿全書的方法：從約束推導設計¶

方法論只有一句：先明確任務與品質要求，列出計算、儲存、通信和依賴關係，對照硬體的容量、頻寬和算力做數量級估算。

作者特別點名這類估算人容易錯，AI 也一樣，並列出四個典型錯法：

只算權重讀取而忘了 KV 快取
按峰值算力推算速度，而不查頻寬能否供給
把工作平分給多張卡，卻遺漏卡間通信
漏掉任何一項，結論都可能偏離幾倍甚至幾個數量級

還有一層來自他讀博時導師張霖濤的叮嚀：優化一定要做到物理所允許的極限。 全書貫徹這個習慣——先按第一性原理算出硬體允許的上限，再看實測離上限還有多遠；差距不是模型漏了項，就是系統有可以去掉的開銷。

全書反覆追問的五個問題¶

作者說從 FPGA 加速 Bing 搜尋排序、昇騰 AKG 算子生成到 UB 萬卡互聯，他反覆遇到的是同一條線索——資料搬移。所以全書反覆問：

搬什麼、搬多少、搬幾次、經過哪裡、誰必須等它。

這五個問題就是這本書的骨架。看任何一章都可以拿這五問去對。

十二章與各章的主問題¶

章	主題	主問題	正文大小
1	初識 AI Infra	一次生成需要多少顯存、計算和資料讀寫？	68 KB
2	模型架構	注意力、歷史狀態與專家結構如何改變系統需求？	148 KB
3	推理與訓練負載	任務階段、到達模式和狀態壽命如何影響資源需求？	99 KB
4	加速器架構	如何在計算、儲存、頻寬、功耗與成本之間取捨？	153 KB
5	算子與執行期	融合、複用、並發和調度如何減少執行開銷？	125 KB
6	超節點	多設備協作如何平衡容量、吞吐和同步代價？	158 KB
7	資料中心網路	網路頻寬、通信方式和壅塞如何影響計算效率？	165 KB
8	推理優化	批次處理、KV 管理、卸載與推測解碼何時有效？	104 KB
9	分散式推理	如何放置計算和狀態，並處理擴縮容與恢復？	144 KB
10	訓練系統	如何安排顯存、通信和重算，讓訓練更高效？	130 KB
11	資源調度與執行環境	模型服務和工具環境如何共享資源，減少等待？	102 KB
12	端邊雲協同	任務放在本地、邊緣還是雲端，如何兼顧效果、延遲和成本？	110 KB

正文合計約 1.5 MB Markdown（不含配圖）。注意每一章的標題都是一個問句——這不是章節命名的花招，是「從約束推導設計」這套方法的直接體現。

怎麼讀（作者給的路線）¶

先讀 1–3 章建立模型與負載的概念，然後依身分分流：

做模型應用 / 推理服務 → 重點 8、9 章，再看 11、12 章的部署；遇到容量、算子或通信問題再回頭追 4–7 章
做系統或網路 → 重點 5–7 章，再看 9、10 章
做晶片與體系結構 → 重點 4–7 章，配合後續章節的算例檢查硬體指標怎麼轉成服務能力

作者的建議很「量化研究方法」：遇到書中的算例，先自己估一下，再看推導和實驗結果。 也可以換成你正在用的模型和硬體，看結論是否改變。

最值得注意的：三個可驗證的配套¶

這本書跟一般技術書最大的差別在這裡——它把「你可以自己驗證」做成了基礎設施。

1. `calculations/`：不用 GPU 就能複算全書數字¶

python3 calculations/calc.py models                                        # 看支援哪些模型
python3 calculations/calc.py forward --model qwen3-8b --tokens 8192 --format md

靜態計算只需 Python 3.10+ 標準庫，不用 GPU、不用模型權重。 換一組模型和輸入就能估自己場景的資源需求。附有模型設定檔與結果索引。

2. `experiments/`：負結果完整保留，不改寫成成功¶

實驗按 experiments/chXX/XX-YY/ 存放，每個目錄有 run.py（獨立執行，只依賴標準庫）、README.md（題目、固定輸入、結果、判斷與限制）、results/，以及選配的 verify.py（跟 calculations/ 的獨立實作交叉核對）。

狀態統計誠實到少見：

delivered（93 項）：已交付
delivered_with_documented_gaps（17 項）：主路徑已交付，但 remaining 欄位逐項寫明還沒覆蓋的部分（沒有 E2B 憑證、公開紀錄中不存在同條件的訓練原始資料、後端拒絕某項配置、Agent 沒產出可用的新 kernel……）

README 裡這句話直接寫在協議層級：

負結果與失敗嘗試按原協議完整保留，不改寫成成功。

實跑類實驗跑在 Apple M2 Max 或一張 RTX PRO 6000 Blackwell（96 GB）上，而且註明 GPU 上有其他常駐服務，測量保留共享設備條件，不聲稱整卡獨占。連「歷史編號跟當前正文題號在第 8、11 章有錯位」都寫進 README 並保留路徑作為穩定證據地址。

3. `research/`：把寫書的過程也 commit 了¶

research/ 下有 54 個目錄，名字長這樣：ch04-whole-chapter-review-2026-09-11、ch02-five-models-2026-09-10、ch01-03-model-led-rewrite-2026-09-10、ch07-textbook-revision-2026-09-10。每一個都是某章某次重組／改寫的決策與校驗紀錄，README 直說「一般讀者不需要閱讀」，但便於追溯某段文字為什麼這樣寫。

裡面還有跨章的專題調研，例如〈2024–2026 AI Infra 長期調研〉〈2023–2026 token 成本下降專題〉〈DeepSeek V4/V4.1 Flash：基礎設施驅動模型設計的證據與修訂建議〉。

目錄名出現 model-led-rewrite 和 parallel-workers，加上 experiments/audit-2026-09-14/、249 KB 的 inventory.json、299 KB 的 calculations/PROGRESS.md——這本書本身就是一個大規模 AI 輔助寫作專案的公開紀錄。對一個剛寫完《深入理解 AI Agent》的作者來說，這件事本身就很有看頭：他把自己書裡講的東西拿來寫下一本書，而且把過程留檔。

工程細節¶

PDF 每次 push 到 main 就自動建置發 Release——實際上一天可以好幾個版本（build-20260914-145529、build-20260914-103601…）。README 明講推薦讀 PDF，因為書裡有大量公式、表格、腳註和交叉引用，GitHub 直接看 Markdown 時 LaTeX 常常渲染不全。PDF 用 XeLaTeX 排版，沿用《深入理解 AI Agent》的 ElegantBook 模板。
Git LFS 約 20 GB（論文與較大的輸入與測量紀錄），但 .lfsconfig 預設跳過所有 LFS 檔案——正文、配圖和靜態計算都不需要它們。要複現某個實驗才 git lfs pull --include="experiments/ch05/05-01/**" 只抓那一個目錄。這是大型資料 repo 值得抄的設定。
正文的唯一來源是 manuscripts/ 下的 Markdown，網頁版和 PDF 都由它建置生成。
case-studies/ 有 72 份案例分析，references/ 是引用資料與版本快照。

目前限制¶

書稿仍是初稿，正在持續修訂。 不只是客套話——research/ 裡整章重組的紀錄一路排到 2026-09-11，章節結構還在動。引用時務必記下你讀的是哪一個 build。
只有簡體中文。姊妹作《深入理解 AI Agent》有 15 種語言含繁中台灣版，這本目前沒有，README 的貢獻章節把翻譯列為歡迎認領的方向。
需要一些基礎：Python、線性代數、計算機系統。這不是入門科普書。
2.6K★ 但只有 3.5 週——熱度是姊妹作帶來的，內容成熟度還要時間驗證。0 open issues 也可能只是還沒累積讀者回饋。

研究價值與啟示¶

關鍵洞察¶

「模型是新的作業系統」這個框架比書的內容更值錢。 傳統系統優化必須在可程式性與效能之間取捨，因為不知道未來要跑什麼程式；而 LLM 成為最重要的應用之後，整條堆疊可以針對特定模型和加速器共同設計，模型甚至反過來適應硬體（DeepSeek V4.1 重新設計長上下文表示）。這個視角一旦建立，很多 AI Infra 的設計決策就從「工程細節」變成「可推導的結果」。
五個問題（搬什麼、搬多少、搬幾次、經過哪裡、誰必須等它）是可以直接帶走的思考工具。 不只用在 AI Infra——任何效能問題都可以先問這五題。它把「哪裡慢」這個模糊問題轉成五個有明確答案的子問題。
「先算出物理極限，再看實測差多遠」比「量測後調優」高一個層級。 差距不是你的模型漏了項，就是系統有可以去掉的開銷——兩個結論都有行動意義，而純粹的效能量測往往只能告訴你「現在多快」。
它把「你可以自己驗證」做成了基礎設施，這在技術書裡極罕見。 純標準庫的計算 CLI、跟 CLI 交叉核對的 verify.py、逐項寫明缺口的 delivered_with_documented_gaps、明講「共享設備、不聲稱整卡獨占」——這套做法對照本站剛做過的 AutoHedge（37 MB 沒人看過的假交易紀錄、指向不存在 tests/ 的 18 個 CI workflow）就是最強烈的反差。同樣是 commit 進 repo 的產出物，一邊是可複算的證據，一邊是沒人讀過的垃圾。
把寫作過程 commit 進 repo 是一種新的可信度來源。 research/ 那 54 份重組紀錄不是給讀者看的，是給「為什麼這段這樣寫」留的檔。在 AI 輔助寫作變成常態之後，「過程可追溯」可能會取代「作者權威」成為技術書的信任基礎。

與其他專案的關聯¶

對照	關係
《深入理解 AI Agent》	同一作者的姊妹作、同樣 Apache-2.0 全書開源、同一套 ElegantBook PDF 模板。Agent 那本教你怎麼用模型，這本教你模型底下那台機器。建議先讀 Agent 那本再讀這本
AutoHedge	極端反差組：同樣是 commit 進 repo 的產出物，這本是可交叉核對的實驗證據，那個是 37 MB 沒人讀過的假交易紀錄
Vibe-Trading	同樣把「已知還沒補的洞」公開寫出來（那邊是 grounding gate 的 open issues，這邊是 `delivered_with_documented_gaps`），誠實揭露限制是兩個高品質專案的共同特徵
system-design-primer / HighScalability	傳統分散式系統的量化思維來源；這本是同一種思維在 LLM 時代的重寫