概述 | AI 框架部署方案之模型部署

模型訓(xùn)練重點關(guān)注的是如何通過訓(xùn)練策略來得到一個性能更好的模型，其過程似乎包含著各種“玄學(xué)”，被戲稱為“煉丹”。整個流程包含從訓(xùn)練樣本的獲?。ò〝?shù)據(jù)采集與標注），模型結(jié)構(gòu)的確定，損失函數(shù)和評價指標的確定，到模型參數(shù)的訓(xùn)練，這部分更多是業(yè)務(wù)方去承接相關(guān)工作。一旦“煉丹”完成（即訓(xùn)練得到了一個指標不錯的模型），如何將這顆“丹藥”賦能到實際業(yè)務(wù)中，充分發(fā)揮其能力，這就是部署方需要承接的工作。

因此，一般來說，學(xué)術(shù)界負責(zé)各種 SOTA(State of the Art) 模型的訓(xùn)練和結(jié)構(gòu)探索，而工業(yè)界負責(zé)將這些 SOTA 模型應(yīng)用落地，賦能百業(yè)。

這個問題主要源于中心服務(wù)器云端部署和邊緣部署兩種方式的差異 云端部署常見的模式是，模型部署在云端服務(wù)器，用戶通過網(wǎng)頁訪問或者 API 接口調(diào)用等形式向云端服務(wù)器發(fā)出請求，云端收到請求后處理并返回結(jié)果。邊緣部署則主要用于嵌入式設(shè)備，主要通過將模型打包封裝到 SDK，集成到嵌入式設(shè)備，數(shù)據(jù)的處理和模型推理都在終端設(shè)備上執(zhí)行。

針對上面提到的兩種場景，分別有兩種不同的部署方案，Service 部署和 SDK 部署。  Service 部署：主要用于中心服務(wù)器云端部署，一般直接以訓(xùn)練的引擎庫作為推理服務(wù)模式。SDK 部署：主要用于嵌入式端部署場景，以 C++ 等語言實現(xiàn)一套高效的前后處理和推理引擎庫（高效推理模式下的 Operation/Layer/Module 的實現(xiàn)），用于提供高性能推理能力。此種方式一般需要考慮模型轉(zhuǎn)換（動態(tài)圖靜態(tài)化）、模型聯(lián)合編譯等進行深度優(yōu)化

部署的核心目標是合理把控成本、功耗、性價比三大要素。

成本問題是部署硬件的重中之重，AI 模型部署到硬件上的成本將極大限制用戶的業(yè)務(wù)承受能力。成本問題主要聚焦于芯片的選型，比如，對比寒武紀 MLU220 和 MLU270，MLU270 主要用作數(shù)據(jù)中心級的加速卡，其算力和功耗都相對于邊緣端的人工智能加速卡MLU220要低。至于 Nvida 推出的 Jetson 和 Tesla T4 也是類似思路，Tesla T4 是主打數(shù)據(jù)中心的推理加速卡，而 Jetson 則是嵌入式設(shè)備的加速卡。對于終端場景，還會根據(jù)對算力的需求進一步細分，比如表中給出的高通驍龍芯片，除 GPU 的浮點算力外，還會增加 DSP 以增加定點算力，篇幅有限，不再贅述，主要還是根據(jù)成本和業(yè)務(wù)需求來進行權(quán)衡。

在數(shù)據(jù)中心服務(wù)場景，對于功耗的約束要求相對較低；在邊緣終端設(shè)備場景，硬件的功耗會影響邊緣設(shè)備的電池使用時長。因此，對于功耗要求相對較高，一般來說，利用 NPU 等專用優(yōu)化的加速器單元來處理神經(jīng)網(wǎng)絡(luò)等高密度計算，能節(jié)省大量功耗。

