本文重點
- 先分資料採集、訓練與上機推論；三個階段的瓶頸不一樣。
- 官方 VRAM 數字是特定訓練條件下的量級參考，不是所有資料集與模型版本的保證。
- 相機解碼、資料讀取與儲存不足時，先查資料管線，不要直接把問題歸咎 GPU。
- 工作站適合訓練、評估與重跑；Jetson 適合目標裝置驗證，但不等於所有模型都能直接部署。
- Jetson 開發套件適合開發與測試；量產要改以模組、載板、I/O、供電、散熱與軟體版本做整機驗證。
- 模型能輸出動作不代表可安全控制機器；急停、限制、故障處理與人工接管必須獨立驗證。
直接答案：先把 LeRobot 拆成資料、訓練與上機三個硬體問題
LeRobot 的硬體需求沒有一個通用答案。原因是「能錄到資料」、「能把策略訓練完」和「能在目標機器人上穩定執行」分別受不同條件限制：
- 資料採集先受相機、機器狀態、時間同步、網路和儲存影響。
- 訓練或微調先受模型類型、批次大小、影像解析度、GPU VRAM、CPU 解碼和資料讀取吞吐影響。
- 上機推論先受目標電腦、感測器 I/O、模型 runtime、功耗、散熱、延遲和故障處理影響。
Hugging Face 的 LeRobot Compute Hardware Guide 提供的是訓練階段 VRAM 量級參考。它很適合拿來縮小工作站候選，但不是機器人整機的效能、延遲或安全保證。
三層硬體責任不要混在一起
| 階段 | 主要硬體 | 先量什麼 | 不能直接推論 |
|---|---|---|---|
| 資料採集 | 相機、機械手臂或移動平台、感測器、時間同步、儲存 | 資料是否缺幀、時間戳是否對齊、是否能重播、儲存是否跟得上 | GPU 很大就代表資料品質足夠 |
| 訓練／微調 | GPU、CPU、RAM、NVMe 或網路儲存 | 峰值 VRAM、資料讀取時間、每次更新時間、OOM 與可重現設定 | 模型可在工作站訓練就能直接裝到機器人 |
| 目標裝置驗證 | Jetson 或其他邊緣電腦、目標載板、感測與控制 I/O、供電散熱 | 代表性輸入的延遲、記憶體、溫度、I/O 穩定性和失效降級 | 開發套件跑過 Demo 就可量產或安全上機 |
這個分法也能避免一個常見誤判：把「工作站顯卡訓練成功」寫成「機器人平台已能部署」。兩者中間仍有資料前處理、模型格式、依賴套件、感測器同步、功耗與現場維運等工作。
官方 VRAM 參考：先用策略群組估量級
以下資料轉錄自 Hugging Face LeRobot 的硬體指南。條件是 batch size 8、AdamW 的訓練峰值 VRAM 量級；原始指南也提醒，實際結果可能因資料、模型與設定偏離約 50%。這不是本站實測，也不是採購清單。
| 策略群組 | 官方列舉範例 | 峰值 VRAM 量級 | 官方起步 GPU 參考 | 正確判讀 |
|---|---|---|---|---|
| 輕量行為克隆 | ACT、VQBeT、TD-MPC | 約 2–6 GB | RTX 3060、L4、A10G 級 | 可作為小型策略的起點，不包含所有相機和資料管線情況。 |
| Diffusion policy | Diffusion 類策略 | 約 8–14 GB | RTX 4070 以上、L4、A10G 級 | 影像解析度、序列和批次會很快改變顯存需求。 |
| 小型 VLA | SmolVLA | 約 10–16 GB | RTX 4080 以上、L4、A10G 級 | 是官方目前的量級參考，不能拿來涵蓋所有 VLA。 |
| 較大 VLA | pi0、pi0_fast、pi05、xVLA、Wall-X | 約 24–40 GB | A100 40 GB 以上 | 24 GB 在 batch 1 也可能很緊；要用實際設定驗證。 |
| 多模態策略 | GR00T、EO-1 | 約 24–40 GB | A100 40 GB 以上 | 模型、影像、資料和訓練方式不同，不能套用單一數字。 |
| 強化學習 | RL 類工作負載 | 依環境和設定而定 | 依環境和設定而定 | 主要瓶頸可能是模擬器、平行環境或 CPU，而不是單一模型。 |
可下載原始欄位整理：JSON 訓練硬體矩陣｜CSV 訓練硬體矩陣。資料保留條件、限制與來源網址，方便後續與自己的實測分開比較。
先辨認 GPU 問題還是資料管線問題
LeRobot 官方指南建議同時觀察資料載入時間和更新時間。若 dataloading_s 已接近或超過 update_s，先檢查資料讀取、解碼、workers、影像解析度與儲存；在這種情況下，只換更快 GPU 不一定能縮短整體訓練時間。
| 觀察到的現象 | 先查哪裡 | 不要先下的結論 |
|---|---|---|
| 一開始就 OOM | 批次、影像解析度、精度、可訓練模組、優化器狀態與模型群組 | 所有模型都需要同樣 VRAM |
| GPU 常在等資料 | 資料格式、解碼、workers、NVMe 或網路儲存、相機串流轉檔 | GPU 算力不足 |
| 訓練可跑但很慢 | 每步更新時間、資料載入時間、CPU、儲存、背景程序與溫度 | 只要改大模型就會改善結果 |
| 工作站推論正常但上機失敗 | 目標 runtime、模型格式、感測器前處理、記憶體、電源、熱與 I/O | 目標裝置只差一個效能數字 |
最有用的最小紀錄是：資料集版本、相機與解析度、模型和 commit、batch size、精度、GPU、峰值 VRAM、dataloading_s、update_s、訓練步數和驗證方式。沒有這些條件的「跑得動」很難重現。
工作站和 Jetson 的工作不同
AI 工作站適合處理資料、訓練、評估、模擬與重跑；目標邊緣電腦則要處理上機後的感測器輸入、模型推論、I/O、功耗與熱限制。兩者可以共用工具鏈，但不能互相取代。
NVIDIA 的 Jetson FAQ 明確把開發套件放在開發與測試的位置，而量產部署要以 Jetson 模組和目標載板為主。因此，上機前至少應完成：
- 在目標軟體映像與模型 runtime 上重現代表性輸入。
- 量測感測器進入、模型輸出與控制介面之間的平均、P95、P99 和最差延遲。
- 在預期功耗、環境溫度和持續負載下看記憶體、熱與降頻。
- 重跑斷線、感測器錯誤、模型逾時、重啟和版本回復情境。
- 把急停、硬限制與人工接管保留在獨立且可驗證的機制中。
這些測試是在判斷能否做下一階段 PoC，不是在宣告模型或裝置已具備量產、安全或商業可用性。
最小選型路徑
如果現在還沒有任何硬體量測，可以先按下面順序收斂：
- 選一個真實任務與一組代表性相機、動作和失敗情境。
- 依策略群組和 batch size 估訓練 VRAM，先做小規模可重現訓練。
- 量
dataloading_s和update_s，確認瓶頸在資料還是 GPU。 - 把訓練結果轉成目標 runtime，在 Jetson 或其他上機平台做單機測試。
- 再把功耗、散熱、I/O、故障處理與安全驗證放入台架和封閉場域。
LeRobot 硬體的正確問題不是「哪張 GPU 最強」，而是「我的資料、策略、目標裝置與失效邊界，各自需要被量到什麼程度」。把這四件事分開，工作站與機器人平台的選擇才有依據。
常見問題
LeRobot 一定要用 Jetson 嗎？
不一定。LeRobot 的資料採集與訓練可在工作站或雲端環境進行；是否用 Jetson 要看目標機器人的模型、感測器 I/O、延遲、功耗與軟體支援。應先在目標平台驗證，不要把工作站能訓練當成已可上機。
24 GB 顯存就能訓練所有 LeRobot VLA 嗎？
不能這樣判斷。官方指南把小型 VLA 與較大的 VLA 分在不同的 VRAM 量級，且明確指出批次大小、影像解析度、優化器、精度、資料集與軟體版本都會改變結果。24 GB 是某些工作負載的起點，不是通用保證。
LeRobot 訓練一定要 AI 工作站嗎？
不一定。輕量策略可能可在較小 GPU 上開始；多相機、高解析資料、大型 VLA 或多人共用資料集才較容易需要更完整的工作站、儲存與網路。應先用代表性資料和設定量測，再決定是否擴大硬體。
Jetson 開發套件可以直接用於量產機器人嗎？
不應直接這樣推論。NVIDIA 將 Jetson 開發套件定位為開發與測試工具；量產前要以目標模組和載板，重新驗證軟體映像、感測器與控制 I/O、供電、散熱、環境與維護流程。
訓練完成代表機器人已安全可用嗎？
不代表。訓練完成只說明模型在指定資料與設定下已產生權重。上機前還要在代表性輸入、台架和封閉場域檢查延遲、失效模式、降級、急停與人工接管；AI 模型不能當成唯一安全控制器。