1. 項目概述當稀疏化遇上多任務BEV感知最近在自動駕駛感知算法的圈子里地平線推出的“SparseBevFusionMultitaskOE-V1.0”這個參考算法引起了不少工程師和研究員的好奇。這個名字聽起來有點長但拆開來看每一個詞都指向了當前感知領域最前沿的幾個技術(shù)方向Sparse稀疏化、BevFusion鳥瞰圖融合和Multitask多任務。簡單來說這是一個基于地平線征程系列芯片專門為高效、高性能的多任務鳥瞰圖感知而設計的算法參考實現(xiàn)。如果你正在為車載計算平臺上的感知模型部署發(fā)愁尤其是面對動輒幾十個GFLOPs甚至上百TFLOPs的復雜BEV模型時感覺內(nèi)存和算力都捉襟見肘那么這個算法可能就是你一直在找的“參考答案”。它核心要解決的就是在有限的車規(guī)級芯片算力下如何讓一個模型同時、高效地完成3D目標檢測、可行駛區(qū)域分割、車道線檢測等多個關鍵感知任務。這不僅僅是把幾個任務的網(wǎng)絡頭拼在一起更深層的是通過稀疏化計算來大幅降低冗余讓模型跑得更快、更省資源。我之所以花時間深入研究它是因為在實際項目中我們常常遇到這樣的困境單個任務的BEV模型比如只做3D檢測已經(jīng)能讓芯片的NPU利用率飆到80%以上再加上其他任務要么延遲超標要么內(nèi)存爆掉。地平線這個參考算法給出了一種將前沿學術(shù)思想稀疏BEV、多任務學習與芯片硬件特性如BPU架構(gòu)深度結(jié)合的工程化范例。它不僅僅是論文里的代碼更是考慮了真實部署約束的解決方案。對于算法工程師、部署工程師甚至是負責技術(shù)選型的架構(gòu)師理解這個算法的設計思路和實現(xiàn)細節(jié)都能為自家的感知系統(tǒng)優(yōu)化帶來直接的啟發(fā)。2. 核心設計思路與稀疏化價值解析2.1 從密集BEV到稀疏BEV的范式轉(zhuǎn)變要理解SparseBevFusionMultitask首先得明白傳統(tǒng)密集BEVBird‘s-Eye-View感知的瓶頸在哪里。經(jīng)典的BEV感知流程通常是將多攝像頭圖像通過一個強大的視覺主干網(wǎng)絡如ResNet、Swin Transformer提取特征然后通過一個稱為“View Transformer”的模塊比如LSS、BEVFormer等方法將這些透視視圖下的特征“抬升”或“變換”到鳥瞰圖坐標系下形成一個密集的BEV特征圖。這個BEV特征圖就像一張俯視的地圖每個像素位置都對應著地面上的一個物理位置并包含了該處的視覺語義信息。問題就出在這個“密集”上。為了覆蓋車輛周圍足夠大的感知范圍比如前向100米左右各50米并保持足夠高的分辨率比如0.1米/像素這個BEV特征圖會非常龐大。假設范圍是100m x 100m分辨率0.25m那么BEV特征圖就是400x400的網(wǎng)格。如果特征通道數(shù)是256那么單幀的BEV特征數(shù)據(jù)量就是400 * 400 * 256 ≈ 4千萬個元素對于float32數(shù)據(jù)類型就是約160MB。這僅僅是特征圖還不算后續(xù)檢測頭、分割頭的計算量。如此密集的計算和內(nèi)存訪問對于車載芯片是巨大的負擔。稀疏BEV的核心思想就是打破這個密集網(wǎng)格的約束。它認為在真實的駕駛場景中感興趣的目標車輛、行人和可駕駛區(qū)域只占據(jù)了整個BEV空間的一小部分大部分區(qū)域是空曠的或無信息的。因此完全沒有必要為所有位置都進行計算和存儲。稀疏BEV算法會動態(tài)地生成一組“BEV查詢”或“BEV錨點”這些查詢只聚焦在可能有物體的區(qū)域。計算和特征存儲只發(fā)生在這組稀疏的查詢位置上從而極大地減少了計算量和內(nèi)存占用。在這個參考算法中“Sparse”前綴正是體現(xiàn)了這一關鍵設計。它很可能采用了類似Sparse BEV或PETR系列算法的思想使用一組可學習的稀疏查詢向量直接與圖像特征進行交互生成稀疏的BEV特征從而避免了構(gòu)建龐大密集特征圖的開銷。2.2 多任務學習的協(xié)同與權(quán)衡“Multitask”是這個算法的另一大支柱。在自動駕駛感知中3D目標檢測框出車輛、行人的位置和大小、語義分割劃分出道路、車道線、人行道等區(qū)域通常是獨立模型。但這帶來了幾個問題1) 多個模型重復計算底層特征算力浪費2) 模型間輸出可能不一致比如檢測框壓到了分割出的道路上3) 系統(tǒng)集成復雜調(diào)度開銷大。多任務學習用一個共享的主干網(wǎng)絡Backbone來提取圖像的通用特征然后為不同任務配備不同的任務頭Task Head。這樣特征提取只做一次各個任務頭在此基礎上進行特異性解碼。這能顯著提升計算效率并可能因為任務間的相關性而提升各自的性能知識共享。然而多任務設計并非簡單的“搭積木”。它面臨嚴峻的挑戰(zhàn)任務沖突不同任務的最優(yōu)特征表示可能不同。例如檢測任務需要精確的邊界信息而分割任務需要連貫的區(qū)域信息。強行共享特征可能導致相互干擾性能都不如單任務模型。損失平衡各任務的損失函數(shù)量綱、數(shù)值范圍差異巨大。如何平衡檢測損失如Smooth-L1 Loss和分割損失如交叉熵Loss的權(quán)重是一個需要精心調(diào)參的難題。部署友好性多個任務頭的輸出后處理邏輯不同需要設計高效的流水線避免成為新的瓶頸。地平線的這個參考算法其價值就在于它提供了一個經(jīng)過驗證的多任務網(wǎng)絡結(jié)構(gòu)設計和損失平衡方案并且是針對其BPU硬件進行過優(yōu)化的確保了算法高效性的同時也兼顧了部署的便利性。2.3 BevFusion特征融合的藝術(shù)“BevFusion”指明了算法的另一項關鍵技術(shù)融合。在自動駕駛中感知的可靠性不能只依賴于單一傳感器。雖然這個算法名稱和當前的熱點“BEVFusion”融合激光雷達和攝像頭在字面上重合但根據(jù)其作為“參考算法”的定位以及地平線芯片主要面向純視覺方案的特點此處的“Fusion”更可能指的是多攝像頭之間的視覺特征融合或者是在BEV空間中對時序特征的融合。對于多攝像頭每個攝像頭只能看到場景的一部分且存在重疊區(qū)域。如何將這些不同視角、不同畸變的圖像特征統(tǒng)一、無失真地融合到一個共同的BEV空間表達中是View Transformer模塊要解決的核心問題。這個參考算法所采用的融合策略直接決定了BEV特征的空間一致性和精度。此外時序融合也至關重要。單幀圖像難以判斷靜止或低速目標也容易受遮擋影響。引入歷史BEV特征通過遞歸神經(jīng)網(wǎng)絡如ConvGRU或Transformer進行融合可以顯著提升感知的穩(wěn)定性和對遮擋目標的預測能力。這部分如果實現(xiàn)得好對于城區(qū)復雜場景的感知提升將是巨大的。3. 算法模塊深度拆解與實操要點3.1 圖像主干網(wǎng)絡與特征提取優(yōu)化圖像主干網(wǎng)絡Backbone是感知系統(tǒng)的基石負責從原始像素中提取豐富、多尺度的語義特征。在車載環(huán)境主干網(wǎng)絡的選擇必須在性能和效率之間取得完美平衡。常見選型與地平線適配像ResNet、ResNeXt、RegNet這類CNN backbone因其結(jié)構(gòu)規(guī)整、易于優(yōu)化在部署中很受歡迎。而近年來Swin Transformer等視覺Transformer憑借其強大的全局建模能力在精度上往往更勝一籌。然而Transformer的自注意力機制計算復雜度高對芯片的矩陣乘加能力和內(nèi)存帶寬要求苛刻。地平線的BPUBrain Processing Unit對卷積類操作有深度優(yōu)化。因此這個參考算法極有可能采用了一種重參數(shù)化卷積網(wǎng)絡或高效CNN架構(gòu)作為主干例如RepVGG、GhostNet的變體或者地平線自研的、針對BPU指令集特化過的基礎網(wǎng)絡結(jié)構(gòu)。這類網(wǎng)絡在訓練時可能結(jié)構(gòu)復雜多分支但在部署時可以通過結(jié)構(gòu)重參數(shù)化轉(zhuǎn)換為單一的直連卷積從而獲得極高的推理速度。注意在嘗試替換主干網(wǎng)絡時務必考慮其與后續(xù)View Transformer模塊的兼容性。有些Transformer-based的View Transformer如BEVFormer與CNN主干的配合可能需要調(diào)整特征圖的尺度或通道數(shù)。直接套用可能破壞原有的設計平衡。多尺度特征融合目標有大有小車道線細長這就要求主干網(wǎng)絡能提供多尺度的特征圖例如1/8, 1/16, 1/32下采樣率。參考算法會精心設計一個特征金字塔網(wǎng)絡FPN或雙向特征金字塔BiFPN來融合這些多尺度特征。這里的一個實操技巧是在融合時可以為不同尺度的特征分配可學習的權(quán)重如BiFPN讓網(wǎng)絡自動學習哪些尺度對后續(xù)的BEV生成和不同任務更重要。在部署時這些額外的加權(quán)操作可能會增加一些開銷需要評估其帶來的精度收益是否值得。3.2 稀疏BEV查詢生成與視圖變換這是整個算法的核心創(chuàng)新點所在也是“Sparse”一詞的落腳點。稀疏查詢的初始化算法不會創(chuàng)建一個覆蓋全場景的密集BEV網(wǎng)格而是初始化一組固定數(shù)量比如900個的可學習參數(shù)每個參數(shù)稱為一個“查詢”Query。每個查詢可以理解為一個“虛擬的智能體”它被賦予了一個初始的3D空間參考位置x, y, z和一個特征向量。這些初始位置可以是均勻分布在感興趣區(qū)域內(nèi)的錨點也可以是純粹可學習、由數(shù)據(jù)驅(qū)動的?；趫D像的查詢細化初始的查詢是“盲目的”。接下來這些查詢需要與多攝像頭的圖像特征進行交互從而獲取視覺信息并細化自身。這個過程通常通過交叉注意力Cross-Attention機制實現(xiàn)每個查詢通過相機參數(shù)投影到所有攝像頭的圖像平面上找到其對應的圖像區(qū)域。查詢的特征向量與對應圖像區(qū)域的特征進行交叉注意力計算。查詢作為“問詢者”圖像特征作為“被檢索的信息源”。通過注意力機制查詢從圖像中聚合最相關的特征更新自身的特征表示同時也可能微調(diào)其3D位置如果設計允許。這個過程是稀疏的因為只有這有限數(shù)量的查詢參與計算而不是所有BEV網(wǎng)格。輸出稀疏BEV特征經(jīng)過多輪通常是幾層Transformer Decoder層與圖像特征的交互后這組查詢就攜帶了豐富的、基于視覺的3D場景信息。它們的特征集合就構(gòu)成了我們需要的稀疏BEV特征。相比于400x400的密集網(wǎng)格900個查詢的特征數(shù)據(jù)量小了近兩個數(shù)量級。實操心得查詢數(shù)量的設置是一個關鍵的超參數(shù)。數(shù)量太少無法充分表達復雜場景會丟失小目標或細節(jié)如遠處車道線數(shù)量太多則稀疏化的收益降低。需要在實際數(shù)據(jù)集上進行驗證。一個實用的方法是分析場景中目標分布的密度讓查詢數(shù)量略高于平均每幀的目標數(shù)并留有一定余量。3.3 多任務頭設計與損失函數(shù)工程在得到稀疏的BEV特征后不同的任務頭將在此基礎上進行解碼。這是體現(xiàn)“Multitask”設計水平的關鍵環(huán)節(jié)。3D目標檢測頭由于BEV特征是稀疏的傳統(tǒng)的基于密集錨框Anchor的檢測器不再適用。通常采用基于查詢的檢測頭。每個BEV查詢本身就蘊含了一個潛在目標的位置和特征信息。檢測頭通常由幾個全連接層MLP組成直接對每個查詢進行分類是車、人、自行車等和邊界框回歸中心點偏移、尺寸、朝向。這種“一對一”的預測方式避免了后處理中復雜且耗時的非極大值抑制NMS或者只需要很輕量級的NMS進一步提升了效率。語義分割頭可行駛區(qū)域、車道線分割任務需要輸出每個BEV位置的類別標簽這似乎又回到了密集預測。這里有兩種主流策略渲染法利用稀疏BEV查詢的特征和其對應的3D位置通過一個輕量級的解碼器如幾層反卷積網(wǎng)絡“渲染”出密集的BEV分割圖。因為查詢已經(jīng)包含了關鍵信息這個渲染過程可以做得比較輕量。查詢直接預測法將BEV空間預先劃分為一個粗糙的網(wǎng)格比如40x40每個網(wǎng)格單元分配一個或多個查詢。分割頭直接預測每個查詢所負責的網(wǎng)格單元的類別。這種方法更省計算但分辨率較低。損失函數(shù)平衡術(shù)這是多任務訓練中最棘手的部分。損失通常由三部分組成L_total w_det * L_det w_seg * L_seg w_lane * L_lane。L_det檢測損失常用Focal Loss分類和L1/L2損失回歸。L_seg分割損失常用帶權(quán)重的交叉熵損失或Dice Loss以處理類別不平衡道路區(qū)域遠大于障礙物。L_lane車道線損失因其細長結(jié)構(gòu)可能使用特定損失如親和力損失Affinity Loss。手動調(diào)整權(quán)重w_*非常耗時。參考算法很可能采用了動態(tài)損失加權(quán)策略例如不確定性加權(quán)為每個任務的損失學習一個可訓練的參數(shù)對數(shù)方差讓任務難度大的自動獲得較小的權(quán)重。GradNorm在訓練過程中動態(tài)調(diào)整權(quán)重使得各任務損失的梯度幅度相近。 我個人的經(jīng)驗是在項目初期可以使用不確定性加權(quán)快速得到一個基線然后基于驗證集上各任務的表現(xiàn)進行微調(diào)。要密切關注一個任務精度快速提升時是否以另一個任務的顯著下降為代價。4. 基于地平線平臺的部署與優(yōu)化實踐4.1 模型量化與BPU適配地平線征程芯片的核心是其BPU。要讓PyTorch或TensorFlow訓練出的浮點模型在BPU上高效運行必須經(jīng)過模型量化和編譯器優(yōu)化。量化流程詳解量化是將模型權(quán)重和激活值從高精度如FP32轉(zhuǎn)換為低精度如INT8的過程能大幅減少內(nèi)存占用和加速計算。地平線提供了完整的量化工具鏈如天工開物工具鏈。流程一般如下校準準備一個代表性的數(shù)據(jù)集驗證集的一部分讓浮點模型在“校準模式”下運行。工具會統(tǒng)計每一層激活值的分布最大值、最小值、直方圖為后續(xù)確定量化參數(shù)scale, zero_point做準備。量化感知訓練QAT可選但強烈推薦在訓練的最后幾個epoch在模型中插入“量化模擬器”QAT。前向傳播時模擬INT8計算的效果反向傳播仍用FP32。這能讓模型權(quán)重主動適應量化帶來的誤差是保證量化后精度不掉點的最關鍵步驟。參考算法應該提供了對應的QAT訓練配置。模型轉(zhuǎn)換使用地平線提供的編譯器如hb_mapper將訓練好的模型可能是QAT后的轉(zhuǎn)換成BPU支持的指令序列文件.bin。避坑指南量化最容易出問題的是那些激活值分布范圍大或不穩(wěn)定的層例如注意力機制中的Softmax輸出、某些激活函數(shù)如Swish之后。在參考算法中稀疏交叉注意力模塊需要特別關注。在地平線工具鏈中通常支持分層量化可以為這些敏感層單獨設置更高的量化位數(shù)如保持FP16或使用更精細的校準方法如KL散度校準。算子支持與定制BPU有其支持的算子列表。參考算法中使用的所有操作如變形后的稀疏注意力、特定的插值操作都必須落在支持列表中或者能夠被等價分解為一系列支持的操作。如果使用了不支持的算子就需要進行算子替換或子圖重寫。地平線的工具鏈通常提供了常見算子的替代實現(xiàn)方案。4.2 內(nèi)存與耗時瓶頸分析即使算法本身是稀疏的在真實部署中仍需警惕內(nèi)存和耗時瓶頸。內(nèi)存占用分析模型權(quán)重INT8量化后模型本身大小會顯著減少。主要關注點在于模型中間激活值Activation占用的內(nèi)存。稀疏算法雖然減少了BEV特征的內(nèi)存但圖像主干網(wǎng)絡產(chǎn)生的多尺度特征圖仍然是內(nèi)存消耗的大頭。工具鏈的編譯報告會詳細列出每一層的輸出張量大小。輸入輸出緩沖區(qū)多路高清攝像頭如1280x720的輸入數(shù)據(jù)以及多個任務檢測框、分割圖的輸出數(shù)據(jù)也需要預留連續(xù)的內(nèi)存空間。優(yōu)化策略利用BPU的內(nèi)存復用機制至關重要。編譯器會嘗試讓不同層的臨時輸出共享同一塊內(nèi)存區(qū)域。在模型結(jié)構(gòu)設計時有意識地讓網(wǎng)絡的計算圖更“整潔”減少長距離的跳躍連接有助于編譯器進行更優(yōu)的內(nèi)存規(guī)劃。推理耗時剖析工具鏈生成的性能分析報告會給出每個算子的耗時。需要重點關注卷積層尤其是主干網(wǎng)絡中的大kernel深度可分離卷積通常是耗時主力。自定義/稀疏操作如果稀疏注意力是通過一系列基礎算子組合實現(xiàn)的其整體效率需要評估?？赡苄枰谒惴ㄔO計階段就采用BPU友好的稀疏計算模式。后處理檢測頭的輸出解碼、車道線的多項式擬合等CPU側(cè)的后處理也可能在整體Pipeline中占據(jù)可觀比例不能忽視。一個實用的技巧是進行端到端E2E性能評測即從接收圖像數(shù)據(jù)到輸出感知結(jié)果的總時間。這包括了數(shù)據(jù)預處理縮放、歸一化、BPU推理、結(jié)果后處理等所有環(huán)節(jié)。只有E2E延遲滿足要求如100ms算法才算真正可用。4.3 多任務輸出后處理與同步模型在BPU上跑完輸出的是原始的張量數(shù)據(jù)需要經(jīng)過后處理才能變成應用層可用的信息。檢測輸出處理基于查詢的檢測頭輸出通常是一個列表每個查詢對應一個預測結(jié)果類別得分、邊框參數(shù)。后處理包括得分過濾根據(jù)置信度閾值如0.3過濾掉低質(zhì)量預測。邊框解碼將預測的偏移量解碼為實際的3D框中心點、長寬高、朝向。輕量級NMS由于查詢設計已經(jīng)減少了冗余可能只需要一個簡單的、基于3D IoU的NMS即可。分割輸出處理如果分割圖是密集渲染的后處理主要是取argmax獲得每個像素的類別ID。如果是查詢預測的粗糙網(wǎng)格可能需要一個簡單的上采樣或插值來匹配所需的分辨率。關鍵挑戰(zhàn)——輸出同步檢測結(jié)果是物體列表分割結(jié)果是二維網(wǎng)格車道線可能是另一套參數(shù)化表示。如何保證這些輸出在時間和空間上是同步的例如檢測框的底部應該落在可行駛區(qū)域分割圖內(nèi)。這要求所有任務頭共享完全相同的BEV空間坐標系和時序輸入。在后處理模塊中有統(tǒng)一的時鐘和幀管理確保處理的是同一時刻的數(shù)據(jù)。 參考算法的框架應該已經(jīng)考慮了這一點提供了統(tǒng)一的結(jié)果封裝接口。在集成到更大的自動駕駛系統(tǒng)中時需要確保從這個接口獲取的是自洽的一幀感知結(jié)果。5. 復現(xiàn)環(huán)境搭建、調(diào)試與常見問題排查5.1 從零開始搭建復現(xiàn)環(huán)境復現(xiàn)官方參考算法是理解它的第一步。環(huán)境配置是第一個攔路虎。基礎環(huán)境配置# 1. 創(chuàng)建并激活conda環(huán)境強烈推薦 conda create -n sparse_bev python3.8 -y conda activate sparse_bev # 2. 安裝PyTorch版本需嚴格匹配地平線工具鏈要求如1.10.0cu113 pip install torch1.10.0cu113 torchvision0.11.0cu113 -f https://download.pytorch.org/whl/torch_stable.html # 3. 安裝地平線開發(fā)套件以Horizon OpenExplorer為例 # 通常需要從地平線官方渠道獲取安裝包例如 pip install openexplorer-xxx.whl # 具體包名和版本以官方文檔為準 pip install hbdk-xxx.whl # 模型編譯工具項目代碼與依賴從地平線官方Git倉庫或提供的壓縮包獲取SparseBevFusionMultitaskOE-V1.0源代碼。進入項目根目錄安裝其特定的Python依賴pip install -r requirements.txt。這里經(jīng)常會出現(xiàn)版本沖突。特別注意項目可能依賴一些定制化的CUDA算子如Deformable Attention的實現(xiàn)。需要按照項目README中的說明使用python setup.py build_ext --inplace進行編譯。編譯失敗通常是CUDA版本、PyTorch版本或編譯器如g不匹配導致的。數(shù)據(jù)集準備算法通常基于NuScenes、Waymo Open Dataset或自有的標注數(shù)據(jù)集。需要下載數(shù)據(jù)集至指定路徑。運行項目提供的預處理腳本將原始數(shù)據(jù)轉(zhuǎn)換為項目約定的格式如.pkl或.bin文件。在配置文件中修改數(shù)據(jù)集路徑。踩坑實錄最常遇到的問題是“內(nèi)存溢出”。尤其是在數(shù)據(jù)加載或模型前向傳播時。除了檢查硬件內(nèi)存是否足夠更應檢查代碼中是否存在不必要的緩存。例如數(shù)據(jù)加載器是否使用了過大的num_workers導致內(nèi)存翻倍在訓練腳本中是否在每個epoch結(jié)束后沒有及時釋放不再需要的變量可以使用torch.cuda.empty_cache()進行手動清理但這只是治標。治本之策是優(yōu)化數(shù)據(jù)流和減少單次加載的數(shù)據(jù)量。5.2 訓練過程中的典型問題與調(diào)參即使環(huán)境搭好了訓練過程也可能一波三折。損失震蕩或NaN現(xiàn)象訓練初期損失值劇烈跳動或突然變成NaN。排查學習率過高這是首要懷疑對象。多任務模型對學習率更敏感。嘗試將初始學習率降低一個數(shù)量級例如從1e-3降到1e-4。數(shù)據(jù)異常檢查數(shù)據(jù)預處理特別是歸一化Normalization的參數(shù)mean, std是否正確。是否有破損的圖像或標注梯度爆炸在反向傳播計算梯度時可以使用torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0)進行梯度裁剪。損失權(quán)重不當如果某個任務的損失值遠大于其他任務可能導致梯度主導?；仡檮討B(tài)損失加權(quán)的設置或手動調(diào)整到一個更平衡的初始值。某個任務性能始終很差現(xiàn)象檢測精度尚可但分割mIoU極低或者反過來。排查任務頭能力不足可能是分割頭或檢測頭的網(wǎng)絡容量層數(shù)、通道數(shù)不夠。嘗試輕微增加其復雜度。特征共享沖突這可能是根本原因?？梢試L試在共享主干網(wǎng)絡和任務頭之間插入任務特定適配層。例如為分割任務和檢測任務分別設計一個輕量的卷積模塊讓它們從共享特征中提取出更適合自己的特征再輸入各自的任務頭。這增加了少量參數(shù)但能有效緩解沖突。數(shù)據(jù)標注質(zhì)量仔細檢查該任務標注數(shù)據(jù)的質(zhì)量。分割的邊界是否模糊檢測框是否準確過擬合現(xiàn)象訓練集損失持續(xù)下降驗證集損失早早就停止下降甚至上升。對策數(shù)據(jù)增強加強數(shù)據(jù)增強策略如隨機裁剪、顏色抖動、Mosaic等。對于BEV任務在圖像空間做增強要謹慎需同步考慮其對相機參數(shù)和BEV空間映射的影響。更安全的增強是在BEV空間進行如隨機旋轉(zhuǎn)、平移。正則化增加Dropout層、權(quán)重衰減Weight Decay。早停監(jiān)控驗證集指標當連續(xù)多個epoch不再提升時停止訓練。5.3 模型轉(zhuǎn)換與部署驗證問題訓練出一個精度不錯的模型只是成功了一半能否成功部署到芯片上才是終極考驗。量化精度損失過大現(xiàn)象浮點模型mAP為70%量化后模型在驗證集上掉到65%以下。排查與解決校準集不具代表性確保校準集能覆蓋各種場景白天/黑夜、晴天/雨天、擁堵/暢通。校準集數(shù)據(jù)量不宜過少通常需要幾百張有代表性的圖片。敏感層處理使用工具鏈的分析功能找出量化誤差最大的層。嘗試對這些層使用定點-浮點混合精度即保持其FP16精度。QAT是關鍵務必進行充分的量化感知訓練。檢查QAT訓練時模擬量化的配置如量化位寬、對稱/非對稱是否與最終部署的配置完全一致。使用更先進的量化策略探索工具鏈是否支持動態(tài)范圍量化或通道級量化這些方法比傳統(tǒng)的層級靜態(tài)量化更精細可能帶來更好的精度保持。編譯失敗或編譯后模型錯誤現(xiàn)象hb_mapper編譯過程中報錯或編譯出的.bin模型在仿真器上運行結(jié)果異常。常見原因不支持的操作符模型中使用了一個BPU不支持的PyTorch操作。需要根據(jù)錯誤信息在代碼中找到該操作并按照地平線提供的算子替換指南進行修改。常見需要替換的包括某些特殊的插值模式、自定義的激活函數(shù)等。張量形狀動態(tài)模型中存在根據(jù)輸入數(shù)據(jù)動態(tài)決定形狀的操作如非固定數(shù)量的查詢。BPU通常需要靜態(tài)圖。需要修改代碼將動態(tài)性移除例如設置一個固定的最大查詢數(shù)量并用掩碼mask表示有效查詢。中間輸出檢查在編譯前使用工具鏈的check_model功能對比PyTorch模型和轉(zhuǎn)換后模型在相同輸入下的逐層輸出。如果某層開始出現(xiàn)巨大偏差問題就出在這一層或之前。部署后性能不達標現(xiàn)象模型在芯片上運行的幀率FPS低于預期。性能分析使用性能分析工具地平線工具鏈通常提供性能分析工具可以生成詳細的時間線顯示每個算子的耗時。找出最耗時的“熱點”算子。優(yōu)化數(shù)據(jù)搬運在預處理CPU和后處理CPU與模型推理BPU之間數(shù)據(jù)搬運DDR訪問可能成為瓶頸。確保使用零拷貝或高效的內(nèi)存接口。模型輕量化如果某些算子耗時過高考慮是否能用更高效的算子組合替代。或者在精度可接受的范圍內(nèi)是否可以進一步減少主干網(wǎng)絡的深度、寬度或者減少稀疏查詢的數(shù)量。Pipeline優(yōu)化如果是多攝像頭輸入是否可以并行處理多個攝像頭的預處理模型推理和前后處理是否可以流水線化隱藏部分延遲這需要系統(tǒng)級的架構(gòu)設計。在整個復現(xiàn)和部署的旅程中保持耐心和細致的日志記錄至關重要。每一個報錯信息都是線索每一次性能分析都是優(yōu)化機會。地平線的這個參考算法提供了一個高起點但真正讓它在你自己的產(chǎn)品中發(fā)揮威力還需要大量的工程打磨和場景適配。