23、CNN加速：CPU与加速器协同调度技术解析

CNN加速：CPU与加速器协同调度技术解析

1. CPU - 加速器协同调度概述

在CNN加速中，CPU - 加速器协同调度是一种有效的方法。其基本原理是将不同的3D滤波器张量分配给CNN加速器和CPU进行处理。例如，将“K”个3D滤波器张量分配给CNN加速器，用于生成“K”个输出通道；将“OC - K”个滤波器张量分配给CPU。在运行时，由CPU执行的协同执行控制模块会启动加速器和CPU针对给定输出通道的协同执行。CONV层操作包含卷积、批量归一化（BatchNorm）和激活操作。当加速器和CPU分别生成“K”和“OC - K”个2D输出特征图（OFMs）后，会将这些OFMs聚合起来，组成完整的3D OFM张量。

1.1 线性回归延迟模型

为了进行延迟估计，采用了基于线性回归的方法。一般线性回归方程的形式为：
[Y = \alpha X + \beta]
其中，(X)和(Y)分别是解释变量和因变量。通过线性回归训练（直线拟合），利用(X)和(Y)的成对值来确定(\alpha)和(\beta)的值。基于此方程形式，可扩展用于估计处理单个CONV层时加速器和CPU的延迟。

1.1.1 加速器延迟模型

加速器延迟可分为三个部分：计算延迟、数据传输延迟和一致性延迟。
- 计算延迟 ：主要取决于生成OFMs所需的操作数量。首先，生成一个单位延迟(L_{uACC})，它对应于1PE加速器（即具有一个处理单元的加速器）生成一个OFM元素时的计算延迟，计算公式如下：
[L_{uACC} = \alpha_{comp} \times Size_{FT} + \beta_{comp}]
其中，(Size_{FT})表示一个3D滤波器张量中的元素数量。例如，若一个3D滤波器张量的大小为(3×3×3)，则(Size_{FT})为27。(\alpha_{comp})和(\beta_{comp})通过线性回归分析确定。可将其扩展以推导生成(N_F)个OFMs（即(N_F)个输出通道）时的加速器计算延迟(L_{comp})：
[L_{comp} = L_{uACC} \times Size_{OFM} \times \left\lceil\frac{N_F}{N_{PE}}\right\rceil]
其中，(Size_{OFM})、(N_F)和(N_{PE})分别对应一个2D OFM中的元素数量、某个CONV层中的输出通道总数以及加速器中的处理单元数量。(\left\lceil\frac{N_F}{N_{PE}}\right\rceil)表示加速器执行必须触发的次数。
- 传输延迟 ：与要传输的数据大小呈线性比例关系，可通过以下方程估计：
[L_{tran} = \alpha_{tran} \times Size_{Data} + \beta_{tran}]
其中，(Size_{Data})表示要传输的数据的总大小（以元素数量计），(\alpha_{tran})和(\beta_{tran})也通过线性回归分析确定。(Size_{Data})的计算公式为：
[Size_{Data} = Size_{IFMs} + Size_{\gamma} + Size_{\beta} + Size_{FT} \times N_F + Size_{OFM} \times N_F]
对于输入数据传输，需要计算(Size_{IFMs})、(Size_{\gamma})和(Size_{\beta})，它们分别对应（多个）输入特征图、批量归一化的伽马值和贝塔值的元素数量。对于输出传输，需要计算加速器生成的OFMs的数据大小，即(Size_{OFM} \times N_F)。
- 一致性延迟 ：由缓存刷新和缓存失效两部分组成。缓存刷新在触发DMA读取（将输入数据发送到加速器的PLM）之前进行，缓存失效在触发DMA写入（将输出数据从PLM发送到主内存）之前进行。缓存刷新延迟(L_{fl})的计算公式为：
[L_{fl} = \alpha_{fl} \times (Size_{IFMs} + Size_{\gamma} + Size_{\beta} + Size_{FT} \times N_F) + \beta_{fl}]
缓存失效延迟(L_{inv})的计算公式为：
[L_{inv} = \alpha_{inv} \times Size_{OFM} \times N_F + \beta_{inv}]
总一致性延迟(L_{cohr})为：
[L_{cohr} = L_{fl} + L_{inv}]
加速器的总延迟(L_{ACC})为计算、传输和一致性延迟之和：
[L_{ACC} = L_{comp} + L_{tran} + L_{cohr}]

1.1.2 CPU延迟模型

