GPU 利用率

3 秒看懂

GPU 利用率（GPU Utilization）是衡量 GPU 計算資源在給定時間內被實際投入工作的比例。它直接決定每單位時間的有效算力輸出，是深度學習訓練與推論成本最佳化的核心槓桿。但“利用率高” ≠ “算力被充分利用”——表層百分比常常掩蓋 SM 流水線停頓、視訊記憶體頻寬瓶頸或無效 Kernel 啟動等問題，真正有效的是將利用率拆解至 Tensor Core 活躍度與 MFU（模型 FLOPS 利用率）。

3 分鐘產業解釋

在 AI 算力叢集中，GPU 利用率的每一絲波動都牽連著全生命週期成本。常見的 nvidia-smi 給出的“GPU-Util”是 GPU 核心時鐘是否活躍的粗略時間佔比，但它無法區分計算單元是在高效執行大規模矩陣乘還是在空轉等待資料。產業界真正看重的是細粒度利用率：

• SM（Streaming Multiprocessor）佔用率：反映每個 SM 中活躍 warp 的飽滿程度。
• Tensor Core 利用率：判斷混合精度訓練中的張量核心是否被有效觸發。
• MFU（Model FLOPS Utilization）：模型訓練每個迭代實際達到的浮點運算元與 GPU 理論峰值的比值，是演算法-架構-硬體協同的“終極體檢報告”。

分散式訓練場景下，通訊等待、資料載入流水線斷流、梯度累積的運算元間隙，都會讓表層利用率虛高（核心反覆啟停）或驟降。因此，雲端廠商、大型模型團隊和 AI Infra 創業公司正把利用率最佳化工具視作解鎖昂貴 GPU 叢集潛在生產力的鑰匙。

15 分鐘專家深入

從底層的 stream multiprocessor 排程到高層的訓練迴圈，GPU 利用率是一個多層次概念，專業分析需要區分五類事件：

1. 計算空泡：來自通訊未完成（AllReduce 依賴）、資料搬運未就緒，或運算元圖排程間隙。
2. 低效佔用：SM 有活躍執行緒但大量 warp 因視訊記憶體延遲（資料未到達）而停滯，表現為高 occupancy 但低吞吐。
3. 非計算佔用：短促 Kernel 啟動開銷、頻繁的 cudaLaunchKernel 指令導致 GPU 排程器忙於切換上下文。
4. 有效計算深潛：Tensor Core 真正執行矩陣融合乘加（FMA），且數值精度滿足要求。
5. 頻寬限度：視訊記憶體頻寬成為瓶頸，計算單元等效利用率下降。

現場診斷通常採用 Nsight Systems（時間線分析） 和 Nsight Compute（Kernel 效能剖析） 組合：

• Nsight Systems 揭示整體時間線，標出計算、通訊、記憶體複製的空隙，可直觀看到 GPU-Util 上下跳動的原因。
• Nsight Compute 深挖單個 Kernel 的 SM 佔用率、記憶體吞吐、計算吞吐等指標，計算出計算利用率（Compute Throughput Utilization）與記憶體利用率。

大型訓練架構（如 Megatron-LM）的並行策略對利用率有幾何級放大效果：

• 張量並行內頻繁的 AllReduce/ReduceScatter 會打斷計算流，增加空泡。
• 流水線並行微觀 Batch 氣泡會拉低平均 SM 活躍度。
• 專家混合（MoE）的 All-to-All 通訊在路由不均衡時造成 GPU 閒置。

高階最佳化手段包括：運算元融合（減少 Kernel 啟動）、非同步流水線（計算與通訊 Overlap）、動態圖切分、梯度累積（增大有效 Batch Size 以提升 Kernel 平均長度）以及選擇性重計算（用計算換視訊記憶體，調整核心排程）。當前前沿在探索模型編譯棧自動調優（如 Triton、TVM）來生成高佔用率的核心，使 MFU 趨於極致。

技術原理（最深）

GPU 利用率的多層計時模型

              ── 全取樣週期 T ──
├────────┼══════════┼──────│──────────┤
 idle     active      idle    active
         (gpu-util)          (gpu-util)

nvidia-smi 的利用率 = Σ active 時間 / T × 100%（粒度約 1/6 秒取樣）。此指標未計入：

• SM 在 active 期間內部 stall cycle 的比例。
• Tensor Core 是否切實在做矩陣融合乘加，而非被降級為通用 CUDA Core。

SM 級利用率深化

每個 SM 有若干 warp 排程器，在任意時鐘週期，SM 可發射指令的 warp 數量上限為理論 warp 並行度。Occupancy（佔用率） = 活躍 warp 數 / 最大可駐留 warp 數。高佔用率能更好地隱藏延遲，但若頻寬不夠，喂不飽計算單元，真實計算利用率依然低下。

