3. 推理时间

这里涉及到一个 gap，很多部署的同学们更喜欢谈“计算效率”，而实际上算法同学真正关心的点是“推理时间”，导致两者在对接的时候经常会出现一些 misleading。因此我这里单独开一节来探讨一下“推理时间”的评估方法。

其实也很简单，按照 RoofLine 模型，我们很容易就能得到算子实际的执行时间：

这是一个分段函数，拆开来可得：

一句话总结：对于访存密集型算子，推理时间跟访存量呈线性关系，而对于计算密集型算子，推理时间跟计算量呈线性关系。

讲到这里，我们就能初步回答本章一开始的问题了：按照 RoofLine 模型，在计算密集区，计算量越小，确实推理时间越小。但是在访存密集区，计算量与推理时间没关系，真正起作用的是访存量，访存量越小，推理的时间才越快。在全局上，计算量和推理时间并非具有线性关系。

上一节中，OP4 虽然计算效率很低，但由于访存量也很低，因此其实推理速度还是快于其他几个 OP 的。但是我们可以观察到，其计算量虽然只有 OP1 的 1/130，但是推理时间仅降低到了 1/6，两者并非是线性关系（也是当年我把模型减到 1/10 计算量，但其实没快多少的原因）。

再举两个例子强化一下，首先看这两个卷积，他们的计算量差不多，但是因为都在访存密集区，OP3 的访存量远低于 OP5，其推理也更快：

下面这个栗子更明显，OP5 和 OP6 的区别仅仅是一个是 DepthWise Conv，一个是普通 Conv，其他参数没有变化。按照我们之前的直观感受，Conv 换成 DepthWise Conv 应该会更快，但实际上两者的推理时间是差不多的（这组参数也是当年我用过的【手动捂脸）：

4. 小结

从上面的讨论中我们可以看出：计算量并不能单独用来评估模型的推理时间，还必须结合硬件特性（算力&带宽），以及访存量来进行综合评估。并非是计算量越低模型推理越快。在评价模型大小时，也建议加上访存量作为重要的评价指标。

需要强调的一点是，不同的硬件平台峰值算力和内存带宽不同，导致同一个模型在平台 1 上可能是计算密集的，在平台 2 上可能就变成了访存密集的。例如上文提到的 Intel X86 平台，“拐点”值为 48，而 NVIDIA V100“拐点”值为 173.6，上文举的例子在 V100 平台上仅有 OP2 落在了计算密集区，剩下的全部是访存密集的。因此，同样的模型在不同平台上性质可能会发生改变，需要具体情况具体分析。

我们很难给出一个通用性的结论，究其原因是 RoofLine 模型本身是一个非线性模型。这里必须要强调一点的是，除了峰值算力和内存带宽之外，还有硬件限制、系统环境、软件实现等诸多因素会影响程序的实际性能，使得其非线性特性更加严重。因此 RoofLine 模型仅仅只能提供一个性能上界的评估方式，并不代表能够达到的实际性能。实际性能最准确的测量方式只有真机实测。

RoofLine 模型更重要的是提供了一种分析性能的思想，即计算密集型程序更多的受限于硬件算力，而访存密集型程序更多的受限于硬件内存带宽。在理解这一点的基础上设计网络结构，并分析网络的性能，将更有理论参考。不会再对”计算量减半，为啥推理时间没变“这种问题抱有疑问了（说的就是我【流泪）

下文将对 RoofLine 模型的一些限制进行讨论，分析哪些因素将以何种方式影响程序，使得其到达不了 RoofLine 模型估计的性能上界。

（下文要开始难度升级了，建议没看懂 RoofLine 模型的同学们再把这一章看一遍，不然后面会看的有点懵）

三、影响模型推理性能的其他因素

RoofLine 模型可以用来评估程序的性能上界，但是实际能达到的性能还会受到硬件限制、系统环境、软件实现等诸多因素的影响，距离性能上界有一定距离。本章将对这些影响因素进行分析。

1. 硬件限制对性能上界的影响

前面 RoofLine 模型使用的峰值算力及内存带宽，是根据纸面数据计算得到的，是理论上的最大值。但在实际情况下，硬件会因为种种原因，无法达到这个理论值。因此建议大家对硬件进行micro-benchmark，以获取硬件的真实性能上限。

以上文的 Intel X86 CPU 为例，我们之前计算的 avx512 理论算力为 4.608 TFLOPs/s，但这个数值的前提是频率能维持在 4.5 GHz。然而实际上在使用 16 核跑 avx512 指令时，CPU 频率会下降到约 2.9 GHz，此时理论算力仅剩下 2.96 TFLOPs/s，而实测值仅有 2.86 TFLOPs/s。

