业务背景

蔚来自动驾驶研发平台（NADP）是着力服务于自动驾驶核心业务方向的研发平台。平台化的推理能力作为常规机器学习平台的重要组成部分，也是 NADP 所重点建设和支持的能力之一。NADP 所支持的推理业务，整体上有以下几个特性：

10% 的业务产生 90% 的流量（优化重点业务收益大）；

追求引擎层的高性能；

要求在算法框架，量化加速维度尽可能强的扩展性，为算法业务的框架选型， 与后续可能的加速方案都提供尽可能的兼容；

多个模型有业务关联，希望能够满足多个模型之间串行/或者并行的调度。

经过对众多方案的对比和筛选，NVIDIA Triton 在上述每一个方面都能满足蔚来的需求。比如，Triton 支持多个模型或模块进行 DAG 式的编排。其云原生友好的部署方式，能够很轻松的做到多 GPU、多节点的扩展。从生产级别实践的稳定性角度来看，即便是一个优秀的开源方案，作为平台级的核心组件，也是需要长时间、高强度的验证，才能放心的推广到最核心业务上。经过半年的使用，Triton 证明了自己，在保证强大功能的前提下，也提供了很好的稳定性。另外，NVIDIA 有着优秀的生态建设与社区支持，提供了优质的 Triton 社区内容和文档共享，保障了 NADP 的核心推理业务迁移到 Triton 方案上，并平稳运行至今。

Triton 在设计之初，就融入了云原生的设计思路，为后面逐步围绕 Triton 搭建完整的云原生平台性推理解决方案提供了相当大的便利。作为 NADP 推理平台的核心组件，Triton 与 NADP 的各个组件形成了一套完整的推理一站式解决方案。接下来，将集中在以下 4 个方面具体叙述 Triton 如何在 NADP 推理平台中提供助力：

集成效率 

高性能

易用性

高可用

Triton + Jupyter

在 Triton 镜像中集成了 Jupyter 组件之后，提供开箱即用的开发调试环境，在遇到复杂问题需要进行线上 debug 或者再线下复现问题时，Jupyter 能够提供一个方便的开发环境供用户进行调试。

Triton + Istio

具体来讲：

集群内容器直接访问只需要一次跨物理机网络转发；

完美复用 k8s 的 readiness 状态，通过和 Triton 节点的 liveness/readniess 探针进行服务的健康监控；

后续结合模型仓库/配置中心提供用户更友好的服务发现方式：基于域名的服务发现方案切换为基于模型的服务发现方案。

Triton + Apollo 配置中心

使用 Apollo 配置中心，可以极大程度提供更多的便利性。将基于域名的服务发现提升为基于模型名的服务发现。用户将不需要了解模型所部署的具体的域名即可访问模型。结合模型仓库，用户可以直接触发模型的部署。

Triton + k8s CRD

围绕 Triton 蔚来搭建了服务 NIO 推理场景的 K8s CRD。它是以下几个 K8s 原生 CRD 或其他自研 CRD 的组合。而这每一个组件都在一定程度上保障了服务的高可用。

自动扩缩容规则（HPA Rule）：进行基于流量的自动扩缩容，在服务流量上升时自动扩容；

Istio service：可靠的 side car 机制，保障 gRPC 流量的服务发现和负载均衡；

Ingress：多实例部署，动态扩容的 Ingress 节点，保障跨集群流量的访问；

k8s deploy：在一个推理实例内管理至少 3 个 Triton Pod，消除了服务的单点问题，并且通过 Triton server 加载多个模型的功能，实现多模型混布共享 GPU 算力，而且消除单点的同时不引入额外的 GPU 资源浪费；

Service Monitor：用于 prometheus 指标的收集，随时监控服务状态，上报异常信息；

Service Heartbeat Probe：集成了 Triton Perf Analyzer 的 Pod。Triton 生态中的 Perf Analyzer 工具能够根据部署的模型 meta 信息生成真实请求并部署为主动请求探针，在没有流量的时候监控服务的健康状态并主动重启异常实例，同时上报异常信息。

Triton + Promethus/Grafana

