CUDA Kernel
3 秒看懂
CUDA Kernel 是執行在 NVIDIA GPU 上的一段並行程式,一次啟動會生成成千上萬個輕量執行緒,同時處理資料的不同部分。在深度學習中,幾乎所有運算元的實際執行(矩陣乘法、卷積、注意力計算等)最終都被編譯或對映為最優的 CUDA Kernel,它就是 AI 算力底層的“原子作業”。
3 分鐘產業解釋
可以把 CUDA Kernel 想像成在工廠流水線上同時工作的數萬名工人:每個工人只處理極微小的一件任務,但合起來能瞬間加工完一整批貨物。CPU 像是少數幾個精密的工程師,擅長複雜的邏輯控制和低延遲任務;GPU 則靠 CUDA Kernel 排程成百上千個“簡單工人執行緒”,以極高吞吐量吞噬大規模平行計算。
在 AI 產業裡,資料科學家用 PyTorch、TensorFlow 寫一行 torch.matmul 或 F.conv2d,架構底層就會呼叫 NVIDIA 的 cuBLAS、cuDNN 等庫,這些庫裡封裝了手寫調優到極致的 CUDA Kernel——它們針對 Tensor Core、共享記憶體、資料預取等做了大量微架構級別的最佳化。可以說,控制了 CUDA Kernel 的效率和生態,就等於控制了 AI 訓練與推論的即時成本和效能天花板。這也是為什麼其他 AI 晶片公司不得不投入大量資源建置自己的編譯器和運算元庫,以突破 CUDA 的“軟硬體一體”護城河。
15 分鐘專家深入
CUDA Kernel 程式碼使用帶擴充套件的 C++ 編寫,通過 nvcc 編譯為 GPU 可執行的機器碼。啟動一個 Kernel 時,程式設計師需要指定執行緒層次:
- 整個任務空間叫一個 grid,可以是一維、二維或三維,適應影像、矩陣或張量的形狀。
- 每個 grid 被分解為許多 block,每個 block 包含最多 1024 個執行緒(這是程式設計模型的限制,實際可排程量由硬體資源決定)。
- 每個 block 內的執行緒又分組為 warp(固定 32 個執行緒),warp 是 GPU 執行和排程的最小單元。
記憶體層次是效能的關鍵:同一 block 內執行緒共享極快的 shared memory,block 之間可通過 global memory(視訊記憶體)交換資料,另外有隻讀的 constant memory、texture memory 和每個執行緒專有的 local memory(位於視訊記憶體中的私有儲存區,當暫存器溢位時被使用)。CUDA Kernel 的最佳化大量圍繞“如何把資料從緩慢的 global memory 搬運到 shared memory,做足計算再寫回”展開。
深度學習中的典型 Kernel 包括:
- 矩陣乘法 (GEMM):採用 tiling 策略,將大矩陣切成小片,每片由 block 計算,子片由 warp 和 thread 協作完成,中間結果暫存在 shared memory 和暫存器中,最大化資料複用。
- 卷積:早期使用 im2col 將卷積轉換為矩陣乘法;現代實現多采用 Winograd 演算法或直接利用張量核心的 Implicit GEMM。
- 注意力機制 (Softmax + MatMul):像 FlashAttention 這樣的 Kernel,重排了計算順序,以分塊方式載入 Q、K、V,線上計算 softmax 並累計結果,避免將整個注意力矩陣寫入慢速視訊記憶體,極大降低 IO,是近年來 LLM 推論加速的里程碑。
- 融合運算元:將多個連續操作(如 layer norm + gelu)合併成一個 Kernel,消除中間資料的視訊記憶體往返,是編譯器最佳化(如 XLA、Triton)的核心能力。
此外,Tensor Core 是一種專門加速矩陣乘積累加(MMA)操作的硬體單元,通過特殊的內聯指令(如 mma.sync)可在 Kernel 中排程,提供遠超通用核心的矩陣運算吞吐,但需要精心對齊資料和形狀。
技術原理(最深)
執行緒組織與排程
CUDA Kernel 的啟動配置記為 <<<gridDim, blockDim, sharedMemBytes, stream。每個執行緒內建三維索引變數 threadIdx(block 內位置)、blockIdx(grid 內位置)、blockDim 等,用於計算全域性資料索引。
grid 由 2×2 個 block 組成
-------------------------
| Block (0,0) | Block (0,1) |
| thread 0 | thread 0 |
| thread 1 | thread 1 |
| ... | ... |
-------------------------
| Block (1,0) | Block (1,1) |
-------------------------
每個 block 被分配到某個 Streaming Multiprocessor(SM)上執行。SM 內包含多個 warp scheduler,每個週期選擇一個就緒 warp 下發指令。warp 內所有執行緒執行同一條指令(SIMT 模型),若發生分支(if-else),不同路徑會被依次序列執行(warp divergence),導致效率損失。
記憶體模型與延遲隱藏
GPU 沒有 CPU 那樣複雜的快取預測和亂序執行,而是靠大量併發執行緒來隱藏記憶體延遲。當 warp 因 global memory 訪問而暫停時,warp scheduler 立刻切換到另一個已就緒的 warp。所以保持 SM 上有足夠多 active warps(高佔用率)是隱藏延遲的關鍵,但佔用率並非絕對越高越好——如果暫存器或 shared memory 消耗過大,反而會限制並行 warp 數量。
Shared memory 是片上 SRAM,bank 數目和位寬因架構而異。如果同一個 warp 內多個執行緒同時訪問 shared memory 的同一個 bank 的不同地址,會發生 bank conflict,降低有效頻寬。最佳化 Kernel 時會精心設計資料版面配置和訪問步長來避免。
深度學習典型 Kernel 微觀機制
以分塊矩陣乘法 C[M,N] += A[M,K] * B[K,N] 為例(簡化 tile 演算法):
for (int i = 0; i < M; i += BM)
for (int j = 0; j < N; j += BN) {
// 將 A 和 B 的子塊載入 shared memory
for (int k = 0; k < K; k += BK) {
// 各執行緒協作載入 A[i:i+BM, k:k+BK] 到 sh_A
// 各執行緒協作載入 B[k:k+BK, j:j+BN] 到 sh_B
__syncthreads();
// 每一個執行緒計算部分乘積並累加區域性暫存器
for (int ki = 0; ki < BK; ki++)
C_reg += sh_A[ty][ki] * sh_B[ki][tx];
__syncthreads();
}
// 將暫存器結果寫回 global memory
C[全域性行][全域性列] = C_reg;
}
其中 __syncthreads() 是 block 內 barrier,確保所有執行緒都完成了 shared memory 寫入後,再開始下一步計算。無此同步則資料競爭。
在利用 Tensor Core 的 Kernel 中,上述區域性 inner product 會被替換為一條 MMA 指令,一次性計算一個 16×16 或更大小塊的矩陣積並累加,配合 shared memory 的奇異排列避免 bank conflict,這類 Kernel 的彙編級調優接近硬體極限。
關鍵引數(定性,隨架構變化)
- Warp size:固定為 32 執行緒。
- 每個 SM 的最大 resident warps / threads:取決於暫存器檔案和 shared memory 容量,不同 GPU 差異極大。
- Shared memory 大小:架構決定,部分 GPU 可配置 shared memory 和 L1 快取之間的劃分比例。
- Tensor Core 支援的 MMA 尺寸:16×16×16、8×32×16 等,不同精度 (FP16, BF16, TF32, INT8) 形狀不同。
- 記憶體頻寬、峰值 TFLOPS:完全由具體 GPU 型號決定,不做死板陳述。
技術演進史
- 2006 年:NVIDIA 釋出 CUDA 1.0,首次將 GPU 抽象為通用平行計算裝置,引入 Kernel 程式設計模型和 nvcc 編譯器。早期的 Kernel 多用於科學計算,深度學習尚未興起。
- 2012 年前後:AlexNet 使用 CUDA 實現卷積,標誌著深度學習開始融入 CUDA 生態,但此時 Kernel 多由研究者手寫,效率參差。
- 2014 年:cuDNN 推出,提供高度最佳化的卷積、池化等深度學習基本 Kernel,讓架構可直接呼叫,大幅降低最佳化門檻。
- 2017 年 Volta 架構:引入第一代 Tensor Core,徹底改變深度學習運算元形態。Kernel 中不再只用 CUDA Core 做標量乘加,而是通過
wmmaAPI 或內聯 PTX 利用硬體矩陣引擎,通用矩陣乘法效能提升數倍。 - 2018–2020 年 Turing、Ampere:擴充套件 Tensor Core 精度(TF32、BF16、INT8、INT4),引入稀疏矩陣支援,Kernel 設計需要考慮選擇正確的 MMA 指令和輸入資料型別。
- 2022 年 Hopper 架構:新增 Tensor Memory Accelerator (TMA) 和基於描述符的非同步複製,允許 Kernel 通過描述符非同步在 shared memory 和 global memory 間搬運資料,從而將複雜的記憶體排程從計算邏輯中分離,極大簡化了 flash attention 之類 IO 密集型 Kernel 的實現。同時在軟體層面,Triton 語言興起,使得編寫高效 GPU Kernel 的門檻降低,其生成的 CUDA Kernel 在部分場景已接近手寫最佳化效果。
- 未來趨勢:多 Kernel 協同(CUDA Graphs)、動態並行、自動調優系統(如 TVM、Triton)將持續演化,CUDA Kernel 可能越來越多由編譯器合成,而非人手編寫。
技術路線對比(量化表)
| 特性 | CUDA Kernel | OpenCL Kernel | HIP Kernel (AMD) | Intel OneAPI (SYCL) | Apple Metal Shader |
|---|---|---|---|---|---|
| 平台 | NVIDIA GPU 專屬 | 跨平台 (GPU/CPU/FPGA) | AMD GPU 原生,可跨平台 | Intel GPU/CPU/FPGA | Apple GPU / Intel/AMD on Mac |
| 原生程式語言 | C++ 擴充套件,PTX 內聯 | C99 擴充套件 | C++ 擴充套件(與 CUDA 高度相似) | 標準 C++ 與 SYCL 佇列 | Metal Shading Language (C++14) |
| Tensor Core / 矩陣加速 | 一級支援,有專用內聯指令 | 無標準專用加速,需靠廠商擴充套件 | 有類 Tensor Core,但 API 不同 | Intel XMX 矩陣引擎支援 | Apple Neural Engine 通過 MPS 暴露,非直接 Shader 訪問 |
| 生態成熟度 | 極深,cuDNN/cuBLAS/TensorRT/PyTorch 原生支援 | 生態較弱,缺乏專用 DNN 庫 | ROCm/MIOpen 逐步追趕,相容層翻譯 CUDA | 新興,oneDNN 部分支援 | Core ML / MPSGraph 掩蓋底層,Shader 不直接用於主流訓練 |
| 典型深度學習架構支援 | PyTorch, TensorFlow, JAX 一級最佳化 | 幾乎無直接使用 | PyTorch 已支援 ROCm | 早期支援,PyTorch 有實驗性後端 | PyTorch MPS 後端為 Metal 封裝,不上手寫 Shader |
| 效能天花板 | 最高,廠商調優至極限 | 受限於平台和驅動成熟度 | 接近 CUDA,部分場景持平或略低 | 發展期,潛力待驗證 | 適合推論,大規模訓練尚不成熟 |
上下游
- 上游:CUDA C++ 原始碼、PTX 中間表示、
nvcc編譯器、針對不同 GPU 架構的 SASS 指令集;演算法層面的線性代數庫、迴圈分塊策略、資料版面配置設計。 - 中游:Kernel 本身(原始碼或二進位制 cubin);手寫與自動生成的分界線是 NVIDIA 庫、編譯器(如 Triton、XLA)及自動調優工具。
- 下游:
- 硬體執行單元:SM(包括 CUDA Core、Tensor Core、LD/ST 單元、SFU 等),互聯結構,L1/L2 快取,HBM 控制器。
- 執行時系統:CUDA Driver / Runtime API,管理上下文、stream、event 等,將 Kernel 下發到命令佇列。
- 上層軟體棧:深度學習架構(PyTorch、TensorFlow、JAX),推論最佳化器(TensorRT),強化學習、推薦系統、LLM 推論等服務。
- 最終應用:大語言模型訓練(MOE 路由 Kernel)、即時推論(FlashDecoding)、自動駕駛感知(點雲端卷積 Kernel)等。
從 AI 產業鏈視角,CUDA Kernel 是“軟體定義硬體效能”的終極體現:同樣的 Transformer 架構,不同 Kernel 實現在同一硬體上的吞吐可差數倍,這直接轉化為雲端運算成本與產品體驗的差異。
關鍵指標
評估一個 CUDA Kernel 好壞的核心維度(全定性,無固定目標值):
- 吞吐 (Throughput):單位時間完成的計算量或樣本數,受制於硬體計算能力和頻寬。
- 記憶體頻寬利用率:實際資料搬運速率與 GPU 峰值頻寬的百分比。許多 Kernel 是記憶體受限的,尤其 element-wise 操作和 softmax 等,最佳化集中在向量化訪問和資料合併傳輸。
- 佔用率 (Occupancy):SM 上活躍 warp 數量與理論最大值之比,過低會無法充分隱藏延遲;過高可能因暫存器/共享記憶體不足而失敗。
- 計算利用率:計算單元(CUDA Core / Tensor Core)實際工作週期佔比,避免流水線排空。
- warp divergence:同一 warp 內分支導致序列執行的程度,在 NLP 變長序列、稀疏模型中尤需警惕。
- Bank conflict 率:shared memory 訪問時的衝突比例,對延遲敏感 Kernel 很關鍵。
- 指令混合:MMA、FMA、LD/ST 等指令的比例是否與硬體流水線匹配。
- 啟動延遲:Kernel launch 本身的開支,若大量小 Kernel 序列,啟動延遲可能淹沒計算時間(可用 CUDA Graph 緩解)。
深度學習架構通常不直接暴露這些指標,而是通過 NVIDIA Nsight 等效能分析工具讓開發者深入最佳化。
供需與市場資料
CUDA Kernel 本身不構成獨立市場商品,它是 NVIDIA 生態的“軟實力”體現。其供需更多反映為 CUDA 生態的鎖定效應:
- 開發者供給:據 NVIDIA 財報電話會定性引用,CUDA 註冊開發者數百萬,但無精確數量驗證。[未充分揭露]
- 需求面:全球 AI 訓練和推論工作負載的絕大部分落在 NVIDIA GPU 上,幾乎所有大規模叢集都在執行經高度手寫或編譯最佳化的 CUDA Kernel。Hyperscaler 和 AI 初創公司為了極致的 TCO 會持續投入工程資源進行自研 Kernel 開發(如 Megatron-LM、vLLM 中的定製運算元),形成內部“Kernel 工程師”的強力需求。
- 競爭動態:隨著 PyTorch 2.0 編譯棧(TorchInductor)和 OpenAI Triton 的流行,很多高效能 Kernel 開始由 Python DSL 生成,降低了對直接編寫 CUDA 程式碼的依賴。但當前真正頂級效能的 Kernel(如 FlashAttention-3)依然離不開對 CUDA 彙編和硬體細節的深刻理解。這股 Kernel 自動化浪潮 在中期可能部分侵蝕 CUDA 手寫生態,但短期仍受限於編譯器成熟度和目標硬體支援範圍。
代表公司與資本對映
- NVIDIA:CUDA Kernel 生態的絕對建置者與控制者。不僅提供編譯器、庫,還通過 GTC 大會、文件、樣例、研究人員合作等營造了不可替代的開發者社群。其資料中心營收(財報口徑)絕大部分由 CUDA 生態支撐。
- AMD:通過 HIP(Heterogeneous-compute Interface for Portability)實現 CUDA 到 AMD GPU 的轉譯和原生開發;ROCm 棧下的 MIOpen 庫對標 cuDNN,但人力規模和成熟度差距明顯。資本層面,AMD 數次收購(如賽靈思)以增強整體系統能力,挑戰 NVIDIA 的“CUDA 護城河”是其主要敘事。
- Intel:借 oneAPI 和 SYCL 統一程式設計模型,同時為資料中心 GPU(Ponte Vecchio 系列)建立底層運算元庫;結合 Habana 加速器專有軟體棧,試圖從訓練側切入。
- 雲端廠商自研晶片:Google TPU 使用多級編譯器(XLA)生成針對 Systolic Array 的 Kernel,完全不相容 CUDA;AWS Trainium 的 Neuron SDK 編譯器自動生成配合其近存計算架構的核心;這些“非 CUDA 路線”在資本市場被視為對 NVIDIA 生態的部分替代威脅。
- 初創公司與工具:OpenAI 釋出 Triton 語言,能使開發者用 Python 編寫接近手工 CUDA Kernel 效能的程式碼,降低了 GPU 程式設計門檻;Modular 公司的 Mojo 語言和 MAX 引擎試圖取代 CUDA 的底層地位。這些專案一旦成功,可能重新定義 Kernel 的“誰來寫、怎麼寫”。
產業鏈觀察邏輯
- 生態護城河價值:CUDA Kernel 對 AI 訓練推論的深度滲透,形成數千萬行最佳化程式碼和數十萬熟練開發者積累,使替換成本極高。這是 NVIDIA 資料中心業務高毛利、高粘性的根基之一。
- 軟硬脫鉤風險:如果主流架構(如 PyTorch)完全偏向編譯器自動生成 Kernel,且後端能完美適配非 NVIDIA 硬體(如通過 OpenXLA/StableHLO),那麼手寫 CUDA Kernel 的優勢可能被稀釋,硬體競爭將更聚焦於晶片算力和能效本身。
- 細分機會:專注 Kernel 最佳化工具(如自動調優、效能剖析)的初創公司;具備極致 CUDA 調優能力的 AI 推論部署公司(如 Fireworks AI 基於 vLLM 的最佳化),它們能通過推論降本直接創造商業價值。
- 人才價值:高階 CUDA Kernel 工程師是稀缺資源,大中型 AI 團隊往往會因一兩位“Kernel 大神”的存在而獲得顯著成本或延遲優勢。研究時可追蹤人才密集的 AI 研究實驗室、雲端服務商自研晶片團隊及推論部署公司。
- 技術路徑關注點:Triton 社群的增長速度、AMD ROCm 在 PyTorch 中的覆蓋率、Intel oneAPI 能否吸引主流架構使用者,這些是衡量 CUDA Kernel 生態長期壁壘鬆動的先行指標。
常見誤讀糾偏
誤讀 1:“CUDA Kernel 就是一串並行迴圈,用 GPU 執行緒自動搞定。” 糾偏:簡單地把一維迴圈對映到執行緒,80% 時間可能浪費在視訊記憶體訪問上。高效能 Kernel 必須深刻理解記憶體層次和資料複用:如果不使用 shared memory 暫存塊、不搞暫存器分塊、不注意全域性記憶體合併訪存,效能可能只有峰值頻寬的十分之一甚至更低。深度學習架構能自動生成部分運算元,但極致最佳化仍需手工設計資料流。
誤讀 2:“網路結構定了,跑的 Kernel 速度都一樣,效能瓶頸只在硬體。” 糾偏:同一 Attention 架構,naive 實現、記憶體最佳化實現(FlashAttention)和針對特定序列長度定製的 Kernel,吞吐量可以相差數倍。對於 LLM 推論,prefill 階段和 decode 階段的瓶頸不同(compute bound 與 memory bound),分別需要不同拆分策略的 Kernel。所以軟體層面的 Kernel 實現直接決定了硬體投入的產出比,這也是為何頭部 AI 雲端服務競相招聘 GPU 系統工程師。
誤讀 3:“Tensor Core 可以自動加速任何矩陣乘法。” 糾偏:Tensor Core 對矩陣形狀、記憶體對齊和資料型別有嚴格要求。如果輸入不是對應的精度(如 FP32 做標準 MMA),或者維度不是硬體要求 tile 大小的倍數,就必須在 Kernel 中進行補邊、變換資料型別,否則無法使用。這導致很多看似簡單的操作(如 GEMV)並不能直接躺上 Tensor Core,需要精巧的彙編級重排。
學習路徑
- 入門:NVIDIA 官方《CUDA C++ Programming Guide》前 5 章,理解執行緒層次、記憶體模型、非同步併發;動手完成 “vectorAdd” 到 “matrix multiply” 的幾個練習 Kernel。
- 進階:閱讀《Programming Massively Parallel Processors》(Kirk & Hwu)中關於 tiling、卷積、歸併最佳化的章節;學習 Nsight Systems / Compute 進行效能剖析;嘗試用 cuBLAS 配合手寫 Kernel 實現一個簡單計算圖。
- 深度學習專用:學習 cuDNN 文件,理解卷積演算法選擇;研讀 FlashAttention 論文及其開源實現中的 CUDA Kernel 程式碼(GitHub);學習 Triton 語言,其教程易上手且產出可直接轉化為 CUDA 原生思維。
- 硬核最佳化:掌握 PTX 和 SASS 基本閱讀能力,使用 NVIDIA 的官方工具 Micro‑benchmark 理解具體 SM 的微架構引數;閱讀 CUTLASS 原始碼,它是 NVIDIA 官方模板庫,展示了最高級別的 GEMM 和卷積 Kernel 設計模式。
- 系統性理解:結合 GPU 架構白皮書(Volta、Ampere、Hopper),對照 Kernel 如何利用 TMA、非同步複製、Tensor Core 組合,建立 end-to-end 效能分析閉環。
一句話總結
CUDA Kernel 是釋放 NVIDIA GPU 全部並行算力的最小能量單元,它在深度學習世界中的地位就相當於“機械指令之於 CPU”,卻是目前看不見卻最難替代的軟硬生態耦合點。
延伸閱讀與來源
- 由於本次檢索未能獲取即時網頁資料,以下為權威固定來源:
- NVIDIA CUDA C++ Programming Guide(最新版隨工具包釋出),docs.nvidia.com/cuda/
- NVIDIA GPU Architecture White Papers(Volta, Turing, Ampere, Hopper),nvidia.com
- FlashAttention 論文與 GitHub 倉庫:Dao-AILab/flash-attention
- CUTLASS(CUDA Templates for Linear Algebra Subroutines):github.com/NVIDIA/cutlass
- OpenAI Triton 文件:triton-lang.org
- AMD ROCm Documentation,rocm.docs.amd.com
- Intel oneAPI Programming Guide,intel.com/content/www/us/en/developer/tools/oneapi
- 深度學習架構整合相關:PyTorch 官方 cuDNN 後端文件,TensorRT Developer Guide。
注:凡涉及精確硬體數量(如 SM 數量、快取大小、具體 TFLOPS 值)的市場討論,請以對應產品廠商最新公開資料為準,本文僅做定性技術原理解析。