1. 為什么在端側(cè) AI 時代回頭啃 CNN 不是走彎路很多人聽說我在嵌入式崗位上干了幾年之后反而掉頭去把卷積神經(jīng)網(wǎng)絡(luò)從最底層重新學(xué)一遍第一反應(yīng)都是你是不是搞反了方向。畢竟現(xiàn)在打開任何一個技術(shù)社區(qū)滿屏都是大模型、Transformer、端側(cè)部署量化推理這些詞CNN 看起來像是上個時代的產(chǎn)物。但我自己踩過一圈坑之后越來越確信在嵌入式到端側(cè) AI 的這條路徑上CNN 不是過時的東西而是繞不開的地基。先說清楚這個判斷的背景。嵌入式開發(fā)和端側(cè) AI 部署本質(zhì)上都受同一組約束支配算力有限、內(nèi)存有限、功耗有限、實(shí)時性要求高。你在服務(wù)器上可以隨手堆幾百億參數(shù)但在一個只有幾百 KB RAM、主頻幾百 MHz 的 MCU 上或者在一個算力被嚴(yán)格限制的邊緣設(shè)備上每一個乘加運(yùn)算、每一次內(nèi)存搬運(yùn)都要精打細(xì)算。CNN 恰好是理解計算量從哪來、內(nèi)存帶寬怎么被吃掉、精度和速度怎么權(quán)衡這件事最直觀的載體。它的結(jié)構(gòu)足夠簡單簡單到你可以在紙上把一層卷積的乘加次數(shù)算清楚又足夠典型典型到幾乎所有端側(cè)推理框架的優(yōu)化手段——算子融合、權(quán)重量化、內(nèi)存復(fù)用、Winograd 變換——都是圍繞它發(fā)展出來的。我決定重新從 CNN 開始還有一個很現(xiàn)實(shí)的原因端側(cè)部署里 80% 的坑根子都在對模型計算過程的理解不夠。你如果只是會調(diào)庫、會跑現(xiàn)成的推理腳本一旦遇到精度掉點(diǎn)、推理變慢、內(nèi)存溢出就完全不知道從哪下手。而當(dāng)你親手把一層卷積的前向傳播、反向傳播、量化誤差都推導(dǎo)過一遍之后再看那些部署工具報出來的日志你會突然發(fā)現(xiàn)每一條都在說人話。這篇文章我想聊的不是CNN 是什么這種教科書內(nèi)容而是站在一個從嵌入式轉(zhuǎn)過來的人的角度把 CNN 和端側(cè) AI 之間那條真實(shí)的連接線講清楚為什么嵌入式背景的人學(xué) CNN 有獨(dú)特優(yōu)勢、CNN 的核心計算到底怎么落到硬件上、量化為什么是端側(cè)的生命線、以及從零搭一個能在端側(cè)跑起來的小模型需要經(jīng)歷哪些環(huán)節(jié)。適合正在做嵌入式、想往端側(cè) AI 轉(zhuǎn)或者已經(jīng)在做端側(cè)部署但總覺得根基不牢的朋友。2. 嵌入式背景學(xué) CNN優(yōu)勢比你想的大得多2.1 你早就懂資源約束這門課做嵌入式的人有一個天然優(yōu)勢就是對資源約束有肌肉記憶。你寫單片機(jī)代碼的時候會下意識地關(guān)心這個變量占幾個字節(jié)、這個循環(huán)會不會被編譯器優(yōu)化掉、這段代碼放在 Flash 還是 RAM 里。這種思維習(xí)慣遷移到 CNN 上簡直是降維打擊。舉個具體的例子。一個普通的卷積層輸入特征圖是 32×32×16卷積核 3×3輸出通道 32。很多人第一反應(yīng)是這不就是個矩陣乘法嘛但如果你有嵌入式背景你會立刻開始算這一層有多少次乘加輸出特征圖每個點(diǎn)要做 3×3×16 144 次乘加輸出一共 32×32×32 32768 個點(diǎn)所以總共約 471 萬次乘加。如果每個乘加按一次 MAC 算在只有幾十 MHz 主頻、沒有硬件加速的 MCU 上這一層就要跑幾十毫秒。這個數(shù)字一出來你就知道為什么端側(cè)模型必須做通道剪枝、必須做量化了。這種先算賬再動手的習(xí)慣是很多從純算法轉(zhuǎn)過來的人欠缺的。他們習(xí)慣性地認(rèn)為算力是無限的直到部署的時候才發(fā)現(xiàn)模型根本跑不動。而你從一開始就會把算力預(yù)算當(dāng)成設(shè)計約束這讓你在設(shè)計模型結(jié)構(gòu)時就有天然的克制。2.2 內(nèi)存布局和訪存模式嵌入式人一看就懂CNN 在硬件上跑得快不快很多時候不取決于計算量而取決于訪存模式。這一點(diǎn)嵌入式開發(fā)者理解起來特別快因為你調(diào)過 DMA、寫過緩存友好的代碼、知道什么叫內(nèi)存對齊。卷積的計算有個特點(diǎn)計算密度其實(shí)不高但訪存很頻繁。以 NHWC 和 NCHW 兩種常見的內(nèi)存布局為例同一個卷積在不同布局下的訪存效率可能差好幾倍。NCHW 布局下通道維是連續(xù)的做逐通道卷積時訪存很友好但 NHWC 布局下空間維連續(xù)做 3×3 卷積時相鄰像素的讀取更連續(xù)。端側(cè)推理框架之所以要針對不同硬件選擇不同布局本質(zhì)就是在優(yōu)化訪存局部性。我在實(shí)際調(diào)試一個端側(cè)模型時遇到過這樣的情況同一個模型只是把輸入張量的內(nèi)存布局從 NCHW 換成 NHWC在某個邊緣設(shè)備上的推理時間就從 45ms 降到了 28ms。原因就是這個設(shè)備的緩存行是 64 字節(jié)NHWC 布局下連續(xù)讀取的像素能更好地填滿緩存行減少了緩存未命中。這種優(yōu)化思路做過嵌入式內(nèi)存優(yōu)化的人幾乎是本能反應(yīng)。2.3 定點(diǎn)數(shù)思維讓你對量化不再恐懼端側(cè) AI 繞不開量化而量化本質(zhì)上就是把浮點(diǎn)運(yùn)算換成定點(diǎn)運(yùn)算。這件事對嵌入式開發(fā)者來說太熟悉了——你在 MCU 上做傳感器數(shù)據(jù)處理的時候早就習(xí)慣了用 Q 格式定點(diǎn)數(shù)來避免浮點(diǎn)運(yùn)算的開銷。量化的核心是把 FP32 的權(quán)重和激活值映射到 INT8 的整數(shù)域。聽起來復(fù)雜但如果你理解定點(diǎn)數(shù)的定標(biāo)原理就會覺得這不過是換了個 scale 而已。一個 FP32 數(shù)值 x 量化成 INT8 的過程是先確定一個縮放因子 s然后 q round(x / s)反量化時 x q × s。這個 s 怎么選、怎么保證量化后精度損失最小就是量化算法的核心。而嵌入式開發(fā)者對精度和范圍的權(quán)衡這件事早就在 ADC 采樣、PWM 占空比這些場景里練過無數(shù)遍了。提示如果你之前沒接觸過定點(diǎn)數(shù)建議先花半天時間把 Q 格式比如 Q15、Q7的加減乘除和溢出處理搞清楚再回頭看量化會發(fā)現(xiàn)概念是通的。3. 把 CNN 的計算拆到硬件層面才算真正理解它3.1 一層卷積到底在算什么很多人學(xué) CNN 的時候腦子里是一張張漂亮的示意圖但真到了部署階段示意圖幫不上忙。你需要把卷積拆成硬件能執(zhí)行的原子操作。一個標(biāo)準(zhǔn)卷積層輸入張量形狀是 [H, W, C_in]卷積核是 [K, K, C_in, C_out]輸出是 [H_out, W_out, C_out]。它的計算可以拆成四層循環(huán)遍歷輸出通道、遍歷輸出空間位置、遍歷卷積核空間位置、遍歷輸入通道。最內(nèi)層的操作就是一次乘加acc input[...] * weight[...]。這個四層循環(huán)的循環(huán)順序直接決定了訪存效率和能不能做并行。比如把輸出通道放在最外層那么每個輸出通道的計算可以獨(dú)立進(jìn)行適合多核并行把輸入通道放在最內(nèi)層那么內(nèi)層循環(huán)可以連續(xù)讀取輸入和權(quán)重適合向量化指令。端側(cè)推理框架里的im2col GEMM策略本質(zhì)就是把卷積展開成矩陣乘法然后調(diào)用高度優(yōu)化的矩陣乘法庫這樣就能復(fù)用成熟的 BLAS 優(yōu)化。但 im2col 有個代價它會復(fù)制輸入數(shù)據(jù)把內(nèi)存占用放大 K×K 倍。在內(nèi)存緊張的端側(cè)設(shè)備上這個代價有時候不能接受。所以很多輕量級框架會選擇直接卷積direct convolution雖然計算效率低一點(diǎn)但省內(nèi)存。這就是一個典型的端側(cè)權(quán)衡用計算換內(nèi)存還是用內(nèi)存換計算。3.2 感受野、步長、填充這些參數(shù)怎么影響端側(cè)性能感受野、步長、填充這些概念在算法層面是理解模型表達(dá)能力的關(guān)鍵但在端側(cè)部署層面它們直接決定了計算量和內(nèi)存占用。步長stride是最直接的影響因素。步長為 1 的卷積輸出空間尺寸基本不變步長為 2 的卷積輸出尺寸減半計算量直接降到四分之一。所以在端側(cè)模型里早期層經(jīng)常用步長 2 來快速降分辨率減少后續(xù)層的計算量。但步長太大會丟失空間信息影響精度這個平衡點(diǎn)需要根據(jù)具體任務(wù)調(diào)。填充padding影響的是邊界處理。SAME padding 會讓輸出尺寸和輸入一致VALID padding 則會讓輸出縮小。在端側(cè)padding 的處理方式會影響內(nèi)存分配——SAME padding 需要在輸入邊界補(bǔ)零如果實(shí)現(xiàn)得不好會產(chǎn)生額外的內(nèi)存拷貝。有些框架會通過隱式 padding來避免實(shí)際拷貝只在計算時判斷邊界這樣能省下不少內(nèi)存。感受野則是理解模型看到多大范圍的關(guān)鍵。在端側(cè)做目標(biāo)檢測或者語義分割時感受野不夠大會導(dǎo)致模型無法理解全局上下文。但擴(kuò)大感受野的手段——堆更多層、用空洞卷積、用大卷積核——都會增加計算量。所以端側(cè)模型設(shè)計的一個核心矛盾就是在有限算力下怎么用最少的計算獲得足夠大的感受野。MobileNet 用深度可分離卷積、ShuffleNet 用通道混洗本質(zhì)上都是在解這個矛盾。3.3 從乘加次數(shù)到實(shí)際延遲中間隔著什么理論上算出來的乘加次數(shù)MACs和實(shí)際推理延遲之間往往差著好幾倍。這個差距來自哪里是端側(cè)部署必須搞清楚的。第一是內(nèi)存帶寬。很多端側(cè)設(shè)備的算力其實(shí)不弱但內(nèi)存帶寬是瓶頸。卷積層的計算密度每讀一個字節(jié)能做多少次運(yùn)算如果太低那實(shí)際性能就被內(nèi)存帶寬卡死而不是被算力卡死。這就是為什么深度可分離卷積雖然 MACs 大幅降低但在某些設(shè)備上加速比并沒有理論值那么高——因為它的計算密度更低更容易受內(nèi)存帶寬限制。第二是算子啟動開銷。每個算子卷積、激活、池化在硬件上執(zhí)行都有啟動開銷算子越多開銷累積越明顯。所以端側(cè)推理框架會做算子融合把卷積 BN 激活融合成一個算子減少中間結(jié)果的寫回和讀取。這個優(yōu)化在理論上不減少 MACs但實(shí)際延遲能降 20% 到 40%。第三是數(shù)據(jù)搬運(yùn)。模型權(quán)重從 Flash 加載到 RAM、中間特征圖在不同內(nèi)存層級之間搬運(yùn)這些都有開銷。端側(cè)設(shè)備的內(nèi)存層級往往比服務(wù)器簡單但 Flash 讀取速度慢這個問題很突出。所以權(quán)重量化不僅是為了減少計算也是為了減少權(quán)重體積降低加載開銷。影響因素對延遲的影響典型優(yōu)化手段內(nèi)存帶寬計算密度低時成為主瓶頸提高計算密度、算子融合算子啟動開銷算子數(shù)量多時累積明顯算子融合、圖優(yōu)化權(quán)重加載Flash 讀取慢時突出權(quán)重量化、權(quán)重常駐 RAM緩存未命中訪存模式差時嚴(yán)重調(diào)整內(nèi)存布局、分塊計算4. 量化端側(cè) AI 的生命線也是理解 CNN 的最佳切口4.1 為什么端側(cè)幾乎必然要量化在端側(cè)設(shè)備上量化不是可選優(yōu)化而是能不能跑起來的問題。原因有三層。最直接的是內(nèi)存。一個 FP32 的權(quán)重占 4 字節(jié)量化成 INT8 只占 1 字節(jié)模型體積直接降到四分之一。對于一個幾 MB 的模型這意味著能不能塞進(jìn)設(shè)備的 Flash 里。很多低端 MCU 的 Flash 只有 512KB 到 1MB不量化根本放不下。其次是計算速度。INT8 乘加在大多數(shù)端側(cè)硬件上比 FP32 快得多。有些 DSP 或者 NPU 有專門的 INT8 加速單元吞吐量是 FP32 的好幾倍。即使沒有專用硬件INT8 運(yùn)算的功耗也更低這對電池供電的設(shè)備至關(guān)重要。第三是功耗。浮點(diǎn)運(yùn)算的能耗遠(yuǎn)高于整數(shù)運(yùn)算。有研究數(shù)據(jù)表明一次 FP32 乘加的能耗大約是一次 INT8 乘加的十幾倍。在功耗預(yù)算嚴(yán)格的端側(cè)場景量化帶來的功耗下降是決定性的。4.2 訓(xùn)練后量化與量化感知訓(xùn)練怎么選量化有兩條主要路線訓(xùn)練后量化PTQ和量化感知訓(xùn)練QAT。PTQ 是在模型訓(xùn)練完成之后用一批校準(zhǔn)數(shù)據(jù)統(tǒng)計激活值的分布然后確定量化參數(shù)。它的優(yōu)點(diǎn)是簡單快捷不需要重新訓(xùn)練適合快速驗證。缺點(diǎn)是精度損失可能比較大尤其是對那些激活值分布不均勻的模型。PTQ 又分動態(tài)量化和靜態(tài)量化動態(tài)量化在推理時實(shí)時計算激活的量化參數(shù)靈活但開銷大靜態(tài)量化提前算好參數(shù)推理時直接用效率高但需要校準(zhǔn)數(shù)據(jù)。QAT 是在訓(xùn)練過程中就模擬量化誤差讓模型學(xué)會適應(yīng)量化。它的精度通常比 PTQ 好尤其是量化到 INT8 甚至更低比特時。代價是需要重新訓(xùn)練訓(xùn)練過程也更復(fù)雜要在前向傳播里插入偽量化節(jié)點(diǎn)。我的經(jīng)驗是如果模型本身比較小、結(jié)構(gòu)比較規(guī)整PTQ 通常夠用如果模型對精度敏感或者要量化到 8 比特以下QAT 更穩(wěn)。在端側(cè)實(shí)際項目里我一般先用 PTQ 快速跑通流程看精度掉多少如果掉點(diǎn)在可接受范圍內(nèi)就直接用如果掉太多再上 QAT。4.3 量化誤差從哪來怎么定位量化誤差主要來自三個地方權(quán)重量化誤差、激活量化誤差、以及兩者疊加后的累積誤差。權(quán)重量化誤差相對好控制因為權(quán)重是靜態(tài)的可以提前分析分布選擇合適的量化范圍。激活量化誤差更麻煩因為激活值是動態(tài)的不同輸入的激活分布可能差別很大。如果校準(zhǔn)數(shù)據(jù)的分布和實(shí)際推理數(shù)據(jù)不一致激活量化誤差就會很大。定位量化誤差我常用的方法是逐層對比把 FP32 模型和量化模型在同一個輸入上的中間層輸出都 dump 出來逐層算余弦相似度或者相對誤差。哪一層的誤差突然變大問題就出在哪一層。常見的原因是那一層的激活值有長尾分布或者有極端值把量化范圍撐大了導(dǎo)致大部分值被壓縮到很小的量化區(qū)間里。解決手段也有幾種一是對那一層單獨(dú)用更高的比特混合精度量化二是對激活值做截斷把極端值裁掉犧牲一點(diǎn)精度換整體量化效果三是調(diào)整那一層的量化粒度從 per-tensor 改成 per-channel。注意per-channel 量化對權(quán)重的效果通常比 per-tensor 好很多因為不同輸出通道的權(quán)重分布差異可能很大。但 per-channel 量化會增加推理時的開銷因為每個通道要用不同的 scale。在端側(cè)要權(quán)衡。5. 從零搭一個能上端側(cè)的小 CNN完整實(shí)操鏈路5.1 先定約束再設(shè)計結(jié)構(gòu)端側(cè)模型設(shè)計的第一步不是畫網(wǎng)絡(luò)結(jié)構(gòu)而是把約束列清楚。我通常會問自己幾個問題目標(biāo)設(shè)備的 RAM 有多大、Flash 有多大、有沒有硬件加速單元、推理延遲要求是多少、精度底線是多少。這些約束定下來之后模型結(jié)構(gòu)其實(shí)就八九不離十了。舉個例子假設(shè)目標(biāo)設(shè)備有 256KB RAM、1MB Flash、沒有 NPU、要求單幀推理在 50ms 以內(nèi)。那么模型參數(shù)量大概要控制在 100K 到 300K 之間中間特征圖峰值內(nèi)存不能超過 200KB?；谶@些約束我會選擇深度可分離卷積作為基本模塊早期層用步長 2 快速降分辨率通道數(shù)從 16 開始逐步增加到 128 左右最后用全局平均池化代替全連接層來減少參數(shù)。這個設(shè)計過程不是拍腦袋而是每一步都有約束在背后撐著。通道數(shù)為什么從 16 開始因為第一層輸入通道通常是 1 或 3輸出通道 16 已經(jīng)能提取足夠的初級特征再大就浪費(fèi)。為什么用全局平均池化因為全連接層的參數(shù)量通常是整個模型的大頭去掉它能省下大量 Flash。5.2 訓(xùn)練階段的幾個關(guān)鍵設(shè)置端側(cè)模型的訓(xùn)練和普通模型訓(xùn)練有些不一樣的地方這些細(xì)節(jié)直接影響后面能不能順利量化。首先是權(quán)重衰減。端側(cè)模型通常比較小容易過擬合所以權(quán)重衰減要設(shè)得合理。但權(quán)重衰減太強(qiáng)會讓權(quán)重分布過于集中反而不利于量化。我的經(jīng)驗是權(quán)重衰減設(shè)在 1e-4 到 1e-5 之間比較穩(wěn)。其次是BN 層的處理。BN 層在訓(xùn)練時很有用但推理時會被融合進(jìn)卷積。融合的前提是 BN 的參數(shù)已經(jīng)穩(wěn)定所以訓(xùn)練時要確保 BN 的移動平均更新充分。如果訓(xùn)練輪數(shù)太少BN 統(tǒng)計量不準(zhǔn)融合后精度會掉。我一般會在訓(xùn)練后期凍結(jié) BN 的統(tǒng)計量再跑幾輪微調(diào)。第三是激活函數(shù)的選擇。ReLU 是最省算力的但它的輸出沒有上界量化時不好確定范圍。ReLU6 把輸出限制在 0 到 6 之間量化友好得多這也是 MobileNet 系列用 ReLU6 的原因。如果對精度要求高可以用帶參數(shù)的激活函數(shù)但要注意它們對量化的友好程度。5.3 量化實(shí)操從 FP32 到 INT8 的完整流程下面是我常用的量化流程以靜態(tài) PTQ 為例。第一步準(zhǔn)備校準(zhǔn)數(shù)據(jù)。校準(zhǔn)數(shù)據(jù)不需要標(biāo)注但分布要盡量接近實(shí)際推理數(shù)據(jù)。一般準(zhǔn)備 100 到 500 個樣本就夠了。數(shù)據(jù)太少校準(zhǔn)不準(zhǔn)太多浪費(fèi)時間。第二步插入觀測節(jié)點(diǎn)。在模型里插入統(tǒng)計激活值分布的節(jié)點(diǎn)跑一遍校準(zhǔn)數(shù)據(jù)收集每一層激活的最小值、最大值或者直方圖。第三步計算量化參數(shù)。根據(jù)收集到的分布用 KL 散度或者最小化均方誤差的方法確定每一層的 scale 和 zero_point。KL 散度方法會找一個截斷點(diǎn)把長尾部分裁掉讓量化范圍更緊湊。第四步轉(zhuǎn)換模型。把 FP32 的權(quán)重和激活都轉(zhuǎn)成 INT8同時把卷積、BN、激活融合成量化算子。第五步驗證精度。在測試集上跑量化模型對比 FP32 模型的精度。如果掉點(diǎn)超過閾值回到第三步調(diào)整量化策略。# 量化流程的偽代碼示意 def quantize_model(fp32_model, calib_loader): # 1. 插入觀測節(jié)點(diǎn) model prepare_for_quantization(fp32_model) # 2. 跑校準(zhǔn)數(shù)據(jù)收集分布 for batch in calib_loader: model(batch) # 3. 計算量化參數(shù)并轉(zhuǎn)換 quantized_model convert_to_int8(model) # 4. 驗證 acc_fp32 evaluate(fp32_model, test_loader) acc_int8 evaluate(quantized_model, test_loader) print(fFP32 acc: {acc_fp32}, INT8 acc: {acc_int8}) return quantized_model5.4 部署到端側(cè)后的性能調(diào)優(yōu)模型量化完、轉(zhuǎn)換完只是走完了一半。真正部署到設(shè)備上之后還有一輪性能調(diào)優(yōu)。首先要確認(rèn)推理框架用的是不是針對目標(biāo)硬件優(yōu)化過的版本。同一個模型用通用框架和用廠商優(yōu)化過的框架性能可能差好幾倍。廠商的框架通常會針對自家硬件的緩存大小、DMA 特性、加速單元做專門優(yōu)化。其次是內(nèi)存規(guī)劃。端側(cè)推理框架一般會做內(nèi)存復(fù)用把不同層的中間特征圖分配到同一塊內(nèi)存上因為它們的生命周期不重疊。但內(nèi)存復(fù)用算法有好有壞好的算法能把峰值內(nèi)存壓到理論下限附近。如果發(fā)現(xiàn)內(nèi)存占用比預(yù)期高可以檢查一下框架的內(nèi)存規(guī)劃策略。第三是線程和并行。如果設(shè)備是多核的要確認(rèn)推理框架有沒有用上多核。有些框架默認(rèn)單線程需要手動開啟多線程。但多線程也不是越多越好線程太多會有調(diào)度開銷在核數(shù)少的設(shè)備上反而變慢。最后是輸入預(yù)處理和后處理。這兩部分經(jīng)常被忽略但在端側(cè)它們可能占總延遲的很大比例。比如圖像 resize、歸一化、NMS 這些操作如果實(shí)現(xiàn)得不好可能比模型推理本身還慢。我遇到過預(yù)處理占了總延遲 40% 的情況后來把 resize 換成硬件加速才解決。6. 那些只有踩過才知道的端側(cè) CNN 坑6.1 精度掉點(diǎn)不一定是量化的鍋有一次我量化完一個模型精度掉了 5 個百分點(diǎn)第一反應(yīng)是量化策略有問題調(diào)了半天量化參數(shù)都沒用。后來逐層對比才發(fā)現(xiàn)問題出在 BN 融合上——訓(xùn)練時 BN 的移動平均沒更新充分融合后統(tǒng)計量偏移導(dǎo)致精度掉。重新訓(xùn)練并凍結(jié) BN 統(tǒng)計量之后量化精度只掉了 0.5 個點(diǎn)。這個坑讓我養(yǎng)成了一個習(xí)慣精度掉點(diǎn)先查 BN 和算子融合再查量化本身。因為 BN 融合是確定性的數(shù)學(xué)變換如果實(shí)現(xiàn)正確不應(yīng)該掉精度一旦掉了說明 BN 參數(shù)本身有問題。6.2 校準(zhǔn)數(shù)據(jù)的分布比數(shù)量重要另一個常見的坑是校準(zhǔn)數(shù)據(jù)選得不對。我見過有人用訓(xùn)練集的前 100 張圖做校準(zhǔn)結(jié)果這 100 張圖恰好都是某個類別的激活分布嚴(yán)重偏斜量化后其他類別的精度慘不忍睹。校準(zhǔn)數(shù)據(jù)的核心要求是分布覆蓋不是數(shù)量。100 張覆蓋各類別、各場景的圖比 1000 張同質(zhì)化的圖效果好得多。如果實(shí)在不確定可以用聚類的方法從訓(xùn)練集里挑代表性樣本。6.3 端側(cè)設(shè)備的標(biāo)稱算力要打折扣設(shè)備規(guī)格書上的算力數(shù)字和實(shí)際能跑出來的性能往往差很遠(yuǎn)。標(biāo)稱 1 TOPS 的設(shè)備實(shí)際跑 CNN 可能只能發(fā)揮 20% 到 30%。原因很多內(nèi)存帶寬跟不上、算子支持不全、調(diào)度開銷大。所以選型的時候不要只看標(biāo)稱算力要看實(shí)際跑目標(biāo)模型的 benchmark。如果廠商提供了 benchmark 數(shù)據(jù)要看它跑的是什么模型、什么精度、什么 batch size。條件允許的話最好自己拿目標(biāo)模型實(shí)測一下。6.4 別忽略數(shù)值穩(wěn)定性端側(cè)量化模型在極端輸入下可能出現(xiàn)數(shù)值溢出。比如某個激活值在訓(xùn)練集里最大是 10量化范圍定到 10但實(shí)際推理時來了一個激活值 15 的輸入量化后就溢出了輸出完全錯誤。解決辦法是在確定量化范圍時留一點(diǎn)余量或者用飽和處理。但余量留太多會浪費(fèi)量化精度這個平衡要根據(jù)實(shí)際場景調(diào)。如果應(yīng)用場景輸入可控余量可以留小一點(diǎn)如果輸入不可控余量要留足。7. 回頭看這條路該怎么走從嵌入式轉(zhuǎn)到端側(cè) AI再回頭把 CNN 重新啃一遍我最大的體會是這兩件事本來就是一件事。嵌入式的資源約束思維、定點(diǎn)數(shù)思維、訪存優(yōu)化思維和端側(cè) AI 的量化、算子融合、內(nèi)存規(guī)劃底層邏輯是通的。CNN 只是把這些思維應(yīng)用到了一個具體的計算模式上。如果你也在走類似的路我的建議是不要急著去追最新的模型結(jié)構(gòu)先把一個最簡單的 CNN 從訓(xùn)練到量化到部署完整走一遍。走完之后你對端側(cè) AI 的理解會比看十篇綜述都扎實(shí)。具體來說可以拿一個經(jīng)典的圖像分類任務(wù)自己搭一個幾層的小 CNN訓(xùn)練到能用的精度然后量化、轉(zhuǎn)換、部署到一個真實(shí)的端側(cè)設(shè)備上測延遲、測內(nèi)存、測精度。這個過程中遇到的每一個問題都是真正長本事的時刻。至于后續(xù)往哪個方向深入我的看法是先把 CNN 這條線走透再去看 Transformer 在端側(cè)的部署。因為端側(cè) Transformer 的很多優(yōu)化手段——量化、算子融合、內(nèi)存復(fù)用——都是從 CNN 時代積累下來的。地基打牢了上面蓋什么樓都穩(wěn)。