上線影片推理服務 使AI應用更高效

解碼 → NV12轉RGB → 前處理 → 模型推理 → 後處理 → RGB轉NV12 → 編碼

如果編解碼在CPU上完成，推理在GPU完成，還會多出在記憶體和視訊記憶體之間搬移資料的環節。1080p一幀圖片RGB原資料大小為5.93MB。按兩倍影片速率計算，一秒鐘需要在記憶體和視訊記憶體之間傳輸的資料量為：2x24x5.93x2=569.28MB。按照3GB/s的傳輸速度（Pageable Data Transform），大約需要190ms。也就是說大約20%時間，會花費在資料傳輸上。

1. 所有操作都在GPU完成，並且支援批次推理；

2. 前後處理及推理過程都透過python指令碼完成；

3. 完整方案包括影片下載，處理，上傳流水線並行服務。
   

本方案的第二特點是最獨特的亮點，解決DeepStream內部黑盒操作方式，最大化使用自由度。我們採用使用者自定義python指令碼，來載入模型和執行推理，大大增加了業務適配和驗證工作的速度。本方案提供的python環境預裝了Tensorflow，PyTorch，cupy，opencv等常見的演算法庫，覆蓋了大多數基本功能。同時也支援自定義CUDA kernel呼叫，解決長尾和效能需求。

一些模型還有複雜的前後處理要求。開始部署時，對資源的需求量比較少，透過指令碼快速開發，將一些基礎操作組合起來，實現業務快速落地，儘早評估模型效果，加快迭代速度。如果反饋結果比較好，業務擴大服務規模，資源需求變得龐大。這時我們可以針對計算瓶頸，使用CUDA API編寫計算kernel，提高計算效率，節省大量成本。

我們最終的期望是，演算法工程師可以自行使用SDK來除錯推理功能，確認結果，以減少平臺工程師介入。同時，SDK還提供了操作計時功能，可用於分析效能瓶頸。

常見使用場景是，一個服務通常會使用多個模型進行推理，然後使用boosting演算法取得更加可靠的結果。本方案可以輕鬆支援多模型推理，只要視訊記憶體容量滿足需求，甚至可以同時對Tensorflow和PyTorch的模型進行推理。

在不同計算框架間，進行資料交換，是這個方案面臨的重要問題。深度學習開發社群提出了DLPack協議，來解決這個問題。因為DLPack沒有做資料搬移，效能損失可以忽略。這個協議一推出就得到PyTorch，mxnet，cupy等框架的支援。但是在專案開發時，Tensorflow還沒有不支援DLPack功能。Google工程師建議，將視訊記憶體資料搬移到記憶體中，生成一個numpy物件後，再傳送到Tensorflow Session。這樣一來，把資料保持在視訊記憶體的設計就被打破了。我們透過編寫了特殊的Tensorflow OP，解決了這個問題。這個OP將視訊記憶體中的資料複製到指定變數中，推理時使用指定變數作為輸入。但在使用這個特殊OP時，呼叫者需要保證傳遞的資料不能超過目標變數的空間。

值得慶幸的是，社群開發了tfdlpack-gpu來完成這個目標。這個特殊OP也完成了它的歷史使命。

在解決長影片變換問題之後，我們嘗試將這個服務擴充套件到短影片推理業務上。短影片推理服務多用於稽核、打標籤等業務中，使用場景多為同步線上服務。這就對整個請求延遲要一定的要求。業務願意用更多的資源來換取更低的請求延遲，所以這類服務線上上的GPU利用率比長影片服務更低。

要達到低延遲的目標，常見的辦法是降低處理資料量。其中一個典型的方法是，只對短影片的關鍵幀做處理。一兩分鐘的影片，關鍵幀的數量為10到20個。這方式可以透過一次推理就能取得結果。

但是為長影片構建的流水線，在短影片上表現得並不好。因為在開始解碼前，我們需要對硬體解碼器做初始化，通常會花費大約110ms。推理的耗時大概也在100ms左右，實際端到端延遲是純推理耗時的大約兩倍。經過仔細閱讀手冊，我們發現一個解決辦法：對硬體編碼器進行重新配置，而不是重新初始化。拿到第一幀資料的時間從110ms縮短到15ms。最終得到的結果是，推理時間佔比大於85%。

經過愛奇藝技術產品團隊的細緻調優後，影片影像增強專案最終吞吐速率比ffmpeg方案提升了10倍，相同的任務使用的資源量只有原來的10%。這樣因為資源使用量減少了，所以影片影像增強專案中，運營同學就可以把節約的資源更多的用於擴大影片增強的覆蓋範圍。