让算力不再成为瓶颈，小红书机器学习异构硬件推理优化之道

模型特点：以小红书 2022 年底的推荐主模型为例，该模型具有充分的稀疏性， 部分结构由连续值特征和矩阵运算构成， 也存在大规模的稀疏参数比如 < 笔记id * 用户城市 >，单个模型的 sparse 特征多达 1TB，但通过比较有效的模型结构优化，dense 部分控制在 10GB 以内，可放在显存中。用户每刷一次小红书，计算的总 FLOPs 达到了 40B， 超时的控制在 300ms 以内 ( 除去特征处理，带 lookup ) 。

推理框架：在 2020 年之前，小红书采用 TensorFlow Serving 框架作为在线服务框架，2020 年后，逐渐迭代成基于 TensorFlowCore 自研的 Lambda Service 服务。TensorFlow Serving 在进图之前进行一次内存拷贝 TensorProto -> CTensor，以确保模型推理的正确性和可靠性。然而，随着业务规模的扩大，内存拷贝操作会对模型性能产生影响。小红书自研框架通过优化免去一次不必要的拷贝，同时保留 Runtime、图调度能力、优化能力可插拔的特点，并为后期 TRT、BLADE、TVM 等不同优化框架的配合使用奠定了基础。现在看来，在合适的时候选择自研是一个明智的选择， 同时为了最大化减少数据传输带来的成本， 推理框架还承担了一部分特征抽取和转化的实现，这里小红书还在预估服务近侧部署自研的边缘存储， 解决了远端拉取数据的成本问题。

3.1 系统优化

3.1.1 物理机

在物理机优化方面，可以采用一些常规的优化思路， 主要目的是降低除 GPU 以外的其它系统开销成本， 降低虚拟化的中间商赚差价。一般来说，一套系统优化可以提升 1%-2% 的性能，从我们实践来看，需要结合云厂商实际能力来进行优化。

● 中断隔离：将 GPU 的中断单独分离出来，避免因为其他设备的中断而影响 GPU 的计算性能。

● 内核版本升级：提高系统的稳定性和安全性，提高 GPU 驱动程序的兼容性和性能。

● 指令透传：将 GPU 的指令直接透传到物理设备上，加速 GPU 的计算速度。

3.1.2 虚拟化和容器

在多卡情况下，将单个 pod 绑定到特定的 NUMA 节点上，从而提高 CPU 和 GPU 之间的数据传输速度。

● CPU NUMA Affinity，亲和性是指从 CPU 角度来看，哪些内存访问更快，延迟更低。如前所述，与该 CPU 直接相连的本地内存是更快的。因此，操作系统可以根据任务所在 CPU 来分配本地内存，以提高访问速度和性能，这就是基于 CPU NUMA Affinity 的考虑，尽量让任务运行在本地的 NUMA Node 里。在小红书场景里，CPU 上面的访存开销并不小。能够让 CPU 直连本地内存可以节约大量的 CPU 上 kernel 执行的耗时， 从而给 GPU 留足够的空间。

● 将 CPU 使用率控制在 70% 下，可以将延迟由 200ms -> 150ms。

3.1.3 镜像

3.2 计算优化

3.2.1 充分使用算力

● 计算优化，首先需要充分了解硬件性能，将其吃透。在小红书的场景中，如下图所示，我们遇到了两个核心问题：

1. CPU 上的访存较多， 内存 page fault 频率较高，导致 CPU 资源浪费，以及请求 latency 过高

2. 在线推理服务中，计算通常具有两个特点：单次请求的 batch size 小，单个服务的并发规模大。小 batch size 会导致 kernel 无法充分利用 GPU 的计算能力。GPU kernel 执行时间一般较短，无法充分掩盖 kernel launch 的开销，甚至 kernel launch 的时间比 kernel 执行时间还长。在 TensorFlow 中，单个 Cuda Stream launch kernel 成为瓶颈，导致推理场景下 GPU 利用率只有 50% 。此外，对于小模型场景（简单的 dense 网络），用 GPU 替换 CPU 完全不划算，限制了模型的复杂度。

