SemiAnalysis 研究報告- NVIDIA Tensor Core Evolution

ASIC 應用場景是否會越來越少

深度解析 NVIDIA 如何從 Volta 到 Blackwell 逐步優化 Tensor Core

探討為何這項技術對 AI 運算至關重要

🧱 一、這篇文章到底在講什麼?

🔍 主題:

從 Volta → Blackwell,NVIDIA 怎麼一步步優化 Tensor Core?為什麼這件事對 AI 運算這麼重要?

🧠 核心概念:

  • 深度學習需要大量矩陣運算(Matrix Multiply, MMA)
  • NVIDIA 為了加速這類運算,設計出專用硬體單元:Tensor Core
  • 每一代 Tensor Core 都為了「更快、更省電、更省記憶體」進行設計變革
  • 從 Volta 到 Blackwell,設計哲學變成一件事:減少搬運資料的時間,最大化並行處理

🧠 二、各世代的設計邏輯

五大主軸,每一代進化都有對應解法:

問題 造成什麼困難 每一代如何解法
Matrix 運算需要大量資料搬運 DRAM太慢 → 整體瓶頸 V100 開始加入 Tensor Core(Volta)
Hopper 加 TMA(快取資料)
Blackwell 加 TMEM(專用記憶體)
Register 使用太多 跟資料搬運搶資源 Ampere 開始 async copy
Blackwell 完全不靠 Register 做運算
需要用更多線程合作 設計困難、浪費資源 Volta 用 8 thread
Ampere 用 32 thread
Hopper 用 128 thread
Blackwell 只要 1 thread(革命性)

🧠 二、各世代的設計邏輯(續)

問題 造成什麼困難 每一代如何解法
精度 vs 效能拉扯 精度太高佔空間、功耗高 支援 BF16 → FP8 → NVFP4(精度夠用但面積小)
記憶體頻寬永遠不夠 記憶體讀取變瓶頸 Hopper 推出 TMA multicast
Blackwell 用 CTA Pair 區域共享記憶體

🧪 三、Blackwell 有什麼突破?

✅ 關鍵創新(對比前一代 Hopper):

技術 Hopper Blackwell
MMA 啟動方式 需要 128 個 thread(warpgroup)合作 一條 thread 就能做(簡化設計 + 效能提升)
記憶體使用 Shared Memory + Register TMEM + Shared Memory,完全不再靠 Register
支援資料格式 FP16 / FP8 / E4M3 / E5M2 加入 MXFP4 / NVFP4 / pair-wise 4:8 sparsity

🧪 三、Blackwell 突破(續)

技術 Hopper Blackwell
運算非同步性 初步 async 全指令皆 async 支援,能同時搬運與計算
記憶體共享 有 TMA multicast 新增 CTA Pair,共用 Matrix B,進一步減少搬運

🧭 總結一句話:

Blackwell 是為了"完全非同步運算 + 記憶體最小搬運"打造的 Tensor Core 革命版本。

🎯 四、為什麼這篇文章重要

(不只是講硬體規格)

這不是簡單的「幾倍 FLOPS 提升」,而是:

  • 它揭露了 NVIDIA 整體架構與 CUDA 設計邏輯的轉變
  • 它告訴我們:為什麼高效能 AI 計算不再只是疊加硬體,而是系統層次的整合優化
  • Blackwell 的設計也啟發了未來可能出現的 客製化 AI ASIC(像 AWS Trainium、Google TPU)怎麼抄也抄不出來的效率優勢

📈 五、以上的整理代表什麼?

  • NVIDIA 越來越難被超越:因為這種設計不是買製程升級能做到,是整合 CUDA、compiler、kernel 的深度優化。
  • 未來 AI 推論也可能採用 TMEM + Async 模式:Blackwell 開始模糊訓練與推論硬體的界線。
  • 如果對手(如 AMD)還在模仿早期的 Tensor Core(像Volta/Ampere),將無法在能效上贏回市場。

🧬 Blackwell 不可複製的優勢

Blackwell 的設計不是單純的硬體升級,而是整個「運算流程 × 記憶體層級 × CUDA 編譯模型 × 非同步設計」的全面整合。

🧠 創新在「系統級架構整合」

面向 傳統設計(可模仿) Blackwell 設計(難以抄襲)
Tensor Core 運算 模仿 MMA 矩陣乘法硬體 ❌ 拋棄 register、改用 TMEM,需重新設計記憶體調度
CUDA 編譯器路徑 可以模仿 kernel 寫法 ❌ Blackwell 指令如 tcgen05.mma 屬於深層自動優化流程

