CUDA系统拆解-01-CUDA为什么存在：从计算负载到编程模型

本文是「CUDA系统拆解」系列第 01 篇。
系列导读：CUDA系统拆解-00-导读：从编程模型到 AI 推理系统的学习路线
下一篇：CUDA系统拆解-02-第一个CUDA程序：最小闭环与代码执行路径

1. 这篇解决什么问题

CUDA 到底是什么，它和 GPU、深度学习框架、高层加速库分别是什么关系。
为什么很多 AI 计算更适合 GPU，而不是 CPU。
CUDA 为什么会出现，它想解决的核心问题是什么。
为什么 CUDA 的编程模型强调“很多线程做相似的事”。
为什么做 AI Infra / 推理，最终很难绕开 CUDA。

2. 先记住的核心结论

CUDA 不只是 .cu 语法，而是 NVIDIA 提供的并行计算平台和编程模型。
GPU 的核心优势不是单线程更强，而是更擅长高吞吐并行计算。
CUDA 适合处理数据量大、并行度高、计算模式相对规则的问题。
CUDA 采用 thread / block / grid，本质上是在表达如何把大任务拆成很多相似小任务。
AI 推理系统虽然表面上在做调度、缓存和框架封装，但底层仍然要落到 CUDA 的执行和内存现实上。
学 CUDA 不能只背 API，关键是理解任务如何拆、数据如何流、性能为什么快或慢。

3. 正文讲解

3.1 CUDA 到底是什么

很多初学者容易把下面几层东西混在一起：

GPU：硬件
CUDA：并行计算平台和编程模型
cuBLAS / cuDNN / NCCL / TensorRT：建立在 CUDA 之上的高层库
PyTorch / TensorFlow：更上层的框架

先把关系理顺：

GPU 负责提供并行算力。
CUDA 负责把通用计算映射到 GPU 上执行。
高层库负责把常见计算封装成高性能实现。
深度学习框架负责进一步屏蔽底层细节，提供更高层接口。

所以，CUDA 不是单纯“写 kernel 的语法”，而是包含编译工具链、运行时、驱动接口、分析工具和底层加速库的一整套生态。

换句话说，框架可以屏蔽 CUDA，但不会消灭 CUDA。你在框架里写一句矩阵乘法，底层仍然可能在调 cuBLAS、Triton 或自定义 CUDA kernel。

3.2 CUDA 为什么会出现

CUDA 出现的背景很直接：很多计算问题虽然不是图形任务，但和图形渲染有相似特征。

这些问题通常有几个共同点：

数据规模大
操作重复多
并行度高
每个元素做的事情相对相似

例如：

向量计算
矩阵乘法
卷积
attention
各类 reduction

传统 CPU 当然也能算这些问题，但 CPU 的设计重点不是这里。CPU 更强调：

低延迟
单线程性能
复杂控制流
更强的分支和缓存体系

而这类 AI / HPC 问题更需要的是：让大量相似计算同时推进，把整体吞吐拉高。

GPU 最早为图形渲染而生，本来就擅长大规模并行处理。CUDA 的价值，就是把这种硬件能力开放给通用计算。

3.3 为什么 GPU 更适合这类计算

很多人会说 GPU 快是因为“核心多”，这只说对了一半。

更准确的说法是：

GPU 用更少的复杂控制能力，换取了更强的并行吞吐能力。

CPU 和 GPU 的设计目标不一样：

CPU 更像“精英小队”，适合复杂、变化多、决策密集的任务。
GPU 更像“大规模流水线”，适合大量重复、规则统一的任务。

因此 GPU 更擅长：

矩阵和张量运算
规则的批量计算
高吞吐场景

但 GPU 不一定擅长：

强串行依赖
分支极多的逻辑
非常随机的访存
任务规模很小的工作负载

所以“能并行”还不够，一个问题是否适合 CUDA，还要看任务规模、访存模式、控制流复杂度，以及数据搬运成本能不能摊薄。

3.4 CUDA 的设计目标是什么

CUDA 的目标，不是让你“把 CPU 程序原样搬到 GPU 上”，而是让你用一种适合 GPU 的方式表达并行任务。

它主要在做三件事：

第一，把大任务拆成很多相似的小任务。
这就是为什么 CUDA 的核心抽象不是普通函数调用，而是 thread / block / grid。

第二，在抽象和控制之间取平衡。
CUDA 没有把硬件细节完全隐藏掉。它给了你足够高层的并行抽象，但同时也保留了很多硬件相关控制能力，比如线程块大小、访存方式、同步、shared memory、stream 等。

