cuBLAS

3 秒看懂

cuBLAS（CUDA Basic Linear Algebra Subprograms）是 NVIDIA 在 CUDA 平台上提供的一套基礎線性代數子程式庫，由 NVIDIA 官方開發與維護。它的核心任務是把矩陣乘法、矩陣-向量乘法、向量點積等運算在 GPU 上做到效能極致，使其成為 PyTorch、TensorFlow、JAX 等所有主流深度學習架構事實上的底層計算引擎。當一個開發者寫下 torch.matmul 或 tf.linalg.matmul 時，呼叫鏈路穿越架構、運算元庫，最終絕大多數稠密線性代數運算都會降落到 cuBLAS 的 GEMM（通用矩陣乘法）或 GEMV（矩陣向量乘法）上。沒有 cuBLAS 提供的這一層高度最佳化的代數原語，任何一次神經網路的前向傳播或反向傳播的延遲都會增加一個數量級，大型模型訓練的時間成本將完全站不住腳。

3 分鐘產業解釋

深度學習架構在呼叫線性代數操作時，計算路徑最終基本都會由 cuBLAS 接管。cuBLAS 的意義遠不止於“把 BLAS 標準搬到 GPU 上”。它針對每一代 NVIDIA GPU 架構——從 Volta、Turing、Ampere 到 Hopper（以及後續的 Blackwell）——的快取層級設計、Tensor Core 計算單元、共享記憶體尺寸和暫存器檔案容量，做了大量手工彙編級的核心函式引數調優。每一代 GPU 的 SM（Streaming Multiprocessor）微架構變化都會在 cuBLAS 的分塊策略、流水線深度和指令排布中有所體現。

cuBLAS 的介面形態分兩條腿走路：一是傳統 BLAS 介面（cuBLAS API），完整覆蓋 Level-1（向量操作）、Level-2（矩陣-向量操作）、Level-3（矩陣-矩陣操作），介面語義與 Netlib BLAS 標準對齊，適合需要穩定、可預測效能的業務場景；二是更靈活的 cuBLASLt（輕量級），它允許使用者在呼叫前生成“計劃”，針對特定的矩陣形狀、資料型別、轉置方式以及指標偏移等引數組合，在執行時通過啟發式搜尋選擇最優的核心實現方案。對 Transformer 類模型中大量存在的不規則小矩陣乘法（如多頭注意力中的批次小矩陣乘、序列長度動態變化導致的非方形 GEMM），cuBLASLt 能通過在執行時挑選合適的分塊策略和數學變換路徑，顯著減少計算尾部的浪費。

在產業意義上，cuBLAS 的每一次重大更新（如引入 FP16、BF16、TF32 混合精度支援，再到 FP8）都直接解鎖了訓練吞吐和推論延遲的瓶頸。2022 年 Hopper 架構引入 FP8 後，cuBLAS 針對 E4M3 和 E5M2 兩種資料格式分別提供 GEMM 核心，大型模型訓練的計算效率再次被推上新臺階。可以說，業界前沿模型的時間成本曲線，有一半是由 cuBLAS 所搭載的代數原語效率決定的。

技術原理

cuBLAS 並非“一個庫”，而是一套隨 CUDA 工具包持續演進的代數執行體系。理解其工作原理，需要從介面層級、呼叫路徑和核心最佳化三個維度拆解。

介面層級

傳統 cuBLAS API 要求使用者在呼叫前顯式建立 cuBLAS 控制代碼（handle），該控制代碼管理 GPU 上下文、內部工作緩衝區以及一系列可配置屬性（如 Tensor Core 使用策略、數學模式精度）。所有操作在控制代碼的上下文中發起，保證執行緒安全與資源複用。Level-3 函式（如 cublasGemmEx）是重頭戲，支援混合精度輸入輸出，根據 GPU 架構自動分派到最快的硬體指令。

cuBLASLt 在前者基礎上增加了“計劃生成”步驟。使用者先描述矩陣乘法操作的特徵（matmul_desc）、矩陣版面配置（matrix_layout）以及期望的 epilogue 操作（如偏置加、啟用函式、轉置或量化），然後呼叫 cublasLtMatmulAlgoGetHeuristic 觸發內部搜尋演算法。該演算法會查詢一個帶歷史測量資料的快取，如果快取未命中，則對候選核心配置進行微型基準測試，選擇最優方案。計劃生成後，可重複用於相同特徵的操作。

