GPU 并行编程的基本原理与入门实践指南

引言：先建心智模型，再学语法

深度学习的训练与推理、科学计算、图像处理、大规模数据分析，底层都离不开大规模并行计算。无论你使用本地 GPU 服务器，还是使用云上 GPU 算力实例（各大云服务商，包括百度智能云，均提供此类通用算力产品），底层的编程原理是同一套。很多入门资料直接从 API 语法开始教，读者往往“会写但不懂”，一旦遇到性能问题便无从下手。本文反其道而行：先建立硬件与执行模型的心智模型，再谈上手路径。为照顾易读性，部分表述做了简化，严谨定义请以所用 GPU 平台的官方架构文档为准。

一、换一种思维方式：吞吐量优先的大规模并行

CPU 的设计目标是尽可能降低单个任务的延迟：少量功能强大的核心、复杂的分支预测、深层级缓存、乱序执行。GPU 则完全相反：它牺牲单线程性能，换来数量惊人的计算核心，目标是让海量“同质”任务同时推进，最大化吞吐量。

一个直观类比：CPU 像几位资深教授，什么难题都能解，但一次只能带几个学生；GPU 像上千名训练有素的学生，每个人只做相对简单的题，但同一时刻能处理成千上万道同类题目。如果你的问题可以拆成大量“长得差不多”的独立小任务，GPU 就是利器；反之，高度串行、分支复杂的逻辑仍更适合 CPU。

因此，GPU 编程可以粗略理解为“规模放大了三个数量级的多线程编程”，但有几个全新的特点：线程数量极多、线程被成组调度、存储层级更深、性能取决于访存模式而非指令条数。这些新特点正是学习的重点。

二、全局视角：GPU 芯片的结构

从芯片层面看，一块现代 GPU 就是一个多核结构。业界通常把 GPU 内部的基本计算单元称为流式多处理器（SM），主流数据中心级 GPU 通常集成上百个 SM。入门阶段可以简单地把一个 SM 理解为“一组核”，类似 CPU 里的一个核心，只不过 GPU 里有上百个这样的“核心”，而且每个“核心”内部还能同时驻留成百上千个线程。

所有 SM 都要读取数据才能计算，数据主要来自两级：

• 显存（DRAM，编程模型中称为全局内存）：容量大（常见为数十 GB），但离计算单元远，访问延迟高；
• 片上 SRAM（如二级缓存）：容量小（通常为几十 MB 量级），速度快得多。

由此得到第一条重要的性能直觉：GPU 程序优化的核心之一，是尽可能提高片上缓存的命中率，减少对慢速显存的反复访问。 这一点与 CPU 的缓存优化思路相似，区别在于：CPU 上硬件与编译器已替程序员做了大部分工作，一般不太需要操心；而在 GPU 上，访存模式主要由你的线程组织方式决定，程序员必须主动配合硬件。

三、走进 SM 内部：两类计算资源

把 SM 放大看，它内部通常划分为若干子分区，每个子分区包含两类计算资源：

1. 通用标量计算单元。即各种位宽的算术逻辑单元（ALU），例如整数、单精度浮点、双精度浮点等，负责执行一般意义上的标量算术与逻辑运算，也就是 CPU 也能做的那类计算。
2. 专用矩阵计算单元。主攻矩阵乘法的加速单元。神经网络训练与推理的绝大部分计算量都归结为矩阵乘法，因此其吞吐量远高于用标量单元逐个累加。背后经典的电路组织方式是脉动阵列：让数据在单元阵列中有节奏地流动、在流动过程中被反复使用，从而以极低的访存开销完成乘加流水线。这一结构由体系结构学界在二十世纪七十年代末提出，至今仍是各类矩阵加速器的主流设计思想之一，建议学有余力的读者扩展阅读。

此外，每个子分区还配有线程束调度器，这是下一节的关键角色。

四、线程如何被组织与调度：线程束与 SIMT

GPU 的线程模型是分层的：整个计算任务构成网格，网格由若干线程块组成，每个线程块可包含数百至上千个线程（上限依架构而定）。硬件层面，线程不是逐个独立调度的，而是打包成组：

• 调度器把线程按固定粒度打包管理，常见粒度为 32 个线程一组（个别架构为 64），这一组线程称为线程束（warp）；
• 同一线程束内的所有线程在同一时刻执行同一条指令，只是各自处理不同的数据。这种“单指令、多线程”的执行方式常被称为 SIMT，其思想根源是并行计算中经典的 SIMD（Single Instruction, Multiple Data，单指令多数据）架构。

这个设计带来两条极其重要的编程启示：

其一，线程应当“同质化”。 既然一组线程必须执行同一指令，那么同一线程束内的线程若因数据不同走向不同分支，硬件就只能把两条分支都执行一遍、再丢弃无效结果，即所谓分支分化，会直接浪费一半甚至更多算力。写核函数时应尽量让相邻线程走相同路径。

