本文重點
- 先定感測器、控制週期與失敗模式，再選 GPU、NPU 或邊緣平台。
- 平均延遲不夠，物理 AI 還要看最差延遲、抖動與錯過 deadline 的處理方式。
- 相機數量、解析度、LiDAR、雷達與力覺會共同決定 I/O、頻寬、記憶體與儲存需求。
- 工作站的高算力不代表適合上機；功耗、尺寸、耐震、溫度、電源與長期供應同樣重要。
- 高階 AI 推理與安全控制應分層，不能把生成式模型當成唯一保護機制。
- 選型表的目的是把任務、硬體責任與驗收條件放在一起，不是做單一產品性能排名。
直接答案：物理 AI 硬體是一整條即時資料與控制鏈
物理 AI 選硬體不能先問「哪顆晶片 TOPS 最高」，而要先問：機器看什麼、多久要反應、動作錯了會怎樣、斷網時要不要繼續，以及設備要在哪種環境長期運作。
一個完整系統通常包含：
- 相機、深度、LiDAR、雷達、IMU、編碼器或力覺等感測器。
- 時間同步、前處理、影像或訊號輸入。
- CPU、GPU、NPU 或其他加速器執行感知與模型推理。
- 動作規劃和即時控制器。
- 馬達、驅動器、機械手臂、輪組或其他致動器。
- 安全控制、急停、人工接管、日誌與遙測。
- 網路、電源、散熱、機構與環境保護。
只買一台很強的 GPU 電腦，不能自動補齊其他六層。
要把這七類需求對回台灣現有的感知、Edge AI、控制、傳動、整機與驗證能力，可搭配台灣物理 AI 零組件地圖查代表性公開方案與來源。該地圖是能力對照，不是產品效能或採購排名。
八類規格要一起看
| 規格面向 | 要回答的問題 | 只看 TOPS 會漏掉什麼 |
|---|---|---|
| 感測器與同步 | 多少相機？是否有深度、LiDAR、雷達、IMU、力覺？資料時間能否對齊？ | 模型可能在處理不同時間點的世界。 |
| I/O 與頻寬 | 影像、點雲與控制資料能否準時進出？ | 算力很高，資料卻卡在輸入、網路或匯流排。 |
| AI 算力 | 模型精度、吞吐與並行需求是什麼？ | 不同精度與軟體條件的數字無法直接相比。 |
| 記憶體 | 模型、影像、點雲、地圖、快取與多程序能否同時放下？ | 模型放不下或資料搬移造成延遲。 |
| 延遲與抖動 | 平均與最差反應時間是多少？錯過 deadline 怎麼辦？ | 偶發延遲可能比平均速度更危險。 |
| 功耗與散熱 | 移動平台的電池、機構與長時間熱設計能否承受？ | 實際上機後降頻、續航縮短或過熱停機。 |
| 環境與生命週期 | 溫度、粉塵、震動、濕度、維修與供應年限是否符合場域？ | 開發板能跑，不代表量產設備能穩定維護。 |
| 安全與資安 | 急停、隔離、權限、簽章、更新、回復與日誌怎麼做？ | 模型正常時很聰明，失敗時卻沒有受控出口。 |
感測器會先決定資料量
物理 AI 的輸入不是只有文字。多台高解析度相機、深度資料、LiDAR 點雲、雷達、IMU 與力覺可能同時進來，還要做時間同步和校正。
因此選型前要先列出：
- 每種感測器的數量、解析度、幀率與資料格式。
- 是否要保存原始資料，還是只保留特徵與事件。
- 資料是否要跨網路傳送，斷網時如何處理。
- 校正資料、時間戳與設備狀態如何記錄。
- 感測器失效或被遮擋時，系統如何降級。
這些答案會直接影響相機介面、網路、儲存、記憶體與散熱，而不是最後才補。
如果要先把相機 raw、編碼後 topic、LiDAR／點雲、持續寫入與保存容量換成同一組單位，可用機器人感測器資料量計算器做第一版預算；結果仍要回到目標介面、ROS 2 graph 與儲存裝置做長時間掉幀驗證。
2026-09-11 工具導引補充：不確定要先估頻寬、查多相機同步，還是記錄 VLA 延遲？依問題選工具，先核對輸入與輸出。這個入口能避免把容量估算當成掉幀診斷，或把任務完成率當成安全證據；它不推薦未驗證的硬體組合，也不代表本頁既有產品來源全部重新查證。
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硬體大未來的原創選型表 v1.0（2026-08-19）。它不把不同品牌、TOPS 或實驗室結果硬排成單一名次；它先把「任務要誰負責、資料怎麼流、失敗時怎麼停」放進同一張表，再決定需要哪一層硬體。
| 最接近的任務 | 先定義的硬體責任 | 優先盤點的硬體層 | PoC 前要量的事 | 不能從這一列直接推論 |
|---|---|---|---|---|
| 機械手臂抓取、分揀或精密操作 | 物件範圍、速度、力量、可用空間與人員邊界 | 相機 / 深度 / 力覺、推理平台、即時控制器、獨立安全層與致動器介面 | 感測同步、p95 / 最差延遲、重試、停止與回安全位置 | VLA 或 GPU 可以取代低階控制、急停或安全認證 |
| AMR、移動平台或巡檢設備 | 地圖、速度、場域變化、人員偵測、斷網後的行為 | 定位與感測器同步、場域邊緣運算、網路備援、電池與散熱 | 端到端延遲與抖動、掉幀、定位失效、續航與降級策略 | 桌面工作站跑得動，就能直接裝到移動載具 |
| 遙操作與資料採集 | 示範覆蓋範圍、成功 / 失敗標記、保存期限與版本責任 | 相機、深度、力覺、時間戳、同步、儲存、網路與操控介面 | 資料遺失率、校正、時間對齊、事件可追溯性與標註成本 | 收集到影片，就已經能訓練或驗收機器人行為 |
| VLA、視覺模型或策略開發 | 模型版本、輸入格式、context、資料批次、訓練與推論邊界 | 工作站 GPU / VRAM、系統 RAM、儲存、網路與可重跑的開發環境 | 模型記憶體、資料吞吐、迭代時間、版本對應與代表性測試集 | 訓練主機的容量或模型參考，就等於上機即時需求 |
| 模擬、合成資料與數位孿生 | 哪些物理、感測或場域差異會改變決策結果 | 模擬工作站、GPU / VRAM、資料儲存、場景資產與真實資料回放 | 模擬重現性、reality gap、真實資料覆蓋與版本回歸 | 模擬通過或畫面逼真，就代表真機可安全上線 |
| 企業封閉 PoC 到小規模營運 | 任務基線、驗收門檻、owner、人工接管、回復與維護責任 | 場域推理平台、控制 / 安全分層、遙測、儲存、網路、備援與維修介面 | 任務成功率、最差延遲、人工介入率、故障回復、設備狀態與成本 | Demo 成功一次，就可以擴大採購或省略安全與維運設計 |
使用方式：先選最接近的一列，寫下本列的驗收條件，再由「優先盤點的硬體層」建立需求清單。最後才回到特定平台、模組或工作站的官方規格與實測。這份矩陣可引用，但引用時應保留版本與限制，不能把它當成產品採購、效能保證或安全認證。
資料版：下載 CSV ｜ 閱讀 JSON 與方法
2026-09-07 補充：若已選定用工業 3D 相機做定位取放，可接著看台灣零組件地圖的 AE400 整合證據矩陣，核對工件影像、PoE／多機頻寬與 Jetson／ROS 2 版本組合。產品頁列出支援不等於你的軟硬體組合已驗證；新矩陣保留官方文件版本與待測條件。本次只補這段延伸入口，不代表本文所有既有來源都在今日重查。
2026-09-12 補充：如果任務是外觀瑕疵檢測，可先看台灣散熱片公開案例與八層硬體選型表，從缺陷可見度、光源／相機、資料量到 Edge 與人工複判逐步評估。內含假設計算與留白驗收範本，不是本站實測，也不替整篇舊資料重設查證日。
最後記住：
物理 AI 的好硬體，不是跑分最高，而是在真實環境、最差條件與故障狀態下仍能被理解和控制。
常見問題
物理 AI 要看 TOPS 還是 TFLOPS？
兩者都只是特定精度與硬體條件下的算力線索。實際還要看模型、記憶體、感測器吞吐、軟體框架、延遲、功耗與長時間穩定性，不能直接跨平台做單一排名。
NPU 可以取代 GPU 跑機器人 AI 嗎？
要看工作負載。NPU 適合高效率推論，GPU 適合較彈性與高吞吐的視覺、生成式與多模型工作；不少系統會搭配 CPU、GPU、NPU與專用控制器，而不是只選一種。
為什麼物理 AI 特別在意抖動？
因為控制與感測不只要平均很快，還要在可預期時間內完成。如果偶爾突然慢很多，可能錯過控制 deadline。ROS 2 的即時系統文件也把延遲、可預測性與錯過期限後的失敗模式分開處理。
一般桌機能當機器人運算平台嗎？
可以做開發或原型，但上機時還要確認尺寸、功耗、電源、相機與 CAN 等 I/O、耐震、溫度、啟動與故障回復。一般桌機不一定適合長期放在移動機器或工業環境。
感測器越多越好嗎？
不是。感測器越多，校正、同步、頻寬、功耗、散熱、資料品質與故障處理越複雜。應從任務和安全需求反推，而不是把所有感測器都裝上去。