在實體 AI（Physical AI／物理 AI）架構中，機器人邊緣 AI 把時間敏感的感知、推論與安全判斷放在相機、感測器和致動器附近，即使網路不穩也能維持必要反應。雲端仍適合大規模訓練、機隊分析、資料保存與模型發布；設計重點是分工，不是把所有工作都搬到單一端點。
判斷工作應放在哪裡，先看最晚可以多久得到結果、斷線時是否仍須運作、資料能否離開現場，以及機身可提供的電力與散熱。只比較峰值算力，無法回答機器人在長時間負載下是否穩定。
邊緣 AI 的價值是縮短關鍵回路
避障、抓取修正、異常偵測與安全停機通常有明確期限。若每次影像都要上傳雲端、等待推論再回傳，網路抖動就會直接進入控制回路。裝置端推論可以降低這項不確定性，也減少大量原始資料外傳。
但邊緣不等於完全離線。機器人仍可能需要下載任務、同步地圖、上傳摘要、接收更新與接受遠端診斷。架構應預先定義斷線模式、資料佇列與重新連線後的同步規則。
裝置端、場域邊緣與雲端各有適合工作
| 執行位置 | 適合工作 | 主要限制 | 失效時的設計重點 |
|---|---|---|---|
| 機器人裝置端 | 感知前處理、即時推論、安全與局部控制 | 功耗、散熱、記憶體與重量 | 斷線仍能安全運作 |
| 場域邊緣伺服器 | 多機共享模型、地圖、視覺分析與任務協調 | 區域網路與集中故障 | 保留本機降級能力 |
| 雲端 | 訓練、跨場域分析、版本管理與長期儲存 | 延遲、頻寬、隱私與費用 | 不能承擔必要的即時安全回路 |
表格應轉成每項功能的責任清單。若任務協調放在場域伺服器，機器人仍要知道失聯後是完成目前動作、退回安全點或立即停止；若影像上傳雲端，也要定義保留時間與存取權限。
延遲預算要從感測到動作逐段拆解
完整延遲包含曝光與感測、資料傳輸、前處理、模型推論、後處理、規劃及命令送達控制器。只公布模型核心推論時間，會忽略相機佇列、記憶體搬移與軟體排程。
驗收時應同時量測一般、尖峰與長時間負載，並觀察結果抖動。平均值看似充足，偶發的長尾延遲仍可能讓機器人錯過煞停或抓取修正時機。
功耗與散熱決定可持續效能
嵌入式平台在機身內會與馬達、感測器、通訊與電池共享能源，外殼與風道也限制散熱。晶片達到高峰效能後若因溫度降頻，實際週期時間就可能逐步變差。
測試應使用目標外殼、環境溫度、相機串流與完整模型管線，記錄功耗、溫度、頻率、記憶體及掉幀。桌上開放環境的短跑資料，不足以代表機器人班次中的持續表現。
軟體堆疊會影響模型能否真正部署
NVIDIA JetPack 文件呈現驅動程式、運算函式庫與裝置工具的整合角色；NVIDIA Metropolis on Jetson 文件則提供另一個邊緣應用堆疊參考。採購硬體前，應確認目標模型、算子、相機介面與容器流程是否真的受支援。
量化、剪枝、較小輸入或分層推論可以降低資源需求，但每次最佳化都可能改變準確度與失敗型態。效能提升必須用現場資料與任務結果重新驗證，不能只比較模型檔案大小。
雲端應負責學習與治理，不應掩蓋安全責任
雲端適合聚合多機紀錄、訓練候選模型、分析故障與管理發布。正式更新前仍要經過離線評估、受控實機測試、分批發布與可回復機制，避免同一錯誤同時擴散到整個機隊。
資料治理也要在架構階段確定。原始影像、位置、作業內容與人員資訊是否允許上傳，應由場域、法規與合約共同決定；能在裝置端完成的摘要或事件分類，可以降低外傳風險。
安全設計必須涵蓋模型與網路失效
模型信心不足、輸入超出訓練分布、相機失效、裝置過熱與網路中斷，都要有可預期的降級路徑。安全控制不應依賴同一個可能失效的模型，也不能假設雲端永遠可達。
工程團隊應明確區分人工智慧提供的建議、確定性控制器執行的限制，以及獨立安全系統可觸發的停止。這三層若責任不清，效能問題很容易變成現場風險。
採購與驗收要測完整管線
- 列出每項功能的期限、斷線需求與資料敏感度。
- 用目標相機、模型、外殼與溫度量測端到端延遲。
- 記錄持續功耗、降頻、記憶體與掉幀，而非只看峰值規格。
- 測試網路中斷、更新失敗、模型回復與安全停止。
- 把雲端費用、現場維護與版本治理納入總持有成本。
供應商與平台分工可參考物理 AI 企業生態系；現場流程可對照倉儲揀選導入指南；模擬與硬體前測則可搭配機器人模擬器比較。
邊緣部署常見疑問
把模型放在機器人上就一定比較快嗎？
不一定。若前處理、記憶體搬移或熱降頻成為瓶頸，裝置端仍可能超時。必須量測完整管線與長時間負載。
有了邊緣運算，還需要雲端嗎？
多數機隊仍需要雲端或場域伺服器進行訓練、分析、版本管理與長期保存；只是必要的即時與安全功能不應依賴遠端連線。
峰值算力可以直接比較不同平台嗎？
不適合直接比較。模型算子、精度、記憶體、軟體版本、功耗模式與散熱都會改變實際表現，應使用同一任務管線測試。