實際計算利用率通常定義為 實際FLOPS / 理論FLOPS。
可達到的利用率上限受記憶體頻寬限制：當記憶體頻寬成為瓶頸時，計算單元等待資料，導致實際利用率下降。

MFU 的精確定義

MFU 是模型浮點運算效率的“算力利用率”：

• 針對一次訓練步，計算總 FLOP（前向+反向，包含梯度計算等）與花費時間。
• 與 GPU 標稱的峰值 FP16/BF16 Tensor Core FLOPS 對比。
• 典型 MFU 受諸多影響：Kernel 實現效率、編譯器最佳化、資料搬運重疊度、Batch Size 大小導致的尾端浪費。

用虛擬碼表述計算過程：

理論峰值_ops_per_sec = GPU_tensor_core_peak_FLOPS
實際_ops_per_sec = 總FLOP/(步耗時)
MFU = 實際_ops_per_sec / 理論峰值_ops_per_sec

注意：GPU 理論峰值本身也依賴頻率、熱設計，實際可維持頻率低於 Boost，因此觀測 MFU 需要依據即時頻率校正。

通訊與儲存的背離效應

在類似 Megatron 的張量並行中，前向計算的某層輸出需通過 AllReduce 同步，計算 Kernel 會等待通訊完成。儘管此等待段 GPU 處於 active（輪詢或忙於別的 Kernel），但整體計算吞吐停滯，表現為高利用率低 MFU。因此工程師需要將此類 wait 事件從 GPU 核心管道剝離。

技術演進史

• 早期 CUDA 時代（Fermi/Kepler）：計算核心與圖形核心職能混雜，利用率監控粗糙，僅有簡單的 GPU 繁忙百分比。
• Pascal 與 Volta 架構：引入統一計算核心架構，SM 內細粒度排程的指標漸顯；Volta 首次搭載 Tensor Core，但利用率監控最初未做專門獨立。
• 資料中心時代（Turing/Ampere 及後續）：NVIDIA 資料中心 GPU 管理器（DCGM）開始提供 SM 佔用率、Tensor Core 利用率、視訊記憶體頻寬利用率等欄位，讓多租戶環境下的準確計量成為可能。
• 大型模型浪潮與 Infra 爆發：隨著千卡、萬卡叢集訓練，通訊延遲導致的利用率下降成為瓶頸，催生 Nsight Systems/Compute 成為標準除錯工具，Run:ai 等公司推出基於 Kubernetes 的 GPU 利用率精細化管理與配額系統，MFU 成為衡量全棧效率的黃金標準。

技術路線對比（量化表）

利用率指標	粒度	資料來源	典型應用場景	主要侷限
nvidia-smi GPU-Util	整顆 GPU，時間佔比	NVML 驅動取樣	快速健康檢查、叢集粗粒度監控	無法區分有效計算與 stall、空轉；Tensor Core 無感
SM 佔用率 (Occupancy)	每個 SM 的 warp 佔用	效能分析工具（Nsight, DCGM）	Kernel 調優、判斷是否延遲隱藏充分	不直接反映單位時間完成的浮點運算元
Tensor Core 利用率	Tensor Core 活躍週期比例	DCGM 專業欄位	混合精度訓練最佳化，判斷是否充分利用 FP16/BF16 算力	不能獨立代表視訊記憶體頻寬瓶頸
視訊記憶體頻寬利用率	DRAM 讀寫吞吐佔峰值比例	Nsight Compute, DCGM	識別記憶體密集型 Kernel，最佳化資料編排	與計算利用率互相制約，需聯合決策
MFU（模型 FLOPS 利用率）	模型所有迭代綜合	手動計算（FLOP計數/耗時/理論峰值）	大訓練任務的效率評價，叢集招標驗收	計算複雜、忽略 I/O 和編譯器開銷影響，理論峰值取值標準不一

注：表中各項數值範圍均為 0%~100%，具體閾值因硬體與工作負載相差懸殊，未獲得公開統一基準資料，此處不做數值斷言。

上下游

上游硬體與底層介面

• GPU 硬體：主要由 NVIDIA 驅動，提供 NVML（NVIDIA Management Library）與 DCGM 的監控欄位。硬體訊號經驅動封裝交出統計計數器。
• 互聯與儲存：PCIe/NVLink 頻寬、HBM 視訊記憶體頻寬與容量（具體代際、位寬在此次檢索中未獲取可靠資料，僅定性描述），其瓶頸會導致計算單元等效利用率下降。NVSwitch 等拓撲連線方式影響通訊等待時長。