除了频率之外，有些芯片可能会因为一些设计上或实现上的原因，导致在实际使用时达不到理论峰值。比如一些低端芯片不支持多****、不支持乱序执行、采用了阻塞式 Cache 等等，一些芯片甚至会有一些性能 bug，导致在实际使用时几乎到达不了理论峰值（这里我个人倾向于把这些原因归结为硬件限制带来的损失）。

内存同理，该平台理论带宽为 96GB/s，但实测下来最高读带宽仅有 74 GB/s，仅能到达理论带宽的 77%。

我们可以得到修正后的 RoofLine 模型，图中蓝色填充部分反映了因实际算力和内存带宽达到不了理论值而造成的损失：

修正了实测峰值算力和内存带宽后的 RoofLine 模型，蓝色填充部分为硬件限制带来的损失

修正后的模型“拐点”发生了变化，因此算子的性质也会发生变化。建议拿到硬件后对硬件进行 micro-benchmark，这里推荐两个测试工具：

一个是高叔叔写的浮点峰值测试方法的文章，最后有 github 链接，大家可以 clone 下来测试硬件峰值：

还有一个是 stream 测试工具，可以用于测试内存带宽：

2. 系统环境对性能的影响

除非程序运行在裸机中，否则操作系统一定会对性能上界产生一定影响，比如操作系统在多核间的调度损失、操作系统的内存管理带来的损失、操作系统本身占用的运算资源等等。

对于一般的深度学习推理任务而言，现代操作系统对性能的影响并不是特别明显。但是在一些特殊情况下，也会带来严重的性能损失。我这里将会举两个例子：

一个是 Android 系统在大小核上的调度，一旦程序在 CPU 上的占用率不足（比如是周期工作的任务），则有可能被 Android 调度到小核上，带来性能损失。

另一个例子是内存缺页。在 Linux 系统上，当向系统申请内存页后，系统只是返回了虚拟页，等到程序实际使用虚拟页时，才会通过触发缺页异常的方式，进入操作系统内核分配物理页，这一过程会严重降低性能。

好在这些问题可以通过软件进行一部分弥补，例如调度问题可以使用绑核来解决，缺页问题可以通过绑定物理页（需要内核态）或内存池来解决。因此操作系统带来的影响是可控的。

除了操作系统带来的影响，系统中运行的其他进程也会对当前进程造成影响。比如一个系统中运行了多个深度学习实例，或者系统后台一些 APP 自启动了等等。这些进程都会占用核心算力和内存带宽，造成当前进程性能损失。

这往往会导致在工程测试环境下性能达标的模型，在实际部署时性能下降。因此，必须关注工程测试环境和实际部署系统环境的差异。如有条件，最好在实际部署环境下进行测试。

3. 软件实现对性能的影响

除了硬件限制和系统环境外，一个任务的软件实现好坏对性能有着重大的影响。

例如对于同样的矩阵操作任务，使用 python 写的多重 for 循环，和用 numpy 高度优化过的矩阵操作函数，性能可以差出 1~2 个数量级。

对于深度学习模型推理而言，推理框架对模型性能的影响主要体现在：是否充分利用了硬件的流水线资源、是否高效利用了硬件中的缓存、是否采用了时间复杂度更低的算法、是否解决了操作系统带来的性能损失（如上文的调度问题和内存缺页问题）、是否进行了正确高效的图优化等等。

由于影响因素很多，因此软件对性能的影响往往呈现出很强的非线性，导致在评估性能时很难给出一些普适性的结论，很多时候只能具体情况具体分析。（有的时候甚至有点玄学【捂脸）

例如同样计算量的向量四则运算和超越函数，后者往往会慢于前者的原因是很多硬件不支持超越函数的 SIMD 指令；再比如空洞卷积（dilated Conv）性能会弱于普通卷积的原因是前者对访存的利用不如后者高效等等。

在软件实现的影响下，RoofLine 模型的上界再次下降，达到图中的红线（真实的非线性可能会比我随手画的要复杂的多）：

RoofLine 模型各种性能损失示意图，图中曲线不代表真实比例

因此，在评估或分析深度学习推理性能时，简单的计算量/访存量指标是完全不够的，只能做个性能上界参考。实际能达到的性能其实还要关注很多很多因素，例如算子的访存模式、数据排布、是否能够进行图融合、是否有精度可接受的低时间复杂度算法、算法并行度是否充足、各种运算的比例等等因素。

这些因素对于算法同学而言可能过于复杂，并不需要掌握。但如果所在的公司/部门有交流的机会的话，可以跟部署/优化的同学针对模型结构和算子进行探讨，以获取性能优化的建议。

这里可以一些一般性的结论，仅供参考：

对于一些访存非常密集且访存 pattern 连续的算子，如 Concat、Eltwise Sum、ReLU、LeakyReLU、ReflectionPad 等，在 Tensor 数据量很大的情况下，软件实现的损失会非常小，正常情况下基本都能达到内存带宽实测上限；如果框架采用了融合策略的话，基本可以达到 0 开销。

