視訊記憶體利用率（Memory Utilization）

3 秒看懂

視訊記憶體利用率 = 實際佔用視訊記憶體 / 物理可用視訊記憶體總量。 它衡量的是：花大價錢買來的昂貴視訊記憶體（如 HBM），到底用了多少。利用率太低 → 硬體空轉浪費資本；利用率先達 100% → 訓練/推論被”卡脖子”，模型上不去。

3 分鐘產業解釋

為什麼視訊記憶體利用率是 AI 產業的核心指標？

一句話：視訊記憶體是 AI 晶片最貴的”場地費”。

在 AI 加速器（GPU / TPU / NPU）的 BOM（物料清單）中，HBM（高頻寬視訊記憶體）通常佔據相當比例的晶片成本，據行業估算可佔高階 AI 晶片總成本的三成至五成[行業估算，未公開精確比例]。這意味著：

產業視角	影響
晶片廠商	HBM 容量/頻寬是產品競爭力的核心賣點
雲端廠商/資料中心	視訊記憶體利用率直接決定 GPU 例項的 ROI
模型開發者	視訊記憶體決定能訓多大的模型、用多大的 batch
HBM 供應商（SK 海力士/三星/美光）	供需關係決定議價權與產能規劃

當前行業痛點：

大型模型訓練的視訊記憶體需求增速 > 視訊記憶體容量增速
單卡視訊記憶體裝不下大型模型 → 被迫使用更多卡做並行 → 成本指數級上升
視訊記憶體利用率低（如 50%-70%）的叢集，相當於每秒在燒錢

15 分鐘專家深入

視訊記憶體利用率的多層含義

“視訊記憶體利用率”並非單一指標，它在不同語境下有不同含義：

1. 作業系統/驅動層視角

nvidia-smi 報告的 Memory Usage（已用視訊記憶體/總視訊記憶體）
包含：模型引數、梯度、最佳化器狀態、啟用值、視訊記憶體碎片、CUDA Context 開銷
這是靜態佔用，不反映瞬時頻寬利用

2. 硬體監控層視角

HBM Controller 的實際讀寫頻寬 / 峰值頻寬
反映的是頻寬利用率（Bandwidth Utilization）
與”視訊記憶體容量利用率”是正交的兩個維度

3. 排程/叢集管理層視角

一個訓練任務分配到的視訊記憶體 / 整個節點或叢集的總視訊記憶體
反映資源分配效率

4. 有效利用率 vs 名義利用率

名義：分配了但沒有被有效計算使用（如 padding、冗餘複製）
有效：真正服務於 forward/backward 計算的視訊記憶體佔比

關鍵公式

容量利用率（Capacity Utilization）:
    U_cap = Allocated_Memory / Total_Physical_Memory × 100%

頻寬利用率（Bandwidth Utilization）:
    U_bw = Actual_Bandwidth / Peak_Theoretical_Bandwidth × 100%

有效計算視訊記憶體佔比:
    U_eff = (Param + Grad + OptState + Activation) / Allocated_Memory × 100%

技術原理

視訊記憶體中到底裝了什麼？

以典型的混合精度（bf16/fp16）LLM 訓練為例，單卡視訊記憶體佔用構成：

