耗時減半？騰訊雲OCR只做了3件事

導讀｜騰訊雲OCR團隊在產品效能的長期最佳化實踐中，結合客戶使用場景及產品架構對服務耗時問題進行了深入剖析和最佳化。本文作者——騰訊研發工程師彭碧發詳細介紹了OCR團隊在耗時最佳化中的思路和方法(如工程最佳化、模型最佳化、TIACC加速等)，透過引入TSA演算法使用TI-ACC減少模型的識別耗時，結合客戶使用場景最佳化編解碼邏輯、對關鍵節點的日誌分流以及與客戶所在地就近部署持續降低傳輸耗時，克服OCR耗時最佳化面臨的環節多、時間短甚至成本有限的問題，最終實現了OCR產品平均耗時從1815ms降低到824ms。希望大家在閱讀中能收穫一些新的思路。

背景介紹

騰訊雲OCR(文字識別)團隊收到客戶反饋稱，騰訊雲OCR在服務可用性和準確率方面都表現出色，但服務耗時還有可觀的提升空間。因此，我所在的團隊決定最佳化騰訊雲OCR服務耗時，為使用者提供更快的文字識別服務。

但是耗時最佳化是一個系統性工程，需要多方的支援和協作。文字識別服務進行耗時最佳化，主要有以下挑戰：

環節多：耗時最佳化涉及多個環節，包括模型演算法、TI-ACC、工程等。各環節都需要分析各自階段耗時，制定完整的耗時最佳化目標。
時間短：客戶耗時最佳化訴求強烈，但是給到的最佳化的時間很短。
成本考量：降本增效大背景下，單純依賴機器的情況一去不復返。耗時最佳化方案也需要考慮成本最佳化。

我們成立了專項團隊進行攻堅。業務團隊從工程最佳化、模型最佳化、TI-ACC最佳化等方面發力，逐步降低服務耗時。最佳化前平均耗時1815ms，最佳化後平均耗時824ms，耗時效能提升2.2倍，並最終得到重要客戶的肯定。接下來將介紹我們在耗時最佳化方面的具體實踐，希望能給遭遇類似問題的你帶來靈感。

分析問題

1）框架和鏈路分析

OCR服務透過雲API接入，內部多個微服務間透過TRPC進行呼叫。基本架構圖如下：

從客戶發起請求到OCR服務處理完成主要鏈路為：

雲API層：請求首先會傳輸到離客戶最近的雲API接入點，雲API接入點會進行相應的鑑權、定址、轉發等操作。
業務邏輯層：文字識別邏輯層服務會對資料做處理、下載、計費、上報等操作。
引擎層：演算法引擎服務對圖片進行處理，識別出文字。

2）主要階段耗時

主要涉及到下面幾個階段的耗時：

客戶傳輸耗時：客戶請求到雲API和雲API響應到客戶鏈路的傳輸耗時在測試過程中發現波動很大。文字識別業務場景下請求傳輸的都是圖片資料，這受客戶網路頻寬和質量的影響大。此外，因客戶請求的文字識別服務在廣州，所以請求需要跨地域。這進一步增加了傳輸耗時。
業務邏輯耗時：業務邏輯中有很多複雜的工程處理，主要耗時點包括資料處理、編解碼、圖片下載、路由、上報等。
演算法引擎耗時：想達到更好的識別效果和泛化性，通用OCR模型會比較複雜。檢測和識別都會涉及到複雜的浮點計算，耗時長。

因此，要最佳化文字識別服務的整體耗時，就需要從各個階段進行詳細分析和最佳化。

3）測試方法和結論

因為客戶生產環境的機器在雲伺服器上，所以為了保持和客戶測試條件一致，我們購買了和客戶相同環境的雲伺服器(含北京、上海、廣州)進行模擬測試，詳細分析文字識別服務各個階段耗時。

端到端耗時為客戶請求發起直到收到響應的總耗時、客戶到騰訊雲API接入點以及雲API響應給客戶存在著公網傳輸的耗時、從雲API接入後就是騰訊雲內網鏈路服務的耗時。端到端耗時主要由客戶傳輸耗時、雲API耗時、業務邏輯層耗時、引擎耗時組成，經過多次請求通用OCR後統計各個階段的平均耗時，具體情況為：

