今天说“显卡”，很多时候已经不只是指游戏画面。大模型训练、推理服务、科学计算和视频处理，都在使用显卡里的 GPU 完成计算。于是，显卡、GPU、CUDA 这几个词经常被放在一起讨论，但它们属于不同层次：显卡是一块完整的硬件产品，GPU 是显卡上的计算芯片，CUDA 是 NVIDIA 为自家 GPU 建立的软件平台。
理解这三个概念，还需要把它们放回一条完整链路中：芯片由谁设计和制造，GPU 为什么适合并行计算，程序如何把任务提交给 GPU，以及 CUDA 为什么形成了很强的生态壁垒。
一块 GPU 是怎样变成产品的
GPU 产品背后通常有多类公司参与。NVIDIA、AMD、Intel 等公司负责设计 GPU 架构，决定计算单元、缓存、显存控制器、互联和指令执行方式；EDA 厂商提供芯片设计与验证工具；晶圆代工厂按照设计版图制造芯片；封装测试厂把芯片、显存和基板组合起来；板卡厂商再完成 PCB、供电、散热和接口设计。
台积电（TSMC）是先进制程和大规模晶圆制造的重要参与者，但它不是 GPU 产业链的全部。AI 加速器还高度依赖 HBM 等高带宽显存、先进封装、封装产能和良率。对数据中心 GPU 来说，能否把复杂设计稳定地制造出来，并持续交付足够数量的产品，与芯片架构本身同样重要。
这里描述的是产业分工，实际企业可以跨越多个环节：例如 Intel 自身也有晶圆制造业务，不能把所有 GPU 公司都理解为纯设计公司。
国产 GPU 和 AI 加速器也处在这条产业链中。国内企业有的做通用 GPU，有的面向训练或推理加速，有的提供完整软硬件平台。它们的指令集、编程模型和产品定位并不完全相同，因此“国产 GPU”不是一种统一架构。用户最终能否采用某个平台，还要看驱动、编译器、算子库、通信库、框架适配和集群工具是否完整。
GPU 为什么能并发计算
硬件制造出来之后，下一个问题是：这些计算单元为什么适合训练模型？可以先从一个简单任务看起——把两个各有一百万个元素的数组相加。每个位置的加法彼此独立，程序可以把它们分给许多计算单元同时执行。
CPU 通常只有少量高性能核心。每个核心擅长处理复杂控制、分支判断和低延迟任务；GPU 则把更多芯片面积和功耗预算用于大量相对简单的计算单元、寄存器和内存通路。GPU 的优势来自计算单元的规模和吞吐量，而不是单个核心比 CPU 核心更强。
矩阵乘法、卷积、向量运算和图像处理都有相似特点：同一套规则会被应用到大量数据上。GPU 可以把这些数据拆成很多线程，让一组线程同时执行相似指令。NVIDIA 把这种执行方式称为 SIMT（单指令、多线程）；其他 GPU 也有相近的并行执行思想。
并行计算能否获得高性能，还取决于数据访问方式。线程需要尽量连续地访问显存，重复使用的数据可以放进更快的片上存储，硬件则通过同时安排多组线程来隐藏内存访问延迟。**当任务规模足够大、线程之间的工作足够相似时，GPU 才能把大量计算单元持续填满。**任务太小、分支太多，或者 CPU 与 GPU 之间频繁复制数据，都会削弱加速效果。
核心数量为什么会影响价格
这里的“GPU 核心”通常指厂商统计的算术执行单元，并不等于一个完整的 CPU 核心。核心数更适合在相近架构和同类产品之间比较，不能直接拿不同厂商的数字判断快慢。
在相近制程和架构下，更大的计算核心规模通常意味着更多晶体管、更大的芯片面积、更高的晶圆成本，以及更复杂的供电、散热和显存系统。数据中心产品还可能使用 HBM、先进封装和更严格的可靠性验证。于是，核心数量和核心规格既影响理论算力，也会影响芯片成本、产品定位和售价。
不过，价格不是核心数量的简单函数。同一代芯片常常会屏蔽部分核心、调整频率和显存配置，形成不同档位；制程良率、显存容量、封装产能、品牌定位和市场供需也会改变最终价格。因此更准确的说法是：核心规模是定价的重要变量之一，但不是唯一变量。
从图形渲染走向通用计算
大量数据执行相似运算，原本就是图形处理的需求。例如，一张图片上的许多像素都需要进行颜色和光照计算。人们随后发现，这种能力也适合处理矩阵、模拟物理过程，于是开始用 GPU 执行图形之外的任务，这就是 GPGPU，即 GPU 通用计算。
在主要开放图形接口的早期可编程 GPU 上，开发者常常需要把计算包装成渲染操作：把数组存成纹理，把运算写进像素着色器，再绘制一个覆盖输出区域的矩形，将结果写入输出纹理。例如，两个数组相加可以被表达为“读取两张纹理对应位置的数值，相加后写出”。NVIDIA 的《GPU Gems 2》第 31 章详细记录了这类映射方法。[1]
这里的“渲染”是触发运算和存储结果的手段，结果不必显示在屏幕上。借用图形管线只是早期 GPGPU 的实现方式，GPGPU 这个概念也包含今天通过专用计算接口执行的任务。
后来，GPU 厂商和标准组织逐步提供了面向通用计算的接口。CUDA、OpenCL、ROCm/HIP、oneAPI/SYCL 都可以直接描述计算任务；Vulkan Compute 和 DirectX Compute Shader 也能通过图形 API 中的计算管线派发任务。使用 Compute Shader 时，程序可以直接创建计算资源和线程组，不需要绘制三角形，也不需要生成最终画面。
因此，“没有 CUDA”有两种完全不同的情况：
- 如果只有早期图形接口可用，确实可能需要把计算包装成纹理、着色器和渲染操作。
- 如果平台提供 OpenCL、HIP、SYCL、计算着色器或厂商自己的 Runtime，就可以直接提交通用计算任务，不必转成图形渲染。
Khronos 的计算着色器文档也明确区分了计算任务与常规渲染管线。[2] 没有 CUDA，不代表必须绕回图形渲染；关键在于目标 GPU 和驱动提供了哪些计算接口。
既然选择不止一种，CUDA 的特殊之处在哪里？这就需要从“能否提交计算”继续看到“能否方便、高效地完成整个应用”。
CUDA 提供了什么
CUDA 是 NVIDIA 的 GPU 并行计算平台。它把硬件能力包装成开发者可以使用的软件栈，包括：
- 编程模型：用线程、线程块和网格描述并行任务。
- Runtime API：提供
cudaMalloc、cudaMemcpy、设备管理、流和事件等接口。 - 驱动接口：负责上下文、模块和设备操作。
- 编译工具链：把 CUDA C++ kernel 编译为 NVIDIA GPU 能执行的代码。
- 计算库：cuBLAS 用于矩阵运算，cuDNN 提供深度学习算子，NCCL 负责多 GPU 通信。
开发者可以直接写 CUDA C++，也可以通过 PyTorch、TensorFlow、JAX 等框架间接使用 CUDA。大多数 AI 应用开发者采用后者：Python 代码负责组织模型，框架再把矩阵乘法、卷积和通信操作交给 CUDA 及其计算库。
PyTorch 开发者实际如何使用 GPU
PyTorch 是开源的深度学习框架，提供 Tensor、自动求导、神经网络模块和优化器。继续看矩阵乘法：开发者在 Python 中表达张量运算，并把张量和模型放到目标设备，框架负责调用对应后端。对 NVIDIA GPU，常见矩阵运算会使用 cuBLAS；卷积等操作可能使用 cuDNN；其他算子也可能由框架自带或生成的 kernel 完成。
写模型的人通常不需要亲自编写 GPU kernel，但模型能否高效运行，仍依赖底层软件栈。 典型调用链可以表示为：
Python / PyTorch 模型
↓
Tensor 运算（训练时还涉及自动求导）
↓
对应设备后端、计算库与 kernel
↓
Runtime 与驱动
↓
GPU 硬件因此，普通 AI 应用开发者通常不需要手写 CUDA。只有在开发自定义算子、训练框架、推理引擎或 GPU 性能优化时，才需要深入 kernel、内存层级、线程模型和编译器。
这也解释了为什么“PyTorch 开源”和“底层依赖某家 GPU”可以同时成立：框架允许接入不同设备，但具体的算子、扩展和优化仍需要对应后端支持。PyTorch 的 ROCm 实现甚至复用了 torch.cuda 接口名称，底层却使用 HIP/ROCm。[5] 上层调用形式相近，不代表底层运行的是 NVIDIA 的 CUDA 实现。
CUDA 为什么形成了强大的生态壁垒
从应用开发者的视角看，真正需要的是模型能跑、结果可靠、性能达标。CUDA 长期积累的计算库、框架适配和工具，恰好围绕这些需求形成了完整的软件网络。模型作者、算子开发者、框架维护者、云服务商和工具厂商都围绕 NVIDIA GPU 进行适配和优化。一个团队使用 CUDA 时，依赖的往往不只是几行 API 调用，还包括自定义 kernel、cuBLAS/cuDNN、NCCL、多机训练脚本、性能分析工具和大量工程经验。
NVIDIA 官方 CUDA 软件栈面向 NVIDIA GPU，并不是一个可以直接驱动任意厂商 GPU 的通用后端。官方 CUDA 页面将 Toolkit 描述为面向 NVIDIA GPU 加速应用的编译器、运行时、库和开发工具；CUDA EULA也对 SDK、驱动和生成代码的使用设定了许可边界。
这会形成一个持续强化的循环：更多软件针对 CUDA 优化，用户就更倾向于选择 NVIDIA GPU；用户规模越大，开发者越愿意优先支持 CUDA；替代平台也就越难吸引应用迁移。 这就是软件生态如何反过来增强硬件竞争力。
这种软硬件依赖通常被称为 厂商锁定（vendor lock-in）。法国竞争管理局在 2024 年 6 月 28 日发布的生成式 AI 竞争分析中，明确表达了对行业依赖 CUDA 的担忧。[3] 这份文件支持讨论 CUDA 的竞争壁垒，但它本身是一份行业分析，并非认定 CUDA 构成违法垄断的判决。
国产 GPU 为什么要兼容 CUDA
国产 GPU 厂商选择 CUDA 兼容路线，核心原因就是 CUDA 生态已经存在，客户的软件投入也已经存在。一个训练团队可能已经用 PyTorch、CUDA 算子和 NCCL 跑通了多机训练。如果换到另一种 GPU，除了换硬件，还要迁移算子、重新验证数值精度、调整通信方式、重新做性能优化，并确认系统可以长时间稳定运行。迁移成本和交付风险，可能比芯片采购价本身更影响客户决策。
因此，选择 CUDA 兼容路线的厂商，会通过相近的接口、源码迁移工具、计算库替代和框架适配，让已有软件尽量少改动就能运行。另一些平台主要建设自己的软件栈，通过框架层承接模型。共同的商业目标是降低客户迁移成本，兼容 CUDA 是实现这一目标的一条路线。
实现兼容时，上层程序关注的是接口及其行为。例如，调用 cudaMalloc 或 cudaMemcpy 的代码在编译时使用头文件声明，链接和运行时使用相应的库，并不需要读取库内部源码。CUDA 的 API 文档公开，也不意味着 Runtime、驱动和硬件实现全部开源。兼容平台需要在自己的硬件上实现对应行为，并补齐编译器、驱动和计算库。
跨平台实现还受到许可条件的约束：CUDA EULA 第 1.2 节限制为了转向非 NVIDIA 平台而对 SDK 生成的输出进行逆向、反编译或反汇编。[4] 这项条款针对特定行为，不能直接等同于禁止所有独立接口实现。
这类兼容需要分层理解：
| 兼容层次 | 含义 |
|---|---|
| API 兼容 | 函数名、参数、错误行为和调用方式相近 |
| 语义兼容 | 内存、同步、线程和计算结果符合预期 |
| 框架适配 | PyTorch、ONNX Runtime 等能把算子转发到目标设备，但这本身不等于 CUDA API 兼容 |
| 二进制兼容 | 已为 NVIDIA 架构编译的目标代码可以直接执行 |
前几种兼容可以通过重新实现 Runtime、驱动、编译器和计算库来完成；二进制兼容则困难得多。CUDA 源码通常需要转换和重新编译，面向特定 NVIDIA 架构的 cubin 也不能被视为任意 GPU 都能直接执行的通用代码。所以，“兼容 CUDA”通常意味着上层软件容易迁移，并不自动意味着 NVIDIA 的二进制和性能可以原样复制。
结语
GPU 的并行计算能力首先来自硬件结构：大量计算单元、适合并行的执行方式和高带宽内存系统。早期开发者曾经借助图形渲染管线使用这些能力，后来才出现 CUDA、OpenCL、ROCm、SYCL 和各种计算接口，让程序可以直接提交通用计算任务。
CUDA 的真正影响力，在于它把 NVIDIA GPU、编译器、驱动、Runtime、计算库和深度学习框架连接成了成熟生态。国产 GPU 向 CUDA 靠拢，主要是为了接住已经存在的软件、人才和工程投入，降低客户迁移硬件时的成本。理解这条链路，就能同时看懂 GPU 的硬件价值、CUDA 的软件价值，以及 AI 芯片竞争为什么最终会落到生态上。