cuBLASDx（裝置端擴充套件）進一步打破宿主端/裝置端邊界，允許在 CUDA 自定義核心裡直接呼叫 BLAS 運算元，無需返回宿主端，大幅降低延遲。這對融合運算元設計（如 FlashAttention 的前身思路）或在自定義核函式中嵌入矩陣乘非常關鍵。

典型呼叫鏈路

在深度學習場景中，cuBLAS 的實際呼叫路徑通常是：

架構層（PyTorch / TensorFlow / JAX） 
  → 基礎運算元層（aten / XLA） 
    → 加速庫層（cuDNN 或直接 cuBLAS） 
      → cuBLAS / cuBLASLt

以 PyTorch 的 nn.Linear 為例，前向計算會走到 aten::linear，隨後根據張量形狀和精度選擇 cuBLAS GEMM 或 cuBLASLt（當需要 epilogue 融合或遇到非規則形狀時）。卷積操作多數落入 cuDNN，但 1×1 卷積和全連線層在架構層面常被重寫為矩陣乘法後再進入 cuBLAS。

核心最佳化技術（定性）

分塊與快取利用：GEMM 核心將輸出矩陣拆分成瓦片（tile），每個執行緒塊（thread block）負責計算一個 C 子塊。瓦片尺寸、迴圈展開因子和共享記憶體排布經過仔細調校，使全域性記憶體資料先被協作載入到共享記憶體，再由暫存器重複使用，從而最大化隱藏全域性記憶體延遲。

Tensor Core 對映：在 Volta 及後續架構上，cuBLAS 將矩陣乘片段對映到 warp 級 Tensor Core 的 MMA（Matrix Multiply-Accumulate）指令。輸出 tile 尺寸必須是 warp 尺寸（32）的整數倍，保證 warp 內各執行緒同步向 Tensor Core 發射資料片段。

非同步複製與多階段流水線：從 Ampere 架構起，cuBLAS 利用非同步記憶體複製指令（如 cp.async）和多階段軟體流水線，讓當前 tile 的計算與下一 tile 的資料預取重疊執行，有效隱藏全域性記憶體延遲。

資料重排與 swizzling：共享記憶體的地址模式經過異或（xor）變換，避免同一 warp 內多個執行緒同時訪問同一個 bank 導致的 bank conflict，保證共享記憶體頻寬被充分利用。

Epilogue 融合：cuBLASLt 允許在 GEMM 計算完成後，直接在核函式末尾串接偏置加、GELU 或 SiLU 啟用、轉置甚至量化操作。所有操作在片上完成，避免將中間結果寫回全域性記憶體再讀取，對 Transformer 的 FFN 模組（兩個線性層中間夾一個啟用函式）可將延遲降低 30% 以上（行業經驗值，非特定硬體型號資料）。

混合精度與縮放：FP16 的表示範圍有限，累加過程中可能溢位。cuBLAS 內部自動採用 FP32 作為累加器精度，並結合 loss scaling 策略穩定訓練。在 FP8 場景下，縮放因子（scale factor）由使用者傳入或由架構管理，cuBLAS 負責在乘加指令中應用。

資料流示意（GEMM 分塊與 Tensor Core 對映）

 全域性記憶體：
   A[M,K]  B[K,N]  C[M,N]
     |        |
     v        v
 共享記憶體分塊（Tile A, Tile B）
     |        |
     v        v
 暫存器片段 -> warp 級 Tensor Core MMA 指令
     |
     v
 累加到共享記憶體/暫存器中的 C tile -> 寫回全域性記憶體

關鍵引數

cuBLAS 的效能表現取決於多個引數與配置的組合，不同組合對硬體利用率和延遲影響顯著。

• 吞吐：以 TFLOPS 度量，cuBLAS 在適合 Tensor Core 的矩陣形狀下通常能達到對應 GPU 硬體理論峰值的 80%–95%。該數字來自行業公開基準測試的綜合經驗範圍，不是特定型號的官方標稱值，精確數值需參考對應架構的 NVIDIA 白皮書。
• 延遲：單次 GEMM 呼叫的端到端時間，包括核函式啟動、資料傳輸和計算。當應用場景由大量小矩陣組成（如批次歸一化後的仿射變換、注意力分數計算中的小批次 GEMM），核函式啟動開銷可能佔據主導，由此引出分組 GEMM 和 cuBLASLt 的批次呼叫最佳化。
• 精度模式：
  • FP64（雙精度，科學計算和 HPC）
  • FP32（單精度，傳統訓練和推論）
  • TF32（TensorFloat-32，19 位尾數，Ampere 及以上，兼顧範圍和吞吐）
  • FP16（半精度，需配合 FP32 累加）
  • BF16（腦浮點，與 FP32 相同指數範圍，減小溢位風險）
  • INT8（推論量化）
  • FP8（E4M3 用於前向，E5M2 用於反向，Hopper 及以上，2022 年引入） 不同精度模式的吞吐差異極大，BF16/FP16 通常接近 FP32 的 2× 以上吞吐（來源：NVIDIA A100/H100 白皮書，2020/2022），FP8 在此基礎上再次翻倍（行業經驗值）。
