大家好，我是玄姐。

最近，X（原推特）上有一條推文火了灬

大多數人看到后會想：我得學 CUDA 內核工程，這樣才能有價值。

但事實并非如此。

即便你花一輩子鉆研，也大概率擠不進那個約 100 人的頂尖圈子。內核固然重要，但不該是你的第一步。首要任務是理解整個系統的運作邏輯。

你可能讀過幾百篇關于 Triton 內核、PCIe 與 NVLink 對比、或是 DeepSpeed ZeRO 的文章，但作為 GPU 工程師，核心問題不是 “我能手寫內核嗎？”，而是 “這些組件如何協同工作？什么時候需要關注每個組件？” 因為行業真正的缺口不是工具使用技能，而是系統設計能力。

很少有人能真正把模型看作在硬件中流動的字節，把張量看作內存中的數據布局，這正是內核工程師的工作。但要進入這個精英群體，你得先搞懂所有東西的映射關系。

今天這篇文章，我就來給大家梳理這份系統設計思路。當你的模型跨越幾十甚至上百塊 GPU 時，你要問的就不只是 “代碼對不對？”，而是 “這些 GPU 協作高效嗎？會不會相互拖后腿？” 真正的瓶頸存在于同步、通信、調度和利用率這幾個方面。

要弄明白其中緣由，我們先回頭看看所有模型都會經歷的系統工作流（從左到右）：

你應該從 “模型定義” 開始入手。這一步效率更高、難度更低，性價比也最高。只有當問題無法在此層面解決時，再往下一層推進。

一、第一層：模型定義

這是大多數機器學習工程師的起點，也是他們花費時間最多的地方：定義 Transformer 層、接入 PyTorch、依賴自動求導（autograd）并串聯張量運算。

這個層面出現問題，通常是因為：

• 稠密矩陣乘法（matmul）受計算資源限制，占滿了 GPU 的算術邏輯單元（ALU）。
• 注意力層受內存帶寬限制，一直在等待數據傳輸，而非執行計算。
• 啟動了太多小型內核，導致額外開銷。

調試時需要用 PyTorch 或 JAX 的工具進行性能分析，并思考：“這是計算問題、內存問題，還是框架效率問題？”

舉個例子：當你的大語言模型（LLM）規模激增時，限制訓練速度的不只是計算能力，還有內存帶寬。GPT 模型變大后，正是內存帶寬拖慢了訓練進度。每次查詢 - 鍵 - 值（QKV）乘法都會產生海量內存讀寫。解決方案是什么？是 FlashAttention，一種融合內核（fused kernel），通過重新排序計算過程減少內存等待。如果不理解整個系統，你根本不會知道 GPU 為什么會處于空閑狀態。

你的工作應該是先讓模型能運行，嘗試優化，然后再調試。掌握每個層面的工具和框架，能幫你解決 80% 的問題；內核工程只能幫你壓榨剩余 20% 的性能。但如果沒搞定前 80% 就想著精通那 20%，恕我直言，這條路走不通。

即便你花一輩子鉆研，也大概率擠不進那個約 100 人的頂尖圈子。調試時，你會順著這個層級鏈條逐一排查，如下圖所示，按順序深入每個層面。

可以把 GPU 編排想象成一把梯子。每一級臺階對應技術棧的一個層面，各自存在獨特的瓶頸和故障模式。其中任何一級沒處理好，都會導致整體速度變慢。要從頂端開始，只在必要時才往下走。

接下來，我們看看下一層：

二、第二層：并行化

通常情況下，單塊 GPU 不足以運行你的 LLM，這時就需要橫向擴展，進入 “并行化” 層面。這里的核心挑戰不是計算本身，而是同步問題。梯度必須在 GPU 之間傳輸，參數需要分片存儲，優化器狀態也得拆分處理。

這個層面的瓶頸，往往來自：

• 同步式全歸約（all-reduce）內核因個別慢節點（stragglers）陷入停滯。
• PCIe 或 NVLink 的帶寬限制。
• 異步更新雖能提升吞吐量，但可能導致梯度過期（stale gradients）。

到了這一層，你的問題會從 “我的內核高效嗎？” 變成 “我的 GPU 之間信息交換高效嗎？” DeepSpeed ZeRO 能幫助實現狀態和梯度分片，但會引入通信開銷。

此時的瓶頸不再是 GPU 核心，而是網絡結構。你需要權衡：強同步（穩定但速度慢） vs 寬松異步更新（速度快但風險高）。

如果性能分析顯示通信與計算的重疊度很低，你可以用融合內核或自定義內核減少傳輸過程中的計算開銷，但這種情況很少見 ——DeepSpeed ZeRO 或 Megatron-LM 通常已經實現了這些優化。

再往下，我們看看下一層：

三、第三層：運行時編排

當你從單個模型訓練任務擴展到多個任務時，就進入了 “編排” 層面。這時你要問的就不是 “我的注意力內核高效嗎？”，而是 “為什么 30% 的 GPU 都在閑置？”

這個層面的問題通常表現為：

• 一半的 GPU 處于空閑，因為某個工作節點（worker）拖了后腿。
• 任務卡在隊列中，因為調度策略不公平。
• 大量小型任務導致集群資源碎片化，造成資源浪費。

