突破深度模型线上耗时瓶颈，我们做了什么？

广告投放是深度模型应用较为普遍的场景之一，虽然深度模型能够提升业务效果，但往往也会付出更加高额的耗时开销。滴滴现今 DSP（Demand-Side Platform） 业务场景中，耗时问题已然成为限制模型发挥的魔咒，为了打破魔咒，我们探索了一套解决方案，可以让深度模型极大限度摆脱耗时困扰。

原理概述

背景

DSP 先前的线上深度模型基于 CPU + Tensorflow Feature Column 的方式实现，借助 Tensorflow 框架和 Feature Column 的结构化数据处理能力以快速构建深度模型。该方式带来便利的同时，也会牺牲推理性能，随着业务策略迭代日趋深入，性能问题也愈发凸显。

DSP 参竞链路有着严格的耗时要求，策略模型筛选素材并给出最终结果的 P99 耗时需要控制在 40ms 内。当前精排模型 P99 耗时已经超过 30ms，超过 75% 的计算都消耗在精排阶段，其导致 DSP 链路上各个阶段都难以开展优化。

DSP 系统各部分理想情况下的耗时：

在排除网络开销和模型本身问题后，我们发现耗时主要消耗在计算上，因此尝试切换 GPU 进行计算以提高计算性能。单纯的计算场景下 GPU 的确拥有更高的性能，但是用于 Tensorflow 模型推理，耗时却不降反增，经过深入分析，我们发现问题出在了 Feature Column 上。

由于硬件架构差异，Feature Column 特征处理无法完全在 GPU 上进行，部分特征处理过程会被转到 CPU 上，设备之间切换反而会影响整体性能， 其中部分字符串转换操作还会涉及到内存复制与分配，尤为耗时。

降低耗时的核心是分离模型计算和特征处理，为此，我们提出了一套特征外置方案来解决这个问题，并开发了一套同时支持在线和离线的特征处理组件 EzFeaFly（Easy Feature Fly）。

基本原理

当前架构下，DSP 算法能力由两套服务共同支持，策略端服务承接业务系统的预估请求，获取特征后调用模型推理服务进行预估。

为了剥离特征处理部分，我们在 Tensorflow 中彻底舍弃了 Feature Column。策略端服务获取特征后直接利用 EzFeaFly 处理特征，随后传入模型推理服务。传入特征经过插件转换成 Tensor 之后直接喂入模型进行推理计算。

新的方案在保持整体系统架构不变的情况下，优化了整体各方资源的利用效率：

• 解耦特征处理与计算：合理分配计算资源，特征处理并发提效，模型计算利用 GPU 提效；

• 特征处理行为一致性：线上和离线使用同一套工具处理特征，处理结果的一致性有保障。