前陣子接了個(gè)園區(qū)安防的評(píng)估需求對(duì)方開口就問(wèn)我你們那個(gè)帶AI識(shí)別能力的邊緣盒子TOPS能到多少我說(shuō)您先別急著看TOPS先告訴我到底要跑幾路視頻流、識(shí)別什么目標(biāo)、接受多少延遲。結(jié)果算下來(lái)4路1080P視頻流、跑三個(gè)輕量檢測(cè)模型、延遲控制在500毫秒以內(nèi)一臺(tái)有效算力3 TOPS左右的邊緣設(shè)備就能穩(wěn)穩(wěn)扛住壓根不用為用不上的算力買單。邊緣計(jì)算這個(gè)圈子確實(shí)被“算力越大越好”的思維帶偏了很久。這篇文章我就拿這個(gè)4路視頻流的項(xiàng)目當(dāng)例子把算力需求從零開始拆一遍一路視頻流到底吃掉多少算力、3 TOPS是怎么算出來(lái)的、硬件和軟件棧怎么搭、實(shí)操中會(huì)踩哪些坑。無(wú)論你是做邊緣計(jì)算方案選型的工程師還是想把手頭攝像頭項(xiàng)目本地化的開發(fā)者都能從里面抄到一套可以落地的方法論。1. 先把算力這筆賬算明白3 TOPS意味著什么1.1 TOPS并不是越大越聰明TOPS的全稱是Tera Operations Per Second也就是每秒萬(wàn)億次操作。這個(gè)“操作”指的通常是乘加運(yùn)算深度神經(jīng)網(wǎng)絡(luò)的主要計(jì)算量都集中在卷積和矩陣乘法這些乘加操作上所以TOPS常被用來(lái)衡量AI加速芯片的推理能力。很多朋友上來(lái)就盯著TOPS數(shù)字選設(shè)備總覺得30 TOPS一定比3 TOPS好。但在邊緣計(jì)算項(xiàng)目里高TOPS往往意味著更高的功耗、更大的體積、更貴的價(jià)格。一臺(tái)幾十TOPS的AI盒子動(dòng)不動(dòng)幾千上萬(wàn)功耗跑到幾十瓦而你要處理的只是4路攝像頭畫面里的人物框選、煙火檢測(cè)或者區(qū)域入侵判斷這類任務(wù)的模型本身并不大盲目追求高算力純屬浪費(fèi)預(yù)算。這里有個(gè)很關(guān)鍵的概念算力利用率。芯片標(biāo)稱的TOPS是理論峰值實(shí)際運(yùn)行中由于內(nèi)存帶寬瓶頸、NPU調(diào)度開銷、算子優(yōu)化程度等限制通常只能利用到標(biāo)稱值的50%到70%。所以選算力時(shí)不能只看紙面TOPS還要看你的模型在目標(biāo)芯片上的真實(shí)推理幀率。1.2 邊緣視頻流項(xiàng)目的真實(shí)算力需求畫像在算需求之前先給項(xiàng)目畫個(gè)像。這類項(xiàng)目通常長(zhǎng)這樣視頻源4路IPC攝像頭1080P分辨率H.264編碼25幀/秒識(shí)別任務(wù)行人檢測(cè)、車輛識(shí)別、煙火預(yù)警之類的目標(biāo)檢測(cè)任務(wù)實(shí)時(shí)性要求幾百毫秒到1秒內(nèi)給出識(shí)別結(jié)果即可不需要毫秒級(jí)響應(yīng)部署位置園區(qū)機(jī)房、路邊機(jī)柜對(duì)功耗和體積有要求業(yè)務(wù)價(jià)值不追求“把所有畫面每一幀都過(guò)一遍模型”而是按策略抽幀識(shí)別兼顧精度和成本這個(gè)畫像很典型很多邊緣計(jì)算項(xiàng)目本質(zhì)上都是“中等分辨率、多路數(shù)、輕模型、低延遲”的組合。這類項(xiàng)目對(duì)算力的需求并不像外界想象的那么夸張關(guān)鍵是做好視頻流調(diào)度和推理任務(wù)編排。1.3 為什么“夠用就好”是邊緣項(xiàng)目的最高原則有人可能會(huì)問(wèn)算力大一點(diǎn)不好嗎后續(xù)擴(kuò)展不是更方便嗎我的看法是邊緣項(xiàng)目的最高原則是“正好夠用留有余量”而不是“一步到位”。因?yàn)檫吘壴O(shè)備不像云端服務(wù)器那樣可以隨便加卡擴(kuò)容設(shè)備一旦部署下去要換就得連硬件帶現(xiàn)場(chǎng)施工一起換成本很高。但反過(guò)來(lái)算力選太大也有問(wèn)題一是采購(gòu)成本高二是散熱和供電壓力大三是很多高算力設(shè)備的功耗和體積根本塞不進(jìn)現(xiàn)場(chǎng)機(jī)柜。而且算力高的設(shè)備往往配套的軟件棧也更復(fù)雜開發(fā)和維保難度都會(huì)上升。我見過(guò)不少項(xiàng)目買了高算力設(shè)備結(jié)果模型跑的還是輕量模型算力利用率只有百分之十幾純粹浪費(fèi)。所以正確的思路是先算清需求再選設(shè)備。接下來(lái)我詳細(xì)拆解4路視頻流場(chǎng)景下3 TOPS是怎么被“算”出來(lái)的。2. 4路視頻流的算力拆解一路一路算給你看2.1 視頻流處理的完整鏈路解碼、預(yù)處理、推理、后處理很多人以為邊緣識(shí)別就是“把攝像頭畫面丟給AI模型”這么簡(jiǎn)單實(shí)際上一路視頻流進(jìn)到設(shè)備里要經(jīng)歷好幾個(gè)環(huán)節(jié)拉流從攝像頭拿到RTSP或者GB28181的實(shí)時(shí)流解碼把H.264/H.265編碼的視頻幀還原成YUV圖像數(shù)據(jù)預(yù)處理圖像縮放、歸一化、顏色空間轉(zhuǎn)換把數(shù)據(jù)變成模型輸入需要的格式推理NPU或GPU運(yùn)行神經(jīng)網(wǎng)絡(luò)模型輸出目標(biāo)框、類別、置信度后處理NMS去重、目標(biāo)跟蹤、業(yè)務(wù)邏輯判斷推流/輸出把處理后的結(jié)果疊加到視頻流上或者輸出結(jié)構(gòu)化數(shù)據(jù)給平臺(tái)這六個(gè)環(huán)節(jié)里真正吃AI算力的是“推理”但前面解碼和預(yù)處理如果做不好推理再快也沒用。4路視頻流同時(shí)進(jìn)來(lái)硬解碼器和數(shù)據(jù)通路能不能扛住往往比NPU算力更先成為瓶頸。2.2 單路視頻流的推理負(fù)載估算算力需求的核心其實(shí)是要在單位時(shí)間內(nèi)推理多少幀畫面每幀畫面跑什么規(guī)模的模型。假設(shè)我們跑一個(gè)輕量級(jí)的目標(biāo)檢測(cè)模型比如YOLOv8n或者PicoDet這種量級(jí)輸入分辨率640x640INT8量化之后的模型算力消耗大概在5到20 GFLOPs之間取中間值按10 GOPS來(lái)估算比較穩(wěn)。這里的GOPS和TOPS是一個(gè)單位體系1 TOPS等于1000 GOPS。單路攝像頭如果25幀全量跑檢測(cè)一秒鐘就需要跑25幀那就需要25乘以單幀算力消耗也就是大約0.25 TOPS的實(shí)際有效算力。聽起來(lái)很少對(duì)不對(duì)但4路加一起全量幀率推理就需要1 TOPS左右的實(shí)際有效算力再算上預(yù)處理、多路并發(fā)調(diào)度、系統(tǒng)開銷以及前面說(shuō)的算力利用率折損3 TOPS的標(biāo)稱算力這時(shí)候就剛好能兜住。2.3 抽幀調(diào)度讓3 TOPS覆蓋4路視頻流的關(guān)鍵但上面是按每路25幀全量推理來(lái)算的實(shí)際項(xiàng)目中我們并不會(huì)這么做。原因很簡(jiǎn)單安防場(chǎng)景里畫面變化沒那么快每秒跑25次檢測(cè)的邊際收益很低。更合理的做法是給每路視頻流做抽幀策略常規(guī)時(shí)段每路5到10幀/秒的檢測(cè)頻率已經(jīng)足夠覆蓋行人、車輛等目標(biāo)告警時(shí)段一旦檢測(cè)到目標(biāo)事件臨時(shí)提升到15到25幀/秒進(jìn)行跟蹤夜間低峰進(jìn)一步降頻到2到3幀/秒只跑區(qū)域入侵等簡(jiǎn)單邏輯按每路10幀/秒來(lái)算4路視頻流合計(jì)只需要跑40幀/秒的推理。結(jié)合前面說(shuō)的單幀檢測(cè)消耗40乘以10 GOPS需要的有效算力大約是0.4 TOPS。再算上預(yù)處理和系統(tǒng)開銷以及算力利用率折損大約需要1到2 TOPS。這時(shí)候一臺(tái)3 TOPS的設(shè)備實(shí)際負(fù)載率在60%到70%之間剛好處于一個(gè)既穩(wěn)定又有余量的狀態(tài)。這就是3 TOPS作為最優(yōu)解的真正邏輯不是“3 TOPS夠跑4路”而是“通過(guò)合理的抽幀調(diào)度讓3 TOPS的設(shè)備在4路場(chǎng)景下跑得又快又穩(wěn)同時(shí)給突發(fā)流量留出緩沖”。2.4 推理優(yōu)化的三板斧量化、剪枝、算子融合有人會(huì)問(wèn)如果模型算力消耗算出來(lái)超出預(yù)期怎么辦這時(shí)候不是換更大算力的設(shè)備而是先從算法側(cè)優(yōu)化。邊緣計(jì)算里常用的推理優(yōu)化手段有三個(gè)INT8量化把模型從FP16/FP32精度變成INT8整數(shù)運(yùn)算算力消耗和數(shù)據(jù)帶寬都能降一半以上很多邊緣芯片的NPU對(duì)INT8有專用加速單元結(jié)構(gòu)化剪枝把模型里權(quán)重接近零的通道刪掉減少計(jì)算量精度損失通?？梢钥刂圃?%以內(nèi)算子融合把相鄰的卷積層、ReLU層、歸一化層合并成一個(gè)算子減少數(shù)據(jù)搬運(yùn)次數(shù)這個(gè)主要由推理框架自動(dòng)完成這一塊就是搜索熱詞里“邊緣計(jì)算 深度學(xué)習(xí) 推理優(yōu)化 調(diào)度”的核心含義。模型做不做優(yōu)化在3 TOPS設(shè)備上的表現(xiàn)能差好幾倍。同樣的模型FP16模型在3 TOPS設(shè)備上可能只能跑18幀/秒INT8量化之后能跑到40幀/秒以上這就是優(yōu)化帶來(lái)的實(shí)打?qū)嵅罹唷Ｆ鋵?shí)這里我多說(shuō)一句很多開源模型本身是給云端GPU設(shè)計(jì)的直接搬到邊緣設(shè)備上跑效率和幀率都會(huì)很難看。我在實(shí)際項(xiàng)目中只要模型是跑在邊緣NPU上就一定會(huì)做量化適配只有極個(gè)別精度敏感的業(yè)務(wù)場(chǎng)景才保留FP16推理分支。3. 硬件和軟件選型把預(yù)算花在刀刃上3.1 3 TOPS級(jí)的邊緣硬件怎么選現(xiàn)在的邊緣算力設(shè)備選擇非常多同樣是幾TOPS級(jí)別的產(chǎn)品側(cè)重點(diǎn)差別很大。從實(shí)際項(xiàng)目角度我通常關(guān)注五個(gè)維度有效算力、視頻解碼能力、內(nèi)存帶寬、功耗體積、軟件適配度。選型維度重點(diǎn)關(guān)注內(nèi)容常見的坑有效算力實(shí)際INT8推理幀率而不是紙面TOPS紙面算力高但內(nèi)存帶寬不夠推不滿性能視頻解碼能力是否支持多路1080P硬解碼只標(biāo)了算力沒標(biāo)解碼路數(shù)結(jié)果4路視頻解不動(dòng)內(nèi)存帶寬內(nèi)存帶寬要和算力匹配算力強(qiáng)但內(nèi)存窄大模型跑起來(lái)卡頓功耗體積能否適應(yīng)現(xiàn)場(chǎng)機(jī)柜環(huán)境只圖算力大發(fā)熱和功耗把項(xiàng)目搞黃軟件適配SDK、推理框架、工具鏈?zhǔn)欠癯墒煨酒碌臋n爛開發(fā)周期拖好幾倍這里要特別提醒一下“有效算力”這個(gè)維度。有的芯片算力標(biāo)得很高但內(nèi)存帶寬只有幾十GB/s跑大一點(diǎn)的模型數(shù)據(jù)在內(nèi)存里搬運(yùn)不過(guò)來(lái)實(shí)際幀率遠(yuǎn)低于理論值。反過(guò)來(lái)也有芯片算力不算頂級(jí)但視頻解碼能力和推理調(diào)度做得好實(shí)際應(yīng)用體驗(yàn)反而更順滑。在這個(gè)項(xiàng)目里我選的是某款帶獨(dú)立NPU、支持4路1080P硬解碼、標(biāo)稱3 TOPS INT8算力的邊緣AI盒子。整機(jī)功耗控制在10瓦出頭帶無(wú)風(fēng)扇散熱外殼直接塞進(jìn)園區(qū)弱電井的機(jī)柜里。這類設(shè)備市面價(jià)格在幾百到一千多元區(qū)間比動(dòng)輒幾千上萬(wàn)的高算力設(shè)備友好太多。3.2 視頻推拉流架構(gòu)RTSP輸入WebRTC/FLV輸出邊緣視頻流項(xiàng)目的第一步就是把攝像頭的視頻流拉進(jìn)來(lái)。目前市面上主流的攝像頭接入方式有三種RTSP最通用的標(biāo)準(zhǔn)協(xié)議?？?、大華、宇視等攝像頭都支持通常通過(guò)IP端口訪問(wèn)GB28181國(guó)內(nèi)安防設(shè)備常用的國(guó)標(biāo)協(xié)議適合需要對(duì)接公安平臺(tái)的項(xiàng)目RTMP/HTTP-FLV主要用在把視頻推到Web端播放延遲低兼容性好我這個(gè)項(xiàng)目里攝像頭通過(guò)RTSP拉流邊緣設(shè)備解碼之后一路走本地算法分析另一路轉(zhuǎn)成HTTP-FLV或WebRTC協(xié)議推給監(jiān)控平臺(tái)。這里用到的核心工具是FFmpeg一套命令就可以搞定拉流和轉(zhuǎn)推# 從攝像頭拉取RTSP流解碼后重新編碼為低延遲的FLV流推送 ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.64:554/stream1 \ -c:v copy -f flv rtmp://192.168.1.100:1935/live/camera01注意RTSP傳輸那里用-rtsp_transport tcp因?yàn)閁DP傳輸容易丟包會(huì)導(dǎo)致畫面花屏和卡頓TCP傳輸在局域網(wǎng)內(nèi)更穩(wěn)定。3.3 軟件棧搭建解碼線程池 推理隊(duì)列 結(jié)果回調(diào)硬件選好了推拉流架構(gòu)也定了接下來(lái)是軟件棧。我習(xí)慣把整個(gè)邊緣識(shí)別程序拆成幾個(gè)獨(dú)立模塊每個(gè)模塊之間用隊(duì)列通信這樣耦合度低排查問(wèn)題也方便。采集模塊每個(gè)攝像頭一個(gè)線程負(fù)責(zé)RTSP拉流和解碼解碼出的YUV幀交給預(yù)處理隊(duì)列預(yù)處理模塊從隊(duì)列里取幀做縮放和歸一化把RGB數(shù)據(jù)變成模型輸入張量推理模塊把輸入張量送入NPU推理引擎同一時(shí)間只做一次推理多路幀排隊(duì)執(zhí)行后處理模塊解析推理輸出做NMS去重然后回調(diào)給業(yè)務(wù)邏輯層這個(gè)架構(gòu)的好處是每一塊都可以單獨(dú)測(cè)試。采集模塊卡了排查網(wǎng)絡(luò)推理模塊慢了排查模型和調(diào)度業(yè)務(wù)邏輯崩了不影響采集線程繼續(xù)緩沖畫面。模塊之間的數(shù)據(jù)流轉(zhuǎn)我更傾向于用無(wú)鎖環(huán)形隊(duì)列配信號(hào)量避免多線程鎖競(jìng)爭(zhēng)。實(shí)測(cè)下來(lái)在4路視頻流場(chǎng)景下一個(gè)設(shè)計(jì)良好的隊(duì)列調(diào)度能比粗放的“每路視頻一個(gè)進(jìn)程然后各自跑模型”的方案節(jié)省30%以上的CPU開銷那部分CPU占用本來(lái)要吃掉的功耗和發(fā)熱省下來(lái)就是設(shè)備穩(wěn)定性的保障。4. 實(shí)操記錄把一個(gè)邊緣識(shí)別項(xiàng)目真正跑起來(lái)4.1 第一步拉流解碼的穩(wěn)定性排查動(dòng)手部署的第一件事就是先確認(rèn)4路視頻流能不能穩(wěn)定拉進(jìn)來(lái)。我踩過(guò)最典型的坑是解碼線程數(shù)量配置。一開始圖省事用FFmpeg命令行直接起了4個(gè)進(jìn)程拉流結(jié)果發(fā)現(xiàn)設(shè)備內(nèi)存因?yàn)槊總€(gè)進(jìn)程都單獨(dú)初始化了一套解碼器漲得很厲害。后來(lái)改方案在進(jìn)程內(nèi)用硬解碼器實(shí)例池4路視頻流復(fù)用解碼器資源內(nèi)存占用立刻降下來(lái)。跑了一天下來(lái)內(nèi)存消耗穩(wěn)定在設(shè)備總內(nèi)存的一半以內(nèi)。另外一個(gè)特別容易踩的坑是攝像頭斷線重連。邊緣場(chǎng)景下攝像頭和盒子之間隔了幾條網(wǎng)線、交換機(jī)偶爾網(wǎng)絡(luò)抖動(dòng)導(dǎo)致RTSP斷流非常正常。程序里必須加自動(dòng)重連機(jī)制否則斷一次流設(shè)備就傻在那兒不出結(jié)果了。def pull_stream(camera_url): while True: capture cv2.VideoCapture(camera_url) while capture.isOpened(): ret, frame capture.read() if not ret: break process_frame(frame) # 斷線后等3秒重連避免瘋狂重試 time.sleep(3)這段代碼邏輯很簡(jiǎn)單內(nèi)層循環(huán)拉流讀幀讀到失敗就跳出外層循環(huán)等待3秒重新拉流。配合攝像頭掉線告警基本能保證無(wú)人值守情況下也穩(wěn)定運(yùn)行。4.2 第二步讓4路視頻流共享一個(gè)推理引擎多路視頻流同時(shí)跑推理最常見的方案是給每路分配一個(gè)推理線程但邊緣設(shè)備的NPU本質(zhì)上不適合這樣用。因?yàn)镹PU推理是串行執(zhí)行的多個(gè)線程同時(shí)往NPU塞任務(wù)只會(huì)增加調(diào)度損耗。我推薦的做法是只保留一個(gè)推理線程4路視頻流的幀統(tǒng)一丟進(jìn)一個(gè)優(yōu)先隊(duì)列推理線程按順序處理。這樣NPU永遠(yuǎn)只接受一個(gè)任務(wù)流調(diào)度開銷最小幀率也最平穩(wěn)。具體實(shí)現(xiàn)時(shí)要注意抽幀邏輯和推理隊(duì)列深度的配合每路視頻流設(shè)置抽幀間隔比如每3幀取1幀送入隊(duì)列推理隊(duì)列設(shè)置最大長(zhǎng)度比如300幀滿了就丟棄最舊的幀保證實(shí)時(shí)性告警事件觸發(fā)時(shí)調(diào)高對(duì)應(yīng)路上的抽幀頻率這一步做完整個(gè)系統(tǒng)的幀率曲線會(huì)變得非常平穩(wěn)。我在這個(gè)項(xiàng)目里實(shí)測(cè)4路視頻流、每路15幀檢測(cè)頻率的情況下推理線程穩(wěn)定跑到50幀/秒以上設(shè)備CPU占用才20%左右NPU負(fù)載不到70%溫度和功耗都很健康。4.3 常見問(wèn)題速查為什么M3U8播出來(lái)老是花屏項(xiàng)目上線之后最常被客戶問(wèn)到的反而不是AI識(shí)別效果而是視頻畫面怎么看著有問(wèn)題。這里我整理了一份邊緣視頻項(xiàng)目常見問(wèn)題速查表按出現(xiàn)頻率排序現(xiàn)象常見原因排查思路M3U8直播流花屏分片沒有對(duì)齊關(guān)鍵幀或播放器緩存設(shè)置不對(duì)或傳輸丟包嚴(yán)重先確認(rèn)源流是否正常再用M3U8的切片參數(shù)錯(cuò)峰對(duì)齊I幀畫面卡頓、馬賽克RTSP走UDP傳輸丟包或設(shè)備解碼能力不足換成TCP傳輸檢查解碼器利用率延遲越來(lái)越高播放器緩沖積壓或者推流端碼率控制不當(dāng)調(diào)整GOP大小和緩沖隊(duì)列降低碼率攝像頭掉線后無(wú)法恢復(fù)重連邏輯沒做好或者設(shè)備內(nèi)存泄漏加自動(dòng)重連定期查看內(nèi)存占用曲線推理結(jié)果時(shí)有時(shí)無(wú)抽幀策略太激進(jìn)或者模型對(duì)特定角度漏檢調(diào)高抽幀頻率補(bǔ)充訓(xùn)練樣本庫(kù)這里專門說(shuō)一下M3U8花屏這個(gè)問(wèn)題。很多項(xiàng)目喜歡把視頻流轉(zhuǎn)成HLS協(xié)議用M3U8索引播放。HLS本質(zhì)上就是把視頻流切成一個(gè)個(gè)幾秒的小分段文件。如果切分時(shí)沒有對(duì)齊到關(guān)鍵幀也就是GOP的起始位置播放器拿到不完整的編碼幀解碼出來(lái)的畫面就會(huì)花屏。解決辦法有兩類一類是在切片對(duì)齊參數(shù)上下手讓切片器等到關(guān)鍵幀再切割另一類是直接換用HTTP-FLV或WebRTC協(xié)議從源頭上避免切片問(wèn)題。我的個(gè)人經(jīng)驗(yàn)是邊緣視頻項(xiàng)目如果是內(nèi)網(wǎng)低延遲場(chǎng)景直接用HTTP-FLV或WebRTC省掉切片環(huán)節(jié)畫面質(zhì)量和延遲都好控制得多。4.4 推理調(diào)度的細(xì)節(jié)技巧給突發(fā)業(yè)務(wù)留后手3 TOPS的設(shè)備留有余量是好事但怎么把這點(diǎn)余量用在刀刃上要靠調(diào)度策略。我會(huì)在推理隊(duì)列里做優(yōu)先級(jí)分級(jí)高優(yōu)先級(jí)入侵告警、煙火檢測(cè)這類需要立刻響應(yīng)的任務(wù)普通優(yōu)先級(jí)貨架缺貨檢測(cè)、人群密度統(tǒng)計(jì)這類周期性任務(wù)低優(yōu)先級(jí)錄像歸檔分析、離線視頻抽檢這類非實(shí)時(shí)任務(wù)優(yōu)先級(jí)分級(jí)聽起來(lái)簡(jiǎn)單實(shí)際落地時(shí)要注意防止“餓死”。如果高優(yōu)先級(jí)任務(wù)一直占用推理線程低優(yōu)先級(jí)任務(wù)可能很長(zhǎng)時(shí)間得不到處理。我通常給每個(gè)優(yōu)先級(jí)隊(duì)列設(shè)置一個(gè)“最大等待時(shí)間”超過(guò)時(shí)間就強(qiáng)制插隊(duì)處理。這種調(diào)度設(shè)計(jì)在邊緣項(xiàng)目里特別實(shí)用。平時(shí)各路視頻流按低負(fù)載跑突遇某個(gè)攝像頭觸發(fā)告警系統(tǒng)立刻把推理資源傾斜過(guò)去等告警處理完又自動(dòng)恢復(fù)正常節(jié)奏。整個(gè)過(guò)程客戶完全無(wú)感但識(shí)別響應(yīng)速度提升好幾個(gè)檔次。5. 成本對(duì)比與后續(xù)擴(kuò)展這份選擇的長(zhǎng)期價(jià)值5.1 3 TOPS方案的直接成本優(yōu)勢(shì)回歸到開頭那個(gè)問(wèn)題該不該為算力買單我們把賬擺出來(lái)看。同樣是支撐4路視頻流、輕量模型推理的項(xiàng)目3 TOPS方案和高算力方案的成本差異可以說(shuō)是數(shù)量級(jí)的對(duì)比項(xiàng)3 TOPS方案30 TOPS級(jí)方案對(duì)比結(jié)論設(shè)備單價(jià)800元-1500元5000元-30000元高算力方案貴3倍以上整機(jī)功耗8W-15W35W-70W高算力方案功耗高3-5倍散熱要求無(wú)風(fēng)扇或小型散熱片通常需要主動(dòng)散熱風(fēng)扇高算力方案部署限制更多體積重量手機(jī)盒大小適合機(jī)柜通常接近小型工控機(jī)高算力方案占空間維護(hù)復(fù)雜度低工具鏈成熟高軟件棧更復(fù)雜同等起跑線差距不大適用場(chǎng)景4-8路輕量識(shí)別16路以上重型模型本項(xiàng)目3 TOPS方案完全夠用注意這里的結(jié)論有一個(gè)前提模型復(fù)雜度不高幀率要求不極端。如果你真的跑的是大語(yǔ)言模型、視頻結(jié)構(gòu)理解模型那種重量級(jí)任務(wù)2 TOPS確實(shí)不夠那老老實(shí)實(shí)上高算力設(shè)備這個(gè)沒什么好爭(zhēng)論的。關(guān)鍵是別讓算力浪費(fèi)變成常態(tài)。5.2 算力追加的路徑3 TOPS之后怎么辦有人會(huì)擔(dān)心現(xiàn)在選3 TOPS將來(lái)業(yè)務(wù)量漲了再加攝像頭、再加模型不夠用了怎么辦我在項(xiàng)目里通常會(huì)預(yù)留三手準(zhǔn)備第一手視頻流規(guī)模擴(kuò)容到8路以內(nèi)。3 TOPS的設(shè)備如果只跑輕量模型通過(guò)調(diào)低非關(guān)鍵路數(shù)的抽幀頻率通常能再扛下4路新增視頻流也就是說(shuō)從4路擴(kuò)到8路硬件可以不動(dòng)。第二手模型輕量化兜底。如果業(yè)務(wù)需要上更大的模型可以通過(guò)知識(shí)蒸餾把重模型的能力“壓”進(jìn)輕量模型里精度損失有限但算力開銷能降一大截。我在這個(gè)項(xiàng)目里就把一個(gè)200多兆的檢測(cè)模型蒸餾到20多兆的輕量模型推理速度提升了4倍業(yè)務(wù)效果基本沒差。第三手多機(jī)并聯(lián)。邊緣項(xiàng)目不需要把算力集中在一個(gè)設(shè)備里。真到了8路、16路以上直接加一臺(tái)同樣的3 TOPS設(shè)備各自分擔(dān)幾路視頻流比換一臺(tái)高算力設(shè)備更靈活成本也更可控。這個(gè)思路特別適合多點(diǎn)分布式的園區(qū)場(chǎng)景每棟樓放一臺(tái)邊緣盒子中心平臺(tái)統(tǒng)一匯聚結(jié)果天然支持水平擴(kuò)展。5.3 和云端方案對(duì)比延遲與成本的天平近期熱詞里有一條特別有意思“邊緣智能是將AI模型部署在靠近數(shù)據(jù)源的設(shè)備上而不是全部丟到云端”。這和我在項(xiàng)目里用到的思路完全一致。如果4路視頻流全跑到云端做推理估算一下園區(qū)網(wǎng)絡(luò)上行帶寬需要同時(shí)傳4路1080P視頻流碼率按4Mbps算總共需要16Mbps上行帶寬持續(xù)占滿。再加上云服務(wù)器GPU按小時(shí)計(jì)費(fèi)的成本一年的支出很可能超過(guò)這臺(tái)邊緣盒子的十幾倍。如果把AI推理從云端搬到邊緣側(cè)比如能夠做到實(shí)時(shí)分析不受上行帶寬限制不用依賴于外網(wǎng)基建設(shè)施狀態(tài)。斷網(wǎng)時(shí)邊緣盒子還能繼續(xù)做視頻分析的業(yè)務(wù)只有結(jié)構(gòu)化結(jié)果上報(bào)平臺(tái)時(shí)才有網(wǎng)絡(luò)依賴。這個(gè)差異對(duì)安防、工業(yè)檢測(cè)這類場(chǎng)景至關(guān)重要。我在和同行交流時(shí)最常見的后悔就是“當(dāng)初不該買那么大的算力”。邊緣設(shè)備的生命周期很長(zhǎng)部署在室外和機(jī)柜里的設(shè)備一跑就是三五年算力買大了意味著每一次運(yùn)行都在額外耗電每一分電費(fèi)都是在為用不上的算力買單。說(shuō)到最后我最大的體會(huì)是邊緣計(jì)算項(xiàng)目選算力本質(zhì)上是一個(gè)工程決策而不是技術(shù)炫技。先把業(yè)務(wù)邏輯搞清楚把視頻流路上的每一個(gè)環(huán)節(jié)拆開量化每一幀的處理代價(jià)再倒推需要多少TOPS。數(shù)據(jù)擺在面前之后4路視頻流該選3 TOPS還是30 TOPS答案自然就有了。以后再遇到有人拿TOPS指標(biāo)來(lái)壓你不妨讓他先把業(yè)務(wù)場(chǎng)景和預(yù)算擺出來(lái)算完再聊。