• 記憶體頻寬利用率：大矩陣乘法通常受限於全域性記憶體頻寬，小矩陣受限於核函式啟動開銷和共享記憶體延遲。cuBLAS 通過分塊複用將矩陣 A 和 B 的每個元素從全域性記憶體載入一次後，在共享記憶體和暫存器中重複使用多次。業界通常使用 roofline 模型分析具體場景的瓶頸。
• 稀疏性：Ampere 架構起支援 2:4 結構稀疏性，即在每 4 個連續元素中必須有 2 個為零，cuBLAS 能識別並加速這種模式的 GEMM，理論吞吐可達到稠密 GEMM 的 2×（來源：NVIDIA A100 白皮書，2020）。實際提升取決於模型權重的稀疏化水平與剪枝策略。
• Epilogue 融合支援：cuBLASLt 關鍵引數，決定是否在 GEMM 後新增偏置加、啟用函式、轉置或量化操作。這一引數直接影響 30% 以上的端到端延遲（行業經驗值，具體取決於模型結構），是推薦系統中低延遲 MLP 模組和 Transformer FFN 的熱點最佳化項。

技術路線

cuBLAS 跟隨 CUDA 工具包和 GPU 架構代際持續迭代，可大致劃分為以下階段：

2008–2012（CUDA 初期，Tesla/Fermi 架構） 提供經典 BLAS 介面的基礎 GPU 實現，主要加速稠密矩陣乘法與向量運算。介面層面以 Fortran 風格 BLAS 對齊為目標，幫助科學計算使用者從 CPU 遷移到 GPU。

2014–2016（Maxwell/Pascal 架構） 隨著深度學習爆發，cuBLAS 開始支援 FP16 與 FP32 混合計算，採用 FP16 儲存降低記憶體頻寬壓力、FP32 累加保持精度。Pascal 架構引入統一記憶體和 NVLink，cuBLAS 在其中負責跨 GPU 的高效矩陣運算的原語支撐。

2017–2019（Volta/Turing 架構，CUDA 9–10） Tensor Core 首次降臨。cuBLAS 加入 warp 級 MMA 指令支援，單次操作完成 4×4 矩陣乘加（FP16）。同一時期 cuBLASLt 正式釋出，提供靈活的計劃生成與啟發式搜尋架構。BF16 和 TF32 隨後被納入支援列表。

2020–2022（Ampere 架構，CUDA 11） cuBLASLt 成熟為深度學習後端的主路徑，PyTorch 和 TensorFlow 將其設為預設 GEMM 後端。結構稀疏性（2:4 模式）被納入 cuBLAS，提供硬體加速的稀疏 GEMM。同時引入分組 GEMM（grouped GEMM）以應對批次小矩陣乘法的效能碎片化問題。

2023 年至今（Hopper/Blackwell 架構，CUDA 12+） cuBLAS 增加 FP8（E4M3 與 E5M2）支援，適配 Hopper 架構的第四代 Tensor Core。TMA（Tensor Memory Accelerator）等新硬體特性被整合進資料搬運路徑，通過非同步張量記憶體訪問進一步降低資料讀取延遲。Blackwell 架構（2024 年釋出）引入更低精度的微縮放格式（microscaling），cuBLAS 相應推出配套核心，繼續鎖死大型模型訓練和推論的底層加速（來源：NVIDIA GTC 2024 演講）。

對比視角

特性	cuBLAS（傳統）	cuBLASLt	其他 GPU 庫（如 rocBLAS）
介面靈活性	固定 BLAS 標準	計劃生成，執行時搜尋最優方案	類似 cuBLAS 標準，部分支援計劃生成
Epilogue 融合	有限（少量啟用函式）	廣泛（任意偏置、啟用、轉置、量化）	部分支援，仍在追趕
形狀適應性	對固定形狀效能穩定	可自動調優新型形狀，適合動態網路	主要依賴手工最佳化固定形狀
硬體專屬最佳化	每代架構手工編寫核函式	基於架構特徵自動選擇最佳核心	取決於實現質量與投入力度
生態系統整合	NVIDIA 全棧深度整合	PyTorch、TensorFlow、JAX 廣泛使用（2023 年起成為預設）	AMD ROCm 生態，適配進展中