对于CPU，采用统一的延迟模型，不区分数据传输和计算延迟。CPU单位延迟(L_{uCPU})（即CPU生成一个OFM元素的延迟）的计算公式为：
[L_{uCPU} = \alpha_{CPU} \times Size_{FT} + \beta_{CPU}]
其中，(Size_{FT})等于一个3D滤波器张量的大小（以元素数量计）。系数(\alpha_{CPU})和(\beta_{CPU})通过线性回归确定，它们会综合考虑计算和数据传输对CPU单位延迟的影响。利用CPU单位延迟模型，可扩展以估计CPU中整个CONV层的延迟(L_{CPU})：
[L_{CPU} = L_{uCPU} \times Size_{OFM} \times N_F]
其中，(Size_{OFM} \times N_F)对应某个CONV层中的总OFM元素数量。

1.2 通道分配

根据估计的延迟，对输出通道进行分配，以使系统中的加速器和CPU得到充分利用。需要将输出通道分配得使加速器和CPU的执行时间（几乎）相等。用于加速器的输出通道分配方程如下：
[N_{FA} = \left\lceil\left(\frac{L_{CPU}}{L_{ACC} + L_{CPU}}\right) \times N_F\right\rceil]
其中，(N_{FA})表示将在加速器中处理的输出通道数量。显然，其余的滤波器张量将在CPU中处理，即：
[N_{FC} = N_F - N_{FA}]
其中，(N_{FC})表示将在CPU中处理的输出通道数量。输出通道的分配决策在设计时离线进行，一旦确定，该信息将存储在CNN框架中。在运行时，CNN框架可根据存储的分配信息将任务（输出通道）分配给加速器和CPU。

1.3 原型实现

在Darknet框架中实现了所提出的协同调度技术，并使用四个现成的FPGA - SoC平台（Ultra96、Zed、ZCU104和ZCU106）进行验证。这些平台采用了不同类型的CPU，具体规格如下表所示：
| 平台 | CPU架构 | 时钟频率 | 每核心L1缓存 | L2缓存 |
| — | — | — | — | — |
| Ultra96 | 四核Cortex - A53 | 最高1200 MHz | 32 KB I - Cache，32 KB D - Cache | 共享1 MB |
| Zed | 双核Cortex - A9 | 最高667 MHz | 32 KB I - Cache，32 KB D - Cache | 共享512 KB |
| ZCU104, ZCU106 | 四核Cortex - A53 | 最高1334 MHz | 32 KB I - Cache，32 KB D - Cache | 共享1 MB |

实现过程中，使用基于中断的机制同时在加速器和CPU上执行CONV层操作。虽然原型未采用双缓冲技术，但所提出的延迟模型和协同调度方法可扩展以支持双缓冲。在每个平台上运行修改后的框架时，不运行操作系统，这种环境类似于资源受限的嵌入式边缘设备，由固件协调系统运行。所使用的CNN模型精度为32位浮点，但该技术也可应用于其他精度，如16位定点和8位整数，而无需修改延迟模型和通道分配机制。

以下是协同调度技术基于中断机制的时序图流程：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([初始化]):::startend --> B(CPU发起数据传输，包括缓存刷新和DMA传输):::process
    B --> C(CPU开始生成NFC OFMs):::process
    C --> D{DMA传输完成?}:::process
    D -- 是 --> E(加速器开始生成NFA OFMs):::process
    E --> F(加速器执行完成):::process
    F --> G(CPU进行缓存失效和DMA写入操作):::process
    G --> H{加速器是否需要多次触发?}:::process
    H -- 是 --> B
    H -- 否 --> I([结束]):::startend
    D -- 否 --> C

在原型实现中，通过线性回归分析获取(\alpha)和(\beta)值。对于线性回归模型的训练，使用合成生成的任意32个数据点，分别用于传输时间、刷新和失效（一致性）时间以及计算时间的回归训练。这些任意生成的数据点范围足以覆盖实际CNN模型中使用的数据点范围，从而实现准确的延迟估计。以下是通过线性回归分析获得的(\alpha)和(\beta)值：
| 平台 | (\alpha_{tran}) | (\beta_{tran}) | (\alpha_{comp}) | (\beta_{comp}) | (\alpha_{fl}) | (\beta_{fl}) | (\alpha_{inv}) | (\beta_{inv}) | (\alpha_{CPU}) | (\beta_{CPU}) |
| — | — | — | — | — | — | — | — | — | — | — |
| Ultra96 | 0.01 | 2.697551 | 0.099999 | 0.237558 | 0.008811 | 0.514771 | 0.008812 | 1.663402 | 0.049176 | 0.116896 |
| Zed | 0.009999 | 2.162106 | 0.150077 | 0.309062 | 0.009323 | 6.101897 | 0.003748 | 0.986305 | 0.072254 | 0.164479 |
| ZCU104 | 0.009998 | 2.458088 | 0.090014 | 0.218302 | 0.006082 | 0.491329 | 0.006084 | 1.036251 | 0.049155 | 0.113563 |
| ZCU106 | 0.009999 | 2.472711 | 0.090021 | 0.218306 | 0.006101 | 0.314022 | 0.006091 | 0.900236 | 0.049176 | 0.113043 |