客戶的傳輸耗時佔比很大。主要是因為客戶在北京發起請求，需要跨地域到廣州的服務，存在很大的傳輸耗時，這部分需要我們透過最佳化部署來減低耗時。
在服務鏈路中，業務邏輯處理的耗時也較多。這部分耗時需要我們精益求精，最佳化工程邏輯和架構，進而降低耗時。
文字識別服務的引擎耗時佔比最高。所以我們需要對演算法引擎的耗時進行重點最佳化。

透過詳細的各階段耗時測試可以發現：引擎耗時佔主要部分。所以我們會重點最佳化引擎耗時，這裡的主要手段是模型最佳化和TI-ACC加速。為了做到極致最佳化，我們還透過日誌分流和編解碼最佳化降低了業務邏輯層耗時，同時服務就近多地部署，最佳化了客戶傳輸耗時。

解決問題

1 ）模型最佳化—引入TSA演算法減少模型耗時

最佳化之前耗時長度會隨著文字字數增加顯著變大。引入TSA演算法可以明顯改善這種情況，從而減少模型耗時。

OCR特點與演算法過程分析

基於OCR的特點與難點，OCR問題學術界演算法可以劃分成兩大類：基於CTC (Connectionist Temporal Classification)的流式文字識別方案；基於Attention的機器翻譯的框架方案。

在基於深度學習的OCR識別演算法中，整個流程可以歸納成了四個步驟如下圖: 幾何變換；特徵提取；序列建模；對齊與輸出。CTC方案與Attention方案區別主要是在最後一個步驟。它作為銜接視覺特徵與語義特徵的關鍵橋樑，可以根據上下文影像特徵和語義特徵做精確輸入、輸出的對齊，是OCR模型關鍵的過程。

針對上述特點與耗時問題，我們提出了TSA文字識別模型。

TSA研發背景

研究表明，影像對 CNN 的依賴是非必需的。當直接應用於影像塊序列時，transformer 也能很好地執行影像分類任務。63%耗時在(BiLSTM+Global Attn，或attention形式)序列建模。

識別模型特點

特點1：引入self-attention演算法對輸入影像進行畫素級別建模，並替代RNN完成序列建模。相比CNN與RNN，self-attention不受感受野和資訊傳遞的限制，可以更好地處理長距離資訊。

特點2：設計self-attention計算過程中的掩碼mask。self-attention天然可以“無視”距離帶來的影響，因此需要對輸入畫素間自注意力進行約束。其過程如下圖所示。

總結：透過multi-head self-attention對序列建模，可以將兩個任意時間片的建模複雜度由lstm的O (N)降低到 O(1)，預測速度大幅提升。最佳化後的演算法和文字長度無關，對大文字得到成倍的加速提升。

2 ）TIACC加速最佳化—繼續減少模型耗時

為了進一步降低模型的耗時，我們使用了 TI-ACC進行加速，TI-ACC支援多種框架和複雜場景，面向演算法和業務工程師提供一鍵式推理加速功能。

支援複雜結構模型