調試時需要思考：“我是否在合理編排資源，讓 GPU 把時間用在訓練上，而非等待？”

舉個例子，這是我們在演講中討論過的 DeepMind 案例研究：

核心結論：DeepMind 報告稱，即便使用數千塊 GPU，分布式訓練仍會陷入停滯，少數慢節點會拖慢全局同步。在數據并行訓練中，整個任務會等待最慢的工作節點。Ray 和 Kubernetes 能通過彈性管理（節點故障時重新分配任務）和調度（避免 GPU 卡在隊列中）來解決這個問題。

但編排無法神奇地修復糟糕的同步邏輯，你需要同時優化并行化和編排策略。

當這些都實現后，你可以嘗試編寫融合內核，或優化集合通信內核（比如自定義全歸約實現），略微減少 GPU 在等待通信時的計算耗時；也可以預取張量或調整其對齊方式以適配直接內存訪問（DMA）傳輸；還能實現感知調度的自定義內核，在 Ray/Kubernetes 調度任務時更好地利用 GPU 流水線。

但再次強調，內核工程只適用于邊緣場景，具體是否需要，取決于調試中發現的問題類型。

四、第四層：編譯與優化

訓練完成后，LLM 需要處理數百萬次請求，此時生產環境中最關注的是延遲和吞吐量。每毫秒都至關重要。編譯器通過融合內核、優化內存局部性和降低精度來解決這些問題。

這個層面的主要挑戰是：

• 小型運算啟動了過多內核。
• 內存讀寫占滿運行時間（比如嵌入層查找）。
• 缺乏內核融合或量化，導致性能潛力未被充分挖掘。

這里的瓶頸不是訓練速度，而是真實流量下的吞吐量和延遲。調試時需要分析推理工作負載，并思考：“我是否讓每一塊 GPU 都實現了性價比最大化？”

舉個例子，假設你在部署 ChatGPT 的推理服務。ChatGPT 的推理過程通常包含大量小型運算，也就是逐 token 生成。如果每個運算都單獨啟動一個內核，內核啟動的開銷會成為主導因素。

TorchInductor 等編譯器會將多個運算融合成大型內核，TensorRT 會把模型量化為 FP16 或 INT8 格式，既節省計算資源又減少內存占用。Triton Server 則負責編排批處理，讓 GPU 高效處理數千個請求。

這才是內核工程真正發揮作用的地方。與第一層到第三層不同，這個階段的手動調優或編譯器干預，能對延遲和吞吐量產生顯著影響。但通常情況下，只有在窮盡了上述編譯器的優化潛力后，才需要考慮編寫自定義內核。只有當某個運算在每次推理 / 訓練步驟中要運行數百萬甚至數十億次時，自定義內核才有意義。

所以核心經驗是：

• 第一層到第三層：重點關注系統設計、編排和并行化，手寫內核基本無關緊要。
• 第四層：利用編譯器、批處理、量化和內核融合，大多數實際場景的瓶頸都能在這里解決。
• 只有當性能分析證明這些優化仍不足夠，且存在一些高價值運算值得手動調優時，才需要用到自定義內核。

五、第五層：硬件層面

這是整個系統的基石。每一個內核、每一次同步、每一個分片，最終都會觸及 GPU 和互連設備的物理極限。

這個層面的瓶頸表現為：

• 模型并行時 NVLink 帶寬飽和。
• 跨節點擴展時 PCIe 成為瓶頸。
• GPU 顯存不足，被迫卸載到 NVMe 硬盤。

這些問題無法通過框架 “修復”，只能通過調整工作負載結構、改變精度或升級硬件來規避。

大規模訓練中，當數千塊 GPU 同步梯度時，往往會占滿 InfiniBand 鏈路。這是無法通過 “編碼繞過” 的，PCIe 和 NVLink 的帶寬都是有限的。這也是人工智能工程與硬件工程的交叉點。

唯一的解決方案是架構層面的調整：使用更優的互連設備、降低同步頻率，或重新設計算法以減少通信量。

這就引出了我們之前討論的另一個案例研究：

Spectrum X 能夠分析 GPU 內存使用情況、互連帶寬（NVLink、PCIe、InfiniBand）和內核執行情況，精準定位瓶頸所在。

六、核心經驗

每個層面都是模塊化的，但又相互依賴：

• 如果在模型定義階段沒有管理好內存，會在并行化階段產生通信瓶頸。
• 如果在并行化階段配置錯了同步策略，會導致運行時編排階段的 GPU 閑置。
• 如果在編譯階段忽略了內核融合，會在生產環境中因延遲問題浪費成本。

因此，針對不同瓶頸類型，解決方案如下：

• 計算受限 → 通過模型 / 內核優化解決。
• 內存受限 → 通過分片、重計算、內核融合解決。
• 通信受限 → 通過并行化和編排解決。

一旦你掌握了這份 “系統地圖”，那些零散的博客文章、論文和爭議就不再是噪音，而是整個大系統中相互關聯的部分。

好了，這就是我今天想分享的內容。

本文轉載自???玄姐聊AGI??  作者：玄姐