第三，最大化吞吐，而不是只优化单个任务的延迟。
后面你会学到的 warp、occupancy、latency hiding、stream overlap，本质上都在服务这个目标。

3.5 为什么 CUDA 的编程模型是“很多线程做相似的事”

CPU 上常见的思路是：一个线程遍历全部数据。

CUDA 的思路是：让很多线程同时工作，每个线程处理一个或少量元素。

这样设计的原因很明确：

更符合 GPU 的硬件执行方式
更容易把数据并行展开
更容易用并发线程隐藏访存延迟
更容易把任务结构映射到硬件层级

它的代价也很明确：

你要自己考虑线程划分
要考虑边界判断
要考虑同步和访存效率
复杂控制逻辑会更难写

所以 CUDA 的难点和价值其实是同一件事：它更贴近硬件。

3.6 什么样的问题适合 CUDA

这是一个很重要的工程判断。

通常更适合 CUDA 的问题，往往同时满足下面几个条件：

数据量足够大
并行度足够高
很多元素执行相同或相似操作
计算量足以覆盖数据搬运和 kernel launch 开销
访存模式可以被较好地组织

典型例子包括：

向量计算
矩阵乘法
卷积
softmax
attention
各类 reduction

不太适合 CUDA 的问题，通常有这些特征：

任务规模太小
串行依赖很强
分支极其复杂
随机访存非常重
控制流主导，而不是数值计算主导

所以不能把“适合并行”和“适合 CUDA”简单画等号。真正的判断标准，是 GPU 的吞吐优势能不能覆盖掉调度、数据搬运和访存组织的代价。

3.7 先建立一条完整因果链

这篇最重要的不是记住几个定义，而是先建立下面这条因果链：

AI / HPC 中存在大量大规模、重复性强、并行度高的计算。
GPU 的架构更适合处理这类高吞吐任务。
CUDA 提供了把这些任务映射到 GPU 的编程模型和执行环境。
为了表达并行性，CUDA 采用 thread / block / grid。
为了真正跑快，后续还要继续处理 warp、内存层级、同步、occupancy、stream 等问题。
推理框架和推理引擎的上层优化，最终也都要落回这些底层现实。

只要这条链建立起来，后面你学到的每个概念都会有位置，不会变成孤立名词。

4. 和 AI 推理的关系

AI 推理系统表面上在谈：

batching
调度
KV cache
graph capture
并发请求管理

但真正吃算力和带宽的主体，仍然是张量计算：

GEMM
attention
softmax
layernorm / rmsnorm
activation

这些算子的性能，最终都要落到几个底层问题上：

kernel 怎么组织
数据怎么布局
显存怎么用
global memory 往返能否减少
stream 能否并发
launch overhead 能否压低

这就是为什么做 AI Infra / 推理，不能只停在框架接口层。你最终还是要理解 CUDA：否则很难真正解释一个系统为什么快、慢在哪里、还能怎么优化。

这也是为什么很多看起来是“系统层”的优化，最后都会落到 CUDA 视角：

fusion 要看能否减少 global memory 往返
graph capture 要看能否减少反复 launch 的 CPU 开销
KV cache 要看显存组织和读取代价
attention 优化要看数据布局、计算顺序和片上资源利用

推理系统的上层设计，最终都要服从底层执行现实。

5. 常见误区

CUDA 就是把 CPU 代码改成并行 for。不对，CUDA 有独立的执行模型、内存层级和性能瓶颈。
GPU 快只是因为核心多。不对，更核心的是架构取舍和吞吐导向。
只要任务能并行，就适合 CUDA。不对，还要看规模、访存模式、分支复杂度和数据搬运成本。
学会 API 就等于学会 CUDA。不对，真正关键的是理解为什么这样分工、为什么这样访存、为什么这样会快。
做 AI 推理只要会框架，不用懂 CUDA。不对，推理系统的关键优化最终都要落到底层执行和内存现实上。

6. 复习自测

CUDA 和 GPU、cuBLAS、TensorRT、PyTorch 分别是什么关系？
为什么很多 AI 计算更适合 GPU，而不是 CPU？
CUDA 为什么采用 thread / block / grid 这种组织方式？
什么样的问题通常适合 CUDA，什么样的问题通常不适合？
为什么说 CUDA 的重点不是“功能多”，而是“并行、吞吐、数据流”？
为什么 AI 推理系统的上层优化最终要落回 CUDA 的底层执行现实？