前言
这几天，GTC2020上，Nvidia发布了最新的Ampere架构。Ampere架构的改进重心，大部分放在AI上的改动，包括第三代的Tensor Core，以及相关的调度性能，以及互联等。它展示了在加强算力，特别是TC （TC == Tensor Core，下同）算力的情况下，整个系统的改进。
整体上，可以看到NV的GPU向向AI方向快速发展，看起来跟随市场的必然选择。转去吃AI芯片的蛋糕。原CUDA Core并行度增加放缓，A100所有大的改动，看起来都是以AI计算为主要目的，所以Tensor Core以及SM里AI加速的模块和功能大大加强。在数据中心AI芯片这块，弯道超车时间快结束了。基本上大家都回到了vector+tensor混合架构上的直线竞争。
这样，GPGPU逐渐成为了通用和专用混合的架构形态
•Core 架构：CUDA vector core + Tensor core
•Memory system：传统的cache system + AI memory system
•Scale and connection：scale up + scale out in one GPU
•Program Model：original CUDA + WMMA
异构的难题在于利用率上：NV的一些提高效率的改变，包括
•资源动态分配，L1C, L2C, MIG
•软硬件结合
这样，软件栈任务更重了。
因为我一直在GPU/AI软件架构方面工作，我会比较多的从软硬件结合，编程模型，软件上层应用的角度出发来考虑问题。希望给大家不同的视野。
下面从几个方面来学习和思考：
- 核心算力
-
- A100如何大幅度提升算力？
- 数据带宽
-
- 如何解决算力高涨下的带宽问题？
- 计算效率
-
- 如何提高计算效率？
核心算力
A100的算力提升主要集中在AI应用需要的FP16精度以下的类型。
- 传统FP32和FP64只有1.25x的增长。
- FP16有了2.5x的增长 （both CUDA core and Tensor core）
- 通过TF32的引入，让FP32（应用层）的数据处理大幅提升
- 再通过Sparsity的优化，对TC的几个数据类型又double了算力
Tensor core精度
- TF32 TC
-
- FP16/FP32的混合精度训练问题比较多，使用很麻烦，给软件栈和框架都带来不小的难题。（大家可以看一下混合精度训练的实现和问题一些材料）
- FP32 in/out的计算复杂，算力小
- TF32 TC能很好的解决FP16/FP32的混合精度的问题，又能以较小的代价，获得比较好的精度。
Fine-grained structured sparsity
非常棒的一个“快速”解决方案。之前我们关于AI芯片加速sparsity的优化想法，都是局限在"被动"sparsity的方面，也就是上层应用和框架主动做剪枝以后，针对稀疏矩阵做被动的优化。难度很大。原因是各种剪枝出来的数据没有共同特性，因此硬件上很难实现通用的加速。
A100的方法，是主动（由软件）提供固定结构化的剪枝，对训练好后的Dense权重剪枝后，再稍做Fine-tuning，这样得到的稀疏矩阵可以直接使用针对这一特定结构的压缩，硬件加速推理。获得近乎两倍的性能提升。精度方面，50%的剪枝，应该能保证足够的精度。他们应该是论证过的。
整个方法是比较典型的软硬件结合的思路：
- 软件提供包装好的4选2的剪枝方案，（软件实现，可升级算法，结合硬件）
- 简单的Fine-tuning训练
- 压缩剪枝后的weight，得到非零数据和Index，用于推理
- 提升
-
- 减少一半MMA计算
- weight数据，从host->device就开始节省带宽
- activation
-
-
- 根据不同的实现，可以节省L1开始，或者L2开始的带宽
-
数据带宽
A100算力的暴涨，应该是让原来的存储系统，特别是SM内的存储设计跟不上了。
特别的是TF32 TC的引入，带宽需求和FP32一样，但是算力上大了好多。以Tensor Core FP16作为对比，同样使用Tensor Core，同样的操作（Ops/byte ratio），要保证相同的计算吞吐，需要的存储带宽大大地增长了。
- V100，FP16，FLOPS=125T，input data type FP16
- A100，TF32 TC，FLOPS=312T，input data type FP32，
因此，同样利用率的情况下，大概就需要5倍（312/125*2）的带宽了，在打开Sparsity的功能后，还需要更多的带宽，因为Sparse Matrix只压缩weight matrix。
作为对比基础，先给出Volta的存储体系：
数字上的增长
- HBM2
-
- 16GB to 40GB, achive 1.6TB/sec, 73% increase.
- L2 cache
-
- 6M L2 to 40MB, about 7x size, 2.3x read bandwidth with a new partitioned crossbar structure（没有细节，还不理解，后续继续学习）
- L1 data cache and Shared memory
-
- 128 KB to 196 KB，1.5x larger
从数字上看，整个系统的吞吐/容量的纯增长，基本是在2倍左右，偏下。这些改进，相对CUDA core算力1.25x-2.5x的改进，其实是差不多足够了。但是，对于Tensor Core 5倍以上的需求增长，远远不够，所以需要其他架构的改进和新的特性来进一步支持算力。另外，为什么L2 cache急剧地增加到了40MB？
架构和特性的改进
思考
在理解这些改动之前，一定要充分地思考一下，AI特别是DNN的数据流特点，以及计算的特点。然后可以发现，主要的这些改进，都是充分考虑Tensor core的数据和计算特点，给Tensor Core做一些快速，简洁，或者并行性更高的通道。而且，有些改进能在其他芯片中看到类似的理念，但A100的选择和实现总是更通用，更“软”，更巧妙。
我理解的数据特点：
- activation只读，不会更改。流量大。
- 权重复用度高，推理时const只读，训练时需要读和写。
- AI数据里冗余数据多，本质上是稀疏的，特别是Relu之后activation，压缩权重，Embedding输入数据，broadcast数据等。
我理解的AI计算特点（暂时还没有统计数据来支持）：
- 一个网络模型由很多的小Kernel组成。
- 单个Kernel宽而不深，也就是thread多，但kernel不长，指令数不多。
- Tensor Core （MMA）和Compute core的并行优化可能比较难做（库与编译器）
看看A100的存储系统改进，我关注了以下这些：
- 新的异步Copy指令，从global memory直接load到shared memory。
- 超大L2C，partitioned，use it smarter。
- 新的指令做L2 cache residency control。
- Compute Data Compression: 4x DRAM and L2 bandwidth, 2x L2 capacity. （不同于Structured Sparsity）
- Combined L1 data cache and shared memory （其实是Volta架构开始就有的）
Asynchronous copy
我理解为这是专为DNN Kernel里的Input/Activation数据类似的数据流优化。
- 因为这类数据，读自Global Memory，大都一次使用，不需要到RF，用完不需写回。因此没必要走复杂的L1/RF。而把RF/L1的带宽留给weigh和temp变量。
- 另外，这是异步操作，和SM里其他操作可并发，从而可以隐藏较长的copy cycles。使用新的shared-memory-based barrier来做同步。
- 同时，需要新的编程模型（CUDA）支持和编译器支持。
L2 cache residency control
首先，L2的设计很复杂，整理一下思路，根据新的特性出发来思考：
- 大幅度增长的L2 size （40MB），
-
- 首先，主要是为了大量的权重数据重用。
- 其次，MIG architecture的引入，需要将L2分成最多7份，也需要更大的size
- 大的L2，开始分区使用，类似于我们的LLC+L2的设计。
-
- 分区以后，每个GPC直连L2了，带宽增加（细节不懂。。。）
- 每个区应该也继续像以前一样分类，这样就是看，L2像是被做了两维的拆分，不知道这个是不是就是NV提到的new partitioned crossbar structure。
- 但整个L2Cache仍然保持“Shared”属性，HW cache-coherence，以及CUDA编程模型。
AI应用中，L2C应该主要优化了权重的复用，根据模型的大小，可以有不同级别的重用粒度，这个思路和之前在V1.5里提到的根据权重大小不同而产生的不同工作模式
- 权重全部在L2C，就像V1一样，整个模型权重只用装载一次到L2C。
- 权重需要分段轮流装载L2C，
-
- 装载一部分权重后，把相关的计算一个一个batch做完。然后换下一段权重，继续做。
- 这个时候，多batch的工作模式比较有优势。能公用更多的权重。
- 使用double buffer (ping-pong buffer）的模式，可以让计算和权重装载并行。
说到这里，大概就知道为什么需要L2 cache residency control。就是用来分段装载，实现ping-pong buffer的。
同样，也需要指令和CUDA编程模型的支持。
Compute Data Compression
注意这不是Structured Sparsity，而是针对unstructured sparsity and other compressible data patterns.
我知道我们也在看相关的技术。只是现在还不知道A100是怎么做的，但至少证明了这条路是可行的。需要大家一起持续关注。
Combined L1 cache and shared memory
从Volta架构开始，这个改变就发生了。理由看起来也比较充分：越来越多的计算场景，对Shared Memory和Cache的需求有很大不同。很难有一个固定比例能满足大部分的场景。所以可以配置的Shared Memory和L1C应该能比较方便而显著地提高性能。不需要为了固定的Shared Memory/L1C而绞尽脑汁地调整程序和调试性能。
之前的讨论中邹老师提到，做过一些实验发现差别不大。我有一些猜测，可能是实验面不够广，我们可以做进一步的实验：
- 这个改变是在Volta架构里，随着Tensor core一起引入。TC计算里这种差别可能特别明显，比如
-
- 做Matmul/Conv等使用TC的Kernel，通常是Shared Memory要的比较多（绝大部分），而cache用的很少
- 如果是LSTM的复杂Kernel，则会对Cache要求比较多。
- 越来越多的通用/AI计算场景，
整体而言，这个灵活性是有价值的。非常有利用调整和控制Kernel访存的性能和最终性能。
cache系统总结
首先是提供能力：BW/Capacity/利用率
- 直接提高带宽
- Capacity
不止单纯的大小，还包括动态分配等方式
- DRAM BW
1.7x BW不足，通过6.7x L2 + Residency Control弥补
其次是减少需求：
- Sparsity
- Compression
计算效率
Task Graph Acceleration
这应该是对整体性能（整个模型甚至多个模型）非常意义的一个特性。针对的是“一个网络模型由很多的小Kernel组成”这个特征。
这个思路---把多个Tasks，memory copies（uploading/downloading）做成一个图（Graph，Directed Acyclic Graph），加上Dependency关系，以前都是在软件端实现的。比如：
- GPU应用领域，多个draw batches，相互间或有复杂的dependency，为做到高效地并行，避免不必要的bubble，最好能做到out-of-order的执行。我知道的软件栈，做过相关的优化处理：UMD建立有dependency关系的DAG，KMD根据DAG，dependency信息，以及硬件的执行状态，动态的调度draw batches。
- AI领域，DNN本身就是一个DAG。
-
- 在NPU V1架构上，这个问题不明显但也存在。不明显的原因是大部分连续的可支持的算子被合并成了一个执行Engine。但遇到大的Engine需要拆分的时候，还是需要会有这个问题的，所以我们还是在软件栈实现了基于DAG的推理引擎。
- 在GPGPU架构，加上训练功能，将会有很多很多小的Kernel了。因此特别需要这个优化。
因此存在CPU和GPU之间的来回调度。A100的创新是把这个移到了硬件上。去除了这个CPU-GPU调度代价。
CUDA Graph
CUDA 10开始支持的一个特性，是Task Graph Acceleration的基础。首先把多个Kernel一起提交（submit）到GPU。减少kernel提交和同步的时间。不过submit之后的kernel只能按照顺序执行。并行度比较差。
Task Graph Acceleration
Ampere架构支持以图的方式提交，并带有相互的依赖关系。因此GPU硬件可能更高效的调度kernel并行。
