Deep Learning Inference in Facebook Data Centers: Characterization, Performance Optimizations and Hardware Implications #2
Description
https://arxiv.org/abs/1811.09886
针对Facebook的DL Inference场景，分析了DL Inference的特点，介绍了性能优化的工作，并对以后软硬件协同设计进行了展望。
1. 引言
很多预测工作需要CPU的灵活性、可用性、低延迟，因此FB的工作主要针对通用处理器。
论文认为新的DL硬件需要满足下列条件：
- 高内存带宽和Embedding容量
- 支持强大的矩阵和向量引擎
- 用于小批量预测的大型片上内存
- 支持半精度浮点运算
2. DL预测的特点
表示模型
论文将模型分为三类，排序与推荐、CV、NLP。
排序与推荐
推荐可以表达为事件概率预测问题，而ML模型预测的是一个或多个事件的概率。
模型的输入为dense和sparse特征，sparse特征的embedding表常常包括上亿的参数，而全连接层(FC)只有少量的参数。虽然推荐中往往同时预测多个item，可以通过batch实现FC的高性能运算，但整个模型的执行一般是内存密集的embedding查表：随机从表中读取很大数目的列向量。
未来趋势
- 模型探索：时间引入模型
- 更大的Embedding，更多sparse特征和更大Embedding维数能提升模型效果。
CV
论文讲到三类应用：图像分类、目标检测、视频理解。
目标检测比图像分类更加耗时，原因：检测因为精度原因需要高分辨率；Faster-RCNN最后的卷积块需要在许多小型空间区域做batch。
视频理解传统上采用帧采样的手段，而最近的3D卷积因为能同时利用时域和空域信息精度更高而得到了广泛的应用。
未来趋势
- 模型探索：共享主干，精调最后几层。
- 卷积类型，源于移动端预测的group/depth-wise卷积因为精度和FLOP效率的原因在数据中心也更多的使用。
- Large Activations与Batch Size，都需要更大的片上内存
NLP
未来趋势
- 模型探索：增加层数和模型组合可以提高翻译质量，但会导致更大的NMT模型。
- 并行：RNN的依赖使得难以并行。
- Batch Size：即时翻译一般适合用小batch预测，而为了本地化的大规模预测可以使用更大的batch size。
计算特点
FB的DL计算量与系统社区通常研究的有显著不同
- Embedding层占模型空间很大(10G+)，但计算密度很低。Embedding查询操作对新存储技术和专用硬件是很好的机会：高带宽内存(HBM)带宽更高但容量有限；非易失内存(NVM)相比DRAM更经济，但一方面带宽低，另一方面embedding表的低时间本地性(temporal locality)使得缓存很有挑战。
- 最近的模型能从更大的片上内存空间受益。推荐的FC层和NMT模型使用小batch，因此性能由片外内存带宽决定。对CV模型来说，片上内存越大耗时越低。
- 涉及的基础运算更多的是高瘦矩阵或向量，而非方矩阵运算。因此既需要节能的矩阵矩阵引擎来执行计算密集模型的高FLOP运算，也需要强大的向量引擎来处理其他模型。
计算内核
计算中耗时最高的依次为FC、embedding lookup和tensor变换。
推荐和NMT模型batch小，CV模型分组卷积输出少量channel时，矩阵矩阵运算变窄，更像是矩阵向量运算，性能由BLAS3降级为BLAS2。
3. 性能优化
性能分析
DL的模型、特征、tensor时刻在变，需要持续监控性能指标，为此FB实现了Op级别的性能监控，可以判定每层瓶颈是计算还是内存带宽。机器上的agent会上报每层的性能信息，包括执行时间、内存带宽、实际的FLOP/s。
降低精度预测
虽然移动端广泛使用了降低精度预测，但数据中心尚未如此。一方面，移动平台使用了精度换计算量的模型，而服务端倾向于精度高但计算量大的模型，而且核心服务的模型（如feed流，反欺诈）对精度要求更高（<1%的结果变化）。另一方面，通用CPU对高性能降低精度预测支持不佳。
性能挑战
X86处理器支持单精度与半精度浮点数转换，但没有原生的半精度(fp16)计算指令。X86使用一系列指令来实现32位累加的8位整型乘法，仅比fp32的计算呑吐高33%。使用16位累加的话会比fp32高2倍，但精度下降很多，除非结合感知异常点的量化。VNNI指令集支持高性能32位累加的int8乘法，但x86架构尚不支持。
- 如果内存带宽是性能瓶颈，使用fp16存储权重或者使用32位累加的8位乘法能增加2到4倍的计算强度。虽然指令数没有下降，但加速比正比于节省的内存带宽。FB设计实现了FBGEMM，用于DL预测的降低精度线性代数库。
- 如果指令吞吐是性能瓶颈，使用16位累加的8位乘法且定期溢出到32位累加器能够达到fp32的2倍的计算吞吐。为了防止饱和和精度下降，论文使用了感知异常点的量化将权重与异常点区分开来。权重分为2部分，W = Wmain + Woutlier，则计算也分为两部分，XWTmain使用16位累加，XWToutlier使用32位累加。
FB的优化表明根据性能瓶颈使用不同的量化技术是有用的，比如主要节省存储和带宽的量化技术应该使用embedding层、小批量的FC层和depth-wise卷积来做测试。FB的感知异常点量化经验表明高性能稀疏线性代数库既对剪枝模型有用也对降低精度的未剪枝模型有用。
精度挑战
应对精度挑战的技术
- 细粒度量化。相比每个tensor使用一套量化参数，更细粒度的量化是有必要的，例如FC中的每个输出特征量化、Embedding表的逐项量化。
- 感知量化的训练。对满足精度要求是有用的，如fake quantization（用于模拟量化引入的错误）
- 选择性量化。移动端使用端到端量化，但数据中心需要对精度敏感的部分回退到fp32。论文系统的测试每层量化引入的错误，错误过高则不做量化。
- 感知异常点的量化。忽略异常点后，取值空间会进一步缩小，利用这点进行量化
- 感知网络的量化。考虑相邻OP进一步减小值域，如OP后面是ReLU的话可以排除负数范围
软件挑战
DL预测涉及的矩阵形状更小且高瘦。对高瘦矩阵需要均摊packing的成本。对DL来说大量的运算并不是严格的矩阵乘法：卷积运算可以表达为im2col紧跟矩阵乘法，达不到最高性能，需要将卷积提升为一等公民；甚至FC因为有bias项也不能仅用GEMM实现，为了节省内存带宽bias应该融合到GEMM中；ReLU等常用OP也应该支持融合。
Google gemmlowp, Intel MKL-DNN, FBGEMM各有所长。
全图优化
常用的全图优化包括OP融合、消除数据移动、OP调度、inter与intra OP的多线程并行。论文的主要工作针对OP fusion，一方面寻找值得人工优化的收益最高的机会，另一方面寻找更广泛的编译器自动生成kernel的机会。
具体做法为：寻找所有频繁执行的子图并按融合带来的潜在加速排序，使用融合前后的性能来评估潜在加速。排除掉某些模式的子图，如包括非数据并行OP的子图。最后运行top-k算法。
4. 应用驱动的硬件协同设计方向
- 工作负荷多样性。DL模型有多样的计算模型，矩阵并不是方的。DL模型对内存子系统有多样的时而冲突的需求。
- 数据中心的要求。对精度的要求更高，如2-3%的精度下降是不可接受的。为了降低精度下降，预测硬件需要支持按channel量化，对精度敏感的部分回退到fp16或bfloat16运算。
- 服务隔离。DL预测都峰值FLOPs、内存容量、带宽有很高的要求，会影响同机部署的其他类型的服务。
- DL model与硬件协同设计。虽然能耗预算、片上内存、片外内存带宽更为珍贵，但模型优化研究只针对减少浮点数运算。