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 的直接上游包括以下层次，它们共同构成 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 的潜在部署规模。

玩家对比

截至 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 微架构逆向分析工作

（注：以上信源均为公开可获得的一手资料。文中行业经验值数据来自公开技术博客和社区讨论的交叉印证，未在学术期刊或厂商白皮书中形式化发表的，已标注“行业经验值”；具体性能数据以各厂商最新白皮书和独立基准为准。）