上游

cuBLAS 的直接上游包括以下層次，它們共同構成 cuBLAS 執行的技術前提。

硬體層 NVIDIA GPU 的 SM（Streaming Multiprocessor）微架構是 cuBLAS 最底層的物理基礎。SM 內部的 Tensor Core 單元、共享記憶體（shared memory，每 SM 數 KB 到數百 KB 不等，隨架構代際變化）、暫存器檔案和 L2 快取共同決定了 cuBLAS 的分塊尺寸、流水線深度和指令發射模式。Hopper 架構引入的 TMA 單元則直接影響資料搬運方式的演進。

編譯器與執行時 CUDA 工具包（CUDA Toolkit）中的 nvcc 編譯器、CUDA Runtime、CUDA Driver API 以及 PTX 指令集是 cuBLAS 的編譯和執行環境。cuBLAS 核心函式使用 PTX 或直接使用 SASS（機器碼）編寫，依賴 nvcc 的最佳化能力和 CUDA Runtime 的上下文管理。

指令集與閉源屬性 cuBLAS 的原始碼未公開，屬於 NVIDIA 閉源軟體棧的一部分（部分標頭檔案隨 CUDA Toolkit 公開）。其內部實現與 PTX 指令集、各代 GPU 的硬體指令（SASS）深度耦合，競爭對手即使獲取硬體，也無法通過逆向工程合法復刻。

相關協作庫 cuBLAS 常與 cuSOLVER（線性方程組求解、特徵值計算）、cuSPARSE（稀疏矩陣運算）和 cuFFT（快速傅立葉變換）協作。在深度學習中，cuDNN 是 cuBLAS 的重要上游消費者——cuDNN 將卷積、池化等高階操作拆解為矩陣乘法後呼叫 cuBLAS。

下游

cuBLAS 的下游幾乎覆蓋所有在 NVIDIA GPU 上執行的深度學習架構、推論引擎和分散式訓練系統。

深度學習架構 PyTorch、TensorFlow、JAX 是最主要的直接下游。以 PyTorch 為例，torch.matmul、torch.bmm、nn.Linear、nn.MultiheadAttention 中的注意力分數計算等，最終都經過 ATen 運算元庫落到 cuBLAS GEMM 或 cuBLASLt。TensorFlow 的 XLA 編譯器在生成 GPU 程式碼時，也會將矩陣操作對映到 cuBLAS 呼叫。JAX 的 XLA 後端同樣深度依賴 cuBLAS 作為底層線性代數原語。

加速庫與推論引擎 cuDNN（深度神經網路加速庫）將卷積和其他高階操作分解為矩陣乘後呼叫 cuBLAS。TensorRT（推論最佳化器）在建置推論圖時大量使用 cuBLASLt 的 epilogue 融合能力。ONNX Runtime 的 CUDA 執行提供程式也直接呼叫 cuBLAS 實現矩陣運算。

大型模型訓練與推論系統 Megatron-LM、DeepSpeed、vLLM、FlashAttention 系列等大型模型基礎設施，均以 cuBLAS 為底層 GEMM 引擎。FlashAttention 雖然以自定義核心聞名，但其實現中仍將部分矩陣乘子模組委託給 cuBLAS 以利用 Tensor Core 的峰值效能。

間接下游——雲端平台與企業使用者 AWS、Google Cloud、Microsoft Azure 和 Oracle Cloud 等雲端服務商通過 NVIDIA GPU 例項，將 cuBLAS 間接提供給數以萬計的 AI 客戶。企業內部訓練平台（如 Meta 的 PyTorch 叢集、字節跳動的推薦系統訓練平台）也高度依賴 cuBLAS 的效能輸出。

遷移成本與鎖定效應 下游使用者一旦將模型訓練流程和推論系統深度繫結到 cuBLAS 特定 API（如專用的 epilogue 融合模式、FP8 縮放策略），遷移到其他 GPU 平台（如 AMD ROCm）需要重寫相關數學庫呼叫，並重新調優效能。根據公開資料顯示，這種遷移通常需要數人月甚至數人年的工程投入，並可能在過渡期面臨 20%–50% 的效能損失（行業經驗值，具體取決於工作負載特徵）。

受益公司

cuBLAS 本身不獨立定價或銷售，而是隨 CUDA Toolkit 免費分發，與 NVIDIA GPU 硬體捆綁構成事實上的標準。因此，受益方分為直接受益者（NVIDIA 生態）和間接受益者。

