本文重點
- 先定感測器、控制週期與失敗模式，再選 GPU、NPU 或邊緣平台。
- 平均延遲不夠，物理 AI 還要看最差延遲、抖動與錯過 deadline 的處理方式。
- 相機數量、解析度、LiDAR、雷達與力覺會共同決定 I/O、頻寬、記憶體與儲存需求。
- 工作站的高算力不代表適合上機；功耗、尺寸、耐震、溫度、電源與長期供應同樣重要。
- 高階 AI 推理與安全控制應分層，不能把生成式模型當成唯一保護機制。
直接答案：物理 AI 硬體是一整條即時資料與控制鏈
物理 AI 選硬體不能先問「哪顆晶片 TOPS 最高」，而要先問：機器看什麼、多久要反應、動作錯了會怎樣、斷網時要不要繼續，以及設備要在哪種環境長期運作。
一個完整系統通常包含：
- 相機、深度、LiDAR、雷達、IMU、編碼器或力覺等感測器。
- 時間同步、前處理、影像或訊號輸入。
- CPU、GPU、NPU 或其他加速器執行感知與模型推理。
- 動作規劃和即時控制器。
- 馬達、驅動器、機械手臂、輪組或其他致動器。
- 安全控制、急停、人工接管、日誌與遙測。
- 網路、電源、散熱、機構與環境保護。
只買一台很強的 GPU 電腦，不能自動補齊其他六層。
八類規格要一起看
| 規格面向 | 要回答的問題 | 只看 TOPS 會漏掉什麼 |
|---|---|---|
| 感測器與同步 | 多少相機？是否有深度、LiDAR、雷達、IMU、力覺？資料時間能否對齊？ | 模型可能在處理不同時間點的世界。 |
| I/O 與頻寬 | 影像、點雲與控制資料能否準時進出？ | 算力很高，資料卻卡在輸入、網路或匯流排。 |
| AI 算力 | 模型精度、吞吐與並行需求是什麼？ | 不同精度與軟體條件的數字無法直接相比。 |
| 記憶體 | 模型、影像、點雲、地圖、快取與多程序能否同時放下？ | 模型放不下或資料搬移造成延遲。 |
| 延遲與抖動 | 平均與最差反應時間是多少？錯過 deadline 怎麼辦？ | 偶發延遲可能比平均速度更危險。 |
| 功耗與散熱 | 移動平台的電池、機構與長時間熱設計能否承受？ | 實際上機後降頻、續航縮短或過熱停機。 |
| 環境與生命週期 | 溫度、粉塵、震動、濕度、維修與供應年限是否符合場域？ | 開發板能跑，不代表量產設備能穩定維護。 |
| 安全與資安 | 急停、隔離、權限、簽章、更新、回復與日誌怎麼做？ | 模型正常時很聰明，失敗時卻沒有受控出口。 |
感測器會先決定資料量
物理 AI 的輸入不是只有文字。多台高解析度相機、深度資料、LiDAR 點雲、雷達、IMU 與力覺可能同時進來，還要做時間同步和校正。
因此選型前要先列出：
- 每種感測器的數量、解析度、幀率與資料格式。
- 是否要保存原始資料，還是只保留特徵與事件。
- 資料是否要跨網路傳送，斷網時如何處理。
- 校正資料、時間戳與設備狀態如何記錄。
- 感測器失效或被遮擋時，系統如何降級。
這些答案會直接影響相機介面、網路、儲存、記憶體與散熱，而不是最後才補。
GPU、NPU、CPU 與控制器怎麼分工？
沒有一種晶片會包辦全部：
- GPU：適合影像、點雲、VLM / VLA、生成式推理與多模型並行。
- NPU / AI accelerator：適合在功耗受限情況下做高效率推理。
- CPU：處理系統協調、資料流程、控制邏輯與不適合加速器的工作。
- 即時控制器：負責有明確週期與 deadline 的控制工作。
- 安全控制器：獨立監控限制、急停和安全狀態，不把高階模型當成唯一判斷。
實際產品可能把幾種能力整合在同一 SoC，也可能分成不同控制板。重點不是盒子數量，而是責任、資源與故障邊界是否清楚。
平均延遲快，不代表即時性合格
ROS 2 的即時系統設計文件把 real-time 問題拆成延遲、可預測性與錯過 deadline 後的失敗模式。這很重要，因為物理系統最怕的是平常都快，偶爾卻突然慢很多。
評估時應記錄：
- 感測器到模型輸入的延遲。
- 模型推理的平均、P95、P99 與最差時間。
- 規劃到控制命令的延遲。
- 控制週期與 jitter。
- CPU、GPU、記憶體和網路壅塞時是否互相干擾。
- 錯過 deadline 時，是丟棄結果、降低速度、停止，還是切換備援策略。
這些數據比單一 benchmark 峰值更接近可部署能力。
為什麼工作站高算力仍不一定適合上機？
工作站適合模擬、訓練、微調和離線評估，但機器上的運算平台還會碰到：
- 尺寸、重量與安裝位置。
- 電池、電源瞬變與啟動時間。
- 溫度、粉塵、震動與長時間運轉。
- 相機、CAN、Ethernet、USB、PCIe 和其他介面。
- 遠端更新、版本回復與現場維修。
- 供應週期與替換件。
所以開發階段在桌上跑得動，只是第一關。真正上機前，要把模型、驅動、控制和設備環境一起測。
選型順序
比較穩的順序是：
- 定義任務、動作與禁止動作。
- 定義反應時間與失敗模式。
- 列出感測器、資料量與同步需求。
- 選模型與軟體框架，量測真實推理需求。
- 分配高階推理、即時控制與安全控制責任。
- 計算記憶體、I/O、功耗、散熱與網路。
- 用代表性場域做壓力、斷網、遮擋與故障測試。
- 最後才選量產平台、備品與維護方式。
最後記住：
物理 AI 的好硬體，不是跑分最高，而是在真實環境、最差條件與故障狀態下仍能被理解和控制。
常見問題
物理 AI 要看 TOPS 還是 TFLOPS？
兩者都只是特定精度與硬體條件下的算力線索。實際還要看模型、記憶體、感測器吞吐、軟體框架、延遲、功耗與長時間穩定性，不能直接跨平台做單一排名。
NPU 可以取代 GPU 跑機器人 AI 嗎？
要看工作負載。NPU 適合高效率推論，GPU 適合較彈性與高吞吐的視覺、生成式與多模型工作；不少系統會搭配 CPU、GPU、NPU與專用控制器，而不是只選一種。
為什麼物理 AI 特別在意抖動？
因為控制與感測不只要平均很快，還要在可預期時間內完成。如果偶爾突然慢很多，可能錯過控制 deadline。ROS 2 的即時系統文件也把延遲、可預測性與錯過期限後的失敗模式分開處理。
一般桌機能當機器人運算平台嗎？
可以做開發或原型，但上機時還要確認尺寸、功耗、電源、相機與 CAN 等 I/O、耐震、溫度、啟動與故障回復。一般桌機不一定適合長期放在移動機器或工業環境。
感測器越多越好嗎？
不是。感測器越多，校正、同步、頻寬、功耗、散熱、資料品質與故障處理越複雜。應從任務和安全需求反推，而不是把所有感測器都裝上去。