不同的業(yè)務(wù)場景對于芯片的選擇有所不同，以達到更高的性價比。從公司業(yè)務(wù)來看，云端相對更加關(guān)注是多路的吞吐量優(yōu)化需求，而終端場景則更關(guān)注單路的延時需要。在目前主流的 CV 領(lǐng)域，低比特模型相對成熟，且 INT8/INT4 芯片因成本低，且算力比高的原因已被廣泛使用；但在NLP或者語音等領(lǐng)域，對于精度的要求較高，低比特模型精度可能會存在難以接受的精度損失，因此 FP16 是相對更優(yōu)的選擇。在 CV 領(lǐng)域的芯片性價比選型上，在有 INT8/INT4 計算精度的芯片里，主打低精度算力的產(chǎn)品是追求高性價比的主要選擇之一，但這也為平衡精度和性價比提出了巨大的挑戰(zhàn)。

上面簡要介紹了部署的主要方式和場景，以及部署芯片的選型考量指標，接下來以 SDK 部署為例，給大家概括介紹一下 SenseParrots 在部署中的整體流程。SenseParrots 部署流程大致分為以下幾個步驟：模型轉(zhuǎn)換、模型量化壓縮、模型打包封裝 SDK。

4.1 模型轉(zhuǎn)換

模型轉(zhuǎn)換主要用于模型在不同框架之間的流轉(zhuǎn)，常用于訓(xùn)練和推理場景的連接。目前主流的框架都以 ONNX 或者 caffe 為模型的交換格式，SenseParrots 也不例外。SenseParrots 的模型轉(zhuǎn)換主要分為計算圖生成和計算圖轉(zhuǎn)換兩大步驟，另外，根據(jù)需要，還可以在中間插入計算圖優(yōu)化，對計算機進行推理加速（諸如常見的 CONV/BN 的算子融合）。

計算圖生成是通過一次 inference 并追蹤記錄的方式，將用戶的模型完整地翻譯成靜態(tài)的表達。在模型 inference 的過程中，框架會記錄執(zhí)行算子的類型、輸入輸出、超參、參數(shù)和調(diào)用該算子的模型層次，最后把 inference 過程中得到的算子信息和模型信息結(jié)合得到最終的靜態(tài)計算圖。

在計算圖生成之后與計算圖轉(zhuǎn)換之前，可以進行計算圖優(yōu)化，例如去除冗余 op，計算合并等。SenseParrots 原生實現(xiàn)了一批計算圖的精簡優(yōu)化 pass，也開放接口鼓勵用戶對計算圖進行自定義的處理和優(yōu)化操作。

計算圖轉(zhuǎn)換是指分析靜態(tài)計算圖的算子，對應(yīng)轉(zhuǎn)換到目標格式。SenseParrots 支持了多后端的轉(zhuǎn)換，能夠轉(zhuǎn)換到各個 opset 的 ONNX、原生 caffe 和多種第三方版本的 caffe?？蚣芡ㄟ^算子轉(zhuǎn)換器繼承或重寫的方式，讓 ONNX 和 caffe 的不同版本的轉(zhuǎn)換開發(fā)變得更加簡單。同時，框架開放了自定義算子生成和自定義算子轉(zhuǎn)換器的接口，讓第三方框架開發(fā)者也能夠輕松地自主開發(fā)實現(xiàn) SenseParrots 到第三方框架的轉(zhuǎn)換。

4.2 模型量化壓縮

終端場景中，一般會有內(nèi)存和速度的考慮，因此會要求模型盡量小，同時保證較高的吞吐率。除了人工針對嵌入式設(shè)備設(shè)計合適的模型，如 MobileNet 系列，通過 NAS(Neural Architecture Search) 自動搜索小模型，以及通過蒸餾/剪枝的方式壓縮模型外，一般還會使用量化來達到減小模型規(guī)模和加速的目的。

量化的過程主要是將原始浮點 FP32 訓(xùn)練出來的模型壓縮到定點 INT8(或者 INT4/INT1) 的模型，由于 INT8 只需要 8 比特來表示，因此相對于 32 比特的浮點，其模型規(guī)模理論上可以直接降為原來的 1/4，這種壓縮率是非常直觀的。另外，大部分終端設(shè)備都會有專用的定點計算單元，通過低比特指令實現(xiàn)的低精度算子，速度上會有很大的提升，當然，這部分還依賴協(xié)同體系結(jié)構(gòu)和算法來獲得更大的加速。

