NADP加Triton搭建穩(wěn)定高效的推理平臺

業(yè)務(wù)背景

蔚來自動駕駛研發(fā)平臺（NADP）是著力服務(wù)于自動駕駛核心業(yè)務(wù)方向的研發(fā)平臺。平臺化的推理能力作為常規(guī)機器學(xué)習(xí)平臺的重要組成部分，也是NADP所重點建設(shè)和支持的能力之一。 NADP所支持的推理業(yè)務(wù)，整體上有以下幾個特性：

10%的業(yè)務(wù)產(chǎn)生90%的流量（優(yōu)化重點業(yè)務(wù)收益大）；

追求引擎層的高性能；

要求在算法框架，量化加速維度盡可能強的擴展性，為算法業(yè)務(wù)的框架選型，與后續(xù)可能的加速方案都提供盡可能的兼容；

多個模型有業(yè)務(wù)關(guān)聯(lián)，希望能夠滿足多個模型之間串行/或者并行的調(diào)度。

經(jīng)過我們從眾多方案的對比和篩選，NVIDIA Triton 能夠在上述每一個方面都能滿足我們的需求。比如，Triton 支持多個模型或模塊進行DAG式的編排。 其云原生友好的部署方式，能夠很輕的做到多GPU、多節(jié)點的擴展。從生產(chǎn)級別實踐的穩(wěn)定性角度來看，即便是一個優(yōu)秀的開源方案，作為平臺級的核心組件，也是需要長時間，高強度的驗證，才能放心的推廣到最核心業(yè)務(wù)上。經(jīng)過半年的使用，Triton證明了自己，在保證強大功能的前提下，也提供了很好的穩(wěn)定性。另外，NVIDIA有著優(yōu)秀的生態(tài)建設(shè)與社區(qū)支持 ，提供了優(yōu)質(zhì)的Triton社區(qū)內(nèi)容和文檔共享，保障了NADP的核心推理業(yè)務(wù)遷移到Triton方案上，并平穩(wěn)運行至今。

引入Triton之后的推理平臺架構(gòu)

Triton 在設(shè)計之初，就融入了云原生的設(shè)計思路，為后面逐步圍繞 Triton 搭建完整的云原生平臺性推理解決方案提供了相當(dāng)大的便利。

作為NADP推理平臺的核心組件，Triton 與 NADP 的各個組件形成了一套完整的推理一站式解決方案。接下來，將集中在以下4個方面具體敘述Triton 如何在NADP推理平臺中提供助力：

集成效率

高性能

易用性

高可用

一、集成效率

Triton + 模型倉庫 + Argo

Triton 與自建模型倉庫深度結(jié)合，配合 workflow 方案 Argo， 完成全自動化的生產(chǎn)，量化，準(zhǔn)入，云端部署，壓測，上線的CICD流程。

具體來講：

模型上傳模型倉庫自動觸發(fā)配置好的workflow；

創(chuàng)建與部署環(huán)境硬件環(huán)境一致容器，自動量化加速；

得益于Triton生態(tài)中提供的perf analyzer， 可以像使用jMeter 一樣方便的按照模型的Input Tensor Shape 自動生成請求與指定的負載。其壓測出的服務(wù)化之后模型的最大吞吐，很接近真實部署場景。

Triton + Jupyter

在Triton鏡像中集成了Jupyter 組件之后，提供開箱即用的開發(fā)調(diào)試環(huán)境，在遇到復(fù)雜問題需要進行線上debug 或者再線下復(fù)現(xiàn)問題時， Jupyter 能夠提供一個方便的開發(fā)環(huán)境供用戶進行調(diào)試。

二、高性能

Triton + Istio

當(dāng)前NADP服務(wù)的業(yè)務(wù)場景，服務(wù)流量大，主要傳輸cv場景視頻文件+高分辨率圖片，必須使用高性能rpc協(xié)議進行加速，而且推理服務(wù)引擎必須對現(xiàn)有的L4 Load Balancer 和服務(wù)發(fā)現(xiàn)方案有比較好的支持性。

而Triton 原生支持gRPC的方案進行訪問，并且能夠很方便的部署為k8s容器。但因為k8s原生service 不能夠很好的對gRPC進行請求級別的負載均衡（僅支持長連接的負載均衡），故在引入了isito 之后，Triton就能夠在傳輸協(xié)議上滿足我們的需求。

