LeRobot 硬體需求怎麼看？訓練工作站、GPU 顯存與 Jetson 上機檢查

直接答案：先把 LeRobot 拆成資料、訓練與上機三個硬體問題

LeRobot 的硬體需求沒有一個通用答案。原因是「能錄到資料」、「能把策略訓練完」和「能在目標機器人上穩定執行」分別受不同條件限制：

1. 資料採集先受相機、機器狀態、時間同步、網路和儲存影響。
2. 訓練或微調先受模型類型、批次大小、影像解析度、GPU VRAM、CPU 解碼和資料讀取吞吐影響。
3. 上機推論先受目標電腦、感測器 I/O、模型 runtime、功耗、散熱、延遲和故障處理影響。

Hugging Face 的 LeRobot Compute Hardware Guide 提供的是訓練階段 VRAM 與時間量級參考。它很適合拿來縮小工作站候選、判斷一次實驗大約是小時還是天，但不是機器人整機的效能、延遲或安全保證。本站在 2026-09-18 核對到正式 release 為 LeRobot v0.6.1；硬體指南與統一評估、rollout 工作流則是在 v0.6.0 這一代加入，版本不同時不能直接沿用同一組量測。

三層硬體責任不要混在一起

這個分法也能避免一個常見誤判：把「工作站顯卡訓練成功」寫成「機器人平台已能部署」。兩者中間仍有資料前處理、模型格式、依賴套件、感測器同步、功耗與現場維運等工作。

官方 VRAM 參考：先用策略群組估量級

以下資料轉錄自 Hugging Face LeRobot 的硬體指南。條件是 batch size 8、AdamW 的訓練峰值 VRAM 量級；原始指南也提醒，實際結果可能因資料、模型與設定偏離約 50%。這不是本站實測，也不是採購清單。

可下載原始欄位整理：JSON 訓練硬體矩陣｜CSV 訓練硬體矩陣。2026-09 版除了 VRAM，也加入官方共同情境的 wall-clock 錨點；資料保留條件、限制與來源網址，方便後續與自己的實測分開比較。

訓練多久：先算影格與步數，再套每步時間

只問「某張 GPU 要跑多久」仍缺少資料量與訓練設定。官方指南使用下列關係估算：

總影格 = 所有 episode 的影格總和
每個 epoch 步數 = ceil(總影格 / (GPU 數 × batch size))
總步數 = epoch 數 × 每個 epoch 步數
wall-clock ≈ 總步數 × 每步時間

官方共同情境是約 50 個 episode、每段 30 秒、30 FPS，合計約 45,000 影格，訓練 5 個 epoch、AdamW、640×480 影像。以下是量級錨點，不是本站 benchmark，也不是交期承諾：

官方明確提醒真實執行可能因影像解析度、資料 I/O、dataloader threads 與實際 GPU SKU 偏離約 ±50%。所以比較設備時，先固定 dataset revision、模型 commit、batch、precision 與步數，再用自己機器的 step_s 推回完整 wall-clock；不要把上表當成保證完成時間。

先辨認 GPU 問題還是資料管線問題

LeRobot 官方指南建議同時觀察 dataloading_s、preprocessing_s、update_s 與涵蓋三者的 step_s。若資料載入加前處理已接近或超過更新時間，先檢查資料讀取、解碼、workers、影像解析度與儲存；在這種情況下，只換更快 GPU 不一定能縮短整體訓練時間。

最有用的最小紀錄是：資料集版本、總影格與 episode 數、相機與解析度、模型和 commit、epoch、batch size、精度、GPU 數、峰值 VRAM、dataloading_s、preprocessing_s、update_s、step_s、訓練步數和驗證方式。沒有這些條件的「跑得動」很難重現。

工作站和 Jetson 的工作不同

AI 工作站適合處理資料、訓練、評估、模擬與重跑；目標邊緣電腦則要處理上機後的感測器輸入、模型推論、I/O、功耗與熱限制。兩者可以共用工具鏈，但不能互相取代。

NVIDIA 的 Jetson FAQ 明確把開發套件放在開發與測試的位置，而量產部署要以 Jetson 模組和目標載板為主。因此，上機前至少應完成：

1. 在目標軟體映像與模型 runtime 上重現代表性輸入。
2. 量測感測器進入、模型輸出與控制介面之間的平均、P95、P99 和最差延遲。
3. 在預期功耗、環境溫度和持續負載下看記憶體、熱與降頻。
4. 重跑斷線、感測器錯誤、模型逾時、重啟和版本回復情境。
5. 把急停、硬限制與人工接管保留在獨立且可驗證的機制中。

這些測試是在判斷能否做下一階段 PoC，不是在宣告模型或裝置已具備量產、安全或商業可用性。