中游平台與工具

• 叢集管理層：Kubernetes GPU 排程器（NVIDIA GPU Operator）、Run:ai、Volcano，將利用率指標轉換為排程與配額決策依據。
• 監控與視覺化：Prometheus + DCGM Exporter 構成主流監控堆疊，Grafana 面板渲染歷史；Datadog、Sysdig 等 SaaS 平台提供跨雲端 GPU 利用率監控。
• 最佳化與剖析工具：NVIDIA Nsight Systems、Nsight Compute、PyTorch Profiler、TensorBoard 可深入定位利用率損耗點。

下游應用與消費方

• AI 訓練/推論服務提供商：雲端廠商（AWS、GCP、Azure、國內主流雲端）按 GPU 小時計費，內部通過利用率評價 GPU 投入產出。
• 大型模型團隊：關注 MFU 作為 KPI，直接影響研發迭代速度與電力成本。
• AI 架構與編譯棧：PyTorch、JAX、Triton、TVM 通過核心自動調優提升 tensor 操作利用率，降低開發者手動最佳化門檻。

關鍵指標

• 週期級利用率：SM 時鐘週期內啟用佔比（效能分析器核心指標）
• 佔用率（Occupancy）：活躍 warp 與理論最大 warp 的比值（通常 25%~100% 間，視 Kernel 而定）。【注：具體最優範圍因架構而異，本報告未獲取精確典型值】
• 計算吞吐利用率：SM 子單元（FP32/FP64/Tensor Core）被指令實際驅動的吞吐與理論峰值的百分比（作為 MFU 的底層體現）
• 視訊記憶體吞吐與利用率：讀取/寫入利用率分開考量，以定位記憶體牆
• NVLink/PCIe 頻寬利用率：在分散式訓練中，若此值長時間高位且伴隨 SM 空閒，說明通訊受限。
• MFU：最高層指標，直接關聯 Token/秒、成本。業界頂會訓練任務 MFU 通常在 30%-60% 之間，取決於規模與最佳化程度【為通用經驗，未連結具體論文，估略範圍僅用於說明量級】。

供需與市場資料

※ 因聯網檢索遇阻，本節無法援引第三方定量報告，僅作定性趨勢描述。

• 需求推動：大規模 AI 模型訓練單次消耗成千上萬 GPU 小時，1% 利用率提升可能省去數百萬美元成本。企業對 GPU 利用率的精細化管理需求從“是否達到 90%”轉向“MFU 能否從 40% 提升到 50%”。
• 供應與工具市場：GPU 供應持續短缺【根據行業公開報道】，最大化既有算力利用率成為企業剛需。GPU 資源管理平台（如 Run:ai 被 NVIDIA 收購）、Kubernetes 排程增強、自動化混合精度訓練工具等市場活躍度顯著上升。第三方估算稱，GPU 虛擬化與池化軟體市場將隨雲端端 AI 規模快速增長，但具體數字暫無可靠來源，此處不列數值。

代表公司與資本對映

• NVIDIA：核心硬體與基準監控工具 DCGM 定義利用率體系；2024 年收購 Run:ai（未揭露具體金額）以強化 GPU 資源編排與利用率最佳化。
• 雲端服務商：AWS、Microsoft Azure、Google Cloud、阿里雲端、華為雲端等均推出 GPU 例項及監控面板，利用利用率資料指導配售策略。
• 專業 Infra 工具企業：除 Run:ai（已整合）外，社群或商業工具如 Determined AI（被 HPE 收購）、Anyscale、Kubeflow、GC AI Platform 增強排程與效率分析。DataDog、Grafana Labs 將 GPU 利用率納入可觀測性產品。
• 編譯與架構層：OpenAI Triton、Apache TVM 編譯器團隊、PyTorch 團隊通過核心最佳化抬升 MFU；NVIDIA 的 cuBLAS、cuDNN、TensorRT 持續提升執行效率。
• 資本對映：GPU 資源利用率相關融資多發生在排程軟體、MLOps 和可觀測性賽道。因缺乏本次定點檢索的市場報告，此處不列舉融資數字。

投資邏輯

