Bert语义在360搜索中的探索实践-工程优化

奇技 · 指南

Bert模型网络结构较深，参数量庞大，将Bert模型部署成在线服务在实时性和吞吐上面临巨大挑战。本文主要介绍360搜索将Bert模型部署成在线服务的过程中碰到的一些困难以及做的工程方面的优化。

1

背景

在360搜索场景下对在线Bert服务的延迟和吞吐有极高的要求。经过前期的调研探索和试验，将Bert模型做成在线服务主要有以下3个挑战：

1. 模型参数量巨大。12层Bert模型有超过1亿参数量，相比于其他语义模型计算量高很多。

2. 推理时间长。经验证，12层Bert模型在CPU上延迟约为200ms，在GPU上未经优化的推理延迟为80ms，在搜索这个场景下如此性能是不可接受的。

3. 推理计算量大，需要的资源多。经过压测验证，单个机房需要几百张GPU卡才能承接全部的线上流量，投入的成本远高于预期收益。

基于以上几个困难点，我们前期调研了TF-Serving、OnnxRuntime、TorchJIT、TensorRT等几个热门的推理框架，在比较了是否支持量化、是否需要预处理、是否支持变长、稳定性和性能以及社区活跃度等几个维度后，最终选用了Nvidia开源的TensorRT。确定了框架选型之后，我们针对Bert在线服务做了几个不同层面的优化。

2

Bert在线服务优化

框架层面提供的优化

TensorRT推理框架本身提供的优化有：

1. 层间融合和张量融合。本质是通过减少核函数调用次数来提高GPU利用率。

2. Kernel自动调优。TensorRT会在目标GPU卡上选择最优的层和并行优化算法，保证最优性能。

3. 多流执行。通过共享权重的方式并行处理多条任务流，优化显存。

4. 动态申请Tensor显存。当Tensor使用时再真正申请显存，显著提高显存利用率。

5. 模型量化。在保证精度的情况下大幅提升模型的吞吐，同时降低推理延迟。

知识蒸馏

12层Bert模型的线上延迟不能满足性能要求，我们将其蒸馏至6层的轻量级小模型。做完知识蒸馏后，在降低计算量的同时也保