NVIDIA（NVDA） cuBLAS 是 NVIDIA “CUDA 護城河”的核心元件，與 cuDNN、TensorRT、NCCL 等閉源庫共同構成軟體壁壘。對手即使造出在硬體紙面規格上匹敵的 AI 晶片，也因缺乏同等成熟度和最佳化深度的數學庫生態而難以獲得客戶遷移。NVIDIA 的財務資料顯示，其資料中心業務營收從 FY2021（截至 2021 年 1 月）的 67 億美元增長至 FY2024（截至 2024 年 1 月）的 475 億美元（來源：NVIDIA 年報），cuBLAS 作為 GPU 軟體價值主張的一部分，直接推動這一增長。

超大規模雲端廠商（Meta、Google、Microsoft、Amazon） 這些公司是 cuBLAS 的最大終端使用者（通過海量 GPU 部署），同時也是 cuBLAS 的間接貢獻者——它們開源了 PyTorch（Meta）、TensorFlow（Google）、JAX（Google）等架構，這些架構深度整合 cuBLAS。雲端廠商通過將 cuBLAS 加速的 GPU 例項對外出租，獲得營收（如 AWS P4d/P5 例項、Azure ND H100 v5 系列等）。

獨立軟體供應商與 AI 創業公司 如 Anyscale、Run:ai、CoreWeave 等基礎設施提供商，以及 Hugging Face、Anthropic 等模型開發商，均依賴 cuBLAS 的生產級效能輸出，將其作為訓練和推論平台的底層代數引擎。

替代路徑玩家 AMD（AMD）通過 ROCm 中的 rocBLAS 試圖建置類似生態。截至 2024 年底，ROCm 的架構相容性和庫成熟度已有提升，PyTorch 對 ROCm 的原生支援也在改善，但公開資料顯示，在 cuBLAS 對應的大量手工最佳化、epilogue 融合和稀疏性支援方面，rocBLAS 仍存在差距（具體代際對比資料未見公開全面基準）。國產 GPU 廠商（如摩爾線程、壁仞科技、燧原科技等）也各自推出對標 cuBLAS 的數學庫，但截至撰稿日（2025 年初），公開可獲得第三方效能對比資料未揭露。

市場規模

cuBLAS 沒有獨立的銷售營收，其“市場規模”等同於下游 NVIDIA GPU 在 AI 計算領域的市場活躍度，以及深度學習架構中所呼叫線性代數運算的整體計算量規模。

資料中心 GPU 市場 根據多家行業分析機構（Mercury Research、Jon Peddie Research、IDC）的公開資料，2023 年全年，NVIDIA 在資料中心獨立 GPU 領域的出貨量份額超過 80%。這一份額對應約 400 億美元以上的硬體營收（來源：NVIDIA FY2024 年報），cuBLAS 構成了這些硬體在 AI 工作負載中可實現價值的關鍵軟體組成部分。

AI 訓練與推論晶片市場 第三方研究機構（如 Omdia、Counterpoint）估計，2023 年全球 AI 晶片市場規模約為 450 億–550 億美元（口徑含 GPU、ASIC、FPGA，訓練加推論）。NVIDIA 憑藉 GPU + CUDA + cuBLAS 組合佔主導地位，2023–2024 年營收佔比約 70%–80%（具體比例因統計口徑和資料可得性存在差異，建議以 NVIDIA 官方財報和獨立第三方報告交叉驗證）。

“cuBLAS 間接市場”的邊界 如果將 cuBLAS 的“市場”理解為所有依賴它的軟體和雲端服務所創造的總價值鏈，那麼該數字遠大於 GPU 硬體市場，涵蓋了深度學習架構（開源但驅動雲端消費）、大型模型 API 服務（如 OpenAI、Anthropic、Google Gemini 等呼叫的後端計算）以及 AI SaaS 應用。2024 年，全球 AI 軟體與服務市場規模估計超過 1000 億美元（來源：Gartner、IDC 公開摘要），其中大量訓練和推論負載落在 cuBLAS 覆蓋的 GPU 算力上。該指標口徑寬泛，僅作為下游市場規模的間接參考。

供給特徵 作為純軟體產品，cuBLAS 的邊際複製成本接近零，供給不受產能限制。其分發量完全隨 CUDA Toolkit 下載量、NVIDIA GPU 驅動安裝量以及 Docker 映象中 CUDA 基礎映象的拉取量增長。NVIDIA 在 GTC 2024 上揭露 CUDA 累計下載量已超過 4000 萬次（來源：NVIDIA GTC 2024 主題演講），這一數字可間接表徵 cuBLAS 的潛在部署規模。

