1、课程导论与硬件基础：为什么需要GPU推理加速？GPU架构简介（CUDA核心、Tensor Core、显存层次），量化模型推理的挑战与机遇
1.1 为什么我们需要GPU推理加速？
说实话，这个问题我经常被问到。尤其是刚入行的朋友，总觉得CPU也能跑模型，干嘛非得折腾GPU？
嗯，咱们先看一个简单的对比。假设你有一个BERT-base模型，参数量大概1.1亿。在Intel Xeon金牌处理器上跑一次推理，大概需要200-300毫秒。同样的模型，放到NVIDIA A100上，只需要5-8毫秒。差了将近40倍。
为什么会这样？
CPU的设计哲学是「全能选手」。它要处理操作系统调度、IO中断、数据库查询、网页渲染……什么活都得干。所以CPU把大量晶体管用在了分支预测、乱序执行、大容量缓存上。说白了，CPU擅长处理复杂的、串行的、依赖强的任务。
但深度学习推理不一样。它本质上是大量的矩阵乘法、卷积运算。这些运算的特点是：数据并行、计算密集、控制逻辑简单。你想想看，一个矩阵乘法，无非就是乘加运算重复几百万次。这种活儿，让CPU一个个核心慢慢算，太浪费了。
我在项目中遇到过这样一个场景：客户要把一个实时语音识别模型部署到服务器上，要求延迟低于50毫秒。用CPU跑，单路延迟120毫秒，根本没法用。换成T4 GPU，延迟直接降到18毫秒。客户当场就拍板了。
所以，GPU推理加速的核心价值就两点：降低延迟和提高吞吐。对于在线服务来说，延迟就是用户体验；对于离线批处理来说，吞吐就是成本。
核心结论：当你的模型需要处理大量并行计算时，GPU是性价比最高的选择。CPU适合做控制面，GPU适合做数据面。
1.2 GPU架构速览：CUDA核心、Tensor Core、显存层次
很多同学一上来就学CUDA编程，结果被各种概念搞晕了。我个人习惯是，先搞清楚GPU的硬件长什么样，再去看软件怎么用。这样你写代码的时候，脑子里能浮现出数据在硬件上是怎么流动的。
1.2.1 CUDA核心：GPU里的「普通工人」
CUDA核心是NVIDIA GPU最基本的计算单元。你可以把它理解成一个简化版的CPU核心——能做整数运算、浮点运算、逻辑判断。但它没有CPU那么复杂的控制单元和缓存。
一个A100 GPU有6912个CUDA核心。这么多核心同时工作，就是GPU并行能力的来源。
但要注意，CUDA核心虽然多，每个核心的能力其实很弱。它一次只能处理一个浮点运算。所以，如果你让每个CUDA核心干不同的活儿，效率反而不高。最好的方式是让所有核心干同样的活儿——这就是SIMT（单指令多线程）的精髓。
我曾经踩过一个坑：在写自定义算子的时候，让不同的线程执行不同的分支。结果性能惨不忍睹。后来一分析，发现是线程束（warp）内的线程发生了分支发散。嗯，这个后面我们会详细讲。
1.2.2 Tensor Core：专为AI打造的「特种兵」
Tensor Core是NVIDIA从Volta架构开始引入的专用硬件单元。它专门用来加速矩阵乘法和卷积运算。
为什么需要Tensor Core？
你想想看，一个普通的CUDA核心，一次只能做一个乘加运算（FMA）。但一个Tensor Core，一次可以做一个4×4矩阵乘法，也就是64个乘加运算。效率直接翻了64倍。
以A100为例，它每个SM（流多处理器）有4个Tensor Core。每个Tensor Core每个时钟周期可以执行1024个FP16的乘加运算。算下来，A100的Tensor Core算力高达312 TFLOPS（FP16），而CUDA核心的算力只有19.5 TFLOPS（FP32）。差了16倍。
所以，量化模型推理加速的核心，就是尽可能把计算从CUDA核心迁移到Tensor Core上。
| 架构 | CUDA核心算力(FP32) | Tensor Core算力(FP16) | Tensor Core算力(INT8) |
|---|---|---|---|
| V100 | 15.7 TFLOPS | 125 TFLOPS | 不支持 |
| T4 | 8.1 TFLOPS | 65 TFLOPS | 130 TOPS |
| A100 | 19.5 TFLOPS | 312 TFLOPS | 624 TOPS |
| H100 | 60 TFLOPS | 1000 TFLOPS | 2000 TOPS |
实战技巧：在TensorRT或者CUDA编程中，尽量使用INT8或者FP16精度。这样能触发Tensor Core加速。我见过很多团队，模型量化到INT8了，但算子还是用FP32的CUDA核心跑，结果加速效果大打折扣。
1.2.3 显存层次：数据搬运的艺术
GPU的显存结构，说白了就是一个金字塔。从上到下，容量越来越大，速度越来越慢。
- 寄存器（Register）：每个线程私有，速度最快，容量最小（每个线程最多255个32位寄存器）
- 共享内存（Shared Memory）：同一个线程块内的线程共享，延迟约20-30个时钟周期，容量通常48KB-164KB
- L1/L2缓存：硬件自动管理，L1延迟约30-40周期，L2延迟约200-300周期
- 全局内存（Global Memory）：所有线程都能访问，容量最大（几十GB），但延迟高达400-800周期
我在项目中遇到过这样一个问题：一个卷积算子的性能始终上不去。后来用NVIDIA Nsight分析，发现全局内存的访问效率只有30%。原因是数据没有做合并访问（coalesced access），导致大量带宽浪费。
嗯，这里要注意：GPU的算力很强，但显存带宽是瓶颈。很多模型推理慢，不是因为计算不够快，而是因为数据搬运太慢。所以，量化模型不仅能减少计算量，还能减少数据搬运量——INT8的数据量只有FP32的四分之一。
避坑指南：我曾经在量化一个BERT模型时，只关注了计算层的量化，忽略了Embedding层的显存占用。结果模型虽然计算快了，但Embedding查表还是用FP32，导致显存带宽被占满，整体加速比只有1.5倍。后来把Embedding也量化成INT8，加速比直接到了3倍。
1.3 量化模型推理的挑战与机遇
量化，说白了就是把模型从FP32压缩到INT8甚至INT4。好处很明显：模型变小了，计算变快了，功耗降低了。但挑战也不少。
1.3.1 机遇：为什么量化是必由之路？
我给大家算一笔账。一个ResNet-50模型，FP32版本大概98MB。量化到INT8后，只有25MB。这意味着什么？
- 显存占用减少75%：同样的GPU可以塞下更多模型实例
- 带宽需求降低75%：数据搬运更快，延迟更低
- Tensor Core加速：INT8的Tensor Core算力是FP16的两倍
在实际部署中，量化几乎是必选项。我参与过的项目，从云端到边缘端，没有一个是不做量化的。尤其是边缘设备，算力有限、带宽有限、功耗有限，量化是唯一的选择。
1.3.2 挑战：精度损失与硬件适配
量化最大的挑战就是精度损失。FP32有23位尾数，INT8只有8位。你想想看，精度差了三个数量级。
常见的精度损失来源有：
- 激活值分布不均匀：有些层的激活值集中在很小的范围内，量化后信息丢失严重
- 异常值（Outlier）：个别值特别大，导致量化步长被拉大，大部分值被压缩到几个离散值上
- 跨层误差累积：每一层都有量化误差，层层叠加，最终导致模型输出偏差
我曾经在量化一个Transformer模型时，遇到了严重的精度问题。模型在FP32时准确率92%，量化到INT8后直接掉到85%。后来排查发现，是Self-Attention层的Softmax输出分布太集中，量化后信息丢失严重。解决方案是做了逐通道量化（per-channel quantization），把准确率拉回到了91.5%。
另一个挑战是硬件适配。不同GPU对量化的支持不一样。T4支持INT8的Tensor Core，但V100就不支持。H100支持FP8，但A100不支持。所以，量化方案必须和硬件绑定。你不能指望一套量化方案通吃所有GPU。
我的建议：做量化之前，先搞清楚目标硬件的规格。查一下它支持哪些精度、Tensor Core的算力是多少、显存带宽是多少。这些数据在NVIDIA官网上都能查到。别等到模型量化完了，才发现硬件不支持。
1.4 本章知识体系总览
下面这张图，是我自己总结的本章知识体系。你可以把它当成一个地图，后面每讲一个知识点，都能在这张图上找到位置。
这张图把本章的三个核心模块串起来了。左边是「为什么需要GPU加速」，中间是「GPU架构」，右边是「量化推理的挑战与机遇」。底部是我个人的总结：理解硬件、选择精度、优化数据搬运。这三件事做好了，量化推理加速就成功了一大半。
好了，这一章的内容就到这里。后面我们会深入每个知识点，从CUDA编程到量化算法，一步步带你实战。