对于 Conv/FC/Deconv 等算子，在计算密度很高的情况下，大多数框架是能够很接近算力峰值的。但对于计算密度不是特别高的 case，不同框架的表现不一，需要实测才能确定。不过从大趋势而言，都是计算密度越高，硬件的利用率越高的。

尽量使用常用的算子参数，例如 Conv 尽量使用 3x3_s1/s2，1x1___s1/s2 等，这些常用参数往往会被特殊优化，性能更好。

4. 小结

RoofLine 模型仅能用于估计模型所能达到的性能上界，而实际部署时，还会受硬件限制、系统环境、软件实现等因素的影响，导致无法达到 RoofLine 模型所定义的性能上界。

此外，由于这些因素往往会导致性能曲线有较强的非线性，理论分析和实测会有一定差距，有时这些因素会严重影响性能曲线，甚至会导致算子的性质发生变化。因此本节讨论的内容只是提供一些分析的思路与技巧，实测始终是最准确的性能评估方式。

四、面向推理速度的模型设计建议

前面讨论了一大堆，其实最实用的还是“怎么设计模型能够达到更快的推理速度”。

在给出我的个人建议之前，首先要先声明的是：由于不同硬件、不同环境、不同框架的差异会很大，这些建议可能并不是在所有条件下都适用。在设计算法或性能测试遇到疑问时，建议咨询部署/优化的同学。

好了，废话不多说（其实已经说了很多了），给出我的一些个人建议：

方法论建议：

了解目标硬件的峰值算力和内存带宽，最好是实测值，用于指导网络设计和算子参数选择。

明确测试环境和实际部署环境的差异，最好能够在实际部署环境下测试性能，或者在测试环境下模拟实际部署环境。

针对不同的硬件平台，可以设计不同计算密度的网络，以在各个平台上充分发挥硬件计算能力（虽然工作量可能会翻好几倍【捂脸）。

除了使用计算量来表示/对比模型大小外，建议引入访存量、特定平台执行时间，来综合反映模型大小。

实测是最准确的性能评估方式，如果有条件快速实测的话，建议以实测与理论分析相结合的方式设计并迭代网络。

遇到性能问题时，可以逐层 profiling，并与部署/优化同学保持紧密沟通，具体问题具体分析（适当了解一下计算相关理论的话，可以更高效的沟通）。

网络设计建议：

对于低算力平台（CPU、低端 GPU 等），模型很容易受限于硬件计算能力，因此可以采用计算量低的网络来降低推理时间。

对于高算力平台（GPU、DSP 等），一味降低计算量来降低推理时间就并不可取了，往往更需要关注访存量。单纯降低计算量，很容易导致网络落到硬件的访存密集区，导致推理时间与计算量不成线性关系，反而跟访存量呈强相关（而这类硬件往往内存弱于计算）。相对于低计算密度网络而言，高计算密度网络有可能因为硬件效率更高，耗时不变乃至于更短。

面向推理性能设计网络结构时，尽量采用经典结构，大部分框架会对这类结构进行图优化，能够有效减少计算量与访存量。例如 Conv->BN->ReLU 就会融合成一个算子，但 Conv->ReLU->BN 就无法直接融合 BN 层

算子的参数尽量使用常用配置，如 Conv 尽量使用 3x3_s1/s2、1x1___s1/s2 等，软件会对这些特殊参数做特殊优化。

CNN 网络 channel 数尽量选择 4/8/16/32 的幂次，很多框架的很多算子实现在这样的 channel 数下效果更好（具体用多少不同平台不同框架不太一样）。

框架除了计算耗时外，也处理网络拓扑、内存池、线程池等开销，这些开销跟网络层数成正比。因此相比于“大而浅”的网络，“小而深”的网络这部分开销更大。一般情况下这部分开销占比不大。但在网络算子非常碎、层数非常多的时候，这部分开销有可能会影响多线程的扩展性，乃至于成为不可忽视的耗时因素。

一些其他建议：

除了优化网络结构、推理框架性能外，还可以考虑通过一些其他工程技巧来提升系统整体的性能。例如：对推理服务流水化，并行数据读取与计算的过程，掩盖 IO 延时。

本文介绍了评估模型大小的四个常用指标——计算量、参数量、访存量、内存占用，从 RoofLine 模型入手详细讨论了影响模型推理速度的影响因素，并给出了面向推理速度的模型设计方法论与建议。

撰写本文的目的，不仅仅是给算法同学提供有效的网络设计建议，更多的还是希望能够传达性能优化的基础知识与分析思路，减少算法设计到部署之间的 gap，更快速高效的设计推理友好的网络模型。希望能对大家的工作有所帮助。

由于本人知识水平有限，如有错误和不详尽的地方，望大家不吝指出，非常欢迎大家在评论区留言探讨。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。