┌─────────────────────────────────────────────────────┐
│                  總視訊記憶體佔用 (Total)                   │
├─────────────────────────────────────────────────────┤
│                                                       │
│  ┌─────────────────────────────────────────────┐     │
│  │  模型引數 (Parameters)                        │     │
│  │  - 訓練時通常存 2 份: master weight (fp32)    │     │
│  │    + 計算副本 (bf16/fp16)                     │     │
│  └─────────────────────────────────────────────┘     │
│                                                       │
│  ┌─────────────────────────────────────────────┐     │
│  │  梯度 (Gradients)                             │     │
│  │  - 與引數同形狀、同精度                        │     │
│  └─────────────────────────────────────────────┘     │
│                                                       │
│  ┌─────────────────────────────────────────────┐     │
│  │  最佳化器狀態 (Optimizer States)                 │     │
│  │  - Adam: 一階動量(m) + 二階動量(v), fp32      │     │
│  │  - 約為引數量的 2×(fp32) = 8 bytes/param      │     │
│  └─────────────────────────────────────────────┘     │
│                                                       │
│  ┌─────────────────────────────────────────────┐     │
│  │  啟用值 (Activations)                         │     │
│  │  - forward 的中間結果,用於 backward 計算       │     │
│  │  - 與 batch_size × seq_len 正相關              │     │
│  │  - 可通過 checkpointing 重計算換空間           │     │
│  └─────────────────────────────────────────────┘     │
│                                                       │
│  ┌─────────────────────────────────────────────┐     │
│  │  通訊緩衝 / 臨時工作區 / 碎片                   │     │
│  │  - AllReduce/ReduceScatter 的臨時 buffer       │     │
│  │  - 視訊記憶體碎片（fragmentation）導致不可用空間      │     │
│  └─────────────────────────────────────────────┘     │
│                                                       │
└─────────────────────────────────────────────────────┘

量化估算（以 Adam 最佳化器 + bf16 混合精度為例）

每引數的視訊記憶體開銷約為：

組成	精度	每引數位元組數
Master Weight	fp32	4 bytes
計算副本	bf16	2 bytes
梯度	bf16	2 bytes
一階動量 (m)	fp32	4 bytes
二階動量 (v)	fp32	4 bytes
合計	-	~16 bytes/param

粗略經驗：1B 引數 ≈ 16GB 視訊記憶體（僅引數+最佳化器，不含啟用）

注意：上述為經典 AdamW 的典型估算；實際因最佳化器實現、是否使用混合精度策略（如 DeepSpeed ZeRO）而有顯著差異。

利用率先到 100% 時發生什麼？

視訊記憶體利用率先達 100%
        │
        ▼
┌──────────────────┐
│ CUDA OOM Error   │  ← 最常見表現
│ "out of memory"  │
└──────────────────┘
        │
        ▼
┌──────────────────────────────────────┐
│ 系統級應對（部分可觀測到）              │
│ - 頻繁的視訊記憶體分配/釋放 → 頻寬抖動        │
│ - 視訊記憶體碎片 → 分配失敗即使總量夠          │
│ - Host-Device 資料交換增加 → 訓練變慢   │
└──────────────────────────────────────┘

提升有效視訊記憶體利用率的技術手段

技術	機制	效果
梯度檢查點（Activation Checkpointing）	不儲存中間啟用值，backward 時重計算	以約 33% 計算換大幅視訊記憶體節省（原文：約 [待查證]）
ZeRO Stage 1/2/3	分片最佳化器狀態/梯度/引數到多卡	視訊記憶體佔用從 O(N) 降至 O(N/k)，k 為 GPU 數
混合精度訓練	計算用 bf16/fp16，累加用 fp32	引數+梯度視訊記憶體減半
梯度累積	多個 micro-batch 累積後再更新	減少最佳化器狀態更新頻率，間接影響視訊記憶體排程
Flash Attention	避免顯式儲存完整 Attention 矩陣	啟用值視訊記憶體從 O(N²) 降至 O(N)
CPU Offloading	將不活躍引數/狀態解除安裝到 CPU 記憶體	視訊記憶體釋放但增加 PCIe/匯流排延遲
量化推論	INT8/INT4 權重	推論時引數視訊記憶體減 2-4 倍
PagedAttention (vLLM)	類似虛擬記憶體的分頁管理	減少 KV Cache 碎片

技術演進史

視訊記憶體容量與利用效率的代際演進

時間軸（簡化）
──────────────────────────────────────────────────────────────►

2016          2018          2020          2022          2024
  │             │             │             │             │
  ▼             ▼             ▼             ▼             ▼
