前言

模型训练完成后，到在线部署是其所必须要做的一步，伴随模型结构复杂/算力增加，打造低延时/低资源占用的模型预测服务是模型上线的关键；

tensorflow 很早就开源了tf-serving（代码连接：https://github.com/tensorflow/serving），虽然在性能上多有诟病，但我们仍然可以从其设计/实现上发现一个模型推理服务应该具备什么样的功能

阅读本文后，希望读者可以：

1. 了解tf-serving的基本架构/流程
2. 了解生产环境的中模型推理服务会遇到的问题及常用优化思路

一、TF-Serving整体架构

在TF-Serving的文档（https://github.com/tensorflow/serving/blob/master/tensorflow_serving/g3doc/performance.md）中，用一个序列图描述了一次推理请求的调用栈：

在这里插入图片描述

上图比较简洁，我这里再画个图补充下：
在这里插入图片描述

上图中主要包含几点：

函数调用流程
底层依赖TensorFlow
CPU/GPU异构硬件平台的支持

二、模型推理服务

依据TF-Serving的架构，我们可以抽象出一个模型推理服务框架，如下：

在这里插入图片描述
上图中主要包括了几点：

2.1 自定义模型格式

TF-Serving仅支持 saved_model.pb格式，其他深度学习框架在在线推理的场景下，也有相应的解决方案（如ONNXRuntime等）。

从本质上讲，模型数据仅仅保存了训练得到的参数，理论上只需要模型服务实现了读取格式协议，然后推理时正确使用即可。

但另一方面，在线推理、服务真实上线部署时，可能会遇到各种问题，如：

TB级别（超过单机规格）的模型如何上线服务
如何做增量更新
在线如何对模型结构进行优化

等等，要解决上述的问题，一般需要根据业务场景和服务框架自定义模型格式。

2.2 模型链路的时效性

如果模型链路需要的时效性不强，一般**天级的模型更新（第T天的样本数据，第T+1天上线）**即可满足业务需求；

如果业务需要有时效性的需求，模型的训练/产出/更新频次需要进化到 “小时级/分钟级”（样本数据从曝光到Serving上线的时间间隔在小时/分钟），甚至是流式框架；

这对模型服务的数据管理提出了更高的要求，可能会遇到以下的问题：

如何设计合适的数据协议格式？达到在时间的限制下完成数百GB模型更新的效果
更新时，服务的稳定性如何保证？（常见新模型上线后，平响/999线会有飙升，接收流量一段时间后平响才会趋于平稳）

2.3. 硬件平台的支持与优化

一般模型的复杂度和业务场景相关：

算力需求较少（模型结构简单+业务峰值流量少），一般可以进行CPU部署；
算力需求较大，且工程指标要求高（如模型结构复杂 + 业务峰值流量高 + 业务峰值流量下 平响/失败率 要求严格），需要CPU + GPU的异构部署；

这就导致了模型推理服务 仅支持单平台不够，往往需要支持多平台的异构部署（通常方案是CPU + GPU）

另外提下：在搜索/推荐等包含大量稀疏特征的场景中，模型推理在不同的阶段有不同的特点：

（1）稀疏特征的处理，更偏向于 “IO-bound（IO密集型）”，在生产环境中，容易受限的是IO 是访存和网络
（2）网络计算的处理，更偏向于“CPU-bound（计算密集型）”

针对如上特点，模型服务在完成部署后还需要针对相应的硬件平台进行优化，从开源方案中，一般有以下几种优化点：

1. CPU

CPU在不同的部署下，负责的事情不一样：

CPU部署，一般是网络计算，另外如果在PS架构中，做访存也比较多（如查询KV-Embedding等）
CPU+GPU 异构部署，CPU仅负责网络IO、线程调度、H2D等轻量级任务

根据以上任务，CPU平台有如下的优化点：

充分发挥指令集的优势，如充分利用AVX指令集，减少流程中执行周期，指令周期内操作更多的数据
充分发挥计算库的优势，一般DNN网络比较简单，MLP占了绝大部分的计算资源，这种情况可以使用MKL等矩阵乘计算库进行加速

