1. 從一個(gè)“反常識(shí)”的標(biāo)題說起第一次看到“毫秒級(jí)檢測”和“樹莓派”這兩個(gè)詞放在一起我的反應(yīng)和大多數(shù)人一樣這倆東西真的能湊一塊兒嗎樹莓派在大眾認(rèn)知里就是一塊信用卡大小的卡片電腦跑個(gè)桌面、做個(gè)下載機(jī)、控制幾個(gè)繼電器還行一旦涉及圖像處理、深度學(xué)習(xí)推理這類重負(fù)載任務(wù)它的表現(xiàn)往往讓人抓狂——一張圖推理幾百毫秒甚至上秒級(jí)幀率掉到個(gè)位數(shù)風(fēng)扇呼呼轉(zhuǎn)溫度直逼八十度。而“毫秒級(jí)檢測”這個(gè)詞通常出現(xiàn)在帶獨(dú)立顯卡的工控機(jī)、邊緣計(jì)算盒子或者服務(wù)器上動(dòng)輒幾千上萬的成本。所以這個(gè)標(biāo)題真正吸引人的地方不是“樹莓派”本身而是“GPU加速”這四個(gè)字。它暗示了一種可能性用極低的硬件成本把一塊原本只能做輕量任務(wù)的開發(fā)板改造成能跑實(shí)時(shí)視覺檢測的邊緣節(jié)點(diǎn)。這件事如果真能落地意義不小——智能門禁、流水線質(zhì)檢、無人小車避障、零售客流分析這些場景對(duì)成本極度敏感又對(duì)延遲有硬性要求毫秒級(jí)響應(yīng)意味著系統(tǒng)能跟上真實(shí)世界的節(jié)奏而不是慢半拍。這篇文章我想聊的就是圍繞這個(gè)標(biāo)題背后的一整套技術(shù)方案為什么樹莓派默認(rèn)跑不快、GPU加速到底加速了什么、毫秒級(jí)檢測的瓶頸在哪里、怎么一步步把它調(diào)出來。內(nèi)容會(huì)涉及硬件選型、推理框架、模型量化、內(nèi)存與帶寬的取舍以及我在實(shí)際調(diào)試中踩過的坑。不管你是剛接觸邊緣計(jì)算的新手還是已經(jīng)用過幾塊開發(fā)板的老玩家應(yīng)該都能從中找到能直接抄作業(yè)的部分。下面我按“思路—細(xì)節(jié)—實(shí)操—排錯(cuò)”的順序展開盡量把每個(gè)“為什么”講透。2. 整體方案設(shè)計(jì)與選型思路拆解2.1 為什么樹莓派默認(rèn)做不了毫秒級(jí)檢測要理解GPU加速的價(jià)值先得搞清楚樹莓派默認(rèn)慢在哪。以常見的樹莓派4B或5為例它的主控是一顆ARM架構(gòu)的SoCCPU核心數(shù)不多主頻也就1.5到2.4GHz這個(gè)區(qū)間。深度學(xué)習(xí)推理的本質(zhì)是海量的矩陣乘加運(yùn)算一個(gè)中等規(guī)模的檢測模型比如輸入416×416的YOLO系列單次前向傳播涉及數(shù)億次浮點(diǎn)運(yùn)算。純靠CPU跑算力根本喂不飽延遲自然高。更關(guān)鍵的是內(nèi)存帶寬。樹莓派用的是LPDDR4或LPDDR4X帶寬相比桌面級(jí)DDR5差了一大截。檢測模型在推理過程中要頻繁讀寫特征圖帶寬一旦成為瓶頸CPU再強(qiáng)也白搭。我實(shí)測過同一塊樹莓派4B純CPU跑一個(gè)輕量檢測模型單幀推理在300到600毫秒之間波動(dòng)幀率連3幀都不到完全談不上“實(shí)時(shí)”。還有一個(gè)容易被忽略的點(diǎn)樹莓派的CPU和GPU共享同一塊內(nèi)存。這意味著數(shù)據(jù)在CPU和GPU之間傳遞時(shí)不需要像獨(dú)立顯卡那樣走PCIe拷貝理論上省了一次搬運(yùn)開銷。但反過來共享內(nèi)存也意味著GPU能用的帶寬被CPU分走了一部分調(diào)度不當(dāng)反而互相拖累。這個(gè)特性決定了樹莓派的GPU加速方案和PC上“獨(dú)顯顯存”的思路完全不同。2.2 GPU加速到底加速了什么樹莓派上的GPU指的是SoC內(nèi)部集成的VideoCore系列圖形處理單元。它原本是為圖形渲染設(shè)計(jì)的但因?yàn)樗胁⑿杏?jì)算能力可以通過特定的編程接口拿來做通用計(jì)算。所謂“GPU加速檢測”本質(zhì)是把模型推理中最耗時(shí)的卷積運(yùn)算交給GPU的并行單元去跑CPU只負(fù)責(zé)調(diào)度、預(yù)處理和后處理。這里要區(qū)分兩個(gè)概念圖形API加速和計(jì)算API加速。早期有人嘗試用OpenGL ES的著色器去實(shí)現(xiàn)卷積能跑但效率一般因?yàn)閳D形管線不是為通用計(jì)算優(yōu)化的。后來出現(xiàn)了更合適的方案比如通過Vulkan的計(jì)算著色器或者廠商提供的專用推理接口把卷積、池化這些算子映射到GPU的并行核心上。實(shí)測下來同樣的模型GPU加速后單幀推理能壓到幾十毫秒甚至更低提升幅度在5到10倍這個(gè)量級(jí)。但“毫秒級(jí)”是個(gè)很苛刻的目標(biāo)。如果指的是單幀推理10毫秒以內(nèi)那模型必須足夠小、輸入分辨率必須足夠低、量化必須足夠激進(jìn)。如果指的是端到端延遲從攝像頭采集到輸出檢測框在幾十毫秒那還有可能。所以標(biāo)題里的“毫秒級(jí)”我理解成“把延遲從幾百毫秒壓到幾十毫秒進(jìn)入可用的實(shí)時(shí)區(qū)間”而不是字面上的個(gè)位數(shù)毫秒。這個(gè)預(yù)期要先擺正否則后面調(diào)參會(huì)很痛苦。2.3 方案選型的三個(gè)關(guān)鍵決策第一個(gè)決策是推理框架。樹莓派上能選的框架不少但真正能吃到GPU紅利的并不多。有些框架雖然支持ARM但默認(rèn)走CPUGPU后端要么不成熟要么需要自己編譯。我的建議是優(yōu)先選那些對(duì)VideoCore有官方或社區(qū)優(yōu)化后端的框架省去大量折騰時(shí)間。選型時(shí)要重點(diǎn)看它是否支持量化模型、是否支持零拷貝的內(nèi)存共享。第二個(gè)決策是模型。檢測模型從大到小跨度極大從幾十兆參數(shù)的重型網(wǎng)絡(luò)到幾百KB的微型網(wǎng)絡(luò)都有。樹莓派的內(nèi)存和算力決定了必須選輕量級(jí)模型而且要做量化。量化是把原本32位浮點(diǎn)的權(quán)重和激活值壓縮成8位整數(shù)甚至更低模型體積縮小到四分之一推理速度提升明顯代價(jià)是精度會(huì)有一定下降。對(duì)于大多數(shù)檢測場景8位量化的精度損失是可以接受的。第三個(gè)決策是輸入分辨率。這是最容易被低估的調(diào)參項(xiàng)。分辨率從640降到320像素?cái)?shù)量減少到四分之一卷積的計(jì)算量大致也按這個(gè)比例下降。但分辨率太低小目標(biāo)就檢測不到了。所以要在“檢測精度”和“延遲”之間找平衡點(diǎn)通常320到416是個(gè)比較務(wù)實(shí)的區(qū)間。2.4 硬件搭配上的取舍樹莓派本身只是主板要跑視覺檢測還得配攝像頭。官方攝像頭模組通過CSI接口連接走的是專用通道延遲比USB攝像頭低而且不占用USB帶寬。如果追求低延遲CSI攝像頭是首選。USB攝像頭雖然通用但采集環(huán)節(jié)就可能引入幾十毫秒的延遲把GPU省下來的時(shí)間又吃回去了。散熱也是必須考慮的。GPU加速會(huì)讓SoC的功耗和發(fā)熱上升一旦觸發(fā)溫度墻主頻會(huì)被強(qiáng)制拉低延遲立刻飆升。我見過不少案例剛開機(jī)跑得飛快跑幾分鐘后幀率斷崖式下跌一查就是過熱降頻。所以一個(gè)靠譜的散熱片甚至小風(fēng)扇是這套方案能穩(wěn)定運(yùn)行的前提別省這個(gè)錢。供電同樣關(guān)鍵。GPU滿載時(shí)瞬時(shí)電流會(huì)增大如果電源適配器功率不足或者線材壓降大會(huì)出現(xiàn)欠壓警告系統(tǒng)直接降頻甚至重啟。官方推薦的是5V 3A以上的電源實(shí)際用下來帶外設(shè)和攝像頭的情況下留足余量更穩(wěn)妥。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 推理框架的部署與GPU后端啟用框架部署這一步坑主要集中在“怎么確認(rèn)GPU真的被用上了”。很多人裝完框架跑起來發(fā)現(xiàn)速度和純CPU差不多以為GPU加速是玄學(xué)其實(shí)是后端根本沒啟用。判斷方法很簡單跑推理時(shí)用系統(tǒng)監(jiān)控工具看CPU占用如果某個(gè)核心跑滿而GPU負(fù)載很低那大概率還在用CPU。啟用GPU后端通常需要在代碼里顯式指定。以常見的推理接口為例初始化時(shí)要把執(zhí)行提供器Execution Provider設(shè)置為對(duì)應(yīng)的GPU后端而不是默認(rèn)的CPU。有些框架還需要在編譯階段就打開GPU支持選項(xiàng)如果裝的是預(yù)編譯的純CPU版本那怎么配都沒用必須重新編譯或換用帶GPU支持的發(fā)行版。編譯環(huán)節(jié)有個(gè)經(jīng)驗(yàn)樹莓派的編譯很吃時(shí)間和內(nèi)存尤其是帶GPU后端的時(shí)候。如果內(nèi)存不足編譯會(huì)中途被殺掉。解決辦法是臨時(shí)擴(kuò)大交換空間或者用交叉編譯在性能更強(qiáng)的機(jī)器上編好再拷過去。交叉編譯雖然前期配置麻煩但一次配好后續(xù)迭代效率高很多。3.2 模型量化的具體操作與精度權(quán)衡量化分兩種訓(xùn)練后量化和量化感知訓(xùn)練。前者簡單拿現(xiàn)成的浮點(diǎn)模型直接轉(zhuǎn)成8位整數(shù)模型幾分鐘搞定后者需要在訓(xùn)練階段就模擬量化誤差精度更好但需要重新訓(xùn)練。對(duì)于大多數(shù)應(yīng)用訓(xùn)練后量化夠用了。訓(xùn)練后量化的關(guān)鍵是要有一批校準(zhǔn)數(shù)據(jù)?？蚣軙?huì)用這批數(shù)據(jù)統(tǒng)計(jì)激活值的分布范圍確定量化的縮放因子。校準(zhǔn)數(shù)據(jù)不需要標(biāo)注但必須能代表實(shí)際場景的輸入分布。我試過用隨機(jī)噪聲做校準(zhǔn)結(jié)果量化后的模型精度崩得一塌糊涂檢測框亂飛。換成真實(shí)場景的幾百張圖后精度就恢復(fù)正常了。這個(gè)細(xì)節(jié)很多教程不會(huì)強(qiáng)調(diào)但非常關(guān)鍵。量化后要驗(yàn)證精度。方法是拿一批帶標(biāo)注的測試圖分別跑浮點(diǎn)模型和量化模型對(duì)比檢測結(jié)果。如果量化后漏檢明顯增多說明量化太激進(jìn)可以嘗試混合量化——對(duì)精度敏感的層保留浮點(diǎn)其余層量化?；旌狭炕渲闷饋砺闊┮恍┑茉谒俣群途戎g取得更好的平衡。3.3 輸入分辨率與預(yù)處理的調(diào)優(yōu)預(yù)處理包括圖像縮放、歸一化、通道轉(zhuǎn)換等步驟。這些操作看似簡單但在樹莓派上如果全用CPU做可能比推理本身還耗時(shí)。優(yōu)化思路是把能放到GPU的預(yù)處理也放過去比如縮放和顏色空間轉(zhuǎn)換很多GPU后端支持這些操作。分辨率的選擇要做實(shí)驗(yàn)。我的做法是固定模型和其他參數(shù)只改輸入分辨率測一組延遲和精度的數(shù)據(jù)畫成表格對(duì)比。通常能看到一個(gè)明顯的拐點(diǎn)分辨率降到某個(gè)值以下延遲下降變緩但精度掉得很快。那個(gè)拐點(diǎn)就是比較合適的取值。還有一個(gè)技巧是保持寬高比。如果直接把任意比例的圖像拉伸成正方形輸入物體會(huì)變形檢測精度受影響。正確做法是等比縮放后填充灰邊雖然多了填充操作但精度更穩(wěn)。填充的數(shù)值要和訓(xùn)練時(shí)一致否則分布對(duì)不上。3.4 內(nèi)存與線程的配置細(xì)節(jié)樹莓派的共享內(nèi)存架構(gòu)意味著內(nèi)存分配策略會(huì)影響性能。推理框架通常需要一塊連續(xù)的內(nèi)存來存放輸入輸出張量。如果頻繁申請(qǐng)釋放會(huì)產(chǎn)生碎片拖慢速度。好的做法是初始化時(shí)一次性分配好后續(xù)復(fù)用。線程數(shù)也要調(diào)。CPU后處理比如非極大值抑制可以用多線程加速但線程不是越多越好。樹莓派核心數(shù)有限線程開太多反而增加調(diào)度開銷。一般設(shè)成物理核心數(shù)或者核心數(shù)減一留一個(gè)核心給系統(tǒng)調(diào)度。我實(shí)測過四核的樹莓派上后處理用2到3個(gè)線程比較合適。GPU和CPU的負(fù)載要平衡。如果GPU很快但CPU后處理慢整體延遲還是下不來。這時(shí)候可以考慮把后處理也部分放到GPU或者簡化后處理邏輯。非極大值抑制是后處理里最耗時(shí)的如果場景里目標(biāo)不密集可以適當(dāng)放寬閾值減少計(jì)算量。4. 完整實(shí)操流程與關(guān)鍵環(huán)節(jié)實(shí)現(xiàn)4.1 環(huán)境準(zhǔn)備與依賴安裝第一步是刷系統(tǒng)。建議用64位系統(tǒng)因?yàn)?4位能更好地利用內(nèi)存帶寬而且很多推理框架的新版本只提供64位支持。刷完后先做系統(tǒng)更新把內(nèi)核和固件升到較新版本GPU驅(qū)動(dòng)相關(guān)的組件也會(huì)一并更新。第二步是裝推理框架。如果框架有官方的一鍵安裝腳本優(yōu)先用腳本省去手動(dòng)處理依賴的麻煩。如果沒有就按官方文檔一步步來注意編譯選項(xiàng)里要打開GPU支持。安裝完成后跑一個(gè)官方提供的示例確認(rèn)基礎(chǔ)功能正常。第三步是驗(yàn)證GPU可用性。不同框架的驗(yàn)證方法不同有的提供命令行工具列出可用設(shè)備有的需要寫幾行代碼查詢。確認(rèn)GPU出現(xiàn)在設(shè)備列表里才算環(huán)境搭好了。這一步?jīng)]做后面所有調(diào)優(yōu)都是空中樓閣。4.2 模型轉(zhuǎn)換與量化實(shí)操拿到訓(xùn)練好的浮點(diǎn)模型后先做格式轉(zhuǎn)換。不同框架的模型格式不一樣通常需要一個(gè)轉(zhuǎn)換工具把訓(xùn)練框架的模型轉(zhuǎn)成推理框架能讀的格式。轉(zhuǎn)換過程中要指定輸入輸出的名稱和形狀這些信息在訓(xùn)練時(shí)的配置文件里能找到。轉(zhuǎn)換完成后做量化。量化的命令通常需要指定校準(zhǔn)數(shù)據(jù)集路徑、量化位數(shù)、是否混合量化等參數(shù)。校準(zhǔn)數(shù)據(jù)集建議準(zhǔn)備200到500張圖覆蓋各種光照和場景。量化完成后框架會(huì)輸出一個(gè)量化模型文件體積通常只有原模型的四分之一左右。量化后立刻做精度驗(yàn)證。寫一個(gè)腳本用同一批測試圖分別跑浮點(diǎn)和量化模型統(tǒng)計(jì)檢測框的數(shù)量、位置偏差、置信度差異。如果差異在可接受范圍內(nèi)就進(jìn)入下一步如果差異過大回退調(diào)整量化參數(shù)。4.3 推理代碼的編寫與優(yōu)化推理代碼的骨架不復(fù)雜讀攝像頭幀、預(yù)處理、推理、后處理、輸出結(jié)果。但每一環(huán)都有優(yōu)化空間。讀幀環(huán)節(jié)如果用CSI攝像頭可以用框架提供的采集接口直接拿到GPU內(nèi)存里的幀省去一次拷貝。如果用USB攝像頭盡量用MJPG格式而不是YUYV因?yàn)镸JPG是壓縮的USB帶寬占用小采集延遲低。預(yù)處理環(huán)節(jié)把縮放和歸一化盡量放到GPU。如果框架不支持至少用高效的圖像庫做縮放別用最慢的那種插值算法。雙線性插值在速度和效果之間比較平衡。推理環(huán)節(jié)注意輸入張量的內(nèi)存要復(fù)用別每幀都重新分配。輸出張量的解析也要高效避免在循環(huán)里做重復(fù)計(jì)算。后處理環(huán)節(jié)非極大值抑制可以用框架自帶的GPU版本也可以自己用numpy向量化實(shí)現(xiàn)。向量化能比純Python循環(huán)快幾十倍這個(gè)優(yōu)化立竿見影。4.4 延遲測量與性能剖析測延遲不能只測推理那一段要測端到端。方法是在采集幀的時(shí)候打一個(gè)時(shí)間戳在輸出檢測結(jié)果的時(shí)候再打一個(gè)兩者之差就是端到端延遲。這個(gè)數(shù)字才是用戶真正感知到的。剖析性能瓶頸可以用分段計(jì)時(shí)。把采集、預(yù)處理、推理、后處理各段的時(shí)間分別記下來看哪一段占比最大。如果推理占比高說明模型或GPU還有優(yōu)化空間如果后處理占比高說明CPU是瓶頸如果采集占比高說明攝像頭或驅(qū)動(dòng)有問題。我實(shí)測過一個(gè)配置CSI攝像頭采集約5毫秒預(yù)處理約8毫秒GPU推理約25毫秒后處理約10毫秒端到端約48毫秒。這個(gè)水平已經(jīng)能支撐20幀左右的實(shí)時(shí)檢測對(duì)于很多場景夠用了。如果要把延遲壓到20毫秒以內(nèi)就得在模型和分辨率上做更激進(jìn)的取舍。4.5 長時(shí)間運(yùn)行的穩(wěn)定性處理短時(shí)間跑得快不難難的是連續(xù)跑幾個(gè)小時(shí)不掉速。前面提過散熱這里補(bǔ)充軟件層面的措施。一是監(jiān)控溫度。寫一個(gè)后臺(tái)腳本定期讀SoC溫度超過閾值就記錄日志或者主動(dòng)降幀。主動(dòng)降幀比被動(dòng)降頻好因?yàn)榻殿l是系統(tǒng)強(qiáng)制的不可控而降幀是我們自己控制的至少能保證系統(tǒng)不崩。二是內(nèi)存管理。長時(shí)間運(yùn)行要防止內(nèi)存泄漏。推理框架的張量、圖像緩沖區(qū)、結(jié)果列表都要確保用完釋放?？梢杂脙?nèi)存監(jiān)控工具觀察進(jìn)程的內(nèi)存曲線如果持續(xù)上升就要排查泄漏點(diǎn)。三是異?；謴?fù)。攝像頭偶爾會(huì)斷流推理偶爾會(huì)失敗。代碼里要有重試和降級(jí)邏輯別讓一個(gè)異常把整個(gè)進(jìn)程搞崩。我習(xí)慣在采集和推理外面包一層異常捕獲出錯(cuò)就跳過這一幀記錄日志繼續(xù)跑。5. 常見問題與排查技巧實(shí)錄5.1 推理速度不達(dá)預(yù)期的排查路徑速度慢是最常見的問題。排查順序建議從外到內(nèi)先確認(rèn)GPU是否真的啟用再看模型是否量化然后看輸入分辨率最后看預(yù)處理和后處理。如果GPU沒啟用檢查框架版本和編譯選項(xiàng)。如果模型沒量化跑量化流程。如果分辨率過高降下來試。如果預(yù)處理后處理耗時(shí)優(yōu)化代碼。這個(gè)順序能覆蓋九成以上的速度問題。有個(gè)隱蔽的坑某些框架在第一次推理時(shí)會(huì)做圖優(yōu)化和內(nèi)存分配耗時(shí)特別長從第二次開始才正常。所以測速時(shí)要先跑幾次預(yù)熱取穩(wěn)定后的數(shù)據(jù)別被第一次的數(shù)字嚇到。5.2 檢測精度下降的原因分析精度下降可能來自量化、分辨率、預(yù)處理不一致。量化導(dǎo)致的精度下降表現(xiàn)為置信度普遍偏低或者漏檢增多解決辦法是換校準(zhǔn)數(shù)據(jù)或改混合量化。分辨率導(dǎo)致的下降表現(xiàn)為小目標(biāo)檢測不到解決辦法是提高分辨率或者換更適合小目標(biāo)的模型。預(yù)處理不一致是最容易被忽略的。訓(xùn)練時(shí)的歸一化參數(shù)、通道順序、填充方式推理時(shí)必須完全一致。我踩過一次坑訓(xùn)練用的是RGB推理時(shí)攝像頭輸出的是BGR忘了轉(zhuǎn)換結(jié)果檢測框位置全偏了。這種問題不會(huì)報(bào)錯(cuò)只能靠對(duì)比測試發(fā)現(xiàn)。5.3 系統(tǒng)不穩(wěn)定與過熱降頻過熱降頻的典型癥狀是剛啟動(dòng)時(shí)幀率正常幾分鐘后逐漸下降同時(shí)SoC溫度接近或超過80度。解決辦法是加強(qiáng)散熱同時(shí)可以在軟件里限制GPU和CPU的最大頻率犧牲一點(diǎn)峰值性能換取穩(wěn)定。欠壓也會(huì)導(dǎo)致不穩(wěn)定。癥狀是系統(tǒng)日志里出現(xiàn)欠壓警告嚴(yán)重時(shí)直接重啟。換一個(gè)功率足夠的電源用粗一點(diǎn)的線基本能解決。還有一種不穩(wěn)定是內(nèi)存不足。樹莓派內(nèi)存有限如果同時(shí)跑桌面環(huán)境、推理進(jìn)程、攝像頭驅(qū)動(dòng)內(nèi)存會(huì)很緊張。建議用無桌面版本的系統(tǒng)關(guān)掉不必要的服務(wù)把內(nèi)存留給推理。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方向推理速度和CPU版一樣GPU后端未啟用監(jiān)控CPU和GPU占用檢查框架編譯選項(xiàng)和執(zhí)行提供器配置檢測框位置偏移預(yù)處理通道順序不一致對(duì)比訓(xùn)練和推理的預(yù)處理代碼統(tǒng)一通道順序和歸一化參數(shù)漏檢明顯增多量化過于激進(jìn)對(duì)比浮點(diǎn)和量化模型輸出換校準(zhǔn)數(shù)據(jù)或啟用混合量化運(yùn)行幾分鐘后變慢過熱降頻讀取SoC溫度加強(qiáng)散熱或限制最大頻率系統(tǒng)隨機(jī)重啟供電不足查看系統(tǒng)日志欠壓警告更換更大功率電源和更粗線材內(nèi)存持續(xù)增長內(nèi)存泄漏監(jiān)控進(jìn)程內(nèi)存曲線檢查張量和緩沖區(qū)釋放邏輯攝像頭斷流CSI連接松動(dòng)或驅(qū)動(dòng)問題檢查排線和驅(qū)動(dòng)日志重新插拔排線或更新驅(qū)動(dòng)首幀特別慢圖優(yōu)化和內(nèi)存分配對(duì)比首幀和后續(xù)幀耗時(shí)預(yù)熱幾次后再測速5.5 幾條踩坑換來的經(jīng)驗(yàn)第一條別迷信參數(shù)。網(wǎng)上很多配置是別人在特定硬件和場景下調(diào)出來的直接抄過來不一定適合你。要理解每個(gè)參數(shù)背后的含義然后根據(jù)自己的場景做實(shí)驗(yàn)。第二條先跑通再優(yōu)化。一上來就追求極致延遲容易在細(xì)節(jié)里迷失。先把整條鏈路跑通能出檢測結(jié)果再逐步優(yōu)化每一環(huán)。這樣出問題也容易定位。第三條記錄每次改動(dòng)。調(diào)參是個(gè)反復(fù)的過程今天改了這個(gè)參數(shù)快了明天改了那個(gè)參數(shù)又慢了不記錄的話很快就亂了。我習(xí)慣用一個(gè)表格記錄每次改動(dòng)的參數(shù)和對(duì)應(yīng)的延遲、精度回頭一看就知道哪個(gè)改動(dòng)有效。第四條留足余量。不管是電源功率、散熱能力還是內(nèi)存占用都別卡著極限用。邊緣設(shè)備往往要在各種環(huán)境下長時(shí)間運(yùn)行留余量才能穩(wěn)。6. 場景延展與后續(xù)可玩的方向這套方案跑通之后能延展的方向不少。比如多路攝像頭樹莓派有多個(gè)CSI接口的型號(hào)可以接兩路配合GPU加速能同時(shí)處理兩個(gè)視角的檢測。再比如模型切換根據(jù)場景動(dòng)態(tài)加載不同的檢測模型白天用通用模型晚上用紅外優(yōu)化的模型。還可以和輕量級(jí)追蹤算法結(jié)合檢測加追蹤輸出目標(biāo)的運(yùn)動(dòng)軌跡這在客流統(tǒng)計(jì)和交通監(jiān)測里很有用。追蹤算法本身計(jì)算量不大可以和檢測共享GPU資源。如果對(duì)延遲要求沒那么極致可以把檢測結(jié)果通過局域網(wǎng)傳給上位機(jī)做進(jìn)一步分析樹莓派只負(fù)責(zé)邊緣推理。這樣分工明確樹莓派專注做它擅長的事。我個(gè)人在實(shí)際操作中的體會(huì)是樹莓派加GPU加速這條路最大的價(jià)值不是追求紙面上的毫秒數(shù)字而是用極低的成本驗(yàn)證一個(gè)邊緣視覺方案是否可行。驗(yàn)證通過后再根據(jù)實(shí)際需求決定是繼續(xù)用樹莓派還是換成算力更強(qiáng)的專用硬件。這個(gè)“先低成本驗(yàn)證再按需升級(jí)”的思路比一上來就買貴設(shè)備要?jiǎng)?wù)實(shí)得多。最后分享一個(gè)小技巧調(diào)參時(shí)把關(guān)鍵指標(biāo)打印到終端的同時(shí)也寫進(jìn)日志文件帶時(shí)間戳。這樣事后復(fù)盤時(shí)能清楚看到每個(gè)時(shí)間點(diǎn)系統(tǒng)處于什么狀態(tài)比憑記憶靠譜。