OCR任務可以分為兩大類：檢測任務和識別任務。檢測任務和識別任務一般會儲存成兩個獨立的TorchScript模型，每個任務又分為了多個階段。通用OCR檢測任務包含了backbone(RepVGG等)、neck(FPN等）、head（Hourglass等）等部分。

識別任務包含特徵提取部分和序列建模部分。其中特徵提取部分既有傳統CNN網路，也有最新ResT等基於Transformer的網路。序列建模部分既有傳統RNN網路，也有基於Attention的網路。

加速OCR業務模型是對推理加速引擎相容性的考驗。下表分別對比了TIACC和Torch-TensorRT（22.08-py3-patch-v1）對本文模型加速能力：

降低請求延遲並提高系統吞吐

OCR業務不僅模型結構複雜，模型輸入也很有特點。下圖顯示了本文其中一個模型的輸入：

上述輸入包括以下特點：輸入型別多；輸入shape變化範圍大；有些最小shape維度是0；輸入不僅包含Tensor也包含Tuple。僅僅上述模型輸入格式，就會導致一些推理引擎不可用或加速效果不明顯。舉個例子，TensorRT不支援int64輸入、Torch-TensorRT不支援Tuple輸入。輸入變化範圍大會導致推理引擎視訊記憶體消耗過高，導致某些推理引擎加速失敗或無法單卡多路並行推理，進而導致無法有效提升TPS。對於OCR這種大呼叫量業務，TPS提升可以有效降低GPU卡規模從而帶來可觀成本降低。

針對OCR模型shape範圍過大視訊記憶體佔用量高問題，TIACC能透過視訊記憶體共享機制有效降低了視訊記憶體佔用。對於動態shape模型，推理加速引擎在部分shape加速明顯，部分shape反而會效能降低的問題。TIACC透過重寫關鍵運算元、根據模型結構，選擇業務全流程最優的運算元實現，有效解決了實際業務中部分shape加速明顯但整體加速不理想的問題。

透過打磨OCR業務模型，能提升模型的推理延遲。即使多路部署也可以有效提升模型的吞吐。下表顯示了TIACC FP16相比libtorch FP16的加速倍數，數字越高越好。

TIACC底層使用了TNN作為基礎框架，效能強大。其中TNN是優圖實驗室結合自身在AI場景多年的落地經驗，也是向行業開源的部署框架。TIACC基於TNN最新研發的子圖切分功能基礎上做產品化封裝，為企業提供 AI 模型訓練、推理加速服務。它顯著提高模型訓練推理效率，降低成本。

3）工程最佳化——最佳化邏輯和傳輸耗時

編解碼最佳化

文字識別採用微服務架構設計，整體服務鏈路長。其中涉及到TRPC、HTTP、Nginx-PB協議的轉換和呼叫，所以請求和響應需要有很多的編解碼操作。文字識別場景下，請求和響應包體都非常大，RPC協議之間的轉換和編解碼增加了計算耗時。為了進一步降低服務耗時，我們對這些編解碼操作進行了整體的最佳化，減少了協議轉換和編解碼次數。

日誌分流處理

在業務中有很多關鍵節點需要記錄日誌，便於問題定位。在文字識別業務場景下，日誌需要脫敏處理大量識別出的文字資料，寫入速度慢。為了避免日誌操作影響服務響應耗時，我們設計了日誌分流上報服務，將日誌操作全部透過非同步流程上報到其他微服務完成，減少主邏輯耗時。

就近部署—降低傳輸耗時

經過多次詳細測試文字識別業務在北京、上海、廣州區域機器發起請求的耗時差異，我們對跨地域傳輸耗時有了比較明確的認識。服務跨地域請求時（比如在北京發起請求，實際服務部署在廣州），會存在很大的傳輸耗時波動，客戶的使用體驗會下降。因此我們針對通用OCR介面進行了就近多地部署，在服務部署的架構上對耗時進行了最佳化。

在文字識別跨地域請求時，我們進行多地部署。通用OCR介面線上多地部署釋出以後，我們對線上雲API記錄的總耗時監控進行了觀察和對比，耗時有了很明顯的下降——某段時間內耗時從平均1100ms下降到800ms，下降了300ms。

GPU視訊記憶體最佳化-提高系統吞吐

隨著OCR業務功能點越來越多，業務中使用的AI模型越來越多且更復雜，所以對視訊記憶體的要求也越來越大。顯示卡視訊記憶體大小影響服務能開啟併發數，而併發數影響服務的吞吐——所以視訊記憶體往往成為業務吞吐量的瓶頸。

視訊記憶體管理主要就是解決上述問題。其主要思想是解耦合視訊記憶體佔用大小跟服務併發路數之間的關係，提高併發路數不再導致視訊記憶體增大，進而提升服務整體吞吐量；由服務路數實現並行方式轉換為不同模型之間並行方式，提高了GPU計算的並行度，更好的充分利用GPU資源。以通用OCR為例，下圖可以看使用前後GPU利用率變化和視訊記憶體佔用變化。