玩家對比

玩家	數學庫	硬體繫結	最佳化深度與成熟度	生態整合
NVIDIA	cuBLAS / cuBLASLt	僅 NVIDIA GPU，每代專用核函式	最高，20+ 代架構迭代，手工彙編級最佳化，epilogue 融合廣泛	PyTorch、TensorFlow、JAX 預設 Gemm 後端（截至 2024 年）
AMD	rocBLAS（ROCm 棧）	僅 AMD GPU（MI 系列）	中等，在 MIOpen 配合下可執行主流架構，但最佳化深度、稀疏支援和融合廣度存在差距	ROCm 生態，PyTorch 相容性持續改善但非預設
Intel	oneMKL（含 GPU BLAS）	Intel GPU（Ponte Vecchio 等）+ CPU	面向自家 GPU，生態尚在早期，庫成熟度與覆蓋率有待驗證	oneAPI 生態，PyTorch 支援預覽階段
開源/跨平台	OpenBLAS、BLIS	多 CPU 和部分 GPU，但無 NVIDIA GPU 最佳化	GPU 支援有限，效能遠低於廠商庫	部分架構可選後端（CPU）
編譯器生成	Triton、MLIR、OpenAI Triton	跨硬體（NVIDIA、AMD、部分其他）	通過自動調優編譯器生成核心，靈活性高，但在峰值利用率和工程深度上不如手寫 cuBLAS	PyTorch 2.x 的 torch.compile 可生成 Triton 核心，成為 cuBLAS 的潛在替代路徑
定製晶片	自研編譯器 + 數學庫（Cerebras、Graphcore、SambaNova 等）	完全自有硬體	繞過 cuBLAS 體系，效能取決於自有硬體設計，公開基準資料有限	不與 NVIDIA 生態相容，需遷移訓練棧

截至 2025 年初，公開可獲得的全面對比基準（涵蓋不同矩陣形狀、精度和融合模式，在相同代際硬體上標準化對比）未見釋出（來源：公開資料未見）。多數對比為零散評測或廠商選擇性公佈，全面對比需以第三方獨立機構的標準化基準為準。

風險

cuBLAS 雖然當前是深度學習底層代數的事實標準，但仍面臨多重中長期風險。

競爭庫與編譯器演進 Triton（OpenAI 釋出的開源核心編譯器）和 MLIR 生態正在逐步降低對廠商專屬庫的依賴。PyTorch 2.x 的 torch.compile 在部分場景下能將簡單的矩陣操作直接編譯為 Triton 核心，繞過 cuBLAS 呼叫。雖然當前 Triton 生成的複雜 GEMM 核心在峰值利用率和邊界場景處理上仍不如手寫 cuBLAS（來源：公開資料未見全面基準），但編譯器的自動最佳化能力呈上升趨勢。一旦架構層面的核心生成能覆蓋 80% 以上常見矩陣運算形狀且效能持平，cuBLAS 的鎖定效應將顯著弱化。

AMD ROCm 生態追趕 AMD 在 2023–2024 年間大幅增加 ROCm 開發投入，rocBLAS 的運算元覆蓋率、效能最佳化和架構整合度已在提升。如果 ROCm 在未來 2–3 年內能在主流架構中實現“開箱即用”且效能差距縮小至 10%–20% 以內，部分價格敏感型客戶可能會分流。

地緣政治與出口管制 美國對高階 GPU 的出口管制（2022 年 10 月起，2023 年 10 月更新）限制 NVIDIA 向特定國家/地區銷售資料中心 GPU。如果管制範圍或力度進一步擴大，會削弱 cuBLAS 所依託的硬體出貨基數，迫使受限市場加速自研替代方案，長期看會分裂 cuBLAS 的單一生態地位。

ASIC 與領域專用架構的衝擊 Google TPU、AWS Trainium/Inferentia 等自研 AI 晶片不依賴 cuBLAS，而是使用自有編譯器棧（如 Google XLA、AWS Neuron）。隨著雲端廠商加大自研晶片部署比例（如 Google 宣稱其內部大型模型訓練已大量使用 TPU v5），cuBLAS 可觸達的通用 GPU 工作負載佔比可能被侵蝕。不過截至 2024 年底，第三方機構（如 Liftr Insights）追蹤的雲端例項資料顯示，NVIDIA GPU 仍是 AI 例項絕對主力，ASIC 的侵蝕速度需持續觀察。