P100          V100          A100          H100          B200
~16GB         ~32GB         ~80GB         ~80GB         ~192GB
HBM2          HBM2          HBM2e         HBM3          HBM3e
  │             │             │             │             │
  │             │             │             │             │
  ▼             ▼             ▼             ▼             ▼

視訊記憶體管理技術演進：
──────────────────────────────────────────────────────────────►
2016-2018     2019-2020     2021-2022     2023-2024
  │             │             │             │
  ▼             ▼             ▼             ▼
手動管理      混合精度      ZeRO/         Flash Attention
CUDA 碎片     Apex 開始     FSDP 出現     PagedAttention
  → 使用者    → 自動混合    → 分散式視訊記憶體   → 運算元級視訊記憶體
  自己負責     精度普及      最佳化成為標配    最佳化成熱點

關鍵轉折點

混合精度訓練普及（~2019）：NVIDIA Apex，後 PyTorch 原生支援 → 視訊記憶體效率顯著提升
ZeRO 論文釋出（2019）：DeepSpeed 團隊 → 分散式視訊記憶體最佳化的理論基礎
Flash Attention v1（2022）：Tri Dao 提出 → 注意力機制的視訊記憶體從 O(N²) → O(N) 的突破
HBM3/3e 量產（2023-2024）：單顆堆疊層數增加，容量和頻寬同步提升

技術路線對比

不同並行策略下的視訊記憶體效率對比

策略	視訊記憶體分片方式	通訊開銷	視訊記憶體效率	適用場景
資料並行（DP）	不分片，每卡全量複製	AllReduce 梯度	低（每卡冗餘）	小模型、資料量大
模型並行（張量並行，TP）	按層內張量維度切分	每層 AllReduce / ReduceScatter	中等	單節點多卡（NVLink）
流水線並行（PP）	按層切分到不同裝置	點對點通訊（pipeline bubble）	中等	跨節點、多層模型
ZeRO Stage 1	分片最佳化器狀態	AllReduce 梯度	較高	視訊記憶體最佳化入門
ZeRO Stage 2	分片最佳化器+梯度	ReduceScatter + AllGather	高	平衡方案
ZeRO Stage 3	分片一切（引數+梯度+最佳化器）	AllGather 前向 + AllGather/ReduceScatter 反向	最高（理論）	超大型模型
FSDP (PyTorch)	類 ZeRO Stage 3	類似 ZeRO-3	高	PyTorch 生態

視訊記憶體最佳化技術對比

技術	節省的是什麼	計算代價	實現複雜度
混合精度	引數/梯度視訊記憶體	幾乎無（可能更快）	低（架構原生支援）
梯度檢查點	啟用值視訊記憶體	~33% 額外計算（業界常見估算，實際因模型結構而異）	低-中
CPU Offloading	整體視訊記憶體佔用	PCIe 延遲增加	中
Flash Attention	Attention 矩陣視訊記憶體	無（可能更快，減少 HBM 訪問）	低（庫支援）
量化（INT8/4）	權重視訊記憶體	精度損失風險	中-高（需校準/量化感知訓練）

上下游

產業鏈位置

上游                          本概念核心                        下游
─────                        ─────────                       ─────

┌─────────────┐            ┌──────────────────┐           ┌──────────────────┐
│ HBM 供應商   │            │                  │           │ 模型訓練/推論     │
│ SK海力士     │───────────►│  視訊記憶體利用率       │──────────►│ - LLM 訓練       │
│ 三星        │  HBM 晶片   │  Memory          │  約束能力  │ - 推論服務       │
│ 美光        │            │  Utilization     │           │                  │
└─────────────┘            │                  │           └──────────────────┘
                            │  核心意義：       │
┌─────────────┐            │  決定硬體資源的   │           ┌──────────────────┐
│ 封裝廠商     │            │  實際產出效率     │           │ 雲端廠商 / AI公司   │
│ 台積電 CoWoS │───────────►│                  │──────────►│ TCO 最佳化         │
│ 日月光 ASE   │  先進封裝   │                  │  運營指標  │ 例項定價         │
└─────────────┘            └──────────────────┘           └──────────────────┘