2. 实验结果

2.1 实验设置

在这部分，将对所提出的协同调度技术进行多方面的实验评估，包括延迟模型准确性、性能和能耗等指标。实验使用Ultra96、Zed、ZCU104和ZCU106这四个FPGA - SoC平台。对于CPU时钟频率，Ultra96、ZCU104和ZCU106设置为1.2 GHz，Zed设置为667 MHz，并基于这些时钟频率进行线性回归分析。

为了评估不同加速器的性能，为每个平台实现了三种不同版本的加速器，分别为2PE、4PE和8PE，其中xPE表示具有“x”个处理单元的加速器。由于目标是资源受限的边缘设备，因此不考虑具有大量处理单元（如超过100个PE）的CNN加速器设计。

实验使用了14个不同的CONV层作为工作负载，具体信息如下表所示：
| 网络 | 层编号 | SizeIFMs | SizeOFM × NF | SizeFT × NF |
| — | — | — | — | — |
| SqueezeNet (SN) | 0 | 57 × 57 × 16 | 57 × 57 × 64 | 1 × 1 × 16 × 64 |
| SqueezeNet (SN) | 1 | 57 × 57 × 16 | 57 × 57 × 64 | 3 × 3 × 16 × 64 |
| SqueezeNet (SN) | 2 | 29 × 29 × 32 | 29 × 29 × 128 | 1 × 1 × 32 × 128 |
| SqueezeNet (SN) | 3 | 29 × 29 × 32 | 29 × 29 × 128 | 3 × 3 × 32 × 128 |
| MobileNet - v2 (MN) | 4 | 28 × 28 × 32 | 28 × 28 × 192 | 1 × 1 × 32 × 192 |
| SqueezeNet (SN) | 5 | 15 × 15 × 64 | 15 × 15 × 256 | 3 × 3 × 64 × 256 |
| SqueezeNet (SN) | 6 | 15 × 15 × 48 | 15 × 15 × 192 | 3 × 3 × 48 × 192 |
| MobileNet - v2 (MN) | 7 | 14 × 14 × 96 | 14 × 14 × 576 | 1 × 1 × 96 × 576 |
| MobileNet - v2 (MN) | 8 | 7 × 7 × 576 | 7 × 7 × 160 | 1 × 1 × 576 × 160 |
| MobileNet - v2 (MN) | 9 | 7 × 7 × 320 | 7 × 7 × 1280 | 1 × 1 × 320 × 1280 |
| MobileNet - v2 (MN) | 10 | 7 × 7 × 160 | 7 × 7 × 960 | 1 × 1 × 160 × 960 |
| Synthetically Generated (SG) | 11 | 7 × 7 × 160 | 7 × 7 × 160 | 3 × 3 × 160 × 160 |
| Synthetically Generated (SG) | 12 | 7 × 7 × 160 | 7 × 7 × 960 | 3 × 3 × 160 × 960 |
| Synthetically Generated (SG) | 13 | 7 × 7 × 160 | 7 × 7 × 1280 | 3 × 3 × 160 × 1280 |

2.2 延迟模型准确性

通过平均绝对百分比误差（MAPE）来衡量延迟模型的准确性。使用所获得的(\alpha)和(\beta)值，测量加速器和CPU的实际延迟与模型估计延迟之间的误差率。具体的MAPE结果如下表所示：
| 平台 | 加速器版本 | 1 × 1 CONV | 3 × 3 CONV |
| — | — | — | — |
| Ultra96 | LACC PE2 | 1.01% | 0.14% |
| Ultra96 | LACC PE4 | 0.74% | 0.16% |
| Ultra96 | LACC PE8 | 0.47% | 0.26% |
| Ultra96 | LCPU | 0.65% | 0.76% |
| Zed | LACC PE2 | 0.82% | 0.18% |
| Zed | LACC PE4 | 0.26% | 0.17% |
| Zed | LACC PE8 | 0.98% | 0.26% |
| Zed | LCPU | 0.40% | 0.67% |
| ZCU104 | LACC PE2 | 1.06% | 0.13% |
| ZCU104 | LACC PE4 | 0.63% | 0.12% |
| ZCU104 | LACC PE8 | 0.87% | 0.19% |
| ZCU104 | LCPU | 0.48% | 0.68% |
| ZCU106 | LACC PE2 | 1.06% | 0.13% |
| ZCU106 | LACC PE4 | 0.63% | 0.11% |
| ZCU106 | LACC PE8 | 0.87% | 0.19% |
| ZCU106 | LCPU | 0.47% | 0.68% |

