這幾年我陸續(xù)做過好幾個具身智能相關的實車和實機項目從輪式巡檢底盤到機械臂抓取平臺從室內配送車到半室外割草機器人幾乎市面上主流的端側算力平臺都上手摸了一遍。這個過程中踩過的坑比順利跑通的 demo 還多。每次看到群里有人問“我這個機器人該選什么算力板卡”“Jetson Orin 和 RK3588 到底差多少”我都想直接甩一篇文章過去——今天終于把它寫出來了。這篇指南不會給你堆一堆 TOPS 參數(shù)就完事而是從我實際選型、打樣、部署、調優(yōu)的完整過程出發(fā)把所有容易踩坑的環(huán)節(jié)都捋一遍。適合正在做具身智能硬件選型的工程師、準備把算法部署到車載/機載設備的算法工程師以及帶學生做機器人競賽或畢設的團隊參考。文章的核心就一句話算力芯片的選型不是選最高分而是選最匹配你整套系統(tǒng)的方案。1. 端側算力需求解析先搞清楚具身智能到底要多少算力1.1 具身智能場景下的算力特征和普通視覺盒子完全不同很多第一次接觸具身智能的朋友最容易犯的錯就是把端側算力選型當成“服務器推理卡的小型化版本”。實際上具身智能設備——不管是車載還是機載——的算力需求和純視覺分析場景有本質區(qū)別。舉一個最簡單的例子一輛普通的智能巡檢車如果只做車道線識別和障礙物檢測那本質上是一個低速視覺任務30FPS 的處理速度就夠用。但如果你要在這臺車上跑一個端到端的具身智能模型讓車根據(jù)視覺語言指令去理解環(huán)境、規(guī)劃路徑、控制底盤動作那么這不僅僅是一個感知模型的事而是“感知 規(guī)劃 控制 狀態(tài)估計”的多模型串聯(lián)推理。這種多模型流水線對算力的要求是疊加的而且是“硬實時”約束下的疊加。車上傳感器同時進來圖像、激光雷達點云、IMU 數(shù)據(jù)每個模塊都要在自己的時間窗口內完成推理任何一環(huán)延遲過高整個控制閉環(huán)就會抖動。我實測過一個室內輪式機器人感知模塊用 YOLOv8s 做檢測規(guī)劃模塊用 3D 目標跟蹤控制模塊跑 MPC 優(yōu)化——在算力不夠的板子上控制頻率從 50Hz 掉到 20Hz 以下機器人走直線都走不穩(wěn)。另外還要注意一點具身智能設備大多由電池供電算力、功耗和散熱是鐵三角關系。你不可能既要有極強的算力又要求低功耗還要小體積。在選型時這三者的平衡優(yōu)先級甚至高于單純的芯片性能指標。1.2 算法適配性才是選型的真正分水嶺算力只是入場券我見過太多項目前期選型只看芯片算力數(shù)值把板卡買回來之后才發(fā)現(xiàn)自己的算法根本跑不起來或者跑起來但實時性完全達不到要求。這里的核心邏輯是端側算力芯片的算力需要“工具鏈”才能兌現(xiàn)。同樣一張 100 TOPS 的卡A 廠家的 API 和編譯器優(yōu)化得好你的模型量化后能跑到 40FPSB 廠家的工具鏈比較拉胯可能只能跑到 15FPS。所以在選型階段必須把“我的算法能不能在這塊芯片上高效部署”作為第一優(yōu)先級來考量。這些年我試過的部署路線包括NVIDIA 系的 TensorRT 加速生態(tài)成熟、文檔豐富基本主流的檢測、分割模型都有官方優(yōu)化過的樣例遇到問題基本能在社區(qū)里搜到解決方案。地平線的工具鏈這幾年進步確實快特別是對 Transformer 類模型的支持已經(jīng)從“無法運行”變成了“可以跑但需要調優(yōu)”而且在國產(chǎn)芯片里它的工具鏈毛病算少的。瑞芯微 RKNN 工具鏈在輕量級模型上表現(xiàn)不錯但如果你要跑稍微大一點的視覺語言模型就會比較吃力量化支持也偏保守。華為昇騰的 CANN 工具鏈算力密度高但開發(fā)門檻也高需要花不少時間啃文檔。所以我的建議是先把你最終的算法模型定下來拿測試樣本去各個平臺上跑一遍“最小可行性驗證”再決定買哪塊板卡不要先買硬件再看算法。2. 主流端側算力芯片實測對比從 Jetson 到國產(chǎn)方案2.1 NVIDIA Jetson 系列生態(tài)最成熟但要注意散熱和供電先說用得最多的 NVIDIA Jetson 系列。我手頭有 Jetson Orin NX 16GB 和 Jetson AGX Orin 64GB 兩塊板子分別用在兩個不同的項目上。Jetson Orin NX 16GB 在 10W~25W 功耗檔位上可以提供相當不錯的 INT8 算力實測下來跑一個經(jīng)過 TensorRT 優(yōu)化的 YOLOv7 模型輸入分辨率 640×640在 25W 模式下可以達到 50FPS 左右完全滿足低速移動底盤的感知需求。但這里有個關鍵問題25W 模式下板卡溫度會迅速飆升如果散熱片不給力幾分鐘后就會觸發(fā)降頻性能直接掉到一個沒法用的水平。我在一個輪式巡檢車項目上吃過一次大虧。前期測試都是敞開放在桌上室溫 25°C被動散熱片加一個小風扇跑 20 分鐘溫度穩(wěn)定在 70°C 左右一切正常。等裝進車體密封艙里艙內還有電池和其他發(fā)熱模塊結果跑了不到 10 分鐘Jetson 的煎餅溫度傳感器就開始觸及降頻閾值——推理幀率從 50FPS 掉到 25FPS 以下。后來沒辦法重新設計了風道加了一個渦輪風扇直吹散熱片才把溫度壓住。AGX Orin 64GB 在算力上當然是更強的但功耗也是真的大。這個級別的板卡裝上已經(jīng)接近小半個工控機了對電池選型和供電設計都有更高的要求。不建議在電池容量有限、體積重量敏感的小型機載平臺或者輕量化人形機器人上用。2.2 國產(chǎn)方案實測地平線、瑞芯微和昇騰的真實表現(xiàn)國產(chǎn)芯片這幾年進步明顯如果項目對性價比和供應鏈安全有要求完全可以認真考慮。地平線旭日系列是我比較推薦的國產(chǎn)第一梯隊選擇。旭日 X5 在端側做視覺感知任務時的表現(xiàn)超出我的預期特別是它的 BPU 對 CNN 類模型的支持不錯配合官方工具鏈YOLO 系列模型量化后精度損失可以控制在 1% 以內部署速度也比較可觀。我在一個機械臂抓取項目里用旭日 X5 跑目標檢測 關鍵點檢測雙模型總幀率在 30FPS 左右穩(wěn)定性不錯而且功耗只有 8W 左右。地平線的問題在于對 Transformer 和重模型的支持還在完善如果你要做多模態(tài)大模型推理現(xiàn)階段需要謹慎評估。瑞芯微 RK3588是一個性價比非常高的選擇6 TOPS 的 NPU 算力雖然不算強但它有 8 核 CPU 和強大的多媒體處理能力非常適合做“感知前置 數(shù)據(jù)預處理 輕量推理”的混合負載。我在一個巡檢小車項目里用 RK3588 同時接了 4 路攝像頭做拼接和輕量檢測CPU 做導航NPU 跑檢測整體跑得很穩(wěn)整板功耗還能控制在 15W 以內。但要注意RKNN 工具鏈對部分 op 的支持還不夠全面有些模型需要改結構或者做子圖切分算法適配工作量得提前算進項目排期。昇騰 Atlas 200I DK A2算力密度很高單卡 20 TOPS 左右適合算力要求高但對體積敏感的場景。但這個平臺的開發(fā)門檻是真的不低CANN 框架的文檔和樣例偏工程化如果想要快速跑通一個自定義的分割模型需要花比 Jetson 多一半到一倍的時間。如果團隊里有人之前沒接觸過 CANN我的建議是慎重選除非有人專門負責工具鏈啃文檔。我對幾款主流板卡的實測對比數(shù)據(jù)整理如下均基于我實際測試的項目環(huán)境數(shù)值僅供參考板卡有效 INT8 算力內存帶寬實測功耗工具鏈成熟度適合場景Jetson Orin NX 16GB強102GB/s10W~25W極佳輪式底盤、室內機器人、多傳感器融合Jetson AGX Orin 64GB極強204GB/s15W~60W極佳高算力車載、復雜多模態(tài)感知地平線旭日 X5中強較窄8W上下較好視覺感知、機械臂抓取、安防巡檢RK3588中較寬LPDDR58W~15W中等數(shù)據(jù)預處理、輕量檢測、導航計算昇騰 Atlas 200I DK A2強中等10W~20W中等偏差高算力小型化、有專用開發(fā)團隊2.3 從應用場景反推選型你的機器人到底屬于哪一類根據(jù)項目類型來選芯片比拿著參數(shù)表硬比要靠譜得多。如果是做輕量化人形機器人或雙足平臺功耗和重量是第一紅線。這類設備對算力的需求其實沒有想象中那么大——因為本體運動控制占用了大量計算資源留給感知和決策的余量有限。我建議選 Jetson Orin NX 8GB 或 16GB 這一檔足夠了。如果你的人形機器人主要做遠距離遙控 端側輕感知甚至 RK3588 都夠。人形機器人的核心難點在運動控制的實時性而不是視覺大模型的運行速度。如果是做輪式巡檢機器人或室內配送車需要考慮長時間運行穩(wěn)定性和多傳感器接入能力。這一檔推薦 Jetson Orin NX 或者地平線旭日 X5前者適合復雜環(huán)境、多傳感器融合的項目后者適合成本敏感、任務鏈路清晰的項目。如果是做機械臂抓取和分揀重點要考慮視覺模型和運動規(guī)劃是跑在一個芯片上還是分開跑。我建議視覺部分用一個獨立的端側算力平臺比如地平線或 Jetson運動規(guī)劃放到工控機或者 PLC 上兩邊通過以太網(wǎng)或者共享內存通信這樣能避免運動控制被打斷。如果是做車載高算力平臺比如無人配送車、Robotaxi 之類的那基本就是 AGX Orin 或者昇騰 310 系列的領域。這種場景對算力的需求上限很高同時對功能安全、接口冗余、散熱管理都有更嚴格的要求需要按車規(guī)思路做整套系統(tǒng)設計。3. 硬件選型細節(jié)與關鍵參數(shù)實測內存、存儲、接口、電源、散熱3.1 內存和存儲板載內存夠不夠、存儲會不會過熱掉速很多人在選算力板卡的時候只盯著芯片算力忽略了內存帶寬和容量。實際上對具身智能場景來說內存帶寬常常比算力更容易成為瓶頸。我實測過同樣一個實例分割模型Jetson Orin NX 16GB 版本102GB/s 內存帶寬比 8GB 版本68GB/s 內存帶寬在相同算力下推理速度快了約 30%—40%。原因很簡單分割模型需要大量讀寫中間特征圖內存帶寬低了數(shù)據(jù)搬運就成了瓶頸算力根本吃不滿。這里也提醒一下大語言模型或視覺語言模型對內存容量的依賴非常明顯。跑一個量化后的 4B 級別語言模型模型權重大概要占 4GB 左右再算上 KV cache 和運行時的激活值8GB 基本是卡著邊跑16GB 才算寬裕。如果你計劃在設備上跑多模態(tài)模型盡量選 16GB 以上的內存版本。存儲方面我在多個項目里堅持用 NVMe SSD 而不是 eMMC原因有兩個一是具身智能設備會持續(xù)記錄傳感器數(shù)據(jù)和日志eMMC 的寫入壽命和速度都跟不上二是不少端側推理框架會把模型緩存和臨時文件寫到系統(tǒng)盤如果存儲太慢模型加載時間會明顯增加。還有一個很容易被忽視的問題SSD 和算力板卡裝在同一個密閉艙體里面高負載下 SSD 的工作溫度能到 70°C 以上而很多消費級 SSD 超過 70°C 就會觸發(fā)過熱保護直接掉速甚至暫時掉盤。處理方案是給 SSD 也留出散熱空間或者選工業(yè)級寬溫 SSD。3.2 接口選型攝像頭、激光雷達、CAN 總線一個都不能少具身智能設備的外設接口選型是硬件選型中我認為比算力芯片更需要花心思的部分。先看攝像頭接口。強烈建議優(yōu)先選帶 MIPI CSI 接口的算力板卡。USB 攝像頭雖然即插即用、開發(fā)方便但在長時間運行的機器人上問題很多USB 帶寬被多路攝像頭搶占會導致幀率抖動USB 線材在移動平臺的震動環(huán)境下容易松動而且 USB 協(xié)議的延遲波動不適合硬實時控制。我實測下來同樣 3 路攝像頭MIPI CSI 接口的幀率波動在 1ms 以內而 USB 接口的波動能達到 10ms 以上這對視覺伺服類的機械臂項目影響非常大。再看激光雷達的接口。目前主流的機械式激光雷達大多走以太網(wǎng)以 UDP 或 TCP 數(shù)據(jù)包形式輸出點云。一般算力板卡都會有一個千兆以太網(wǎng)口夠用。但要注意一點如果以太網(wǎng)口同時接了激光雷達、相機和其他調試設備一定要規(guī)劃好 VLAN 或者子網(wǎng)隔離不然廣播風暴會把主控的 CPU 占用率拉滿。CAN 總線接口是車載和不少移動機器人平臺的標準配置用來跟底盤電機控制器、IMU、編碼器通信。選板卡的時候留意一下原生帶幾路 CAN并確認操作系統(tǒng)層面的驅動支持。我之前遇到過一塊國產(chǎn)板卡的 CAN 驅動在 Linux 內核里不穩(wěn)定通信偶爾丟幀排查了很久才發(fā)現(xiàn)是驅動 bug后來換內核版本才解決。3.3 電源和散熱設計讓算力芯片穩(wěn)定輸出的最后一道保障端側算力平臺的電源設計是體現(xiàn)團隊工程水平的分水嶺。我在選型階段吃過虧之后現(xiàn)在做任何一款新板卡時都會優(yōu)先關注供電方案。Jetson 系列對電源質量比較敏感官方要求輸入電壓穩(wěn)定在 5V/9V/12V 等檔位而且動態(tài)響應要快。移動機器人平臺上電池電壓會隨著負載變化出現(xiàn)明顯波動電池滿電 12.6V大電流放電瞬間可能掉到 11V 以下。如果直接給算力板供電很容易觸發(fā)板載電源保護甚至突然重啟。我的處理方案是加一級高質量的 DC-DC 穩(wěn)壓模塊把電池電壓穩(wěn)到 12V 再進板卡并在靠近板卡供電端的位置加一個大容量的固態(tài)電容和 TVS 管吸收瞬態(tài)沖擊。散熱設計更是重中之重前面已經(jīng)有一個實戰(zhàn)案例說明了不重視散熱的后果。這里再補充一個重要參數(shù)環(huán)境溫度每升高 10°C芯片的漏電流幾乎翻倍功耗上升溫度進一步升高形成正反饋。所以評估散熱方案時一定要用“最惡劣工作環(huán)境溫度 最高負載 連續(xù)運行 30 分鐘”來考核而不是在空調房里拍腦袋。如果環(huán)境溫度會超過 45°C我建議直接上主動散熱包括風扇、熱管、均溫板這些手段同時做好風道設計別讓熱風在艙體里循環(huán)。4. 實操部署中的性能優(yōu)化把端側算力的每一分價值都榨出來4.1 從原始模型到端側推理量化、裁剪和編譯的完整鏈路拿到一塊新的算力板卡我相信很多人都是先把模型跑通能出結果就算完成。但真正合格的端側項目一定會經(jīng)歷一個“把模型調到又快又準”的系統(tǒng)性優(yōu)化過程。以我們在 Jetson 平臺上部署分割模型的流程為例。第一步是模型選擇與裁剪不是所有的 SOTA 模型都適合端側要先確定精度和速度的可接受下限把模型體積縮小。第二步是量化感知訓練QAT還是訓練后量化PTQ的選擇如果模型精度要求高QAT 幾乎不可避免。第三步是利用 TensorRT 對模型做層融合和 Kernel 自動調優(yōu)相同模型可以直接提升 30%—50% 的推理速度。在國產(chǎn)芯片上流程類似但工具鏈的用法可能有差異。地平線的工具鏈要做模型轉換、校準、量化還會生成一個性能分析報告告訴你每個算子的耗時——這個報告非常有用可以精準定位是哪一層拖慢了速度。瑞芯微的 RKNN 工具鏈同樣有類似的性能剖析能力但我在使用中感覺它的文檔示例偏少遇到不支持的算子時需要多試幾種等價替代結構。這里分享一個我自己的實操套路把性能調優(yōu)當成一個閉環(huán)迭代的過程每次改動比如換一個量化策略、改一個算子融合參數(shù)都記錄下精度和速度兩個指標形成一張對照表。這比憑感覺亂調高效得多也為項目評審留下了完整的調優(yōu)依據(jù)。4.2 多傳感器同步和多模型流水線保證實時性的關鍵工程手段具身智能設備上多傳感器的時間同步是一個看著簡單、做起來極其容易翻車的問題。我第一次做多傳感器融合時想當然地以為相機和激光雷達各自的時間戳對齊一下就行。結果發(fā)現(xiàn)相機的曝光時刻和系統(tǒng)讀取時刻之間有幾十毫秒的延遲激光雷達的掃描是逐點旋轉采集的一圈掃描需要 100ms 左右每個點的時間戳都不一樣。如果沒有做精確的時間同步融合出來的人或障礙物位置會有嚴重偏差機械臂抓取時會出現(xiàn)“看著抓到了實際上差了幾厘米”的問題。現(xiàn)在的做法是如果是 Jetson 平臺盡量用硬件時間戳 PTP 同步方案讓傳感器和控制板使用同一個時間基準。如果是自研傳感器需要在硬件層面把觸發(fā)信號和時間戳結合起來。ROS 2 的 clock 機制也值得認真研究配合傳感器驅動把時間戳校準到統(tǒng)一時鐘上。在多模型流水線方面我的經(jīng)驗是把任務拆成多個并行的模型實例而不是一個模型干所有事。比如一個具身智能服務機器人可以同時跑一個檢測模型負責動態(tài)障礙物識別一個分割模型負責可行區(qū)域判斷一個關鍵點模型負責目標物體定位。這三個模型在不同硬件單元上并行運行總吞吐量遠高于串行執(zhí)行。但這也對算力平臺的多任務調度能力提出了要求需要關注推理框架的流Stream和上下文Context能力以及 CPU 與 NPU/GPU 之間的數(shù)據(jù)拷貝開銷。4.3 功耗調優(yōu)實測25W 模式、動態(tài)調頻和核心鎖核的實際效果功耗調優(yōu)是端側部署繞不開的一環(huán)。Jetson 平臺提供了比較豐富的電源管理接口但很多人忙于把模型跑通沒時間深究這部分。實際上功耗調優(yōu)的效果立竿見影。我在一個需要 6 小時續(xù)航的室內巡檢機器人項目上做過一組對照測試配置推理幀率整機功耗溫度穩(wěn)定點默認最大性能模式52FPS23W78°C25W 模式 頻率鎖定44FPS18W65°C15W 模式 頻率鎖定30FPS12W58°C15W 模式 動態(tài)調頻37FPS波動較大14W62°C從這個結果可以看出25W 模式只損失 15% 的幀率但功耗降低了 20% 以上溫度下降了 13°C這對于長期運行的項目是非常劃算的交換。如果你的項目對實時性要求沒那么苛刻15W 動態(tài)調頻也是一個值得考慮的選擇。另外一個容易踩坑的點是核心調度問題。Jetson 和不少多核芯片都有大小核架構默認調度器未必會把推理線程放在大核上。我遇到過推理任務被調度到小核上幀率掉了一半的情況。排查方法很簡單用taskset或者系統(tǒng)調用把關鍵線程綁定到大核實測幀率立即恢復。這個細節(jié)在算力選型分析時沒人會告訴你但實際項目里卻是一個高頻問題。5. 常見問題完整排查這五類“翻車”實測現(xiàn)場看完少走半年彎路5.1 高負載下板卡掉速性能直接“腰斬”這是我接到咨詢最多的問題“明明測試的時候能跑 50FPS裝到設備上跑半小時后只有 25FPS?！毕葎e急著懷疑硬件壞了第一件事查溫度。在高負載運行幾分鐘后輸入tegrastatsJetson 平臺或cat /sys/class/thermal/thermal_zone*/temp通用 Linux查看芯片當前溫度和頻率。如果看到溫頻曲線明顯下調說明觸發(fā)了熱保護散熱方案需要加強。第二件事查后臺進程看看是不是有其他服務占用了 CPU 或 GPU 資源特別是視覺程序里的內存日志、數(shù)據(jù)上傳模塊可能在某些情況下出現(xiàn)異常搶占。第三件事確認電源有沒有跌壓在低電量下運行芯片會因為供電不足被迫降頻。這類問題的解決大方向就是三個字散熱、排查、壓測。做長期運行的壓力測試一定要在項目早期就安排上。5.2 USB 外設干擾傳感器數(shù)據(jù)頻繁丟幀我在一個項目里同時接了 3 路 USB 攝像頭、一個 USB 麥克風、還有幾個調試模塊。結果發(fā)現(xiàn)主相機在 USB 麥克風啟動的瞬間畫面會出現(xiàn)卡頓和丟幀。USB 總線是共享帶寬的一個高速設備突然猛傳大量數(shù)據(jù)就會擠占其他設備的帶寬。我最后的解決方案是把高速相機全部換成 MIPI CSI 接口剩下的低速外設留在 USB 總線上。如果接口不夠也可以用獨立的 USB 控制器擴展卡來解決總線沖突問題。5.3 服務化部署后內存越用越多最終系統(tǒng)崩潰在 Jetson 上跑模型服務的時候發(fā)現(xiàn)運行幾個小時后系統(tǒng)內存持續(xù)增長一直到被殺掉。排查下來是推理框架在每次請求時都創(chuàng)建了新的上下文和臨時緩沖區(qū)但釋放邏輯有缺陷導致大量顯存和內存碎片無法回收。這個問題的解決方案比較直接在服務代碼里手動復用推理上下文避免反復創(chuàng)建銷毀同時定期監(jiān)控內存占用設置預警閾值。另外不要拿“測試時跑一輪沒問題”來判斷內存管理是否正常一定要用壓力測試工具連續(xù)壓測數(shù)小時才能暴露這類問題。5.4 INT8 量化后精度掉得厲害檢測目標直接“漏檢”量化是端側部署繞不開的事但量化的坑也很多。我在一個行人檢測項目里用 PTQ 量化 YOLOv5s精度掉了 8 個百分點肉眼可見地漏檢。后來改用 QAT 量化感知訓練在訓練時就讓模型適應量化噪聲精度損失控制在 3 個百分點以內。另外校準數(shù)據(jù)集的選擇非常關鍵。PTQ 量化時要用覆蓋真實場景的校準數(shù)據(jù)不要只用幾張簡單的測試圖。我建議校準集至少要覆蓋目標物體的姿態(tài)、光照變化和遮擋情況不然量化出來的模型在真實環(huán)境里會“失靈”。5.5 板卡之間的“大坑”同型號不同批次性能表現(xiàn)差異很大這算是一個比較少被人提及但非常實際的問題。不同批次的板卡因為散熱硅脂、芯片體質、固件版本的差異在極限負載下的表現(xiàn)可能相差 5%—10%。所以我現(xiàn)在的習慣是批量使用同一個型號的板卡做項目時每一塊在出廠驗收時都跑一遍標準壓力測試固定負載 30 分鐘記錄溫度和幀率性能異常的板卡直接退回。這個過程雖然麻煩但能避免很多后續(xù)現(xiàn)場調試的“玄學”問題。5.6 常見問題速查表癥狀可能原因快速排查方法解決方案高負載后性能下降溫度過高觸發(fā)降頻查看芯片溫度加強散熱、降低功耗模式推理幀率不穩(wěn)定核心調度異常、后臺進程搶占查看線程綁定、進程占用鎖定大核、精簡后臺任務傳感器數(shù)據(jù)丟幀USB 總線帶寬沖突查看 USB 設備帶寬占用改用 MIPI CSI 接口、獨立 USB 控制器內存持續(xù)增長推理框架顯存管理缺陷觀察內存曲線復用推理上下文、定期重啟服務量化后精度下降量化校準集不合適、無需訓練量化對比量化前后精度改用 QAT、擴充校準數(shù)據(jù)集設備隨機重啟供電不穩(wěn)定監(jiān)測輸入電壓增加穩(wěn)壓模塊、更換高質量電源如果是從零開始做一個新項目我的個人經(jīng)驗是先把整個系統(tǒng)的供電和散熱方案定型再選算力芯片再定傳感器接口最后才排算法部署和調優(yōu)。很多團隊把順序搞反了先上算法、后補硬件結果每次都是硬件給算法“背鍋”。最后再分享一個我覺得很實用的小技巧——選型階段一定留一塊備用板卡做“破壞性測試”。專門拿它來測極限溫度、極端供電、反復上下電、長時間滿負載運行不用擔心弄壞。這個測試做一遍后面整機聯(lián)調的時候你會省下大量排查時間。我們團隊后來把所有定型項目的板卡都過了一遍這個流程現(xiàn)場出問題的概率直線下降。做具身智能硬件硬件的每一分不靠譜最終都會變成軟件工程師的加班時長。