具體來講：

集群內(nèi)容器直接訪問只需要一次跨物理機網(wǎng)絡(luò)轉(zhuǎn)發(fā)；

完美復(fù)用k8s 的readiness 狀態(tài)，通過和Triton 節(jié)點的liveness/readniess探針進行服務(wù)的健康監(jiān)控；

后續(xù)結(jié)合模型倉庫/配置中心提供用戶更友好的服務(wù)發(fā)現(xiàn)方式：基于域名的服務(wù)發(fā)現(xiàn)方案切換為基于模型的服務(wù)發(fā)現(xiàn)方案。

三、易用性

Triton + Apollo配置中心

使用Apollo 配置中心，可以極大程度提供更多的便利性。將基于域名的服務(wù)發(fā)現(xiàn)提升為基于模型名的服務(wù)發(fā)現(xiàn)。用戶將不需要了解模型所部署的具體的域名即可訪問模型。結(jié)合模型倉庫，用戶可以直接觸發(fā)模型的部署。

具體來講：

用戶在模型倉庫操作上線之后，將會將模型的真實域名寫入配置中心；

用戶使用NADP提供的客戶端可以從配置中心獲取到服務(wù)的真實域名，并直接訪問服務(wù)；

作為下一步規(guī)劃，當(dāng)前的方案正在逐步遷移到基于開源的model mesh方案的版本上。

四、高可用

Triton + k8s CRD

圍繞Triton 我們搭建了服務(wù)我們NIO的推理場景的K8s CRD。它是以下幾個K8s原生CRD或其他自研CRD的組合。而這每一個組件都在一定程度上保障了服務(wù)的高可用。

自動擴縮容規(guī)則（HPA Rule）：進行基于流量的自動擴縮容，在服務(wù)流量上升時自動擴容；

Istio service： 可靠的side car 機制，保障gRPC流量的服務(wù)發(fā)現(xiàn)和負載均衡；

Ingress： 多實例部署，動態(tài)擴容的Ingress 節(jié)點，保障跨集群流量的訪問；

k8s deploy： 在一個推理實例內(nèi)管理至少3個Triton Pod，消除了服務(wù)的單點問題，并且通過Triton server加載多個模型的功能，實現(xiàn)多模型混布共享GPU算力，而且消除單點的同時不引入額外的GPU資源浪費；

Service Monitor： 用于prometheus 指標(biāo)的收集，隨時監(jiān)控服務(wù)狀態(tài)，上報異常信息；

Service Heartbeat Probe：集成了Triton Perf Analyzer的Pod。 Triton 生態(tài)中的Perf Analyzer 工具能夠根據(jù)部署的模型meta信息生成真實請求并部署為主動請求探針，在沒有流量的時候監(jiān)控服務(wù)的健康狀態(tài)并主動重啟異常實例，同時上報異常信息。

Triton + Promethus/Grafana

Triton 提供了一套完整的，基于模型維度的模型服務(wù)指標(biāo)。打點幾乎包括了整個服務(wù)端推理鏈路的每個關(guān)鍵節(jié)點，甚至能夠區(qū)分執(zhí)行推理的排隊時間和計算時間，使得能夠在不需要進入debug 模式的情況下進行細致的線上模型服務(wù)性能診斷和分析。另外，因為指標(biāo)的格式支持了云原生主流的Promethus/Grafana， 用戶能夠非常方便的配置看板和各維度的報警， 為服務(wù)的高可用提供指標(biāo)支持。

模型的級別時延監(jiān)控

模型的級別的qps監(jiān)控

服務(wù)業(yè)務(wù)場景：數(shù)據(jù)挖掘

目前，NADP數(shù)據(jù)挖掘業(yè)務(wù)下的相關(guān)模型預(yù)測服務(wù)已經(jīng)全部遷移至Triton Inference Server，為上百個模型提供了高吞吐預(yù)測能力。同時在某些任務(wù)基礎(chǔ)上，通過自實現(xiàn)前處理算子、前后處理服務(wù)化、BLS串聯(lián)模型等手段，將一些模型任務(wù)合并起來，極大的提升了處理效率。

服務(wù)端模型前處理

通過將服務(wù)的前后處理從客戶端移動到服務(wù)端，不僅能夠在網(wǎng)絡(luò)傳輸上節(jié)省大量的時間，而且GPU服務(wù)端（Triton）可以用Nvjpeg進行GPU解碼，并在GPU上做resize、transpose等處理。能夠大幅加速前處理，明顯減輕client端CPU計算壓力。

