如果要在 Physical AI物理人工智能落地時(shí)只解決一個(gè)問題我會(huì)選延遲如果還能再解決一個(gè)那就是斷網(wǎng)。視覺模型在云端跑得好好的一旦要裝進(jìn) AGV 小車、巡檢機(jī)器人或者工廠產(chǎn)線網(wǎng)絡(luò)抖動(dòng)和推理時(shí)延立刻變成兩道硬坎。這段時(shí)間我把一個(gè)視覺目標(biāo)檢測(cè)模型從云端 GPU 推理遷移到邊緣設(shè)備踩了不少坑也理出一套可復(fù)制的路徑。這篇文章就當(dāng)作一份實(shí)戰(zhàn)復(fù)盤把選型、部署、調(diào)優(yōu)、斷網(wǎng)兜底的思路都寫出來適合正在做邊緣計(jì)算、想在 Jetson 或者邊緣計(jì)算盒子上跑視覺模型的開發(fā)者參考。看完你能知道邊緣側(cè)跑視覺模型到底要跨過哪些坎以及每一步該怎么做。1. 為什么要從云端推向邊緣Physical AI 的剛需場(chǎng)景1.1 Physical AI 到底需要邊緣做什么Physical AI 這個(gè)概念聽起來前沿其實(shí)概括起來就是讓智能系統(tǒng)直接和物理世界打交道感知環(huán)境、做出決策、驅(qū)動(dòng)動(dòng)作。感知這一環(huán)大量依賴視覺模型比如識(shí)別物體、檢測(cè)缺陷、定位目標(biāo)。視覺模型天然吃算力過去大家習(xí)慣把視頻流推到云端去推理形成“端側(cè)采集-云端計(jì)算-端側(cè)執(zhí)行”的閉環(huán)。但是在真實(shí)物理環(huán)境里網(wǎng)絡(luò)不是永遠(yuǎn)穩(wěn)定延遲也不是永遠(yuǎn)可控于是越來越多團(tuán)隊(duì)開始把視覺模型從云端推到邊緣設(shè)備上在攝像頭旁邊、在機(jī)器人本體上直接完成推理。這個(gè)趨勢(shì)背后的邏輯很像“把算力放到數(shù)據(jù)旁邊”。視頻流再清晰傳回云端再返回結(jié)果中間多一道廣域網(wǎng)往返對(duì)實(shí)時(shí)控制類任務(wù)就是致命的。所以現(xiàn)在看到的大量 Physical AI 項(xiàng)目無論工廠機(jī)械臂、AGV、還是戶外巡檢無人機(jī)都在往“邊緣推理”的方向走。你要做的其實(shí)不是拋棄云端而是把云端和邊緣的分工重新設(shè)計(jì)一下邊緣負(fù)責(zé)實(shí)時(shí)推理和現(xiàn)場(chǎng)響應(yīng)云端負(fù)責(zé)訓(xùn)練、管理和歷史數(shù)據(jù)分析。1.2 云端推理的三個(gè)硬傷延遲、斷網(wǎng)、成本我在多個(gè)項(xiàng)目里實(shí)測(cè)過云端視覺推理的延遲一個(gè)最基本的認(rèn)識(shí)是網(wǎng)絡(luò) RTT 只是下限真正的端到端延遲遠(yuǎn)不止這些。假設(shè)攝像頭把一幀 1080P 畫面推上去經(jīng)過編碼、傳輸、云端排隊(duì)、推理、結(jié)果返回整個(gè)鏈路在穩(wěn)定網(wǎng)絡(luò)下也要 200 到 500 毫秒一旦網(wǎng)絡(luò)出現(xiàn)抖動(dòng)突破 1 秒是常有的事。對(duì) AGV 來說500 毫秒足夠讓它撞上人對(duì)產(chǎn)線質(zhì)檢來說幾百毫秒意味著次品可能已經(jīng)進(jìn)入下一個(gè)工位。所以 Physical AI 對(duì)延遲的要求天然和云端推理“不兼容”。斷網(wǎng)比延遲更隱蔽。工廠里金屬屏蔽嚴(yán)重園區(qū)機(jī)房交換機(jī)一換就可能全線斷網(wǎng)戶外設(shè)備更是常常處在弱網(wǎng)甚至無網(wǎng)環(huán)境。云端模式在斷網(wǎng)時(shí)基本等于癱瘓?jiān)O(shè)備只能停在原地而邊緣部署的核心價(jià)值之一就是讓設(shè)備在沒有網(wǎng)絡(luò)的情況下也能繼續(xù)完成本地感知和決策。成本同樣不能忽視多路視頻實(shí)時(shí)上云帶寬費(fèi)用、GPU 實(shí)例費(fèi)用逐月累積視頻流還只是原始數(shù)據(jù)真正的價(jià)值在推理結(jié)果把大量原始視頻傳到云端去算在成本上是不劃算的。這些硬傷疊加促使我在后續(xù)項(xiàng)目里直接采用了邊緣優(yōu)先的部署策略。1.3 哪些場(chǎng)景必須用邊緣視覺模型一張表說清實(shí)際項(xiàng)目中我判斷一個(gè)場(chǎng)景是否必須上邊緣只看兩個(gè)指標(biāo)時(shí)延預(yù)算和網(wǎng)絡(luò)可用性。先看時(shí)延工業(yè)質(zhì)檢、AGV 避障這類任務(wù)要求在 100 毫秒甚至 50 毫秒以內(nèi)完成推理云端做不到再看網(wǎng)絡(luò)戶外巡檢、隧道、地下室、車輛移動(dòng)場(chǎng)景網(wǎng)絡(luò)覆蓋本身就是不可控變量斷網(wǎng)不是“萬一”而是“常態(tài)”。只要兩個(gè)指標(biāo)中有一個(gè)不達(dá)標(biāo)就應(yīng)該優(yōu)先考慮邊緣。拿一個(gè)典型場(chǎng)景舉例工廠安全帽檢測(cè)。產(chǎn)線有幾十路攝像頭如果全部上云上行帶寬要用百兆級(jí)別月成本非?？捎^更重要的是廠區(qū)網(wǎng)絡(luò)改造后某條線路不穩(wěn)定監(jiān)控畫面經(jīng)常掉線。后來我們把模型部署到現(xiàn)場(chǎng)的一臺(tái)邊緣計(jì)算盒子上攝像頭畫面直接進(jìn)盒子里推理檢測(cè)結(jié)果只上傳一個(gè)很小的結(jié)構(gòu)化數(shù)據(jù)帶寬占用幾乎可以忽略斷網(wǎng)影響也大大降低。這種“數(shù)據(jù)不出廠、結(jié)果只傳摘要”的模式在很多 To B 場(chǎng)景里甚至比性能更關(guān)鍵因?yàn)閿?shù)據(jù)合規(guī)要求往往不允許原始視頻離開現(xiàn)場(chǎng)?，F(xiàn)在梳理一張場(chǎng)景對(duì)照表我平時(shí)做方案就靠它說服客戶場(chǎng)景時(shí)延要求斷網(wǎng)風(fēng)險(xiǎn)為什么邊緣工廠質(zhì)檢100ms中高產(chǎn)線不停機(jī)、數(shù)據(jù)不出廠AGV/機(jī)器人避障50ms高移動(dòng)網(wǎng)絡(luò)不穩(wěn)定、實(shí)時(shí)性要求高智慧園區(qū)安防500ms中多路視頻帶寬成本高戶外巡檢無人機(jī)200ms高野外基站覆蓋不足2. 邊緣部署前的選型模型、硬件、推理框架2.1 視覺模型選型怎么不踩坑邊緣模型選型的原則我一直是“先算預(yù)算再挑精度最后看后處理”。算力預(yù)算就是要知道邊緣設(shè)備能提供多少有效算力然后在這個(gè)預(yù)算范圍內(nèi)挑選精度盡量高的模型最后還要評(píng)估后處理復(fù)雜度有些模型推理快但輸出的候選框特別多NMS 一跑反而慢整體延遲未必占優(yōu)。目標(biāo)檢測(cè)方面YOLOv8n 是我用得最多的起點(diǎn)模型參數(shù)量約 3.2M在 Jetson 上配合 TensorRT 很容易跑到 30 FPS 以上。YOLOv5s 雖然參數(shù)量更大但它的生態(tài)成熟網(wǎng)上資料多新手照著抄作業(yè)很省心。分類任務(wù)選 MobileNetV3-Large 或 PP-LCNet前者推理庫支持好后者精度稍高。語義分割優(yōu)先看 PP-LiteSeg它是針對(duì)邊緣場(chǎng)景設(shè)計(jì)的輕量化分割網(wǎng)絡(luò)。模型主要任務(wù)參數(shù)量邊緣端特點(diǎn)YOLOv8n目標(biāo)檢測(cè)3.2M精度/速度均衡TensorRT 支持好YOLOv5s目標(biāo)檢測(cè)7.2M生態(tài)成熟文檔多MobileNetV3-Large圖像分類5.4MCPU 友好PP-LCNet圖像分類3.0M精度高延遲低PP-LiteSeg語義分割約20M邊緣分割首選這里想特別提醒一句不要只看參數(shù)量。有的模型參數(shù)少但輸入分辨率高、卷積層特別深實(shí)際 GFLOPs 并不低有的模型在 GPU 上很快到了 CPU 或 NPU 上因?yàn)樗阕硬患嫒菟俣确炊睢Ｋ栽谧罱K選型之前寫一個(gè)通用 benchmark 腳本把候選模型全部導(dǎo)出在同一臺(tái)邊緣設(shè)備上跑一遍記錄真實(shí)幀率和延遲再讓業(yè)務(wù)數(shù)據(jù)說話。2.2 邊緣計(jì)算盒子與硬件選型指南邊緣設(shè)備的選型很多人按“哪個(gè)便宜買哪個(gè)”或者“哪個(gè)參數(shù)高買哪個(gè)”只盯 TOPS 數(shù)值最后發(fā)現(xiàn)現(xiàn)實(shí)場(chǎng)景里未必跑得快。我的選型步驟是先算算力需求再定平臺(tái)再看整機(jī)配套。算力需求怎么算模型在目標(biāo)輸入尺寸下的 GFLOPs 除以目標(biāo)幀率再乘以一個(gè)工程冗余系數(shù)就能得到一個(gè)粗略的 TOPS 需求。例如 YOLOv8n 在 640x640 下約 8.7 GFLOPs想要 30 FPS理論上需要約 0.26 TOPS 的持續(xù)有效算力但考慮前處理、后處理、系統(tǒng)開銷實(shí)際算力需求放大到 1 TOPS 以上比較穩(wěn)妥。NVIDIA Jetson 系列是推薦優(yōu)先級(jí)最高的平臺(tái)TensorRT 生態(tài)成熟、模型轉(zhuǎn)換省心適合快速落地樹莓派適合原型驗(yàn)證和學(xué)習(xí)跑輕量模型沒問題但 CPU 推理很難上高幀率RK3588 開發(fā)板性價(jià)比高自帶 NPU算力不差就是 RKNN 工具鏈要花時(shí)間折騰。工業(yè)現(xiàn)場(chǎng)更多是直接買邊緣計(jì)算盒子原因很簡單盒子專為工業(yè)場(chǎng)景設(shè)計(jì)通常具備寬溫、防塵、多路 IO、預(yù)裝推理環(huán)境省去整機(jī)設(shè)計(jì)和散熱調(diào)試的工作。需要特別關(guān)注的是散熱和功耗。邊緣盒子放在室外或者產(chǎn)線上溫度一高就會(huì)降頻推理延遲立刻上去。我踩過一次坑盒子放在機(jī)柜里夏天不開空調(diào)推理延遲從 30ms 漲到 80ms最后才發(fā)現(xiàn)是過熱降頻。所以選設(shè)備時(shí)優(yōu)先看支持寬溫、有被動(dòng)散熱設(shè)計(jì)的型號(hào)空間允許的情況下甚至要加裝主動(dòng)散熱風(fēng)扇。接口上也不要只盯著網(wǎng)口工業(yè)現(xiàn)場(chǎng)經(jīng)常需要接 RS485、IO 繼電器、多路 USB 攝像頭盒子接口夠不夠直接影響集成難度。平臺(tái)算力級(jí)別優(yōu)勢(shì)注意點(diǎn)樹莓派 5低上手門檻低、社區(qū)大CPU 推理偏慢適合原型Jetson Orin Nano中高TensorRT 生態(tài)強(qiáng)、性能好價(jià)格偏高RK3588 開發(fā)板中自帶 NPU、性價(jià)比高RKNN 工具鏈要折騰工業(yè)邊緣計(jì)算盒子中高穩(wěn)定、直接部署選型要關(guān)注散熱、IO2.3 推理框架與模型轉(zhuǎn)換工具鏈這一步我不厭其煩地強(qiáng)調(diào)邊緣設(shè)備上不要直接裝 PyTorch 跑推理除非你是純?cè)万?yàn)證。PyTorch 的依賴太胖、啟動(dòng)太慢、性能也沒有針對(duì)邊緣優(yōu)化生產(chǎn)環(huán)境里我基本只用專為邊緣設(shè)計(jì)的推理框架。NVIDIA 平臺(tái)選 TensorRTCPU 平臺(tái)選 ONNX Runtime 或 OpenVINORockchip NPU 選 RKNNARM 移動(dòng)端可以考慮 NCNN。框架選對(duì)了延遲能差出一個(gè)數(shù)量級(jí)。通用轉(zhuǎn)換流程是PyTorch 權(quán)重 - ONNX 格式 - 可選的精度量化 - 目標(biāo)平臺(tái)推理引擎。ONNX 是一個(gè)中間格式幾乎所有推理框架都支持導(dǎo)入。代碼上以 ultralytics YOLOv8 為例from ultralytics import YOLO model YOLO(yolov8n.pt) model.export(formatonnx, imgsz640, simplifyTrue, opset12)為什么建議從 ONNX 走因?yàn)槟悴恢雷约簩頃?huì)跑在什么硬件上。先統(tǒng)一導(dǎo)出 ONNX換平臺(tái)時(shí)就不用重新改模型代碼轉(zhuǎn) TensorRT、轉(zhuǎn) RKNN、轉(zhuǎn) OpenVINO 都是基于同一個(gè) ONNX 文件省很多事。導(dǎo)出時(shí)simplifyTrue會(huì)清理冗余算子opset12以上能避免算子兼容性問題這些參數(shù)建議固定下來形成團(tuán)隊(duì)內(nèi)部的標(biāo)準(zhǔn)操作。3. 核心實(shí)操把視覺模型部署到邊緣設(shè)備3.1 環(huán)境準(zhǔn)備與依賴梳理部署之前先要明確邊緣設(shè)備的運(yùn)行環(huán)境。如果你和我一樣用的是 Jetson建議使用 NVIDIA 官方提供的 JetPack 與 L4T 容器鏡像里面預(yù)裝了 CUDA、cuDNN、TensorRT比自己裸裝環(huán)境省心得多。直接在設(shè)備上安裝依賴時(shí)注意 Python 版本、ONNX Runtime 版本、OpenCV 版本之間容易互相打架所以我一般先在開發(fā)機(jī) Docker 里把模型跑通再同步到邊緣設(shè)備。在開發(fā)機(jī)上我會(huì)建一個(gè)獨(dú)立的 Python 虛擬環(huán)境裝好 ultralytics、onnx、onnxruntime、opencv-python 等基礎(chǔ)包。這一步的核心目標(biāo)是“驗(yàn)證導(dǎo)出結(jié)果沒問題”我會(huì)用一張標(biāo)準(zhǔn)圖分別在 PyTorch 和 ONNX Runtime 下跑一次比對(duì)置信度差距。如果差距在 0.001 以內(nèi)說明導(dǎo)出是成功的不然就要檢查輸入預(yù)處理是否一致、算子是否被錯(cuò)誤替換這將直接決定后面所有環(huán)節(jié)是否可靠。環(huán)境這塊花半小時(shí)理順后面能省出幾天調(diào)試時(shí)間。3.2 模型量化實(shí)操FP16 與 INT8 怎么選量化是邊緣部署里提升性能最直接的手段也是坑最多的環(huán)節(jié)。先說 FP16幾乎沒什么坑Jetson 上用 TensorRT 構(gòu)建 FP16 推理引擎時(shí)精度損失通?？梢院雎匝舆t卻能下降一半左右。INT8 收益更大但需要校準(zhǔn)集校準(zhǔn)集要盡量貼近真實(shí)業(yè)務(wù)場(chǎng)景否則量化出來的模型在真實(shí)數(shù)據(jù)上精度掉得厲害。我用 ONNX Runtime 做動(dòng)態(tài)量化時(shí)代碼相當(dāng)簡單from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic(yolov8n.onnx, yolov8n_int8.onnx, weight_typeQuantType.QInt8)但這里必須說清楚動(dòng)態(tài)量化只是入門方案它只量化權(quán)重激活值還是浮點(diǎn)速度提升有限。如果設(shè)備是 NVIDIA 平臺(tái)我更推薦用 TensorRT 的 PTQ訓(xùn)練后量化流程把校準(zhǔn)圖片喂進(jìn)去自動(dòng)統(tǒng)計(jì)激活值分布生成 INT8 engine。如果是 Rockchip 平臺(tái)用 RKNN 工具做 INT8 量化步驟類似。做完量化后必須做回測(cè)拿同一批測(cè)試數(shù)據(jù)比較量化前后的 mAP偏差超過 5% 就考慮回退到 FP16 或者做混合精度把敏感層保留為浮點(diǎn)運(yùn)算。3.3 推理代碼與視頻流接管的實(shí)現(xiàn)完成了模型轉(zhuǎn)換接下來是把推理代碼在邊緣設(shè)備上跑起來。核心循環(huán)并不復(fù)雜但細(xì)節(jié)決定性能。下面是一段基于 ONNX Runtime 的推理示例import cv2 import numpy as np import onnxruntime as ort session ort.InferenceSession(yolov8n.onnx, providers[CPUExecutionProvider]) cap cv2.VideoCapture(rtsp://user:pass192.168.1.100:554/stream1) while True: ret, frame cap.read() if not ret: break # 前處理letterbox 縮放以保持寬高比 img letterbox(frame, (640, 640))[0] img cv2.cvtColor(img, cv2.COLOR_BGR2RGB).astype(np.float32) / 255.0 tensor np.transpose(img, (2, 0, 1))[None, ...] # 推理 outputs session.run(None, {session.get_inputs()[0].name: tensor}) # 后處理置信度篩選、NMS、坐標(biāo)還原 results postprocess(outputs[0], frame.shape) draw(frame, results)前處理里 letterbox 必須保留直接 resize 會(huì)改變目標(biāo)長寬比導(dǎo)致小目標(biāo)檢測(cè)效果變差歸一化要在轉(zhuǎn)換成 float 之后進(jìn)行cv2 默認(rèn)是 BGR而 PyTorch 和大多數(shù)模型用的是 RGB這個(gè)順序錯(cuò)了模型輸出會(huì)直接亂掉。后處理時(shí)要注意把模型輸出坐標(biāo)映射回原始圖像坐標(biāo)再畫框不然框的位置會(huì)偏移。視頻流接管這一點(diǎn)RTSP 是最常見的協(xié)議但不同攝像頭的推流參數(shù)差異很大。建議連接時(shí)設(shè)置較長的超時(shí)時(shí)間同時(shí)把讀取失敗后的重連邏輯寫進(jìn)代碼避免攝像頭重啟后程序永久卡死。重連之間加隨機(jī)退避不要死循環(huán)重連否則會(huì)把網(wǎng)絡(luò)或設(shè)備拖垮。如果要在 Jetson 上追求極限性能還可以把 provider 換成 TensorrtExecutionProvider并把輸入輸出格式固定下來避免動(dòng)態(tài) shape 帶來的額外開銷。3.4 延遲優(yōu)化實(shí)戰(zhàn)打點(diǎn)、量化、流水線模型能跑之后就要看性能了。我遇到過的最大的坑是“看起來都在跑但幀率上不去”。解決辦法只有一個(gè)不要靠感覺要打點(diǎn)。在解碼、前處理、模型推理、后處理、上傳五段分別記錄耗時(shí)用日志打印出來延遲瓶頸立刻現(xiàn)形。我某次邊緣盒子的實(shí)測(cè)數(shù)據(jù)階段耗時(shí)/幀優(yōu)化方式視頻解碼8ms開啟硬件解碼降低主碼流分辨率圖像前處理12ms減少 resize 次數(shù)早轉(zhuǎn) float模型推理40ms換 TensorRTFP16/INT8量化后處理 NMS15ms用 Fast NMS過濾低置信度框結(jié)果上傳5ms異步上傳批量合并打點(diǎn)之后我的優(yōu)化順序是先模型推理。把 ONNX Runtime 換成 TensorRT在 Jetson 上延遲直接下降一大半如果再上 INT8 量化40ms 可以降到 15ms 左右。然后處理前處理盡量讓解碼后的圖像直接進(jìn)入模型輸入尺寸避免重復(fù)縮放用 GPU 或硬件解碼接口做縮放能再省幾毫秒。最后是后處理安裝一個(gè)優(yōu)化的 NMS 實(shí)現(xiàn)或在候選框數(shù)量很大時(shí)提前過濾低置信度框。另外強(qiáng)烈建議把視頻解碼、推理、上傳放到三個(gè)線程用隊(duì)列串起來形成一條流水線。這樣雖然單幀延遲不一定會(huì)下降但系統(tǒng)吞吐量會(huì)上來幀率穩(wěn)定CPU 也不會(huì)在某一塊突然飆升。串行逐幀處理是最直觀的寫法也是最容易埋雷的寫法能異步盡量異步。4. 斷網(wǎng)與弱網(wǎng)場(chǎng)景工程上怎么兜底4.1 離線優(yōu)先用本地隊(duì)列接住每一幀結(jié)果邊緣部署最容易被忽略的不是模型本身而是斷網(wǎng)時(shí)系統(tǒng)的表現(xiàn)。我見過很多系統(tǒng)線上跑得好好的網(wǎng)絡(luò)一斷所有推理結(jié)果只存在內(nèi)存里網(wǎng)絡(luò)恢復(fù)后數(shù)據(jù)全沒了。正確做法是“離線優(yōu)先”也就是每一幀結(jié)果先落本地再想辦法上傳。SQLite 是我在邊緣設(shè)備上最常用的輕量存儲(chǔ)零配置、支持 SQL、單文件好備份。設(shè)計(jì)一張事件表CREATE TABLE events ( id INTEGER PRIMARY KEY AUTOINCREMENT, camera_id TEXT NOT NULL, event_time DATETIME DEFAULT CURRENT_TIMESTAMP, result_json TEXT, image_path TEXT, uploaded INTEGER DEFAULT 0, retry_count INTEGER DEFAULT 0 );推理線程拿到結(jié)果后先 INSERT再通知上傳線程。上傳線程循環(huán)掃描 uploaded0 的記錄將結(jié)果推送到云端成功后置為 1失敗則 retry_count 加 1超過閾值后單獨(dú)標(biāo)記留給人工處理。這個(gè)模式雖然簡單但能把“斷網(wǎng)后丟數(shù)據(jù)”的風(fēng)險(xiǎn)降到最低所有關(guān)鍵事件在本地都有記錄客戶能接受這種“先處理后上傳”的架構(gòu)。斷網(wǎng)期間本地存儲(chǔ)會(huì)不斷增長尤其是保存了現(xiàn)場(chǎng)圖片時(shí)所以還要設(shè)計(jì)容量上限或定期清理邏輯比如超過 10GB 自動(dòng)刪除最早圖片只保留告警事件關(guān)聯(lián)的圖片避免把存儲(chǔ)寫滿。4.2 網(wǎng)絡(luò)質(zhì)量檢測(cè)與優(yōu)雅降級(jí)別讓設(shè)備“死等”知道網(wǎng)絡(luò)狀態(tài)才能決定用多少資源做實(shí)時(shí)上傳。我在邊緣設(shè)備上常開兩層檢測(cè)。底層是心跳線程每隔幾秒向云端發(fā)送一次輕量探活請(qǐng)求記錄 RTT 和成功率業(yè)務(wù)層統(tǒng)計(jì)連續(xù)上傳失敗的次數(shù)。兩個(gè)指標(biāo)一結(jié)合就能把網(wǎng)絡(luò)狀態(tài)粗略分類正常、弱網(wǎng)、斷網(wǎng)。然后針對(duì)不同狀態(tài)做降級(jí)策略。正常時(shí)高幀率推理結(jié)果實(shí)時(shí)上傳弱網(wǎng)時(shí)主動(dòng)降低幀率上傳推理結(jié)果的摘要而不是原始圖片減少壓力斷網(wǎng)時(shí)干脆停止網(wǎng)絡(luò)相關(guān)操作讓系統(tǒng)進(jìn)入純本地模式等網(wǎng)絡(luò)恢復(fù)后再補(bǔ)傳。降級(jí)操作要注意閾值平滑避免因?yàn)橐淮味秳?dòng)就頻繁切換狀態(tài)。我一般會(huì)加一個(gè)計(jì)數(shù)窗口比如連續(xù) 5 次探活失敗才判定為斷網(wǎng)恢復(fù)也要連續(xù) 3 次成功才切回在線否則網(wǎng)絡(luò)稍一波動(dòng)系統(tǒng)就反復(fù)“跳舞”體驗(yàn)反而更差。網(wǎng)絡(luò)狀態(tài)判定條件推理策略上傳策略正常RTT 正常且上傳成功率高全幀率、高分辨率實(shí)時(shí)上傳弱網(wǎng)RTT 升高或上傳失敗增多降低幀率、縮小輸入尺寸摘要優(yōu)先圖片降采樣斷網(wǎng)連續(xù)多次探活失敗保持本地運(yùn)行停止網(wǎng)絡(luò)操作落庫等待4.3 模型更新與斷網(wǎng)下的回滾機(jī)制邊緣與云端的協(xié)同不只是上傳數(shù)據(jù)還要讓云端更新后的模型能安全下發(fā)到邊緣設(shè)備。網(wǎng)絡(luò)斷斷續(xù)續(xù)時(shí)模型下載到一半是常態(tài)這時(shí)如果直接覆蓋原模型文件很可能把正在運(yùn)行的模型搞壞設(shè)備直接癱瘓。我的做法是模型文件先下載到臨時(shí)目錄下載完成后計(jì)算 md5跟云端的版本值對(duì)比校驗(yàn)通過后再把臨時(shí)文件通過原子 rename 覆蓋正式路徑。模型文件命名也要帶上版本號(hào)和時(shí)間戳例如model_v3_20250112.engine正式路徑可以是一個(gè)軟鏈接指向當(dāng)前版本。每次更新前把上一版保留保留最近兩三個(gè)版本如果新模型在真實(shí)場(chǎng)景里精度下滑或設(shè)備負(fù)載異?？梢赃h(yuǎn)程把軟鏈接指回上一個(gè)版本快速回滾。這個(gè)機(jī)制并不復(fù)雜但能做到“斷網(wǎng)時(shí)下載失敗不影響業(yè)務(wù)更新失敗能快速回滾”是生產(chǎn)環(huán)境必備的工程底線。5. 常見問題與排查技巧實(shí)錄5.1 推理延遲一直降不下來先打點(diǎn)再看瓶頸遇到延遲不達(dá)標(biāo)先不要依賴玄學(xué)優(yōu)化。第一步打點(diǎn)把各階段耗時(shí)打印出來第二步看瓶頸在哪一段。如果是推理慢檢查是否真的用上了硬件加速很多情況下是環(huán)境里安裝的 ONNX Runtime 是 CPU 版本代碼沒報(bào)錯(cuò)但性能就是差了一大截如果是前處理慢檢查是不是在 Python 里做了太多逐像素操作換成向量化方式或者下采樣可以解決如果后處理里 NMS 慢可以用 Fast NMS 或提前過濾低置信度框。還要注意異常值。平均延遲 40ms 不代表體驗(yàn)好如果 P95 延遲到了 200ms說明系統(tǒng)存在偶發(fā)阻塞。我遇到過 P95 飆升排查發(fā)現(xiàn)是內(nèi)存不足導(dǎo)致?lián)Q頁推理線程偶爾被卡住。應(yīng)對(duì)方式是在代碼里加性能監(jiān)控記錄每一段的 P50/P95/P99 延遲丟到日志或時(shí)序數(shù)據(jù)庫里等出問題再回看數(shù)據(jù)比當(dāng)時(shí)肉眼猜測(cè)高效得多。5.2 量化后精度掉點(diǎn)校準(zhǔn)集和敏感層是重點(diǎn)量化掉點(diǎn)是邊緣部署的高頻問題幾乎每個(gè)人都會(huì)遇到。第一步檢查校準(zhǔn)集校準(zhǔn)集和現(xiàn)場(chǎng)數(shù)據(jù)差異太大INT8 模型必然掉點(diǎn)。解決辦法是到現(xiàn)場(chǎng)采集一段真實(shí)視頻抽出幾百幀作為校準(zhǔn)集覆蓋不同光照和角度。第二步檢查敏感層檢測(cè)頭的輸出層往往對(duì)量化最敏感用混合精度把這些敏感層保留 FP16 或 FP32其余層用 INT8通常能把精度損失拉回來。還有一類“假掉點(diǎn)”容易忽略前處理不一致。導(dǎo)出和量化用的圖片如果是 RGB部署時(shí)代碼卻按 BGR 處理模型輸出自然異常。建議部署完成后用一張標(biāo)準(zhǔn)圖分別跑 FP32 和量化模型對(duì)比輸出結(jié)果如果差距很小說明推理鏈路是可信的如果差很多優(yōu)先排查預(yù)處理邏輯。5.3 斷網(wǎng)恢復(fù)后補(bǔ)傳失敗隊(duì)列、去重、退避補(bǔ)傳失敗最常見的三個(gè)原因單條臟數(shù)據(jù)卡死隊(duì)列、重復(fù)推送導(dǎo)致業(yè)務(wù)端重復(fù)處理、斷網(wǎng)重試太頻繁把設(shè)備和云端資源耗盡。針對(duì)第一個(gè)上傳線程必須對(duì)每一條記錄單獨(dú)處理一條失敗不能阻塞整批任務(wù)我用每條 try/catch 包裹重試 3 次后標(biāo)記失敗后臺(tái)可以查看失敗原因。針對(duì)第二個(gè)給事件表加一個(gè)全局唯一 event_id云端按這個(gè) id 去重重復(fù)推送不會(huì)產(chǎn)生重復(fù)告警。針對(duì)第三個(gè)重試策略用指數(shù)退避從 5 秒開始逐次翻倍最大間隔 5 分鐘網(wǎng)絡(luò)恢復(fù)后能較快補(bǔ)齊弱網(wǎng)時(shí)也不會(huì)把資源打滿。5.4 邊緣盒子過熱降頻性能為何突然下降很多項(xiàng)目在實(shí)驗(yàn)室里跑得好好的現(xiàn)場(chǎng)一部署性能就崩很大一部分原因是溫度。邊緣盒子裝在機(jī)柜里、高壓柜旁或者戶外夏天不開空調(diào)芯片溫度一高就觸發(fā)降頻推理延遲從 30ms 漲到 80ms看起來就像代碼出問題。排查方法很簡單進(jìn)入設(shè)備系統(tǒng)查看 CPU/GPU 溫度和頻率觀察延遲飆升時(shí)是否伴隨頻率下降。解決方案要從選型和散熱兩方面下手。選型時(shí)優(yōu)先選支持寬溫的工業(yè)級(jí)設(shè)備現(xiàn)場(chǎng)條件有限時(shí)加強(qiáng)制風(fēng)扇或空調(diào)通風(fēng)把設(shè)備所在位置溫度壓下來。如果還不能解決就只能在軟件層面主動(dòng)限幀讓設(shè)備在高溫環(huán)境下保持一個(gè)更穩(wěn)定的推理頻率而不是一會(huì)兒快一會(huì)兒慢至少對(duì)業(yè)務(wù)來說更好預(yù)測(cè)。最后再分享一個(gè)我反復(fù)用到的實(shí)戰(zhàn)經(jīng)驗(yàn)邊緣設(shè)備上不要什么都往云端傳尤其是原始視頻流。推理結(jié)果只是一個(gè)標(biāo)簽和坐標(biāo)真正有價(jià)值的現(xiàn)場(chǎng)畫面可以按需截幀保存截幀存到本地定期清理只把告警事件關(guān)聯(lián)的圖片上傳。這樣延遲穩(wěn)了斷網(wǎng)不怕了存儲(chǔ)和帶寬成本也能壓住。Physical AI 的路很長但把延遲和斷網(wǎng)這兩件事先解決掉后面的工程化會(huì)順暢很多。