3.2.2 避免算力浪费

a. 初排前置计算：在处理用户侧相关计算时，初排需要计算大量笔记，例如以外流为例，需要计算约 5000 篇笔记，lambda 对其有切片处理。为避免重复计算，将初排的用户侧计算前置到和召回阶段并行，从而使得用户向量的计算从多次重复变成了只需要 1 次，在粗排场景下优化了 40% 机器。

2. 图内训练到推理过程中：

3.2.3 全天动态算力

● 动态计算降级提升全天资源使用效率，秒级别的对 lambda 负载进行自动负反馈调整，做到对单区压测之前不需要人工做降级准备。

● 在外流精排、外流初排、内流精排、内流初排、搜索等主要业务场景均已经上线。

● 在多个业务线解决了容量问题，有效缓解了业务增长导致的资源线性上升，同时大幅提升了系统的鲁棒性。在功能上线后的业务线中，均没有出现因为瞬间成功率大幅下降导致的 P3 及以上事故。

● 大幅提升全天资源使用效率，以内流精排为例（如下图所示），五一假期三天的 10:00-24:00 的 CPU 使用核数均保持 50 核的一条平线（抖动对应发版）

3.2.4 换更好的硬件

3.3.1 DL 栈的自动编译优

● BladeDISC 是阿里最新开源的基于 MLIR 的动态 shape 深度学习编译器， 小红书的自动图优化部分来自于这套框架（ Blade 推理加速库是 Apache 2.0 开源，可以跨任何云使用，无知识产权风险）。该框架提供了 TF 图编译优化（包含 Dynamic Shape Compiler ，稀疏子图优化），同时能叠加我们本身做的算子定制化优化，可以较好的适配我们的业务场景。在压测单机 inference 中，QPS 能提升 20% 。

● 这套框架关键技术

（1） MLIR 基础架构

MLIR，即多层次中间表示语言（Multi-Level Intermediate Representation），是由 Google 发起的开源项目。其目的是提供一个灵活、可扩展的多层 IR 基础设施和编译器实用工具库，为编译器和语言工具的开发者提供一个统一的框架。

MLIR 的设计受到 LLVM 的影响，但与 LLVM 不同的是，MLIR 主要关注于中间表示（ IR ）的设计和扩展。MLIR 提供了一个多层次的 IR 设计，可以支持从高层语言到底层硬件的编译过程，并提供了丰富的基础设施支持和模块化设计架构，使得开发者可以很方便地扩展 MLIR 的功能。此外，MLIR 还具有较强的胶水能力，可以与不同的编程语言和工具进行集成。MLIR 是一个强大的编译器基础设施和工具库，为编译器和语言工具的开发者提供了一种统一的、灵活的中间表示语言，可以方便地进行编译优化和代码生成。

（2） 动态 shape 编译

静态 shape 的限制意味着在编写深度学习模型时需要提前确定每个输入和输出的形状，并且不能在运行时改变它们。这限制了深度学习模型的灵活性和可扩展性，因此需要一种支持动态 shape 的深度学习编译器。

3.3.2 精度调整

● 量化的实现方式之一是使用 FP16

FP16 计算优化：在 MLP 层时用 FP16 替换 FP32 计算，能够较大地减少 GPU 使用率(相对下降 13% )

在调整 FP16 的过程中，选择白盒方式进行精度优化意味着可以更加精细地控制哪些层使用低精度计算，并能够根据经验进行不断调整和优化。这种方式需要对模型结构有较为深入的了解和分析，可以根据模型的特性和计算要求进行有针对性的调整，以达到更高的性价比。

相比之下，黑盒方式则相对简单，不需要了解模型的内部结构，只需要设置一定的容忍阈值即可完成精度优化。这种方式的优点是操作简单，对模型同学的要求也相对较低，但是可能会牺牲一定的性能和精度。

因此，选择白盒还是黑盒方式进行精度优化需要根据具体情况而定。如果需要追求更高的性能和精度，同时拥有足够的经验和技术能力，那么白盒方式可能更加适合。如果操作简单、快速迭代更加重要，那么黑盒方式可能更加实用。