閉源風險 cuBLAS 作為閉源庫，其開發方向、架構最佳化優先順序和 bug 修復節奏完全由 NVIDIA 控制。如果 NVIDIA 未來調整 CUDA 許可條款、對特定行業或地區施加額外限制，或放緩對部分老架構的最佳化支援，依賴 cuBLAS 的下游將面臨被動適配壓力。

誤讀糾偏

誤讀 1：“cuBLAS 只做矩陣乘法” 實際 cuBLAS 完整實現了 Level-1（向量點積、縮放、旋轉）、Level-2（矩陣-向量乘法、秩更新）和 Level-3（矩陣-矩陣乘法）全套 BLAS 操作。深度學習中最頻繁觸發的是 Level-3 的 GEMM，但最佳化器中的權重更新（如 Adam 的 a * weight + b * grad）涉及 Level-1 操作，LSTM 等迴圈結構中的門計算也會用到 Level-2 操作。這些操作同樣由 cuBLAS 加速，並非“矩陣乘法獨佔”。

誤讀 2：“cuBLASLt 總是比傳統 cuBLAS 快” cuBLASLt 的優勢在於形狀不規則或需要 epilogue 融合的場景。但對於非常規整的大型矩陣（如 4096×4096 或 8192×8192），傳統 cuBLAS 通過手工精心最佳化的固定核函式可能仍然最優。cuBLASLt 的啟發式搜尋本身也需要時間，對於每次矩陣形狀都不同的動態圖（如某些樹模型或圖神經網路），搜尋開銷可能侵蝕收益，即時性場景需要快取管理策略來規避。

誤讀 3：“有了 Tensor Core，GEMM 就自動達到峰值” Tensor Core 對輸入矩陣的維度對齊和資料排布有嚴格要求（如分塊尺寸的整數倍）。如果矩陣尺寸不是滿足 Tensor Core 對齊要求的形狀（例如 M、N、K 不是 8 或 16 的倍數，具體數值因架構和精度而異），GPU 在硬體層面可能被迫回退到標量路徑或使用補零填充（padding），實際吞吐可能下降到峰值的 30% 以下（行業經驗值）。cuBLAS 的價值之一就在於對非理想形狀自動做填充、分段或變換，儘可能接近理論峰值，而非把硬體約束直接暴露給上層使用者。

誤讀 4：“cuBLAS 是開源軟體” cuBLAS 是閉源軟體，只有標頭檔案公開，實現細節不開放。下游開發者無法直接閱讀或修改其核心原始碼。這與 OpenBLAS、BLIS 等真正的開源 BLAS 實現不同。PyTorch 社群雖然能呼叫 cuBLAS，但看不到其內部實現。

誤讀 5：“cuBLAS 只跑在 NVIDIA GPU 上，所以是自然壟斷，沒競爭風險” 雖然 cuBLAS 本身只執行在 NVIDIA GPU 上，但替代路徑不是“寫出另一個 cuBLAS”，而是在上層通過架構抽象或編譯器（如 Triton、MLIR、JAX XLA）繞開對 cuBLAS API 的直接依賴。競爭發生在架構預設後端的層面，而非庫與庫之間的一對一替代。

最新事件

（注：以下事件基於截至 2025 年初的公開資訊，具體日期和數值以原始信源為準。）

• 2023 年 8 月 – NVIDIA GTC 主題演講（Hopper FP8 深度展示）：NVIDIA 公開 cuBLAS 對 FP8 GEMM 的效能資料，表明在 H100 GPU 上 FP8 GEMM 吞吐相較 FP16 接近翻倍（來源：NVIDIA GTC 2023 演講）。
• 2023 年 11 月 – PyTorch 2.1 將 cuBLASLt 設為預設 GEMM 後端：PyTorch 2.1（2023 年 10 月釋出）正式將 cuBLASLt 設為 CUDA 上的預設後端，理由是其在多種 Transformer 工作負載中的效能優勢（來源：PyTorch 官方釋出說明，2023）。
• 2024 年 3 月 – CUDA 12.4 釋出，新增 Blackwell 架構預覽支援：cuBLAS 隨 CUDA 12.4 增加了對 Blackwell 架構的早期支援，引入新的微縮放格式核心（來源：NVIDIA CUDA 12.4 釋出說明，2024）。
• 2024 年 5 月 – Triton 社群討論“無 cuBLAS 推論”：OpenAI Triton 社群提出完全用 Triton 生成 GEMM 核心替代 cuBLAS 呼叫的路線圖，PyTorch 團隊表示將探索在 torch.compile 中降低 cuBLAS 呼叫佔比的可行性（來源：PyTorch 開發者論壇公開討論，2024 年 5 月）。
• 2024 年下半年 – AMD ROCm 6.x 釋出：rocBLAS 增加對 FP8 訓練（E4M3/E5M2）和更多 epilogue 融合的支援，架構相容性顯著改善，但獨立基準評測未見全公開（來源：AMD ROCm 釋出說明，2024；公開資料未見第三方全面對比基準）。
• 2024 年 – 美國出口管制更新：美國政府於 2024 年進一步修訂晶片出口管制規則，部分國家/地區獲取高階 NVIDIA GPU 的難度上升（來源：美國商務部工業與安全域性公開檔案），這可能加快受限地區的國產 cuBLAS 替代品開發進度。