2. GPU

GPU 有 2个特点：

算力供给高（单位时间提供更多的浮点运算次数）
显存带宽高（以 NVIDIA A10显卡为例，显存24GB，显存带宽达到了600GB/s，相比之下相连的PCIE 带宽仅有64GB/s）

因此，可以将以下2种操作放在GPU上实现：

计算密集型的网络计算
访存密集型的操作，譬如HashTable的Lookup 以及 Reduce Sum

以上是针对 GPU的硬件特点提出的具体操作，但能否充分发挥出GPU的性能还与具体实现相关

一般而言，我们用以下几个指标来量化工作效果：
（1）服务的吞吐/平响
（2）GPU利用率

3. SSD

整体模型推理服务上，要提供的一个功能是计算，还有一个功能是存储（如特征/KV-Embedding的存储），

从存储介质来看，一般 访问带宽越高/成本越高，由于搜索/推荐场景中的数据存在冷热不均的特点，在不降低（或微降）服务性能的前提下，使用成本更低的存储介质有了可能。

整体思路是依据访问频次不同，将数据分别放置在带宽/成本不同的存储介质上

部分开源的框架实现了GPU Memory -> CPU Memory -> SSD 的三级缓存架构，达到节省成本的目的，如：

oneflow框架的OneEmbedding（一块GPU训练TB级推荐模型不是梦，OneEmbedding性能一骑绝尘）
DeepRec框架的Embedding多级存储（Embedding多级存储）

4. 网络传输

如果数据过大单机难以放下的时候，在线可能会需要分布式部署，这个时候网络带宽可能会成为瓶颈。

这种情况下，伴随着硬件/网络协议的升级可以缓减这方面的问题（如RDMA协议，brpc框架在v1.4.0版本中增加了对RDMA的支持，减少了网络传输中协议栈的开销）

以上仅举了4个典型的硬件场景以及相关的优化点，但实际生产环境远比这个复杂的多，需要针对实际问题具体分析优化

三、总结

这篇主要是以TF-Serving为基础，简单介绍了生产环境中模型推理服务所面临的问题。

针对搜索/推荐等稀疏特征场景，有不少开源的训练框架（如xdl/DeepRec/HugeCtr等），但由于在线推理过程与业务逻辑强相关，实现上与业务/部署较多的耦合在一起，各个公司也大多是基于自身的业务对模型推理服务进行深度定制优化，很少有能普适的开源高性能模型推理框架。

而且模型推理服务是整个推荐系统中最不可或缺的一环，是算法能否落地的关键。其 工程指标+稳定性+性能 要求是整条链路中最高的一个阶段。

针对构建高性能模型推理服务，xdl项目（https://github.com/alibaba/x-deeplearning/blob/master/blaze/serving/README.md）中给出了以下几点优化建议，列出来供有相关需求的同学参考：

使用别的高性能的rpc框架而不是HTTP服务，毕竟HTTP协议栈耗时在这种场景下并不是可忽略的。
客户端与服务端之间的通讯使用protocol的BinaryFormat而不是JsonFormat，这将大大提高序列化/反序列化的效率。
在ModelManager类中创建blaze::predictor的对象池，而不是在每个session中重复创建和销毁。
使用memcpy来将Blaze output中的数据拷贝到返回消息的protobuf中，而不是像此示例中一个一个赋值。（然而这种做法依赖与protobuf的实现，可能造成兼容性问题）

另后续的工程篇会继续介绍针对搜索/推荐等特征稀疏场景的开源框架，这样大家能对模型推理服务的问题/开发有更深层次的了解

本文仅简单的提到模型服务的在线推理可能会遇到的问题，工作的中的许多优化涉及到业务细节不能分享。想进一步了解的同学可以看下美团分享的这篇文章，分享了大规模模型工程的实践中的问题以及优化点，梳理的很详细：外卖广告大规模深度学习模型工程实践