其二，延迟靠“切换”掩盖，而非靠缓存等待。 当某个线程束在等待慢速显存返回数据时，调度器会立刻切换到另一个就绪的线程束继续计算。换言之，GPU 不追求缩短单个线程的等待时间，而是靠同时驻留大量线程把等待时间“填满”。因此线程块里要开足够多的线程、让 SM 上驻留足够多的线程束——这是新手最容易忽视、却对性能影响最大的因素之一。遗憾的是，线程束调度恰恰是很多入门课程没有展开讲的概念。

五、分层存储与关键优化原则

把前面几点合起来，就得到 GPU 的完整存储层级：寄存器（最快、每线程私有）→ 共享内存/一级缓存（线程块内共享）→ 二级缓存（所有 SM 共享）→ 全局内存（容量最大、最慢）。由此派生出几条实践中反复出现的优化原则：

1. 合并访存：让一个线程束内的 32 个线程访问相邻内存地址，硬件就能把它们合并成尽量少的传输事务；若相邻线程访问的地址彼此跳跃，带宽利用率会断崖式下跌。
2. 分块复用：把被反复使用的数据从全局内存一次性搬进片上共享内存，在块内充分复用后再写回。以矩阵乘法为例，朴素的每线程实现需要对全局内存做大量重复读取；分块后，每个数据载入片上即可被整块线程复用，全局内存流量成倍下降。
3. 足够的并行度：线程数要远多于核心数，调度器才能在访存等待时切换到其他线程束。
4. 别忽视传输：主机内存与显存之间的拷贝往往比计算本身更慢，应减少拷贝次数、增大单次拷贝规模，或让数据尽量长驻显存。

六、最小可运行示例：向量加法

理解原理后，第一个程序应当足够简单。以向量加法为例（语言无关的伪代码，展示各类 GPU 编程模型共通的结构）：

// 核函数：由每个线程各执行一份
kernel VectorAdd(float a[], float b[], float c[], int n):
    i = 线程块编号 * 每块线程数 + 块内线程编号   // 全局线程索引
    if i < n:                                    // 边界检查
        c[i] = a[i] + b[i]
// 主机端启动配置
每块线程数 = 256
线程块数   = ceil(n / 256)
启动核函数 VectorAdd，配置为 (线程块数, 每块线程数)

逐行拆解：

• 索引计算是 GPU 编程的灵魂：把“一维线程编号”映射到“数据下标”，绝大多数核函数的第一行都是某种形式的索引映射；
• 边界检查是因为线程块数向上取整后会多出一些线程，必须防止越界；
• 启动配置决定并行度，256 这类值通常是经验起点，实际应结合占用率与剖析结果调整；
• 完整流程还包括主机端分配显存、拷入数据、启动核函数、拷回结果，这个“分配—拷贝—计算—拷回”的骨架，几乎所有入门程序都一样。

写完之后务必做两件事：与 CPU 结果逐元素比对验证正确性；用计时工具测量带宽利用率，判断程序“好不好”。

七、建议的入门路径

1. 跑通骨架：完成向量加法，熟悉“主机—设备”流程与线程层次概念。
2. 理解调度：写一个并行归约（求和）程序，亲身体会分支分化与线程束粒度的影响。
3. 掌握存储层级：实现共享内存版矩阵转置，对比合并与非合并访存的带宽差异。
4. 学会测量：熟悉所用平台的性能剖析工具（各家 GPU 平台均有官方剖析器），关注带宽利用率、占用率、分支分化等指标，养成“先测量、再优化”的习惯。
5. 挑战矩阵乘法：手写分块矩阵乘法，逐步逼近成熟算子库的性能，把前四步的知识点串联起来。
6. 读优秀实现：业界主流高性能线性代数算子库把上述技巧工程化到极致，其设计文档与技术博客是极好的进阶材料；此时再回头看最初觉得晦涩的资料，会有豁然开朗之感。
7. 回到业务：把学到的模型套用到自己的算子上，无论是深度学习、推荐系统还是科学计算。

八、新手常见误区清单

• 把 GPU 当“快一点的 CPU”用：只开几十个线程，硬件大量闲置；
• 频繁的小规模主机—设备拷贝：传输时间远超计算收益；
• 随机或大跨步访存：带宽利用率低下，计算单元大部分时间在等数据；
• 线程束内分支林立：算力被无效分支消耗；
• 拍脑袋定线程块配置：不结合占用率与寄存器用量；
• 过早优化：不做剖析就凭直觉改代码，往往南辕北辙。

结语

一句话总结 GPU 并行编程的心智模型：海量同质线程、成组调度执行、分层存储供给、以吞吐为中心。 先把这张“地图”刻在脑子里，再去学具体平台的语法与 API，你会发现那些看似零散的知识点都能各归其位。本文为照顾易读性对部分细节做了简化，动手实践时请以所用 GPU 平台的官方架构文档与编程指南为准。