144、影像算法DSP/NPU Offloading——降噪/超分/語義分割算子在高通/聯(lián)發(fā)科/海思平臺(tái)的部署選擇上個(gè)月在調(diào)試一臺(tái)搭載驍龍8 Gen2的旗艦機(jī)，客戶反饋夜景模式在暗光下預(yù)覽幀率掉到18fps，而且發(fā)熱明顯。抓了systrace一看，罪魁禍?zhǔn)资亲匝械臅r(shí)域降噪算子——純CPU跑，每幀耗時(shí)32ms，把整個(gè)pipeline拖垮了。當(dāng)時(shí)我第一反應(yīng)是“這玩意兒不是該扔給DSP嗎”，結(jié)果一查代碼，發(fā)現(xiàn)當(dāng)初為了趕進(jìn)度，直接在ARM核上寫了NEON版本，壓根沒考慮過異構(gòu)計(jì)算。這種事兒在行業(yè)里太常見了，算法工程師覺得“能跑就行”，系統(tǒng)工程師又沒空幫你重構(gòu)，最后就是性能爛在產(chǎn)線上。先潑盆冷水：不是所有算子都適合offload。降噪、超分、語義分割這三類，恰恰是“看起來適合、實(shí)際坑最多”的典型。你拿一個(gè)3x3的均值濾波去問DSP要不要接，它當(dāng)然說“來者不拒”，但等你把bilateral filter的權(quán)重計(jì)算搬上去，就會(huì)發(fā)現(xiàn)DSP的L2 cache小得可憐，數(shù)據(jù)搬運(yùn)的時(shí)間比計(jì)算還長(zhǎng)。我見過最離譜的案例，有人把超分網(wǎng)絡(luò)里的transformer block硬塞給NPU，結(jié)果NPU不支持動(dòng)態(tài)shape，每次推理都要重新編譯模型，幀率直接砍半。高通平臺(tái)，Spectra ISP和Hexagon DSP之間有一條叫“camera fast path”的專用通道，數(shù)據(jù)從ISP出來可以不經(jīng)過DDR，直接進(jìn)DSP的TCM（緊耦合內(nèi)存）。這個(gè)設(shè)計(jì)本意是給實(shí)時(shí)降噪用的，但有個(gè)致命限制——TCM總共才幾百KB，你塞不下一個(gè)完整的U-Net。所以高通的推薦做法是“分塊處理”，把圖像切成16x16的tile，