深度学习模型大小与模型推理速度的一些分析

本文对衡量深度学习模型大小的一些常用指标，如计算量、参数量、访存量、内存占用等进行探讨，分析这些指标对模型部署推理的影响，尤其是计算量与访存量对模型推理速度的影响，并给出在不同硬件架构下设计网络结构的一些建议。

0、前言

当年头一次实习做算法的时候，主管给的第一个任务就是“把一个大的分割模型砍成一个小的”。当时并不理解模型“大”、“小”的真正含义，就简单的选取计算量作为评价指标，疯狂砍计算量（backbone 换 MobileNet/ShuffleNet、Conv 换成 DepthWise Conv、以及一些奇奇怪怪的融合结构等等），把模型计算量砍了将近 10 倍，结果一部署发现速度并没有快多少，反而是把最初的 ResNet 简单砍掉几个 block 效果更好。

也是从那时起接触了访存量、流水线、RoofLine 模型等概念，对模型推理速度的问题产生了兴趣，从此踏上了深度学习推理优化的不归路（划掉）。

如今做推理优化和 HPC 已经有一段时间了，还是偶尔能回想起当年不懂推理时设计的与硬件严重不匹配的模型。此外在工作中跟研究员沟通时，也会发现部分研究员对模型大小和模型推理速度的关系不太了解，设计出一些很难发挥硬件计算能力的模型结构。因此在这里对一些用于评价模型大小的指标——计算量、参数量、访存量、内存占用等指标进行详细探讨，分析这些指标会对模型的部署推理产生何种影响，详细讨论计算量和访存量对模型推理速度的影响，并给出不同硬件架构下设计高效网络结构的一些建议。

本文不仅仅是为了给出网络的设计建议，更是希望能够有效传达性能优化的基础理论知识，以及性能分析的基本思路，帮助各位同学减少网络设计与部署之间的 gap，更高效的完成网络设计与部署工作。非常希望本文能够对大家的工作有所帮助，也非常欢迎大家在评论区留言探讨。

一、常用的模型大小评估指标

目前常用于评价模型大小的指标有：计算量、参数量、访存量、内存占用等，这些指标从不同维度评价了模型的大小。本节仅作简单介绍，熟悉的小伙伴可以跳过此节，直接看后面的分析与探讨。ASP站长网

1. 计算量

计算量可以说是评价模型大小最常用的指标了，很多论文在跟 baseline 进行比较时，都会把计算量作为重要的比较依据。

计算量是模型所需的计算次数，反映了模型对硬件计算单元的需求。计算量一般用 OPs (Operations) ，即计算次数来表示。由于最常用的数据格式为 float32，因此也常常被写作 FLOPs (Floating Point Operations)，即浮点计算次数。（这里为了跟传统习惯保持一致，下文就统一采用 FLOPs 啦）

模型的整体计算量等于模型中每个算子的计算量之和。而每个算子的计算量计算方法各不一致。例如对于 Eltwise Sum 来讲，两个大小均为 (N, C, H, W) 的 Tensor 相加，计算量就是 N x C x H x W；而对于卷积来说，计算量公式为（乘加各算一次）：

PyTorch 有不少工具可以模型计算量，但需要注意的是这些工具有可能会遗漏一些算子的计算量，将其计算量算成 0，从而导致统计的计算量跟实际计算量有轻微的偏差，不过大多数情况下这些偏差影响不大。

2. 参数量

早期的论文也很喜欢用参数量来评价模型大小。

参数量是模型中的参数的总和，跟模型在磁盘中所需的空间大小直接相关。对于 CNN 来说参数主要由 Conv/FC 层的 Weight 构成，当然其他的一些算子也有参数，不过一般忽略不计了。

参数量往往是被算作访存量的一部分，因此参数量不直接影响模型推理性能。但是参数量一方面会影响内存占用，另一方面也会影响程序初始化的时间。

参数量会直接影响软件包的大小。当软件包大小是很重要的指标时，参数量至关重要，例如手机 APP 场景，往往对 APK 包的大小有比较严格的限制；此外有些嵌入式设备的 Flash 空间很小，如果模型磁盘所需空间很大的话，可能会放不下，因此也会对参数量有所要求。

除了在设计模型时减少参数量外，还可以通过压缩模型的方式降低软件包大小。例如 Caffe 和 ONNX 采用的 Protobuf 就会对模型进行高效的编码压缩。不过压缩模型会带来解压缩开销，会一定程度增加程序初始化的时间。

（编辑：焦作站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!