做 AI 訓(xùn)練和部署這大半年我最大的一個感受是能把模型的 loss 訓(xùn)下去的人很多但能把一張訓(xùn)練卡的算力用好、把幾千張卡組織成一個不空轉(zhuǎn)的整體、把推理服務(wù)的延遲壓進(jìn) SLA 的人是另一種稀缺。這個領(lǐng)域有一個很寬泛的名字叫 AI Infra。我最初以為它只是“搭環(huán)境、裝驅(qū)動、調(diào)框架”真正深入以后才發(fā)現(xiàn)它是一整條從芯片到業(yè)務(wù)的鏈路算力硬件、集群網(wǎng)絡(luò)、資源調(diào)度、分布式訓(xùn)練、推理引擎、存儲訪問、性能剖析……每一環(huán)都是獨立的深水區(qū)。這篇 AI Infra 知識全景學(xué)習(xí)筆記就是我把這條鏈路里繞不開的知識點整理成的一份地圖式提綱從底層到上層逐層拆解同時把我實際踩過的坑和算過的賬一并寫出來。無論你是剛要從算法轉(zhuǎn)向工程還是已經(jīng)在維護(hù)訓(xùn)練集群這份筆記都能幫你快速建立起全局坐標(biāo)系。1. AI Infra 全景認(rèn)知先給這個領(lǐng)域畫張地圖1.1 AI Infra 不是什么而是什么很多人有一個慣性思維覺得做 AI 最核心的是模型結(jié)構(gòu)。在大模型出現(xiàn)之前這個想法問題不大單卡訓(xùn)練、單機推理瓶頸主要在算法本身。但到了大模型階段問題徹底變了模型參數(shù)動輒幾十 B、上百 B單卡放不下就要切切了就要通信通信就要組網(wǎng)組網(wǎng)就要調(diào)度調(diào)度就要考慮資源隔離和利用率跑起來還要監(jiān)控、評測、優(yōu)化。這一整條鏈路就是 AI Infra。舉一個很直觀的例子你向大模型問一個問題表面上只是輸入一句文本收到一段回答但背后實際發(fā)生了至少四段工作請求進(jìn)入網(wǎng)關(guān)被調(diào)度到某個實例實例從存儲里讀取模型權(quán)重和數(shù)據(jù)GPU 完成數(shù)千次矩陣運算中間還要通過網(wǎng)絡(luò)同步多個設(shè)備的計算結(jié)果。任何一個環(huán)節(jié)慢用戶感受到的就是“轉(zhuǎn)圈圈”。所以 AI Infra 不是某一臺機器或某一個軟件而是讓“輸入-計算-輸出”這條鏈條高效運轉(zhuǎn)的全部工程手段。這也是我把它稱為“知識全景”的原因。它不像某個算法可以用一個公式講清楚而是一個橫跨硬件、網(wǎng)絡(luò)、系統(tǒng)軟件、并行計算、服務(wù)架構(gòu)的交叉學(xué)科。要理解它必須先有一張地圖。1.2 七個層次的知識框架我按自己的理解把 AI Infra 從上到下拆成七個層級。這個分層不一定是標(biāo)準(zhǔn)定義但用來建立知識體系非常順手層級解決的核心問題典型概念與工具算力硬件層提供計算和顯存資源GPU/NPU、HBM 顯存、高速互聯(lián)總線集群網(wǎng)絡(luò)層讓多卡高效交換數(shù)據(jù)RDMA、擁塞控制、集合通信資源管理層把算力按需分配給多個任務(wù)Kubernetes、GPU 虛擬化、調(diào)度策略分布式訓(xùn)練層把大模型拆到多卡上訓(xùn)練數(shù)據(jù)并行、張量并行、流水線并行、ZeRO推理服務(wù)層把訓(xùn)練好的模型變成可用服務(wù)連續(xù)批處理、KV Cache、推理引擎存儲與數(shù)據(jù)層讓數(shù)據(jù)/檢查點讀寫不拖后腿分布式文件系統(tǒng)、緩存、預(yù)取可觀測與性能層定位瓶頸、優(yōu)化成本Profiling、利用率監(jiān)控、成本模型這張表的順序就是知識依賴的方向。底層決定上層的可能性上層則反過來影響底層的選型。比如你推理引擎的批處理策略直接決定了你要買多少卡你的調(diào)度策略又決定了訓(xùn)練任務(wù)的利用率。我在學(xué)習(xí)時的一個心得是不要一上來就扎進(jìn)分布式訓(xùn)練的源碼里而是先按這七個層級各看三篇有分量的文章腦海里有了“哪一環(huán)對應(yīng)什么問題”的索引再往后學(xué)效率會高出很多。接下來我會按從底層到上層的順序把每一層的關(guān)鍵知識點展開講。2. 算力與集群網(wǎng)絡(luò)AI Infra 的地基2.1 為什么算力瓶頸不是“算”而是“搬”很多剛接觸 AI Infra 的人會以為GPU 越快訓(xùn)練越快。這句話只對了一半。真正決定大模型訓(xùn)練和推理上限的往往不是計算峰值而是數(shù)據(jù)搬運速度。大模型的兩個核心階段能很清楚地說明這個問題。訓(xùn)練階段每一輪迭代都要把權(quán)重和梯度在顯存里來回讀寫推理階段自回歸生成是逐 token 解碼的前一個 token 的結(jié)果必須參與后一個 token 的計算本質(zhì)上是串行的訪存密集操作算力的利用率天然受限。我常用一個“食堂打飯”的類比來理解這件事算力就是廚師的炒菜速度顯存帶寬就是窗口遞菜的速度。如果廚師一分鐘能炒十盤菜但窗口一分鐘只能遞出三盤整個食堂的效率就是三盤/分鐘。你換一個廚師更強的算力效率依然不變。AI Infra 大量優(yōu)化的本質(zhì)都是讓“遞菜速度”追上“炒菜速度”。實測來看目前主流訓(xùn)練加速卡的顯存帶寬通常在 2TB/s 到 3TB/s 之間而計算峰值已經(jīng)到每秒幾百甚至上千 TFLOPS。大模型的核心算子基本都是訪存密集型很多時候顯存帶寬直接決定了你的訓(xùn)練吞吐上限。2.2 顯存與 I/OHBM 與緩存的作用顯存帶寬之所以能做到這么高靠的是 HBM高帶寬內(nèi)存技術(shù)。HBM 的邏輯和傳統(tǒng) GDDR 顯存不一樣它通過 3D 堆疊的方式把多個 DRAM 層疊在一起用硅通孔連接從而獲得遠(yuǎn)超平面布線的數(shù)據(jù)通道寬度。簡單說通道更寬一次能并行搬的數(shù)據(jù)就更多。但 HBM 容量相對有限單卡主流是 80GB 左右。這就是矛盾所在一個 7B 參數(shù)的模型光權(quán)重用 BF16 存儲就要 14GB再加上梯度和 Adam 優(yōu)化器狀態(tài)單卡根本裝不下。所以必須把模型切到多張卡上切了之后就要通信這就引出了集群網(wǎng)絡(luò)。在實際調(diào)優(yōu)時還要注意算子庫的選擇和緩存利用。一個卷積或者矩陣乘法會被拆成很多 tile 放到片上緩存里計算如果 tile 切得不夠合理緩存命中率低算力就會被白白浪費。這也是為什么同樣的模型有人能跑到高利用率、有人只能跑到一半的原因。我通常在排查一個算子慢的問題時會先去確認(rèn)是不是顯存訪問模式問題而不是急著懷疑硬件壞了。2.3 集群網(wǎng)絡(luò)高速互聯(lián)、RDMA 與集合通信單機多卡之間目前主流方案是高速 NVLink 全互聯(lián)或類似的高帶寬總線帶寬能到數(shù)百 GB/s延遲極低?？绻?jié)點之間則要用 RDMA 網(wǎng)絡(luò)如 InfiniBand 或 RoCE帶寬通常在 200Gbps 到 400Gbps 級別。注意單位差異節(jié)點內(nèi)是 GB/s跨節(jié)點是 Gbps兩者有 8 倍的單位換算關(guān)系算峰值時很多人會在這一點上被繞暈。有了網(wǎng)絡(luò)之后就要考慮怎么組織通信。分布式訓(xùn)練中最常見的通信原語是 AllReduce也就是把所有卡的梯度做一個求和再廣播給所有卡。業(yè)界最常用的集合通信庫 NCCL 對這個操作做了大量優(yōu)化包括分塊傳輸、流水線重疊、拓?fù)涓兄饶軌虬淹ㄐ帕繅旱浇咏碚撋舷?。但網(wǎng)絡(luò)擁塞會成為隱形的殺手。我遇到過一種情況4 機 8 卡訓(xùn)練時明明單卡之間的通信測試帶寬都正常整個訓(xùn)練吞吐卻只有預(yù)期的 60%。排查到最后發(fā)現(xiàn)是網(wǎng)絡(luò)交換機上的擁塞控制策略沒有開啟多卡并發(fā)傳輸時大量數(shù)據(jù)包排隊丟棄觸發(fā)重傳通信效率被拉低了一個量級。這個坑告訴我AI Infra 的學(xué)習(xí)不能只停留在代碼層交換機配置、網(wǎng)卡參數(shù)這些“硬件晦澀區(qū)”同樣是性能的重要組成部分。3. 資源管理與調(diào)度把算力當(dāng)成稀缺資源對待3.1 從單機到集群為什么 Kubernetes 管理 GPU 這么重要當(dāng)集群里有幾十臺機器、每臺機器多張卡問題就變成了誰來決定一個訓(xùn)練任務(wù)跑到哪張卡上如果只靠人工分配不僅效率低而且容易造成嚴(yán)重的資源碎片。所以絕大多數(shù) AI 集群都會引入 Kubernetes 這類容器編排平臺把底層的異構(gòu)機器抽象成統(tǒng)一的資源池。但 Kubernetes 對 GPU 的管理邏輯很特別。CPU 是用完即釋放的而 GPU 一旦被容器獨占除非任務(wù)結(jié)束否則就會一直占用顯存和計算資源。所以 GPU 調(diào)度不能只看“有沒有空閑卡”還要看顯存余量、算力配額、是否支持在卡間做緊耦合通信。這就催生了 GPU 虛擬化和分時復(fù)用技術(shù)比如對物理 GPU 做硬件切分或者在時間片上把一張卡分給多個推理任務(wù)從而提升整體利用率。我在實際維護(hù)集群時的一個體會是調(diào)度的根本目標(biāo)不是“把任務(wù)塞進(jìn)機器”而是“把任務(wù)放到能完成它且讓整體利用率最高的位置”。比如兩個訓(xùn)練任務(wù)分別需要 60GB 和 20GB 顯存物理卡是 80GB如果調(diào)度器把它們錯開放到同一張卡就能省下另一張卡去跑別人如果調(diào)度器沒有碎片感知能力就會各占一張卡白白浪費 20GB 空間。3.2 調(diào)度策略組合優(yōu)化與權(quán)衡資源調(diào)度本質(zhì)上是一個組合優(yōu)化問題最簡單的兩類策略是“裝箱”Binpack和“打散”Spread。Binpack把任務(wù)盡量集中到少數(shù)節(jié)點上空出整塊節(jié)點。好處是省電壞處是單點故障影響面大并且把多個大型訓(xùn)練任務(wù)放在同一機架可能造成網(wǎng)絡(luò)擁塞。Spread把任務(wù)均勻打散到各個節(jié)點。好處是容錯性好壞處是容易產(chǎn)生碎片并且訓(xùn)練任務(wù)之間的通信可能因為位置分散而變慢。在大規(guī)模訓(xùn)練場景通常還要考慮拓?fù)?。同一個訓(xùn)練任務(wù)里的多張卡最好落在同一個交換機下最好是一個物理機箱內(nèi)因為 NVLink 帶寬比跨節(jié)點網(wǎng)絡(luò)高一個量級。很多調(diào)度器會做拓?fù)溆H和性計算就像訂機票時優(yōu)先安排同航站樓轉(zhuǎn)機一樣需要為“通信密集”的任務(wù)預(yù)留“同一機架”的位置。我踩過一個很典型的坑某團隊 A 同學(xué)反饋 GPU 利用率只有 30%我看了一下任務(wù)分布發(fā)現(xiàn)調(diào)度器為了“均勻”把一個 8 卡訓(xùn)練任務(wù)拆到 8 個不同節(jié)點上每張卡之間都通過網(wǎng)絡(luò)通信。結(jié)果模型的張量并行頻繁跨節(jié)點同步通信開銷把計算時間完全吃掉。后來改成把 8 卡全部調(diào)度到同一臺多卡機器上利用率直接回到 85% 以上。這充分說明調(diào)度策略不是拍腦袋決定的必須結(jié)合任務(wù)的通信模式。3.3 層級調(diào)度與排隊別讓大任務(wù)餓死小任務(wù)除了位置選擇調(diào)度還要處理優(yōu)先級和排隊。一個動輒占用上百張卡的大型訓(xùn)練任務(wù)如果和小型推理任務(wù)混跑可能會長期占據(jù)共享資源。比較成熟的調(diào)度器會設(shè)計兩級結(jié)構(gòu)先按優(yōu)先級和高層策略決定哪一類任務(wù)可以進(jìn)入再在內(nèi)部做具體的放置。訓(xùn)練任務(wù)往往長期霸占推理任務(wù)則偏向延遲敏感兩者混部實際上是另一個大的研究課題。學(xué)習(xí)這一層知識我的建議是先把 Kubernetes 的資源模型Requests/Limits和調(diào)度器擴展機制看懂再去看主流的 AI 調(diào)度器是怎么做 GPU 分配和隊列管理的。這里很多經(jīng)驗都無法從文檔里學(xué)到只能靠真實集群的“性價比”來感知。4. 分布式訓(xùn)練的核心邏輯并行策略與顯存優(yōu)化4.1 單卡裝不下四種并行怎么選分布式訓(xùn)練就是解決“模型太大”和“數(shù)據(jù)太多”兩個問題業(yè)界形成了四種基本并行策略策略切什么顯存收益通信開銷適用場景數(shù)據(jù)并行DP復(fù)制模型切數(shù)據(jù)無每卡都要完整模型每步同步梯度通信量與模型大小成正比單卡能裝下模型時張量并行TP切分矩陣運算的維度每卡只存一部分權(quán)重每層多次集合通信極高單卡裝不下、且節(jié)點內(nèi)高帶寬場景流水線并行PP按層切分網(wǎng)絡(luò)每卡只存部分層通信量小但產(chǎn)生流水線氣泡超深網(wǎng)絡(luò)、跨節(jié)點場景序列并行SP切分序列長度維度減少激活值顯存依賴注意力機制的重計算長序列場景常與 TP 組合數(shù)據(jù)并行的邏輯最好理解每張卡復(fù)制一份完整模型喂不同的數(shù)據(jù)算完梯度后在卡間做 AllReduce 求平均再同步更新。它的顯存開銷最大但通信結(jié)構(gòu)最簡單是工程上最容易被框架封裝好的選擇。張量并行則直接把一個矩陣乘法拆開到多張卡上做比如把權(quán)重矩陣按行切給卡 A、按列切給卡 B每張卡只持有模型的一部分。通信頻率很高因為它作用于模型內(nèi)部每一層的計算每處理一個層就要做數(shù)據(jù)同步。所以張量并行幾乎只在高帶寬的節(jié)點內(nèi)使用跨節(jié)點用張量并行基本是災(zāi)難。流水線并行是另一個極端它把幾十層網(wǎng)絡(luò)切成多段每張卡負(fù)責(zé)一段輸入數(shù)據(jù)像流水線一樣經(jīng)過所有段。通信量小但會產(chǎn)生氣泡——即某些卡在等上游輸出時是空閑的。這兩種策略之間的選擇本質(zhì)上是在“通信成本”和“空閑成本”之間做權(quán)衡。4.2 一個必須算的賬ZeRO 到底省了什么在真正上多機多卡之前建議先把 ZeRO 這套優(yōu)化思路搞懂。它解決的問題是即使單卡裝不下模型也不一定非要切模型可以把模型狀態(tài)“分片并行”地放在多張卡上。先算一筆賬7B 模型用 BF16 存儲是 14GB訓(xùn)練通常需要 FP32 主權(quán)重、一階動量、二階動量三者加起來每參數(shù) 12 字節(jié)也就是說優(yōu)化器狀態(tài)就要 84GB再加上梯度和權(quán)重總量超過 110GB。單卡 80GB 根本放不下。ZeRO 的解決思路是分階段把狀態(tài)切到各卡上ZeRO-1只把優(yōu)化器狀態(tài)切分到各卡每卡顯存從 110GB 降至約 40GBZeRO-2把優(yōu)化器狀態(tài)和梯度都切分每卡約 25GBZeRO-3把參數(shù)、梯度、優(yōu)化器狀態(tài)全部分片每卡約 14GB。代價是通信量上升。ZeRO-3 每一步都需要從別的卡拉取參數(shù)通信量大約是數(shù)據(jù)并行的 1.5 到 2 倍。所以 ZeRO 不是無腦最優(yōu)而是用一部分通信開銷換取顯存空間。配置時常用的經(jīng)驗值是先看單卡能不能放下 FP16 權(quán)重和梯度放得下就用 ZeRO-2放不下才升到 ZeRO-3。4.3 流水線氣泡與微批次調(diào)優(yōu)如果用流水線并行就要立刻面對“氣泡”這個概念。假設(shè)把模型切成 8 段8 個 stage一次只喂一個 micro-batch那么整條流水線只有第一個 batch 進(jìn)入時是滿負(fù)荷后面每個 stage 都是串行執(zhí)行大量時間在等待上游——這就是氣泡。解決辦法是引入多個 micro-batch微批次讓流水線里的每個 stage 同時都在干活。氣泡比例近似等于 (stage 數(shù) - 1) / (micro-batch 數(shù) stage 數(shù) - 1)。stage 越深需要越多 micro-batch 才能填滿流水線。我實際調(diào)參時會先按這個公式算再結(jié)合顯存余量決定 micro-batch 數(shù)量通常調(diào)到氣泡占比低于 10% 才會認(rèn)為參數(shù)合理。還有一個容易忽略的點micro-batch 數(shù)量增大每張卡上的激活值顯存也會增加。所以微批次調(diào)優(yōu)本質(zhì)上是在“氣泡”和“激活顯存”之間找平衡。遇到峰值顯存 OOM優(yōu)先減小 micro-batch而不是盲目換并行策略這是成本最低的調(diào)整方式。4.4 一個真實的選型場景模擬項目 X給一個具體的決策示例。模擬項目 X 要訓(xùn)練一個 30B 參數(shù)的模型集群是 4 臺機器、每臺 8 張 80GB 卡共 32 卡。BF16 權(quán)重 60GB單卡裝不下ZeRO-2 可以把優(yōu)化器狀態(tài)分片每卡權(quán)重 60GB 梯度 60GB 優(yōu)化器狀態(tài)約 30GB合計約 150GB算出來其實仍超單卡。這時正確的組合是把模型切成 4 份張量并行并用 ZeRO-2 處理優(yōu)化器狀態(tài)。每個 TP 組內(nèi)用高帶寬互聯(lián)通信組間再通過數(shù)據(jù)并行同步梯度是典型的“TP ZeRO DP”組合。這種決策樹的推導(dǎo)邏輯是先看單卡能否容納權(quán)重和梯度 → 不能則選擇 TP 切分 → 再看優(yōu)化器狀態(tài)是否超過單卡剩余顯存 → 仍超則加 ZeRO-2 → 如果模型層數(shù)很深可進(jìn)一步加入 PP用跨節(jié)點連接。整個過程中每一步都涉及顯存賬和通信賬只有把兩張賬都算清楚才能得到可靠的配置。5. 推理服務(wù)層讓模型真正跑起來5.1 訓(xùn)練和推理的思路為什么完全不同訓(xùn)練追求的是“吞吐”單位時間處理多少 token、梯度更新多快推理追求的首要是“延遲”用戶發(fā)出請求到收到第一個 token 要多久。這導(dǎo)致技術(shù)選型完全不同。大模型推理可以拆成兩個階段prefill預(yù)填充處理用戶輸入的整段 prompt屬于計算密集型GPU 算力利用率很高decode解碼階段逐 token 生成答案屬于訪存密集型每生成一個 token 都要把當(dāng)前所有緩存權(quán)重讀一遍算力利用率通常很低。很多人第一次看到推理卡的 GPU 利用率只有 20% 到 30%就是這個原因不是卡不行而是 decode 階段天然受帶寬限制。這帶來一個關(guān)鍵結(jié)論推理性能優(yōu)化的重點是盡量減少 decode 階段的訪存量而不是盲目堆算力。5.2 連續(xù)批處理與 KV Cache 管理最早期的推理服務(wù)采用靜態(tài)批處理一批請求同時到達(dá)、同時算完、同時離開。這種模式的問題在于decode 階段批內(nèi)的每個請求長度不同短的請求會等長的請求大量算力白白浪費。于是出現(xiàn)了連續(xù)批處理每個 step 動態(tài)地從隊列里撈入新請求同時把已經(jīng)結(jié)束的請求移出批次。因為 decode 階段每個請求只是順序讀取自己的緩存新舊請求可以互相穿插而不干擾所以吞吐能提升數(shù)倍。這是目前主流推理引擎的標(biāo)準(zhǔn)做法。還有一個繞不開的概念是 KV Cache。自回歸生成時模型需要把之前所有 token 的 Key 和 Value 緩存下來避免每步重新計算。KV Cache 的大小非常驚人以 7B 模型為例每個 token 約產(chǎn)生 0.5MB 緩存4096 token 長度就是 2GB。如果顯存只有 80GB留給權(quán)重約 14GBKV Cache 能容納的并發(fā)請求數(shù)非常有限。主流引擎采用分頁管理的方式優(yōu)化 KV Cache 的顯存利用率核心思想是顯存按頁分配像操作系統(tǒng)虛擬內(nèi)存一樣減少碎片和浪費。這也是我在配置推理服務(wù)時最喜歡調(diào)的一項它直接決定了并發(fā)能力和延遲表現(xiàn)。如果你觀察到服務(wù)排隊嚴(yán)重先別急著加卡看看 KV Cache 的使用率和顯存碎片率。5.3 推理引擎的量化與硬件選型有感推理場景還有一個和訓(xùn)練截然不同的點量化技術(shù)對性能影響極大。把權(quán)重從 FP16 降到 INT8KV Cache 也做量化顯存和帶寬需求幾乎減半decode 吞吐能翻倍。所以推理服務(wù)的性能優(yōu)化往往是從“省內(nèi)存”入手的。在硬件選型上我學(xué)到一個重要指標(biāo)“算力與帶寬比”。如果一款卡算力極高但帶寬一般它跑 decode 任務(wù)時算力會被嚴(yán)重浪費反之如果帶寬高但算力一般反而能在實際推理中表現(xiàn)更好。這個比值可以作為判斷推理場景卡型適配度的第一參考就像選車型時不只看馬力還要看變速箱匹配。具體的卡型選擇我不過多展開因為會牽涉到成本模型建議結(jié)合自己的 token 吞吐目標(biāo)來算。6. 存儲、數(shù)據(jù)與可觀測性容易被忽視的隱形成本6.1 檢查點與數(shù)據(jù)讀取訓(xùn)練被“餓死”的現(xiàn)象很多團隊把精力全放在并行配置上結(jié)果 GPU 利用率還是上不去最后發(fā)現(xiàn)是磁盤讀取慢導(dǎo)致數(shù)據(jù)供不上。訓(xùn)練任務(wù)可以類比成一條生產(chǎn)線GPU 是終端裝配工數(shù)據(jù)加載環(huán)節(jié)就是原料輸送帶。輸送帶一旦斷料再快的裝配工也只能等。大模型的檢查點checkpoint保存非?？膳乱粋€百億級模型的全量權(quán)重和優(yōu)化器狀態(tài)可能有數(shù)百 GB全靠訓(xùn)練結(jié)束一次性寫出寫盤期間整批 GPU 都要停下來等。常用方案是異步 checkpoint把寫盤交給后臺線程讓訓(xùn)練迭代替換繼續(xù)進(jìn)行同時用內(nèi)存緩存或高性能分布式文件系統(tǒng)避免每次讀卡前訪問慢速磁盤。我測試過的一個案例里開啟異步保存后訓(xùn)練吞吐從每分鐘 12 個 step 提升到 19 個 step提升接近 60%只是簡單地把同步寫盤改為后臺異步完成。這說明存儲層的優(yōu)化是性價比極高的投資學(xué)習(xí) AI Infra 時千萬別只看“計算”。6.2 性能剖析與慢任務(wù)定位當(dāng)訓(xùn)練或推理性能不達(dá)標(biāo)時第一件事不是改超參而是定位瓶頸在哪一層。我歸納了一個排查順序表每次按表執(zhí)行就能很快縮小范圍現(xiàn)象優(yōu)先排查對象可能原因GPU 利用率低且波動大數(shù)據(jù)加載鏈路磁盤讀慢、預(yù)處理沒做、隊列太小GPU 利用率低但 CPU 忙數(shù)據(jù)預(yù)處理訓(xùn)練線程在等數(shù)據(jù)轉(zhuǎn)換完成多卡通信時吞吐驟降網(wǎng)絡(luò)層擁塞控制未開、交換機降速、網(wǎng)卡拓?fù)洳粚蝹€節(jié)點明顯比同集群慢硬件層GPU 降頻、HBM 出現(xiàn)錯誤、散熱問題顯存頻繁 OOM并行/緩存配置激活值過大、KV Cache 碎片、micro-batch 過大在實際觀測中我會同時關(guān)注 GPU 利用率、顯存帶寬利用率、網(wǎng)絡(luò)吞吐三個指標(biāo)。如果 GPU 利用率 90% 但顯存帶寬跑滿說明是該卡的訪存極限加卡不一定有用如果網(wǎng)絡(luò)吞吐打到線速則是通信瓶頸又要回頭調(diào)整并行策略。這種綜合分析能力是 AI Infra 學(xué)習(xí)者最核心的一項修煉。7. 學(xué)習(xí)路線與常見坑寫給后來者的實踐建議7.1 我推薦的學(xué)習(xí)順序如果從零開始建議按“單卡訓(xùn)練 → 多機多卡 → 集群調(diào)度 → 推理部署 → 性能剖析”的順序走每個階段都動手做一個小實驗而不是只讀文檔。第一步先把一個開源對話模型的微調(diào)跑通觀察顯存占用和單卡利用率。第二步到兩臺機器上做數(shù)據(jù)并行看看梯度同步帶來的性能損耗。第三步嘗試把模型切成張量并行或流水線并行體驗通信開銷的巨大差異。第四步部署推理服務(wù)調(diào)整批處理和 KV Cache 配置觀察并發(fā)和延遲變化。這個過程走下來你會對每個概念的“手感”非常清晰。遇到問題時不至于在概念之間打轉(zhuǎn)。我認(rèn)識的不少人都會跳步一上來就學(xué)多機多卡結(jié)果連單卡的顯存賬都不會算最后還是得回頭補基礎(chǔ)。7.2 高頻問題速查把幾個經(jīng)常遇到的問題整理成速查表方便直接對照模型訓(xùn)練時 loss 一直是 NaN先查學(xué)習(xí)率和混合精度配置再看數(shù)據(jù)里有沒有異常值最后查梯度累計和 loss scaling。多卡訓(xùn)練時某張卡“掉隊”導(dǎo)致整體等待。這類問題多半是慢節(jié)點需要檢查該卡的時鐘頻率、散熱和 HBM 錯誤。推理服務(wù)響應(yīng)慢但 GPU 利用率不高優(yōu)先級最高的是檢查 KV Cache 命中率和批處理是否生效很多情況下是并發(fā)隊列配置不對。集群利用率統(tǒng)計虛高注意有的監(jiān)控把“已分配但空閑”也算成被使用看真實利用率一定要看算力采樣數(shù)據(jù)而不是分配比例。7.3 一點個人體會說到最后我想分享一個這段時間學(xué) AI Infra 最深的感觸它不是一個靠“多看幾篇論文”就能掌握的知識而是一門靠“算賬”和“試錯”積累的手藝。顯存賬、帶寬賬、延遲賬、成本賬每一步都在做權(quán)衡而真正的優(yōu)化往往發(fā)生在交叉地帶。我在實際維護(hù)集群時發(fā)現(xiàn)最花時間的不是把任務(wù)跑起來而是讓任務(wù)跑得快且穩(wěn)。每一次利用率提升的背后可能只是一行調(diào)度配置的改動或者一次網(wǎng)絡(luò)參數(shù)的調(diào)優(yōu)但它需要你對整條鏈路都有清晰的認(rèn)知。這也是我整理這份 AI Infra 知識全景學(xué)習(xí)筆記的原因把地圖先畫好后面的路才不容易走偏。如果讓我再給一條具體建議那就是把“成本模型”刻在腦子里。無論是選并行策略、買卡、調(diào)顯存還是配網(wǎng)絡(luò)都先估算單位 token 或單位樣本的成本再決定優(yōu)化方向。這個習(xí)慣一旦養(yǎng)成你會發(fā)現(xiàn)所有技術(shù)的選擇都變得清晰起來。