┌─────────────┐                 ▲                              │
│ GPU 架構設計 │                 │                              ▼
│ NVIDIA       │─────────────────┘           ┌──────────────────┐
│ AMD          │  視訊記憶體頻寬/容量               │ 架構 & 編譯器     │
│ 華為昇騰     │  架構決定上限               │ PyTorch/XLA      │
└─────────────┘                              │ DeepSpeed/Megatron│
                                             └──────────────────┘

關鍵上游約束

HBM 產能：當前 AI 晶片放量的主要瓶頸之一，HBM 產能被少數廠商壟斷
先進封裝：CoWoS（台積電）等 2.5D/3D 封裝產能緊俏
視訊記憶體頻寬 vs 容量：有時不是”裝不下”而是”讀不完”——頻寬瓶頸同樣限制有效利用率

關鍵指標

視訊記憶體利用率相關指標體系

指標	定義	觀測工具/來源	目標範圍（經驗性）
容量利用率	已分配視訊記憶體 / 物理視訊記憶體	`nvidia-smi`、DCGM	80%-95%（過高易 OOM）
頻寬利用率	實際頻寬 / 峰值頻寬	硬體 Profiler（Nsight, rocprof）	越高越好，AI 訓練常見 60%-90%
視訊記憶體效率	有效資料 / 總分配	需 Profile 工具估算	需排除碎片和冗餘
Model FLOPS Utilization (MFU)	實際 FLOPS / 硬體峰值 FLOPS	估算（參考 PaLM 論文方法論）	30%-60% 為業界較好水平
啟用值佔比	啟用視訊記憶體 / 總視訊記憶體	架構 Profiler	依賴 batch_size 和模型深度

注：MFU 雖非直接的”視訊記憶體利用率”，但視訊記憶體頻寬往往是 MFU 的瓶頸，兩者高度相關。

供需與市場資料

視訊記憶體供需格局

供給側：

HBM 市場高度集中：SK 海力士、三星、美光三家佔據主要份額（具體市佔率各機構報告口徑不一，據行業估算 SK 海力士份額領先）
HBM 代際：HBM2 → HBM2e → HBM3 → HBM3e → HBM4（規劃中）
單顆堆疊層數和單層容量持續提升（具體數字以廠商公告為準）

需求側：

每代 AI 晶片視訊記憶體容量持續上升（具體規格以廠商釋出為準）
大型模型引數量級增長（數十億 → 數千億 → 萬億級 MoE）驅動視訊記憶體需求
推論側 KV Cache 視訊記憶體佔用隨併發使用者數線性增長

供需張力：

HBM 產能擴張週期長（擴產 12-18 個月）
AI 晶片對 HBM 的需求增速快於產能增速
據多家行業報告估算，HBM 供需緊張態勢在 2024-2025 年持續

視訊記憶體成本佔比

AI 晶片中 HBM 的成本佔比，因晶片代際和具體型號而異，據行業估算，高階 AI 訓練晶片中 HBM 成本可佔到三成至五成[行業估算，廠商未公開精確比例]。這意味著視訊記憶體利用率直接關係到資本效率。

代表公司與資本對映

按產業鏈環節

環節	代表公司	與視訊記憶體利用率的關係
HBM 製造	SK 海力士、三星電子、美光	視訊記憶體硬體供應商，產能決定供給上限
GPU 架構設計	NVIDIA、AMD、華為海思/昇騰	視訊記憶體容量/頻寬架構決定利用率天花板
先進封裝	台積電（CoWoS）、日月光/矽品	HBM 與 GPU die 的整合依賴先進封裝
儲存/封裝配套材料	三星電機、SKC、Ibiden、Shinko	HBM 封裝基板、ABF 載板等
AI 架構/最佳化軟體	Microsoft（DeepSpeed）、Meta（PyTorch/FSDP）、Google（JAX/XLA）	軟體最佳化提升視訊記憶體利用率
雲端廠商/算力平台	AWS、Azure、GCP、阿里雲端、字節跳動	視訊記憶體利用率直接影響 GPU 例項 ROI