量化的技術(shù)棧主要分為量化訓(xùn)練（QAT, Quantization Aware Training）和離線量化（PTQ, Post Training Quantization）, 兩者的主要區(qū)別在于，量化訓(xùn)練是通過對模型插入偽量化算子（這些算子用來模擬低精度運算的邏輯），通過梯度下降等優(yōu)化方式在原始浮點模型上進行微調(diào)，從來調(diào)整參數(shù)得到精度符合預(yù)期的模型。離線量化主要是通過少量校準數(shù)據(jù)集（從原始數(shù)據(jù)集中挑選 100-1000 張圖，不需要訓(xùn)練樣本的標簽）獲得網(wǎng)絡(luò)的 activation 分布，通過統(tǒng)計手段或者優(yōu)化浮點和定點輸出的分布來獲得量化參數(shù)，從而獲取最終部署的模型。兩者各有優(yōu)劣，量化訓(xùn)練基于原始浮點模型的訓(xùn)練邏輯進行訓(xùn)練，理論上更能保證收斂到原始模型的精度，但需要精細調(diào)參且生產(chǎn)周期較長；離線量化只需要基于少量校準數(shù)據(jù)，因此生產(chǎn)周期短且更加靈活，缺點是精度可能略遜于量化訓(xùn)練。實際落地過程中，發(fā)現(xiàn)大部分模型通過離線量化就可以獲得不錯的模型精度（1% 以內(nèi)的精度損失，當然這部分精度的提升也得益于優(yōu)化策略的加持），剩下少部分模型可能需要通過量化訓(xùn)練來彌補精度損失，因此實際業(yè)務(wù)中會結(jié)合兩者的優(yōu)劣來應(yīng)用。

量化主要有兩大難點：一是如何平衡模型的吞吐率和精度，二是如何結(jié)合推理引擎充分挖掘芯片的能力。比特數(shù)越低其吞吐率可能會越大，但其精度損失可能也會越大，因此，如何通過算法提升精度至關(guān)重要，這也是組內(nèi)的主要工作之一。另外，壓縮到低比特，某些情況下吞吐率未必會提升，還需要結(jié)合推理引擎優(yōu)化一起對模型進行圖優(yōu)化，甚至有時候會反饋如何進行網(wǎng)絡(luò)設(shè)計，因此會是一個算法與工程迭代的過程。

4.3 模型打包封裝 SDK

實際業(yè)務(wù)落地過程中，模型可能只是產(chǎn)品流程中的一環(huán)，用于實現(xiàn)某些特定功能，其輸出可能會用于流程的下一環(huán)。因此，模型打包會將模型的前后處理，一個或者多個模型整合到一起，再加入描述性的文件（前后處理的參數(shù)、模型相關(guān)參數(shù)、模型格式和版本等）來實現(xiàn)一個完整的功能。因此，SDK 除了需要一些通用前后處理的高效實現(xiàn)，對齊訓(xùn)練時的前后處理邏輯，還需要具有足夠好的擴展性來應(yīng)對不同的場景，方便業(yè)務(wù)線同學(xué)擴展新的功能?？梢钥吹?，模型打包過程更多是模型的進一步組裝，將不同模型組裝在一起，當需要使用的時候?qū)⑦@些內(nèi)容解析成整個流程（pipeline）的不同階段（stage），從而實現(xiàn)整個產(chǎn)品功能。

另外，考慮到模型很大程度是研究員的研究成果，對外涉及保密問題，因此會對模型進行加密，以保證其安全性。加密算法的選擇需要根據(jù)實際業(yè)務(wù)需求來決定，諸如不同加密算法其加解密效率不一樣，加解密是否有中心驗證服務(wù)器，其核心都是為了保護研究成果。

PS：歡迎大家關(guān)注 AI 框架技術(shù)分享專欄內(nèi)容，如果有感興趣的技術(shù)內(nèi)容和難點歡迎隨時指出，可以多多評論留言。我們也希望能通過本次技術(shù)分享讓大家了解到更多的 AI 框架前沿技術(shù)，也期待和大家一起探討，更歡迎大家加入我們，一同為 AI 框架及 AI 發(fā)展貢獻力量！感興趣的小伙伴兒歡迎加入小 P 家，簡歷投遞：[email protected]

整理不易，點贊三連↓