雲端 vs 邊緣：機器人的 AI 推論該放在哪裡運算

一個看似技術細節、實則決定系統可靠度的架構問題

當機器人需要跑一個視覺語言動作模型或即時避障演算法時，這段運算該放在機器人本體的邊緣運算晶片上執行，還是傳回雲端伺服器運算完再把結果傳回來？這個看似只是「哪裡算力比較強」的問題，實際上牽涉延遲、頻寬、可靠度三個維度的權衡，而且答案幾乎總是取決於任務本身對即時性的容忍度，而非單純比較雲端與邊緣晶片的算力差距。

延遲：即時閉迴路控制的硬性限制

機器人與雲端伺服器之間的通訊，不論網路品質多好，都存在物理上無法完全消除的往返延遲——本站在 GG-CNN 論文導讀中提到的 50Hz 閉迴路抓取控制，每個控制週期只有約 20 毫秒的時間預算，如果把推論放到雲端，光是資料上傳、雲端運算、結果下載的往返時間，就可能超過這整個週期的時間預算，導致控制迴路的即時性假設完全失效。這是為什麼所有需要毫秒等級即時反應的控制迴路——關節伺服控制、即時避障、閉迴路抓取——幾乎必須把核心推論留在機器人本體端的邊緣運算晶片上執行，不能依賴雲端。

可靠度：網路不穩定不能讓機器人停擺

除了延遲，依賴雲端運算還引入了一個額外的失效模式——網路連線本身的穩定性。機器人部署環境的網路品質不一定可靠（工廠角落的 Wi-Fi 死角、戶外場域的訊號不穩定），如果機器人的核心控制邏輯依賴雲端運算才能運作，網路一旦斷線或延遲異常升高，機器人就可能瞬間失去控制能力，這種脆弱性對需要長時間穩定運作的商用機器人系統是不可接受的風險。邊緣運算把核心推論留在本體端，讓機器人的基本安全與控制能力不依賴外部網路連線，這也是本站報導過的高通 Robotics RB6與輝達 Jetson Thor兩款邊緣運算晶片，都強調本體端直接執行大型模型推論的核心賣點。

雲端仍然有它的位置：非即時、跨機器人的任務

即時控制留在邊緣不代表雲端運算在機器人系統裡毫無用武之地——雲端真正的價值在於延遲容忍度高、且需要龐大算力或跨機器人協同的任務。本站報導過 Stellantis 500 台自主移動搬運車車隊採用集中式車隊管理系統統一調度所有車輛的路徑規劃，這類需要同時考慮數百台機器人相對位置與走道壅塞狀況的排程最佳化問題，適合放在算力充沛的雲端或至少是廠區內的集中式伺服器運算，而不是要求每台機器人各自用有限的本體算力解一個牽涉整個車隊的最佳化問題。模型的持續訓練與更新——把多台機器人蒐集到的真實運行資料集中上傳雲端重新訓練，再把更新後的模型權重下發回每台機器人——也是雲端算力規模優勢能發揮價值、且不受即時性要求限制的典型應用。

分層架構：讓每一層運算落在該落的地方

現實中的機器人系統很少是純雲端或純邊緣的二選一，而是依任務即時性需求分層——關節控制與即時避障這類毫秒級任務留在邊緣運算晶片上，任務規劃與長期資料分析這類容忍秒級到分鐘級延遲的任務交給雲端或伺服器等級運算資源處理。這種分層架構，本質上跟本站在模型預測控制一文中討論的多層次控制架構思路一致——不同時間尺度的決策問題，本來就適合用不同層次、不同運算資源規模的系統來處理，強行用單一架構（全部雲端或全部邊緣）解決所有問題，反而會在某個維度上犧牲不必要的效能或可靠度。