追蹤指標

技術層指標

• CUDA Toolkit 版本更新頻率及 cuBLAS 新增特性（留意 FP8/FP4 支援、新架構適配、epilogue 融合新增操作）。
• cuBLASLt 在 PyTorch/TensorFlow 中的預設啟用狀態和架構覆蓋度（關注架構釋出說明中對 GEMM 後端選擇的預設策略變化）。
• NVIDIA GPU 各代架構的 Tensor Core 理論峰值 TFLOPS 變化（通過 NVIDIA 白皮書定期更新）。
• MLPerf Training 與 Inference 基準中主流模型得分，cuBLAS 作為底層驅動庫的貢獻隱含其中（來源：MLCommons 官網，資料按輪次釋出）。

競爭層指標

• Triton 編譯器對 GEMM 的最佳化深度和架構整合度（關注 PyTorch torch.compile 的 GEMM 生成策略更新和社群基準）。
• AMD ROCm / rocBLAS 的版本更新、架構支援矩陣（如 PyTorch 官方釋出說明中對 ROCm 版本的正式支援宣告）。
• 雲端廠商自研 AI 晶片（Google TPU、AWS Trainium/Inferentia）在雲端例項型別中的比例變化（Liftr Insights、雲端廠商財報中 AI 例項的營收拆分）。

市場層指標

• NVIDIA 資料中心營收（季度財報，關注年增率和季增率增速，體現 cuBLAS 所附著硬體的出貨節奏）。
• 主要雲端廠商資本支出展望（Amazon、Microsoft、Google、Meta 的季度報告），作為下游 GPU 採購和部署的領先指標。
• CUDA 累計下載量或 CUDA 基礎 Docker 映象拉取量（非週期性公佈，NVIDIA 偶爾在 GTC 揭露）。
• 美國晶片出口管制政策的更新頻率與範圍調整（美國商務部工業與安全域性公報）。

產業層指標

• 大型模型引數規模增長趨勢以及模型架構變化（如 MoE 模型比例、序列長度趨勢），這些直接影響矩陣乘法的形狀分佈和對 cuBLAS 調優能力的需求。
• 行業會議上（如 GTC、NeurIPS、MLSys、ISCA）關於數學庫、深度學習編譯器、GPU 最佳化相關的論文和演講數量，可反映技術社群對 cuBLAS 路徑依賴與替代路線的研究熱度。

信源

• NVIDIA 官方文件：《cuBLAS Library》與《cuBLASLt 指南》（docs.nvidia.com/cuda/cublas/）
• NVIDIA 各代 GPU 架構白皮書（A100 白皮書 2020、H100 白皮書 2022、Blackwell 白皮書 2024）
• NVIDIA CUDA 工具包釋出說明（各版本，docs.nvidia.com/cuda/）
• NVIDIA GTC 主題演講及技術分會（2023、2024）
• PyTorch 官方釋出說明（pytorch.org，各版本）
• TensorFlow 官方文件中關於 GPU 後端的章節（tensorflow.org）
• AMD ROCm 文件與釋出說明（rocm.docs.amd.com）
• OpenAI Triton 專案文件與社群討論（GitHub）
• Mercury Research、Jon Peddie Research、IDC 資料中心 GPU 市場份額公開摘要
• MLCommons MLPerf 基準結果（mlcommons.org）
• NVIDIA 年度報告（FY2021–FY2024，NVIDIA 投資者關係頁面）
• 美國商務部工業與安全域性關於晶片出口管制的公開檔案
• 學術論文：《Dissecting the NVIDIA GPU Architecture via Microbenchmarking》（多版本更新）等 GPU 微架構逆向分析工作

（注：以上信源均為公開可獲得的一手資料。文中行業經驗值資料來自公開技術部落格和社群討論的交叉印證，未在學術期刊或廠商白皮書中形式化發表的，已標註“行業經驗值”；具體效能資料以各廠商最新白皮書和獨立基準為準。）