🧬 系統級整合(續)

面向 傳統設計(可模仿) Blackwell 設計(難以抄襲)
資料搬運 依靠 DRAM + Shared memory ❌ TMEM + async + multicast + CTA Pair,需要硬體×軟體共設計
運算啟動單元 每次運算需大量 thread(8~128)協同 單線程 MMA,推翻了現有硬體調度模型
時序設計 有 interlock / pipeline lock-in ✅ 完整非同步路徑、需要特殊硬體同步結構與 compiler 調度模型

📌 結論:這是一種「運算與資料搬運的重新耦合設計」,而不是純粹的 compute FLOPS 疊加。

🔒 為什麼 AWS、Google 有錢也抄不來?

AWS 的 Trainium 或 Google 的 TPUv5e 嘗試壓低成本並聚焦特定精度,但 他們做不到的事 包括:

  • 沒有 CUDA + CUTLASS + Kernel 編譯優化配套工具(Blackwell 是 CUDA-native)
  • 無法做到和 TMEM 類似的「thread local but tensor global」記憶體設計
  • 缺乏像 CTA Pair 的小單元分區互通架構(TPC層級共享設計)
  • 無等效於 tcgen05.mma 這種單線程觸發、共享輸入、融合加速的設計

這讓 Blackwell 成為「可程式化架構中效率最像 ASIC,但彈性遠勝 ASIC」的代表。

🎯 動態 CUDA Kernel 解構

🔧 Kernel 的新定義:

Kernel 並不是靜態指令表,而是一種「運算流程圖 + 資料搬運策略 + 指令調度策略」

NVIDIA 透過 CUTLASS + NVCC 編譯器,由編譯器根據 kernel 的 shape、資料格式、可用資源 自動拆解成最佳化執行流程

🧠 自動決定:

  • 哪些資料從 global memory → shared memory → TMEM
  • 哪些 MMA 指令要用 wgmma / tcgen05.mma / mma.2SM
  • 哪些資料能在 warpgroup 或 CTA Pair 中共享
  • 哪些操作可異步執行與疊代(如 cp.async vs tcgen05.commit)

🧭 對手為什麼學不來?

對手 主要障礙
🟠 AWS Trainium 沒有 CUDA 編譯體系,kernel 撰寫無法自動適配低層結構,也無 CUTLASS 一樣的自動 tile 運算策略
🔵 Google TPU 編譯器強大(XLA),但模型限制多且需靜態圖,無法像 CUDA 動態調整 kernel 執行策略
🔴 AMD ROCm 缺少自動化搬運與 async pipeline 的深層整合設計,必須開發者親自 tune 每一段流程

💡 真正的 moat 是「compiler x kernel × memory hierarchy × async scheduling」

🔄 CUDA 動態適配能力

CUDA 已經變成:針對不同演算法與模型需求,能「動態適配不同精度/記憶體配置/運算單元」的全鏈條編譯執行系統。

任務類型 指揮官會這樣調配資源
精度要求高的模型(如 FP32 訓練) 編譯器選用 wgmma + shared memory 排程較穩定的精準計算
推論用途,偏重效率(FP8 / NVFP4) 編譯器自動切換成 tcgen05.mma + 使用 TMEM + CTA Pair 并行化
大模型 KV-cache 快取需求 利用 Hopper/Blackwell 的 TMA multicast 將資料廣播到多 SM
小模型 / latency-sensitive(如 RLHF 推論) 使用 async MMA 與低延遲記憶體布局,壓縮 register 壓力與搬運延遲

🏆 CUDA 勝任任何 AI 運算工作

CUDA 已不是「程式語言」,而是 NVIDIA 將硬體、記憶體架構、非同步排程全部打包整合的一個作戰平台。

層級 CUDA 提供的能力 與對手對比
🧠 編譯器層(NVCC) 根據 kernel、精度、自動產生最適配置(如 tile 大小、記憶體位置) XLA / Neuron 無法像 NVCC 根據 GPU 條件調整 kernel 結構
⚙️ 執行層(kernel schedule) 自動選擇 warp / warpgroup / CTA Pair 的並行策略 ROCm 需手調 launch config,Trainium/TPU 採靜態圖
📦 記憶體排程 編譯器會根據資料量動態切換搬運與儲存方式 大多數架構缺乏等效記憶體層次調度邏輯

🔍 CUDA vs 對手實際成績

