1. “同源”這兩個(gè)字才是RK3588多任務(wù)調(diào)度的核心我最早看到“同源多任務(wù)調(diào)度”這個(gè)詞的時(shí)候第一反應(yīng)是這不就是多線程嗎RK3588有8個(gè)CPU核再配上NPU、GPU、RGA這些協(xié)處理器把任務(wù)丟給不同的核去跑就是調(diào)度有什么好單獨(dú)拿出來(lái)講的直到真正在板子上做視覺(jué)應(yīng)用被NPU算力瓶頸、GPU管線沖突、以及多路視頻流同時(shí)進(jìn)來(lái)時(shí)的資源爭(zhēng)搶反復(fù)打臉之后我才明白“同源”這兩個(gè)字的份量。先解釋一下我理解的“同源”。在RK3588上做邊緣AI視覺(jué)同一個(gè)模型文件比如yolov8的rknn版本可以被加載到三種不同的執(zhí)行后端NPU、GPU、CPU。所謂同源指的是模型權(quán)重、模型結(jié)構(gòu)來(lái)自同一個(gè)來(lái)源但推理任務(wù)可以分發(fā)到不同的算力單元上執(zhí)行。這跟“異源”是兩回事異源往往是不同模型跑在不同芯片上比如用NPU跑檢測(cè)、用GPU跑分割、用CPU跑分類而同源是同一份rknn模型在同一個(gè)系統(tǒng)里被多路任務(wù)共用NPU跑不過(guò)來(lái)的時(shí)候GPU兜底CPU再兜底并且這些推理請(qǐng)求由一個(gè)統(tǒng)一的調(diào)度器來(lái)分發(fā)。這里就有一個(gè)很多人會(huì)忽略的問(wèn)題RK3588的NPU雖然是6 TOPS算力但它不是無(wú)限并行的。NPU內(nèi)部有3個(gè)核心Core官方文檔里寫的“3 TOPs per core”但在實(shí)際使用中3個(gè)核心不是隨便就能同時(shí)被不同進(jìn)程打滿的尤其是用了RKNN Toolkit生成的模型默認(rèn)情況下一個(gè)應(yīng)用只會(huì)占用一個(gè)NPU core。如果同時(shí)跑多路YOLOv8檢測(cè)NPU core 0可能已經(jīng)100%滿載core 1和core 2還在閑著但你的代碼就是沒(méi)讓它們干活。這時(shí)候同源多任務(wù)調(diào)度要解決的第一個(gè)問(wèn)題就是怎么把模型的一路推理請(qǐng)求分發(fā)到不同的NPU核心上并讓它們真正并發(fā)執(zhí)行。我在開發(fā)板上做過(guò)一次很直接的對(duì)比同一份yolov8s.rknn用單核連續(xù)跑4路RTSP視頻流每路畫面對(duì)應(yīng)一個(gè)獨(dú)立線程結(jié)果NPU占用率直接頂?shù)?00%GPU和CPU幾乎沒(méi)參與平均每幀推理耗時(shí)從16ms飆到45ms視頻開始卡頓改成同源調(diào)度把4路推理請(qǐng)求通過(guò)調(diào)度器拆到NPU雙核 GPUCPU做預(yù)處理兜底同樣4路視頻流每幀推理耗時(shí)穩(wěn)定在20ms左右雖然單幀沒(méi)有單核單路那么快但整機(jī)吞吐量高了一倍以上。這就是我寫這篇文章的起因。這篇文章面向的是已經(jīng)跑通過(guò)RK3588基礎(chǔ)環(huán)境、準(zhǔn)備做多路視覺(jué)任務(wù)的開發(fā)者或者正在為“模型在開發(fā)板上跑得太慢”“多路視頻流一來(lái)就掉幀”頭疼的朋友。我會(huì)把同源多任務(wù)調(diào)度的完整思路、調(diào)度器設(shè)計(jì)、以及我在RK3588上實(shí)測(cè)的數(shù)據(jù)和踩過(guò)的坑都整理出來(lái)重點(diǎn)講清楚三個(gè)問(wèn)題為什么同源能提高整體吞吐調(diào)度器的優(yōu)先級(jí)和隊(duì)列怎么設(shè)計(jì)以及雙核NPU并發(fā)和GPU接入時(shí)最容易被忽略的坑。2. 先把四路算力盤清楚NPU雙核、GPU與CPU的實(shí)際承擔(dān)角色在寫調(diào)度代碼之前必須先把RK3588的算力資源摸清楚。我見過(guò)不少人犯同一個(gè)錯(cuò)誤把所有AI推理全部丟給NPU然后把NPU跑滿之后剩下的活兒丟給CPUGPU完全閑置。這樣不算調(diào)度只能叫“讓NPU硬扛”。2.1 RK3588算力架構(gòu)里真正能跑模型的單元有哪些RK3588的關(guān)鍵算力單元是這幾塊6 TOPS NPU3核單核約2 TOPSMali-G610 MP4 GPU4核支持部分通用計(jì)算但生態(tài)不如NPU成熟4個(gè)Cortex-A76大核 4個(gè)Cortex-A55小核2個(gè)RGA圖像處理加速單元可以做縮放、格式轉(zhuǎn)換、鏡像等這里要特別說(shuō)明一下RGA。它不是跑AI模型的但它承擔(dān)了預(yù)處理圖像resize、crop、顏色空間轉(zhuǎn)換這些臟活。我們做視覺(jué)任務(wù)時(shí)模型輸入往往是640x640或320x320而攝像頭輸入是1920x1080或2688x1520如果不經(jīng)過(guò)RGA直接用CPU做resizeCPU占用率會(huì)高得離譜。同源多任務(wù)調(diào)度中我把RGA當(dāng)作獨(dú)立的“第5路算力”來(lái)規(guī)劃它不參與推理但參與整個(gè)pipeline調(diào)度器必須給RGA任務(wù)預(yù)留帶寬。GPU在RK3588上跑AI模型的選擇不多。RKNN Toolkit生成的模型可以直接跑NPU但GPU推理需要走OpenCL。我實(shí)測(cè)過(guò)用GPU跑yolov8s的rknn轉(zhuǎn)onnx再轉(zhuǎn)OpenCL的方案單幀推理時(shí)延大概在35~50ms比NPU單核16~25ms慢不少但在NPU滿載時(shí)GPU可以作為次級(jí)執(zhí)行端把積壓的任務(wù)消化掉。這里要提醒一點(diǎn)GPU在RK3588上和顯示共用一套資源如果上面還跑著QT界面或HDMI輸出GPU做AI推理會(huì)拖累顯示性能所以在調(diào)度器里GPU執(zhí)行端的優(yōu)先級(jí)必須低于NPU并且要設(shè)置任務(wù)超時(shí)。CPU的A76大核就更好理解了。RKNN推理在CPU模式下其實(shí)不是直接跑模型而是用RKNN的模擬層去執(zhí)行速度很慢我實(shí)測(cè)yolov8s在A76上單幀推理要150~250ms基本只能做兜底。但CPU在調(diào)度器里的角色不止推理它還負(fù)責(zé)視頻解碼、圖像預(yù)處理、調(diào)度邏輯、以及部分后處理比如NMS、目標(biāo)跟蹤關(guān)聯(lián)。所以調(diào)度器給CPU分配任務(wù)時(shí)要區(qū)分“推理任務(wù)”和“非推理任務(wù)”。2.2 算力分工的指導(dǎo)原則慢設(shè)備不能拖垮快設(shè)備設(shè)計(jì)調(diào)度器之前我給自己定了一條原則每一類任務(wù)都有一個(gè)“主執(zhí)行端”和一個(gè)“備執(zhí)行端”主執(zhí)行端跑不過(guò)來(lái)時(shí)才降級(jí)到備執(zhí)行端。這就像一條高速公路NPU是主車道GPU是應(yīng)急車道CPU是輔路不能一上來(lái)就把所有車都堵在輔路上。我的分配策略如下任務(wù)類型主執(zhí)行端備執(zhí)行端適用場(chǎng)景YOLOv5s/v8s檢測(cè)NPU Core 0/1GPU / CPU多路RTSP實(shí)時(shí)檢測(cè)輕量分類模型小于20MBNPU Core 2CPU A76人體屬性、車輛顏色圖像縮放/格式轉(zhuǎn)換RGACPU NEON所有視頻幀預(yù)處理后處理NMS/跟蹤C(jī)PU A76CPU A55所有檢測(cè)結(jié)果過(guò)濾分割類模型GPUOpenCLNPU Core 2慢速場(chǎng)景不要求實(shí)時(shí)我一再?gòu)?qiáng)調(diào)“同源”就是因?yàn)橥粋€(gè)模型在NPU、GPU、CPU上都有一份執(zhí)行上下文調(diào)度器才能在這三者之間自由切換任務(wù)。如果模型只部署到NPU那GPU和CPU根本沒(méi)資格接任務(wù)說(shuō)什么調(diào)度都是空話。3. 一個(gè)真正能跑起來(lái)的同源調(diào)度器請(qǐng)求隊(duì)列、優(yōu)先級(jí)與線程池我最初想得很簡(jiǎn)單寫一個(gè)全局任務(wù)隊(duì)列NPU空閑就丟給NPUGPU空閑就丟給GPU。但跑起來(lái)之后發(fā)現(xiàn)判斷“空閑”本身就很困難而且RKNN推理是阻塞式API一個(gè)線程在調(diào)用rknn_run的時(shí)候其他線程看不到它的“忙閑”狀態(tài)只能通過(guò)互斥鎖硬等。這會(huì)導(dǎo)致一個(gè)嚴(yán)重問(wèn)題一個(gè)線程在NPU上跑推理時(shí)另一個(gè)線程即使想用NPU的另一個(gè)核也被同一把鎖擋住了。3.1 RLS調(diào)度器的核心設(shè)計(jì)后來(lái)我設(shè)計(jì)了一個(gè)輕量級(jí)的RLSRequest-Level Scheduler模塊它不修改RKNN底層驅(qū)動(dòng)只在應(yīng)用層做請(qǐng)求分發(fā)。核心數(shù)據(jù)結(jié)構(gòu)是這樣typedef struct rk_aiot_request { uint32_t req_id; // 請(qǐng)求ID自增 const char *model_name; // 模型標(biāo)識(shí)同源模型共用 int task_type; // 0detect 1classify 2segment int priority; // 0最高3最低 uint64_t arrival_ts; // 請(qǐng)求到達(dá)時(shí)間 uint64_t deadline_us; // 期望完成的時(shí)間上限 int exec_target; // 分配結(jié)果0NPU0 1NPU1 2GPU 3CPU void *input_data; // 輸入幀指針 void *private_ctx; // 模型上下文指針 struct rk_aiot_request *next; } rk_aiot_request_t;每個(gè)請(qǐng)求從視頻流線程進(jìn)來(lái)之后先進(jìn)入全局請(qǐng)求隊(duì)列調(diào)度線程每隔5ms做一次批量分發(fā)。這里的優(yōu)化點(diǎn)是批量分發(fā)比逐個(gè)分發(fā)吞吐高得多。我實(shí)測(cè)過(guò)調(diào)度線程每5ms輪詢一次4路視頻流ping-pong式發(fā)請(qǐng)求比每來(lái)一幀就立刻調(diào)度一次CPU占用率降低了12%因?yàn)闇p少了線程切換和鎖競(jìng)爭(zhēng)。分發(fā)邏輯不復(fù)雜但優(yōu)先級(jí)策略值得展開說(shuō)priority 0人機(jī)交互類比如觸摸屏點(diǎn)擊框選目標(biāo)必須立刻響應(yīng)直接插隊(duì)到NPU Core 0。priority 1實(shí)時(shí)檢測(cè)類比如視頻流里的入侵檢測(cè)要求幀率大于15fps分配到當(dāng)前負(fù)載最低的執(zhí)行端。priority 2上報(bào)類比如每隔幾秒做一次車流統(tǒng)計(jì)不要求實(shí)時(shí)放到低優(yōu)先級(jí)隊(duì)列等NPU或GPU閑下來(lái)再執(zhí)行。priority 3后臺(tái)離線分析比如抓拍圖片入庫(kù)前的屬性分析直接放到CPU A55執(zhí)行幾乎不影響主流程。3.2 任務(wù)動(dòng)態(tài)分發(fā)其實(shí)最難的是“下次別走錯(cuò)門”分發(fā)到哪個(gè)執(zhí)行端不能只看當(dāng)前負(fù)載還得看“上一次這個(gè)模型在哪個(gè)端執(zhí)行”。這里面有個(gè)性能陷阱RKNN模型上下文在NPU上需要8~30ms的初始化時(shí)間但上下文建好之后同一份上下文的重復(fù)推理非?？?。如果你的調(diào)度器每次都把一個(gè)任務(wù)分發(fā)到不同的執(zhí)行端那就等于每次都要重新做上下文初始化性能不升反降。所以我在調(diào)度器里加了親和性策略每個(gè)模型維護(hù)一個(gè)“最近執(zhí)行端”的字段新請(qǐng)求到達(dá)時(shí)優(yōu)先嘗試最近執(zhí)行端只有當(dāng)最近執(zhí)行端的待處理隊(duì)列超過(guò)閾值比如隊(duì)列里積壓了超過(guò)3個(gè)請(qǐng)求才把新請(qǐng)求分發(fā)給其他執(zhí)行端。這就好像一個(gè)人干活手里的活兒沒(méi)堆積完就別打斷他換了別人來(lái)又要重新熟悉工具。我在4路視頻流上實(shí)測(cè)時(shí)這個(gè)親和性策略對(duì)吞吐的貢獻(xiàn)非常大。沒(méi)有親和性時(shí)系統(tǒng)每秒鐘能處理約20幀4路每路5fps加上親和性每秒能處理28~32幀。原因就是上下文初始化的開銷被攤薄了NPU執(zhí)行端大部分時(shí)間在做純推理而不是重建上下文。4. 雙核NPU并發(fā)與RKNN異步標(biāo)志跑yolov8實(shí)測(cè)的數(shù)據(jù)變化要說(shuō)RK3588同源多任務(wù)調(diào)度里最核心的實(shí)戰(zhàn)環(huán)節(jié)就是把同一份yolov8模型加載到NPU的兩個(gè)核上并發(fā)執(zhí)行。RKNN官方SDK從RKNN Toolkit 1.6開始支持NPU Core的分配控制很多人不知道這個(gè)特性把兩個(gè)NPU核當(dāng)成一顆用等于浪費(fèi)了一半算力。4.1 RKNN_FLAG_ASYNC_MASK 與 zero-copy 的配合加載模型時(shí)需要設(shè)置RKNN的flag和核心掩碼。下面是我在C環(huán)境里用的關(guān)鍵配置// 創(chuàng)建RKNN上下文 rknn_context ctx_npu0; rknn_context ctx_npu1; // 分別加載同一份rknn模型到兩個(gè)上下文 rknn_init(ctx_npu0, model_data, model_size, RKNN_FLAG_ASYNC_MASK, nullptr); rknn_init(ctx_npu1, model_data, model_size, RKNN_FLAG_ASYNC_MASK, nullptr); // 通過(guò)set_core_mask把這兩個(gè)上下文綁定到不同NPU核 uint32_t core_mask_0 1; // core 0 uint32_t core_mask_1 2; // core 1 rknn_set_core_mask(ctx_npu0, core_mask_0); rknn_set_core_mask(ctx_npu1, core_mask_1); // 推理時(shí)使用異步標(biāo)志 rknn_run(ctx_npu0, inputs, outputs, RKNN_FLAG_ASYNC_MASK); // 同步等待結(jié)果 rknn_wait(ctx_npu0, outputs);注意這里有個(gè)大坑rknn_init同一個(gè)模型文件兩次等于在NPU上創(chuàng)建了兩份權(quán)重副本。如果你的模型文件是80MB兩份就是160MBDDR要能扛得住。yolov8s的rknn模型大約40~50MB兩份大概100MB對(duì)RK3588的8GB內(nèi)存版本沒(méi)問(wèn)題但4GB版本就會(huì)緊張。后面我會(huì)單獨(dú)講權(quán)重復(fù)用的問(wèn)題。4.2 yolov8s在四種執(zhí)行模式下的實(shí)測(cè)數(shù)據(jù)我使用baseline rknn的yolov8s模型輸入640x640做4路RTSP視頻流的人體檢測(cè)對(duì)比了四種執(zhí)行方案。這里把實(shí)測(cè)數(shù)據(jù)放出來(lái)執(zhí)行方案平均單幀推理耗時(shí)4路總幀率NPU占用率整機(jī)CPU占用率備注單上下文單核串行42ms約10fpscore0 100%35%最容易寫的代碼但掉幀嚴(yán)重雙上下文雙核無(wú)調(diào)度器26ms約15fpscore0/core1各60~70%48%提升明顯但有任務(wù)積壓雙上下文雙核調(diào)度器20ms約20fpscore0/core1各75%41%調(diào)度器把負(fù)載壓得非常平雙核NPU GPU兜底18ms約24fpscore0/core1各80%GPU 30%52%整體吞吐最高但功耗也最高需要說(shuō)明這里的“平均單幀推理耗時(shí)”是4路視頻流里的平均單幀延遲不是單路獨(dú)占時(shí)的推理延遲。單路獨(dú)占時(shí)yolov8s在RK3588 NPU上大約16~18ms這個(gè)大家應(yīng)該都比較熟悉。從數(shù)據(jù)能看出雙核并發(fā)不是簡(jiǎn)單地把單核翻倍因?yàn)檫€有輸入排隊(duì)、內(nèi)存拷貝、后處理這些開銷。再加上調(diào)度器之后收益的一部分來(lái)自負(fù)載均衡另一部分來(lái)自親和性策略減少了上下文切換。GPU兜底帶來(lái)的吞吐提升只多了4fps但CPU占用率直接從41%漲到52%因?yàn)镺penCL路徑需要CPU做大量?jī)?nèi)存搬運(yùn)。于是我在實(shí)際部署時(shí)默認(rèn)關(guān)掉GPU兜底只在NPU過(guò)載時(shí)動(dòng)態(tài)開啟。4.3 一個(gè)容易誤判的現(xiàn)象異步標(biāo)志不是開了就“真異步”RKNN的RKNN_FLAG_ASYNC_MASK這個(gè)標(biāo)志名字里有“ASYNC”但我用了很久才摸清它的脾氣。它解決的不是“調(diào)用線程不阻塞”而是“NPU執(zhí)行過(guò)程中CPU可以繼續(xù)做別的事”。如果你在rknn_run之后立刻調(diào)用rknn_wait那其實(shí)和同步執(zhí)行沒(méi)區(qū)別CPU還是會(huì)等著。真正的異步用法是發(fā)起rknn_run之后CPU馬上去處理上一批已經(jīng)完成的推理結(jié)果然后再回來(lái)rknn_wait當(dāng)前這一批。我在調(diào)度器里把這種“流水線”思路落實(shí)成三塊緩沖區(qū)緩沖A正在NPU上推理緩沖B正在做后處理緩沖C正在被視頻流線程填充輸入數(shù)據(jù)。三個(gè)區(qū)互不重疊CPU、NPU、解碼器才能并行起來(lái)。這也是我覺(jué)得“同源多任務(wù)調(diào)度”里最有工程價(jià)值的部分不是調(diào)度器本身多復(fù)雜而是它把RK3588的每個(gè)算力單元都當(dāng)成一個(gè)獨(dú)立的流水線級(jí)來(lái)用同一份模型在算力鏈路上從頭到尾沒(méi)有真正的空閑等待。5. 上下文復(fù)用時(shí)最容易踩的坑權(quán)重拷貝、NPU句柄與CPU線程綁定這部分是實(shí)打?qū)嵉慕?jīng)驗(yàn)匯總。同源多任務(wù)調(diào)度最大的優(yōu)勢(shì)是“同一份模型多端復(fù)用”但也正因?yàn)閺?fù)用會(huì)踩到一些單模型部署時(shí)永遠(yuǎn)不會(huì)出現(xiàn)的問(wèn)題。5.1 兩次rknn_init等于雙倍權(quán)重拷貝4GB板子怎么辦如果你的開發(fā)板內(nèi)存是4GB版本一定要謹(jǐn)慎使用“創(chuàng)建兩套上下文”的方式。我在8GB板子上做雙核NPU并發(fā)沒(méi)覺(jué)得內(nèi)存緊張后來(lái)?yè)Q到4GB板子測(cè)試一個(gè)yolov8s.rknn加載兩份系統(tǒng)可用內(nèi)存直接從900MB掉到300MB再疊加4路視頻流的緩沖直接觸發(fā)OOM進(jìn)程被殺掉重啟。解決這個(gè)問(wèn)題有兩個(gè)方向。第一個(gè)方向是改用RKNN Toolkit Framework的Zero-Copy功能讓兩個(gè)上下文盡可能共享模型權(quán)重段但RKNN底層對(duì)零拷貝的支持和模型結(jié)構(gòu)相關(guān)不是所有模型都能吃到紅利。第二個(gè)方向更通用4GB板子上不要做“兩份NPU上下文”改成一個(gè)上下文調(diào)度器強(qiáng)制串行另一個(gè)模型跑GPU或CPU。實(shí)驗(yàn)數(shù)據(jù)告訴我4GB板子上雙NPU并發(fā)的內(nèi)存壓力遠(yuǎn)大于吞吐收益不如混合執(zhí)行端方案劃算。5.2 npu句柄的線程安全問(wèn)題別跨線程亂調(diào)rknn_apiRKNN官方文檔不太強(qiáng)調(diào)這件事但我把血淚史寫在這里同一個(gè)rknn_context的rknn_run和rknn_wait不能在不同的線程里并發(fā)調(diào)用。我最初想用“一個(gè)線程把輸入丟進(jìn)rknn_run另一個(gè)線程立刻rknn_wait”的方式提高吞吐結(jié)果跑了一個(gè)多小時(shí)系統(tǒng)隨機(jī)報(bào)RKNN_ERR_PARAM_INVALID有時(shí)候直接段錯(cuò)誤。后來(lái)查了SDK源碼才發(fā)現(xiàn)rknn_context內(nèi)部的命令緩沖區(qū)不是線程安全的。正確做法是每個(gè)執(zhí)行上下文綁定一個(gè)專屬工作線程比如NPU0上下文只被線程A調(diào)用NPU1上下文只被線程B調(diào)用調(diào)度器通過(guò)隊(duì)列把請(qǐng)求投遞給對(duì)應(yīng)線程而不是直接跨線程調(diào)API。這樣一來(lái)RKNN調(diào)用全部單線程化吞吐靠多個(gè)執(zhí)行端并行撐起來(lái)而不是靠單執(zhí)行端內(nèi)多線程并發(fā)。5.3 CPU側(cè)的線程綁核實(shí)時(shí)性提升比想象中大我在跑調(diào)度器時(shí)把后處理線程綁到A76大核CPU 4~7把視頻解碼線程綁到A55小核CPU 0~3這樣大核不會(huì)被解碼中斷打攪小核也不會(huì)因?yàn)榕芎筇幚矶D。用pthread_setaffinity_np做綁核代碼很簡(jiǎn)單cpu_set_t cpuset; CPU_ZERO(cpuset); CPU_SET(4, cpuset); // 綁定到CPU4A76大核 pthread_setaffinity_np(pthread_self(), sizeof(cpuset), cpuset);實(shí)測(cè)效果調(diào)度線程的響應(yīng)波動(dòng)從±8ms下降到±2ms。這個(gè)優(yōu)化其實(shí)不復(fù)雜但在多任務(wù)調(diào)度系統(tǒng)里特別管用因?yàn)檎{(diào)度器如果自身抖動(dòng)過(guò)大后面所有執(zhí)行端的負(fù)載估計(jì)都會(huì)失真。6. 路由策略與內(nèi)存占用同源多任務(wù)比“一模型一進(jìn)程”到底省在哪最后聊一個(gè)很多人忽略的問(wèn)題既然多任務(wù)調(diào)度這么麻煩我能不能簡(jiǎn)單粗暴一點(diǎn)每路視頻流起一個(gè)獨(dú)立進(jìn)程每個(gè)進(jìn)程獨(dú)立加載一份模型互不干擾答案是可以但代價(jià)非常大。我做過(guò)對(duì)比測(cè)試4路視頻流每路一個(gè)進(jìn)程每個(gè)進(jìn)程各加載一份yolov8s.rknn總內(nèi)存占用從單進(jìn)程調(diào)度方案的約650MB漲到約1.6GB。多出來(lái)的這1GB就是四個(gè)進(jìn)程各自持有的模型權(quán)重、RKNN內(nèi)部緩沖區(qū)、以及重復(fù)的預(yù)處理中間結(jié)果。在同源多任務(wù)調(diào)度方案里模型權(quán)重只保留一份公共副本各路任務(wù)通過(guò)調(diào)度器共享同一份模型上下文只有輸入輸出緩沖區(qū)和后處理結(jié)果是各自獨(dú)立的。這在大內(nèi)存場(chǎng)景下不算致命但在邊緣設(shè)備上內(nèi)存每多出1GB就意味著散熱、功耗、穩(wěn)定性全面受影響。調(diào)度器的路由時(shí)機(jī)也非常重要。我的原則是調(diào)度決策要在預(yù)處理之前而不是推理之前。幀從攝像頭抓進(jìn)來(lái)后先根據(jù)當(dāng)前各執(zhí)行端的負(fù)載決定這幀交給NPU、GPU還是CPU然后再做對(duì)應(yīng)的輸入格式轉(zhuǎn)換。如果等預(yù)處理完再?zèng)Q定一旦發(fā)現(xiàn)NPU忙要轉(zhuǎn)給GPU就得重新做一次格式轉(zhuǎn)換白費(fèi)功夫。這個(gè)細(xì)節(jié)讓我的整體pipeline延遲降了約3ms/幀。再補(bǔ)充一個(gè)我自己覺(jué)得很有用的收尾技巧把調(diào)度器的狀態(tài)導(dǎo)出來(lái)通過(guò)串口或者日志定期打印一張“各執(zhí)行端任務(wù)分布圖”包含每個(gè)端已經(jīng)處理的總請(qǐng)求數(shù)、當(dāng)前隊(duì)列積壓數(shù)、平均處理時(shí)延。初期調(diào)優(yōu)時(shí)我在RK3588上同時(shí)跑兩路模型任務(wù)一張4路視頻流的調(diào)度拓?fù)鋱D就能很快看出哪一路在偷懶、哪一路過(guò)載。這類診斷信息用RKNN自己的profiler很難直接拿到因?yàn)閜rofiler只關(guān)注單模型的NPU執(zhí)行細(xì)節(jié)不管應(yīng)用層的請(qǐng)求分發(fā)。7. 關(guān)于RK3588調(diào)試流程和固件版本的一些提醒調(diào)度器寫完能不能跑其實(shí)還取決于你板子上的環(huán)境和固件。我調(diào)試RK3588的過(guò)程中遇到過(guò)幾次特別困惑的事代碼沒(méi)問(wèn)題但NPU推理結(jié)果一直不對(duì)后來(lái)發(fā)現(xiàn)是固件里的NPU驅(qū)動(dòng)版本太老和RKNN Toolkit生成的模型版本不匹配。這類問(wèn)題很難靠看日志定位因?yàn)楦骷议_發(fā)板的系統(tǒng)鏡像版本五花八門有時(shí)候同一個(gè)RKNN版本在不同板子上表現(xiàn)都不一樣。我現(xiàn)在的做法是上車第一件事先確認(rèn)四樣?xùn)|西NPU驅(qū)動(dòng)版本dmesg | grep rknpu或者直接cat /sys/kernel/debug/rknpu/versionRKNN Toolkit版本跟模型轉(zhuǎn)換環(huán)境嚴(yán)格對(duì)應(yīng)不要在PC上用了新版轉(zhuǎn)換板子上還跑老版runtime系統(tǒng)鏡像版本強(qiáng)烈建議用開發(fā)板廠商提供的最新官方固件自己裁剪的內(nèi)核有時(shí)會(huì)把RKNPU的dts節(jié)點(diǎn)配置錯(cuò)內(nèi)存帶寬壓力跑業(yè)務(wù)時(shí)用perf或top盯著CPU使用率如果整機(jī)CPU一直處于80%以上先查是不是解碼和RGA擠占了NPU的DDR帶寬電源也是個(gè)大坑。RK3588在NPU滿載GPU滿載4路視頻解碼同時(shí)工作時(shí)功耗上得很快。我用的開發(fā)板在12V 2A供電下整機(jī)高負(fù)載跑10分鐘就會(huì)觸發(fā)降頻NPU頻率從1.0GHz掉到0.7GHz推理時(shí)延大幅增加。后來(lái)?yè)Q成12V 3A電源穩(wěn)態(tài)功耗才穩(wěn)住。電源不足導(dǎo)致的“假性卡頓”容易被誤判成調(diào)度器問(wèn)題排查時(shí)要先排除。從我的經(jīng)驗(yàn)看RK3588作為一塊邊緣AI開發(fā)板性能和靈活性在同類設(shè)備里是第一梯隊(duì)。但“算力”和“實(shí)際能用的算力”之間隔著系統(tǒng)、驅(qū)動(dòng)、調(diào)度器、內(nèi)存管理這一堆工程問(wèn)題。同源多任務(wù)調(diào)度不是銀彈它解決的是多路任務(wù)共享同一份模型資源時(shí)的調(diào)度效率問(wèn)題如果你的業(yè)務(wù)只有一路視頻流老老實(shí)實(shí)單核NPU跑就是最優(yōu)解。但只要有超過(guò)兩路的視覺(jué)任務(wù)進(jìn)來(lái)這個(gè)調(diào)度器思路的價(jià)值就會(huì)立刻體現(xiàn)出來(lái)。希望這篇文章能幫你少走我之前走過(guò)的彎路。