Triton 提供了一套完整的，基于模型维度的模型服务指标。打点几乎包括了整个服务端推理链路的每个关键节点，甚至能够区分执行推理的排队时间和计算时间，使得能够在不需要进入 debug 模式的情况下进行细致的线上模型服务性能诊断和分析。另外，因为指标的格式支持了云原生主流的 Promethus/Grafana， 用户能够非常方便的配置看板和各维度的报警， 为服务的高可用提供指标支持。

目前，NADP 数据挖掘业务下的相关模型预测服务已经全部迁移至 Triton Inference Server，为上百个模型提供了高吞吐预测能力。同时在某些任务基础上，通过自实现前处理算子、前后处理服务化、BLS 串联模型等手段，将一些模型任务合并起来，极大的提升了处理效率。

通过将服务的前后处理从客户端移动到服务端，不仅能够在网络传输上节省大量的时间，而且 GPU 服务端（Triton）可以用 Nvjpeg 进行 GPU 解码，并在 GPU 上做 resize、transpose 等处理。能够大幅加速前处理，明显减轻 client 端 CPU 计算压力。

传压缩图片，而非 input tensor，只需要几百 KB 就能将一张 2K 原图 bytes 传输过去，以当前  onemodel 2k 输入图片为例，模型输入必须为 1920*1080*3*8 byte 大小，而且必须走网络，而在加入服务端后处理之后，在精度损失允许的范围内，可以将原图改为传压缩过的三通道 720P jpg 图片（1280*720*3），在服务端在 resize 成 1920*1080*3*8 byte，节约大量带宽；

服务端前处理完成后将 GPU 显存指针直接送入模型预测，还能省去 Host2Device 的拷贝；

服务端可以封装模型的后处理，使得每次模型升级的时候，client 端不用感知到服务后处理的变化，从而不需要修改处理逻辑代码；

使用 nvJpeg，DALI 等使用 GPU 算力的组件来进行前后处理，加速整体的数据处理速度。

一个统一的前处理模型，一份输入复制多份到多个后端识别模型，该流程在服务端单 GPU 节点内完成，不需要走网络，在 Triton + bls/ensemble 的支持下，甚至可以节约 H2D、D2H 拷贝。

当业务逻辑强制使用多模型 DAG 式编排多个模型之后，每次产生模型的输入/输出都可以叠加服务端前后处理改造的收益，当前部署的 triton 服务最多使用 BLS 串联了 9 个模型；

对于 2k 分辨率的输入来讲，每帧图片的大小为 1920 * 1080 * 3 * 8 = 47Mb, 假设全帧率为 60fps，则每秒输入数据量为 1920 * 1080 * 3 * 8 * 60 = 2847 Mb。如果使用 bls 串联了 9 个模型，则每秒需要产生的数据传输量为 1920 * 1080 * 3 * 8 * 60 * 9 = 25 Gb = 3GB；

如果使用 PCIe 传输，假设 PCIe 带宽为 160Gb = 20GB 每秒， 则理论上每秒产生的数据可以节约 150ms 在数据传输上；

如果使用网络传输，假设可用带宽为 16Gb=2Gb 每秒，则理论上每秒产生的数据可以节约 1500ms 在数据传输上。

NIO 基于 NVIDIA Triton 搭建的推理服务平台，在数据挖掘业务场景下，通过上文详细介绍的“服务器端模型前处理”和“多模型 DAG 式编排”，GPU 资源平均节省 24%；在部分核心 pipeline 上，吞吐能力提升为原来的 5 倍，整体时延降低为原来的 1/6。

另外，NIO 当前已经实现了输入为原始视频而非抽帧后图片的预研版本工作流上线，但只承载了小部分流量。而主要流量还是使用 jpg 压缩图片作为输入的版本。当前只是使用本地脚本完成了数据加载和模型推理，后续会逐步地将当前流程迁移到 Triton 的模型编排能力上。

关于作者 —— 郭城

 

郭城是 NIO 自动驾驶研发平台（NADP）的高级工程师，负责为 NIO 自动驾驶搭建 可靠高效的推理平台和深度学习模型 CICD 工具链。在加入 NIO 之前，他在小米技术委员会参与了小米集团机器学习平台的搭建。他个人对 ML-ops、以及所有其他深度学习工程相关的主题感兴趣。

欢迎自动驾驶领域的各位有志之士加入 NVIDIA Developer Program，复制链接“https://developer.nvidia.cn/login”在浏览器中打开即可注册（请在 Industry Segment 注册选项中选择 Automotive）。