領域 NVIDIA(CUDA)成績 對手狀況
訓練(Transformer, LLM) A100 → H100 → B100 可自動優化 FP8 / shared memory reuse / overlap kernel TPU 需手工設計 static graph,Trainium 效率不穩定
推論(超大模型 low-latency) Hopper/B100 利用 TMA multicast + TMEM 分散 loading 瓶頸 TPU / Neuron 難支援非批次 latency-sensitive 任務
圖形 / AI融合應用 GPU 原生支援 Graphics + Compute + AI fusion(DLSS 就是例子) TPU 完全不能做圖形,Trainium 為專用推論
可擴充性(1張卡 → 數千張) NCCL 多 GPU、NVLink native 支援大規模同步 TPU 與 Trainium 擴充需透過 cluster 編排

⚡ GPU vs ASIC 的核心爭論

✅ 傳統說法:特定任務用 ASIC 更便宜有效率

這個說法 理論上沒錯,但它只成立於以下條件:

  • 任務固定(如模型固定)
  • 數量龐大(高量複用)
  • 模型參數能被離線量化與壓縮

❗ 但真實世界問題:需求一直在變、模型一直在換

  • 🚀 LLM 模型快速演進:GPT-2 → GPT-3 → GPT-4 → Mixtral → GPT-4o,每半年都在變
  • 🧠 客製化模型需求增加:醫療、金融、零售等都需要特化語言模型
  • 📦 Multi-Tenant 雲平台:每分鐘接到不同客戶、不同模型、不同任務的請求

💸 ASIC 表面便宜,實際上反而更貴

面向 ASIC 成本 GPU + CUDA 成本
初始設計 便宜(針對單一任務最佳化) 貴(需建構通用結構)
長期演進 升級即需重新設計,cost 反覆累積 一次部署,可動態適應
運維成本 難以管理多任務多模型 CUDA 生態可同時支援多模型且可升級
開發週期 長(tape-out 前需確定模型) 短(CUDA kernel 可即時部署 + 優化)
資源利用率 多數時間閒置或過窄 GPU 可實現高效資源再利用與任務切換

📌 ASIC 的低成本只是靜態觀點,真實世界變動太快,GPU + CUDA 在 TCO(總擁有成本)上幾乎一定勝出。

📉 ASIC 應用路徑越來越窄

CSP 因為客戶分層,隨著大客戶走向更複雜多變任務,ASIC 就會被逐漸推向「中低階運算層」,而無法主導整體 AI 市場。

等級 客戶型態 對硬體彈性需求 長期趨勢
Tier 1 超大型 AI 公司(如 OpenAI、Anthropic、Meta) 極高:需要新精度、非同步執行、多模型組合 會集中使用 GPU(B100 / GB200)
Tier 2 成熟 SaaS AI 服務商(如 Notion AI、Canva AI) 中度:可配合定制化 ASIC,但需維持相容性 可能被 ASIC 廠商切入
Tier 3 雲上長尾用戶、中小開發者 :只要價格便宜、相容主流模型即可 仍以 GPU + API 為主

📌 ASIC 最可能佔據的是 Tier 2「中端大客戶」,但無法上攻、也難下沉。

🚀 GPT-5 會進一步壓縮 ASIC 空間

GPT-5 代表的變化:

  • 模型規模:參數數量預估 3~10 倍(估達 1 兆參數級)
  • 多模態結構:可能從 text → image → video → action
  • 訓練方式:RLHF + 模型融合 + 連續更新
  • 精度策略:更依賴 BF16 / FP8 / sparse + dense 混合運算

🔑 對 ASIC 的打擊:

  • 📦 訓練架構固定化:GPT-5 training 需要動態策略調整 → ASIC 無法追蹤複雜變化
  • 🧮 精度動態混合:FP16 / FP8 / NVFP4 的混搭 → 需要 NV 的 Tensor Core 動態適配
  • 🔄 運行時多任務混併:LLM 訓練過程中需要推論/蒐集/蒸餾同時進行 → 只有 GPU + CUDA 能支援

🎯 結論:ASIC 應用場景越來越少

📌 核心論點:

未來 ASIC 不是走向主導,而是走向被「架構分層邊緣化」的角色。真正的算力核心會被 GPU + CUDA 穩穩掌握在 Tier 1 需求牽引下,不斷向兩端吞噬市場。

🔚 GPT-5 時代的結構性變化:

  • 🚫 雲端業者不再積極投資訓練型 ASIC
  • 🧨 ASIC 初創公司面臨找不到定錨模型的商業化困難
  • ✅ NVIDIA 的 GPU 訓練份額70%可能不降反升,進一步甚至反攻推論應用

💡 最終洞察:

「CUDA + GPU 是軟體定義的 AI ASIC 平台,而 ASIC 是硬體鎖死的單用途解決方案。」

1 / 21