業(yè)務(wù)流程

收益

傳壓縮圖片，而非input tensor， 只需要幾百KB就能將一張2K原圖bytes傳輸過去， 以當(dāng)前onemodel 2k 輸入圖片為例，模型輸入必須為1920*1080*3*8 byte 大小，而且必須走網(wǎng)絡(luò)，而在加入服務(wù)端后處理之后，在精度損失允許的范圍內(nèi)，可以將原圖改為傳壓縮過的三通道720P jpg圖片（1280*720*3），在服務(wù)端在resize 成1920*1080*3*8 byte， 節(jié)約大量帶寬；

服務(wù)端前處理完成后將GPU顯存指針直接送入模型預(yù)測，還能省去Host2Device的拷貝；

服務(wù)端可以封裝模型的后處理，使得每次模型升級的時候，client端不用感知到服務(wù)后處理的變化，從而不需要修改處理邏輯代碼；

使用nvJpeg，DALI等使用GPU算力的組件來進行前后處理，加速整體的數(shù)據(jù)處理速度。

多模型DAG式編排

一個統(tǒng)一的前處理模型，一份輸入復(fù)制多份到多個后端識別模型，該流程在服務(wù)端單GPU節(jié)點內(nèi)完成，不需要走網(wǎng)絡(luò)，在Triton + bls/ ensemble 的支持下，甚至可以節(jié)約H2D， D2H 拷貝；

統(tǒng)一的后處理模型，動機與上述類似。

業(yè)務(wù)流程

收益

當(dāng)業(yè)務(wù)邏輯強制使用多模型DAG式編排多個模型之后，每次產(chǎn)生模型的輸入/輸出都可以疊加服務(wù)端前后處理改造的收益，當(dāng)前部署的triton 服務(wù)最多使用BLS串聯(lián)了9個模型；

對于2k 分辨率的輸入來講，每幀圖片的大小為1920 * 1080 * 3 * 8 = 47Mb， 假設(shè)全幀率為60fps， 則每秒輸入數(shù)據(jù)量為1920 * 1080 * 3 * 8 * 60 = 2847 Mb。 如果使用bls 串聯(lián)了9個模型，則每秒需要產(chǎn)生的數(shù)據(jù)傳輸量為 1920 * 1080 * 3 * 8 * 60 * 9 = 25 Gb = 3GB；

如果使用PCIe傳輸，假設(shè)PCIe帶寬 為160Gb = 20GB每秒， 則理論上每秒產(chǎn)生的數(shù)據(jù)可以節(jié)約150ms在數(shù)據(jù)傳輸上；

如果使用網(wǎng)絡(luò)傳輸，假設(shè)可用帶寬為16Gb=2Gb每秒，則理論上每秒產(chǎn)生的數(shù)據(jù)可以節(jié)約1500ms在數(shù)據(jù)傳輸上。

總結(jié)和展望

NIO 基于 NVIDIA Triton搭建的推理服務(wù)平臺，在數(shù)據(jù)挖掘業(yè)務(wù)場景下，通過上文詳細介紹的 “服務(wù)器端模型前處理”和“多模型DAG式編排”，GPU資源平均節(jié)省24%；在部分核心pipeline上，吞吐能力提升為原來的 5倍，整體時延降低為原來的 1/6。

另外，NIO 當(dāng)前已經(jīng)實現(xiàn)了輸入為原始視頻而非抽幀后圖片的預(yù)研版本工作流上線，但只承載了小部分流量。 而主要流量還是使用jpg壓縮圖片作為輸入的版本。當(dāng)前只是使用本地腳本完成了數(shù)據(jù)加載和模型推理，后續(xù)會逐步地將當(dāng)前流程遷移到Triton的模型編排能力上。

關(guān)于作者

郭城是NIO自動駕駛研發(fā)平臺（NADP）的高級工程師，負責(zé)為NIO自動駕駛搭建可靠高效的推理平臺和深度學(xué)習(xí)模型CICD工具鏈。在加入NIO之前，他在小米技術(shù)委員會參與了小米集團機器學(xué)習(xí)平臺的搭建。他個人對ML-ops、以及所有其他深度學(xué)習(xí)工程相關(guān)的主題感興趣。

審核編輯：郭婷