資本對映路徑

投資者視角：

視訊記憶體利用率低 → 需要更多 GPU 補償 → GPU/HBM 需求增加
         │
         ├──→ NVIDIA（GPU 銷售）
         ├──→ SK 海力士/三星/美光（HBM 銷售）
         └──→ 台積電（封裝產能）

視訊記憶體利用率最佳化技術成熟 → 同樣任務需要更少 GPU
         │
         ├──→ 利好雲端廠商（成本下降、獲利提升）
         └──→ 短期可能壓制 GPU 需求預期（長期需求仍增長）

投資邏輯

核心投資視角

視角一：視訊記憶體是 AI 算力的”硬約束”

不管軟體怎麼最佳化，大型模型訓練/推論都需要物理視訊記憶體
HBM 供需緊張 → HBM 廠商和封裝廠商受益於量價齊升

視角二：視訊記憶體利用效率提升 = 解鎖更大型模型

Flash Attention、ZeRO 等技術並非減少視訊記憶體需求，而是”同樣的視訊記憶體訓更大的模型”
效率提升 → 模型規模天花板上移 → 總需求繼續增長
Jevons 悖論在 AI 視訊記憶體領域的體現：效率提升 → 需求不減反增

視角三：推論側的視訊記憶體經濟學

推論時視訊記憶體瓶頸 = KV Cache 管理
PagedAttention / KV Cache 量化等技術降低單使用者視訊記憶體佔用
同樣的 GPU 能服務更多使用者 → 推論成本下降 → 應用爆發

視角四：關注視訊記憶體頻寬，而非僅容量

容量決定”裝多少”，頻寬決定”算多快”
HBM3/HBM3e 頻寬提升是代際升級的核心賣點
頻寬瓶頸比容量瓶頸更難通過軟體最佳化解決

風險提示

HBM 產能過剩風險：若 AI 需求增速放緩或替代技術出現
新型儲存技術（如 CXL 擴充套件記憶體）可能改變視訊記憶體供需格局
軟體最佳化快速迭代可能部分緩解硬體瓶頸

常見誤讀糾偏

❌ 誤讀一：`nvidia-smi` 顯示的視訊記憶體佔用 = 實際有效使用

糾偏： nvidia-smi 報告的是 CUDA Context 和已分配視訊記憶體，包含：

視訊記憶體碎片（已分配但不可用）
CUDA 執行時自身的開銷
可能存在”分配但未使用”的塊

實際有效利用率通常低於 nvidia-smi 顯示值。精確評估需要使用 torch.cuda.memory_stats() 等工具檢視 active_bytes vs reserved_bytes。

❌ 誤讀二：視訊記憶體利用率越高越好，應該打滿 100%

糾偏： 視訊記憶體利用率接近 100% 時：

無緩衝空間：任何臨時分配（如通訊 buffer）都可能導致 OOM
碎片風險：即使總量夠，碎片化導致無法分配連續大塊
效能抖動：頻繁的分配/釋放觸發視訊記憶體管理開銷

經驗上，85%-95% 是較為健康的訓練視訊記憶體利用率區間。低於此區間說明資源浪費，高於此區間則 OOM 風險驟增。[經驗性判斷，非硬標準]

❌ 誤讀三：模型引數量 / 總引數量 = 視訊記憶體利用率

糾偏：

MoE 模型的總引數量與啟用引數量差異巨大
一次前向傳播實際載入到視訊記憶體的是：啟用的 expert + 共享層
視訊記憶體利用率應關注實際駐留視訊記憶體的資料，而非模型檔案中的引數總數

❌ 誤讀四：加視訊記憶體就能解決訓練瓶頸