1. 利用率即成本效率：GPU 成本高昂且供不應求，能幫助企業從相同 GPU 數量中“壓榨出更多算力”的工具、平台具有明確 ROI。投資關注能夠提升 MFU 30% 以上的方案。
2. 多租戶與池化：GPU 資源池化（如 vGPU、MIG 分割）與細粒度排程，可以提升整體按租戶聚合利用率，相關技術提供商具備增長潛質。
3. 自動調優克服牆：大型模型訓練受記憶體牆和通訊牆雙重壓制，能夠自動融合運算元、最佳化視訊記憶體版面配置的編譯器/AI Infra 成為投資熱點。
4. 軟體與服務的粘性：一旦企業採用特定利用率監控-最佳化-排程平台，資料積累使得切換成本高，形成護城河。
5. 警惕“利用率虛假繁榮”：產品若僅展示 nvidia-smi 層面的利用率而不解決真實驗速問題，則價值有限。真正的壁壘在剖析與自動最佳化 MFU 的能力。

常見誤讀糾偏

誤讀 1：“nvidia-smi 顯示的 GPU-Util 達到 100% 代表 GPU 跑滿了”

糾偏：該百分比僅統計過去取樣週期內 GPU 有 kernel 在執行的時長佔比，完全不體現 SM 內執行單元的飽和程度。可能的情形是：一個效率極低、大量 warps 因視訊記憶體等待而停頓的 kernel 持續佔住排程器，nvidia-smi 依然顯示 100%，而實際計算吞吐可能不到理論峰值的 10%。正確做法是結合 SM 佔用率與計算吞吐利用率。

誤讀 2：“Tensor Core 利用率就是整體計算利用率”

糾偏：Tensor Core 利用率只表徵混合精度矩陣運算是否在張量核心上執行，但整顆 GPU 還可能大量時間用在 scalar 操作、資料搬運或非矩陣乘的通用數學上。若模型存在大量形狀變化或小運算元，即使 Tensor Core 利用率高，總體 MFU 仍可能被其他部分拖低。

誤讀 3：“MFU 等於標稱峰值百分比的直接換算，越高越好”

糾偏：MFU 受理論峰值的定義（最大 Boost 頻率 vs. 實際穩定頻率）、batch size 導致的尾量浪費、不可避免的最佳化器等輔助計算影響，理論上的 100% 基本不可能達到。更應關注 MRU（Model RAM Utilization）等記憶體指標和端到端吞吐。某些場景下刻意降低 MFU 以換取更優的記憶體佔用或新特徵（如使用重計算）是合理權衡。

學習路徑

1. 基礎入門：瞭解 CUDA 程式設計模型，執行 nvidia-smi dmon，使用 DCGM 暴露指標，繪製訓練時的利用率曲線。
2. 效能剖析：安裝 Nsight Systems，採集一次訓練迭代的 timeline，找出 GPU 空閒間隙，對應程式碼中的 DataLoader、optimizer.step、通訊部分。
3. 深入 Kernel：用 Nsight Compute 抓取一個核心的 GEMM/norm kernel，解讀 Compute Throughput 與 Memory Throughput 利用率，理解 Roofline Model。
4. 大規模訓練實踐：研究 Megatron-LM、DeepSpeed 等架構的並行策略文件，計算所採用的張量並行、流水線並行下的理論通訊時間，與實測 GPU 利用率間隙對比，嘗試最佳化 bubble。
5. 文獻與工具鏈：閱讀 NVIDIA 白皮書《GPUMetrics》系列，追蹤 MLPerf 訓練排行榜的 MFU 資料，試用 Triton 語言編寫融合 kernel 體會佔用率調優。

一句話總結

GPU 利用率是通往 AI 算力經濟韌性的探針，但唯有扒開表層百分比，深入到 SM 完成實際矩陣乘的飽滿度、視訊記憶體頻寬壓力與全棧流水線氣泡，才能將昂貴的“矽基計算力”充分轉化為模型智慧。

延伸閱讀與來源

宣告：本次生成聯網檢索服務遭遇故障（HTTP 403），未能獲取即時資料與具體技術規格。以上內容基於通用 GPU 架構知識（涵蓋 NVIDIA CUDA 程式設計指南、DCGM 指標定義、Nsight 文件以及公共領域討論），對製程、HBM 代際/位寬、封裝方案等具體硬體引數未做斷言，均以定性方式描述。所有數值型論斷未標註來源的，均屬示意範圍或不作斷言。

推薦查閱資源（未直接檢索，但為行業標準渠道）：

• NVIDIA Developer Documentation: DCGM User Guide, NVML API Reference
• Nsight Systems & Nsight Compute User Guides
• PyTorch Profiler Documentation
• MLPerf Training Benchmark Results（觀察各架構的 MFU 指標）
• Run:ai 白皮書（GPU 資源管理與利用率）
• “Efficient Large-Scale Language Model Training on GPU Clusters” (Megatron-LM 論文團隊)

建議讀者根據實際需求訪問上述官方文件與社群，獲取最新指標定義與規格資料。