字节跳动模型大规模部署实战

动手点关注

干货不迷路

1. 背景介绍

在字节跳动，基于深度学习的应用遍地开花，工程师关注模型效果的同时也需要关注线上服务一致性和性能，早期这通常需要算法专家和工程专家分工合作并紧密配合来完成，这种模式存在比较高的 diff 排查验证等成本。

随着 PyTorch/TensorFlow 框架的流行，深度学习模型训练和在线推理完成了统一，开发者仅需要关注具体算法逻辑，调用框架的 Python API 完成训练验证过程即可，之后模型可以很方便的序列化导出，并由统一的高性能 C++ 引擎完成推理工作。提升了开发者训练到部署的体验。

然而，完整的服务通常还存在大量的预处理/后处理等业务逻辑，这类逻辑通常是把各种输入经过加工处理转变为 Tensor，再输入到模型，之后模型的输出 Tensor 再加工成目标格式，一些典型的场景如下：

• Bert

• Resnet

我们的目标就是为以上端到端的过程，提供自动化且统一的训练、推理方案，减轻人工开发推理过程、对齐 diff 等一系列问题，实现大规模的统一部署方案。

2. 核心问题

PyTorch/TensorFlow 等框架相对已经解决了模型的训练/推理统一的问题，因此模型计算本身不存在训推一体的问题了（算子性能优化不在本次讨论范围）。

核心要解决的问题就是：预处理和后处理需要提供高性能训推一体的方案。

对于此类逻辑，TensorFlow 2.x 提供了 tf.function(还不完善)，PyTorch 提供了 TorchScript，其无一例外都是选择了原生 Python 语法子集。  但即使强大如此，仍然存在不可忽略的问题：

• 性能：此方案大多基于虚拟机实现，虚拟机方案灵活并且非常可控，但深度学习框架中的虚拟机大多通常性能不够优良。补充说明一下，框架早期都是为 Tensor 计算设计，数组计算每个算子成本很高，虚拟机的派发和调度成本可以忽略。但是，移植到程序语言编程层面开销难以忽略，代码写多了就会成为性能瓶颈。据测试，TorchScript 解释器性能只有 Python 的 1/5 左右，tf.function 性能更差一些。

• 功能不全：事实上应用到真实场景中，我们仍然可以找出很多 tf.function/TorchScript 不支持的重要功能，比如：自定义的资源不能打包，只能序列化内置类型；字符串只能做 bytes 处理，中文等 unicode 会造成 diff；容器必须同构，不支持自定义类型等等...

再者，还有很多非深度学习任务，比如在自然语言处理中仍然有很多非深度学习的应用或者子任务，如序列标注，语言模型解码，树模型的人工特征构造等任务，这些通常具有更灵活的特征范式，但同时都没有完整实现端到端的训推一体方案，仍然有大量的开发以及正确性校验工作。

为了解决上述问题，我们开发了一套基于编译的预处理方案：MATXScript！

3. MATXScript

在深度学习算法开发中，开发者通常使用 Python 进行快速迭代和实验，同时使用 C++ 开发高性能的线上服务，其中正确性校验和