从表中可以看出，所提出的延迟模型的MAPE在0.11% - 1.06%之间，这表明该延迟模型能够非常准确地估计加速器和CPU在CONV层执行时的延迟。准确的延迟估计有助于将输出通道合理地分配给加速器和CPU，从而充分利用硬件资源，减少空闲时间，提高性能。

2.3 性能评估

对所提出的协同调度技术的性能进行评估，比较了三种不同配置：CPU_ONLY（仅CPU执行）、ACC_ONLY（仅加速器执行）和CPU + ACC（协同调度）。以下是不同加速器版本下的性能结果：
| 平台 | 加速器版本 | CPU_ONLY相对性能 | ACC_ONLY相对性能 | CPU + ACC相对性能（相对于CPU_ONLY） | CPU + ACC相对性能（相对于ACC_ONLY） |
| — | — | — | — | — | — |
| Ultra96 | 2PE | 1× | 0.97× - 1.09× | 1.93× - 2.05× | 1.89× - 2.00× |
| Ultra96 | 4PE | 1× | 优于2PE加速器情况 | 2.84× - 3.07× | 1.43× - 1.48× |
| Ultra96 | 8PE | 1× | | 4.58× - 4.98× | 1.18× - 1.21× |
| Zed | 2PE | 1× | 0.97× - 1.09× | 1.93× - 2.05× | 1.89× - 2.00× |
| Zed | 4PE | 1× | 优于2PE加速器情况 | 2.84× - 3.07× | 1.43× - 1.48× |
| Zed | 8PE | 1× | | 4.58× - 4.98× | 1.18× - 1.21× |
| ZCU104 | 2PE | 1× | 0.97× - 1.09× | 1.93× - 2.05× | 1.89× - 2.00× |
| ZCU104 | 4PE | 1× | 优于2PE加速器情况 | 2.84× - 3.07× | 1.43× - 1.48× |
| ZCU104 | 8PE | 1× | | 4.58× - 4.98× | 1.18× - 1.21× |
| ZCU106 | 2PE | 1× | 0.97× - 1.09× | 1.93× - 2.05× | 1.89× - 2.00× |
| ZCU106 | 4PE | 1× | 优于2PE加速器情况 | 2.84× - 3.07× | 1.43× - 1.48× |
| ZCU106 | 8PE | 1× | | 4.58× - 4.98× | 1.18× - 1.21× |

从性能结果可以看出：
- 对于2PE加速器版本，加速器相对于CPU_ONLY的性能提升有限，这是由于加速器的处理单元数量较少。而协同调度（CPU + ACC）比CPU_ONLY和ACC_ONLY分别有1.93× - 2.05×和1.89× - 2.00×的性能提升。
- 4PE加速器版本的加速器性能优于2PE版本，协同调度（CPU + ACC）比CPU_ONLY有2.84× - 3.07×的性能提升，比ACC_ONLY有1.43× - 1.48×的性能提升。
- 8PE加速器版本下，协同调度（CPU + ACC）比CPU_ONLY和ACC_ONLY分别有4.58× - 4.98×和1.18× - 1.21×的性能提升。

总体而言，由于准确的延迟模型，所提出的协同调度技术能够最小化加速器或CPU的空闲时间，从而比仅使用CPU或仅使用加速器具有更好的性能。

2.4 性能对比流程图

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([开始]):::startend --> B{选择配置}:::process
    B -- CPU_ONLY --> C(仅CPU执行):::process
    B -- ACC_ONLY --> D(仅加速器执行):::process
    B -- CPU + ACC --> E(协同调度执行):::process
    C --> F(记录性能结果):::process
    D --> F
    E --> F
    F --> G([结束]):::startend

综上所述，所提出的CPU - 加速器协同调度技术在延迟模型准确性和性能方面都表现出色，能够有效地加速CNN的CONV层执行，为资源受限的嵌入式边缘设备提供了一种可行的解决方案。