如果已有逐段量測，可用 VLA 延遲預算計算器 把感測、前處理、網路、排隊、推論與控制交接放進同一個決策週期。請分開計算平均、P95、P99 與最差值；逐段相加仍不能取代真正的端到端 trace。

LeRobot 非同步推論與 RTC：上機前別抄錯參數

非同步不等於 RTC，硬體夠快也不代表介面相容。 可以把前者想成廚房做下一道菜時，服務生繼續送上一道；RTC 則另外處理兩道動作片段如何接得順。增加 GPU 算力不會自動修好錯誤參數、模型介面或過期觀察。

以下只核對 LeRobot v0.6.1、commit 7e241bd630a3 的文件與程式。它是軟體路徑整理，不是本站真機測試或 GPU／Jetson 相容性保證。前面的訓練 VRAM／時數表仍保留 2026-09-18 查證範圍，沒有因本段更新而全部重查。

比例、步數與頻率，是三種不同的單位

固定版本的 client 原始碼 以「剩餘動作數 ÷ 收到的片段長度」比較 chunk_size_threshold。例如實際片段長度是 50、門檻是 0.5，就在剩餘不多於 25 步時符合送出新觀察的條件。這只是參數換算，不是實測；實際送出時間還受 client、server 與通訊狀態影響。

rollout RTC 原始碼 則直接比較佇列步數與 inference.queue_threshold。execution_horizon 控制重疊一致性的步數，不是固定「每幾步重新推論」，也不是馬達或安全迴路的 Hz。不要把 0.5 的比例值直接當成 RTC 的步數門檻。

ACT 能做 Async，不代表能直接開 RTC

v0.6.1 的 Async 文件以 ACT 等 policy 作設定範例；rollout RTC 則另要求 supports_rtc() 宣告和接受 inference_delay、prev_chunk_left_over 的呼叫介面。本站定點核對 Pi0、Pi0.5 與 SmolVLA 有 RTC 宣告，ACT 未覆寫基底的否定宣告。這是程式介面判讀，不是完整模型／checkpoint 支援清單。

GitHub #3997 曾回報 ACT 的 RTC 呼叫錯誤，但該 issue 已關閉；不能把舊錯誤照貼成「最新版仍壞掉」。選自己的 checkpoint 時，先固定版本與 processor，核對支援檢查，再做離線回放、台架與閉環試驗，不要為了繞過檢查而直接接真機。

開發文件也不是發行版本。 2026-09-29 的 main 定點文件 已描述 guided／trained 兩種 RTC 路徑；trained 要求特別訓練的 Pi05 checkpoint。這些新增欄位不在本表的 v0.6.1 基準內，不能拿 main 的指令當作已安裝 release 一定可用的功能。

上機驗收要補的四份證據

1. 版本與介面：記錄 release／commit、checkpoint revision、processor、相機與動作欄位；分開寫 Async client／server 或 rollout backend。
2. 時間與佇列：保存觀察擷取、送出、片段可執行、消費與耗盡事件；比例換成步數前，先量實際收到的片段長度。用 非同步佇列估算區 做規劃後，仍要回看真實 trace。
3. 動作接續：測舊觀察、片段交接與人工介入後恢復；觀察過期或動作跳回要另記失敗，不能只看平均推論時間。
4. 獨立停止：測斷線、超時、佇列空和重啟的停止／接管。獨立安全控制器、急停與硬限制不由 RTC 取代。

可下載 JSON 執行路徑矩陣｜CSV 執行路徑矩陣。資料版本 2026-09-30、schema 1.0、三條路徑；真機延遲與成功率保留 null／CSV 留白，不是 0、不支援或已通過。把這份軟體矩陣與訓練硬體矩陣分開使用，再依 VLA 評估紀錄 保存回合與介入證據。

最小選型路徑

如果現在還沒有任何硬體量測，可以先按下面順序收斂：

1. 選一個真實任務與一組代表性相機、動作和失敗情境。
2. 依策略群組和 batch size 估訓練 VRAM，先做小規模可重現訓練。
3. 量 dataloading_s 和 update_s，確認瓶頸在資料還是 GPU。
4. 用總影格、epoch、GPU 數、batch 與 step_s 估完整訓練時間，記錄誤差而不是承諾固定時數。
5. 把訓練結果轉成目標 runtime，在 Jetson 或其他上機平台做單機測試。
6. 再把功耗、散熱、I/O、故障處理與安全驗證放入台架和封閉場域。

LeRobot 硬體的正確問題不是「哪張 GPU 最強」，而是「我的資料、策略、目標裝置與失效邊界，各自需要被量到什麼程度」。把這四件事分開，工作站與機器人平台的選擇才有依據。