VLA 是什麼？視覺語言動作模型、VLM 差別與硬體需求

從「把盒子放進籃子」看懂 VLA

假設桌上有一個紅色盒子，你對機器人說：「把紅色盒子放進左邊籃子。」這是一個概念例子，不是本站已完成的工廠測試。

1. 看見與理解相機畫面、語言指令，加上手臂與夾爪的狀態。
2. 產生動作VLA 提出接近、抓取、移動與放下等動作表示。
3. 限制與執行控制器執行；獨立安全機制持續限制速度、範圍與急停。

VLM 可以回答「紅色盒子在右邊」；VLA 則進一步輸出怎麼動。 但不是對任何手臂說一句話就能直接工作，還要匹配模型、相機、動作表示、控制介面與任務資料。

這個輸入／輸出的區分可對照 Hugging Face 的 SmolVLA 架構：多相機、機器狀態與自然語言指令一起產生動作片段；Google DeepMind 的 VLA 模型頁也把輸出列為動作。兩者都是模型層資料，不是整機安全或現場成功率證明。

LLM、VLM、VLA 怎麼分？

同一個機器人可能同時使用三種模型：LLM 負責長期任務規劃，VLM 理解場景，VLA 產生動作，而傳統控制器負責穩定執行。

VLA 怎麼把指令變成動作？

一個簡化流程是：

1. 相機看到桌面、物件與機械手臂位置。
2. 使用者說「把紅色盒子放進左邊籃子」。
3. 模型把語言、畫面和機器狀態放在同一個上下文。
4. VLA 產生抓取、移動或一連串動作表示。
5. 運動控制器把高階動作轉成符合機械限制的軌跡。
6. 安全層檢查速度、範圍、碰撞、人員與急停狀態。
7. 馬達執行，感測器重新回饋，模型或控制器再修正。

真正系統可能更複雜，但重點是 VLA 前後都有其他層，不是模型一輸出就直接讓馬達無限制動作。

VLA 為什麼受到關注？

傳統機器人常為特定任務寫固定流程。環境、物件或步驟改變後，可能要重新程式設計。VLA 希望利用大規模視覺、語言和動作資料，讓模型能：

• 理解自然語言指令。
• 把新任務拆成多個步驟。
• 在不同物件、位置和背景下泛化。
• 根據新的感測資訊調整動作。
• 用少量示範適應新任務。

但「可以泛化」不等於「所有場景都可靠」。不同機器結構、夾具、負載、光線與安全要求仍需要測試。

訓練 VLA 需要什麼資料？

常見資料包括：

• 相機、深度或其他感測器資料。
• 使用者指令與任務描述。
• 關節、位置、速度、力道和夾具狀態。
• 遙操作或人工示範的動作軌跡。
• 任務成功、失敗、介入與回復紀錄。
• 模擬產生的變化和失敗案例。

NVIDIA 的 sim-to-real 教學以相機、語言命令、關節回饋和馬達位置示範一條 VLA 工作流，也強調模擬與真實環境仍有差距。

VLA 模型需要什麼硬體？

先分清工作階段，再談 GPU、NPU 或記憶體。PyTorch TorchRL 與 Hugging Face LeRobot 的 VLA 文件都把相機影像、語言指令、機器狀態與動作資料放在同一條流程；這表示硬體需求不只由模型參數量決定，還受到相機數量、資料長度、控制頻率、模型格式與部署框架影響。

因此沒有一個適用所有 VLA 的固定顯存答案。小型模型可以在資源較有限的平台做裝置端推論，但相機數、動作歷史、精度與同時執行的感知模型都會占用記憶體。訓練能跑也不代表適合上機；機器上的平台還要通過 I/O、功耗、散熱、啟動回復與最差延遲檢查。

2026-09 VLA 模型與硬體追蹤：先看證據層級

VLA 的模型、框架和硬體更新很快。以下追蹤表只記錄官方文件已明確說到的狀態，或把來源與條件清楚標出的公開部署參考，並把「可以執行」「官方推薦的平台」和「實測效能」分開。它不是跨平台排名，也不是看到顯存數字就保證能上機。

原始資料可下載：JSON 追蹤表｜CSV 追蹤表。資料欄位保留版本、工作階段、硬體訊號、證據層級、限制與來源，之後可按官方版本變動更新，不把一次性的搜尋摘要當成長期事實。

怎麼重查這筆 OpenPi／Thor 參考，而不是把它變成採購結論？

這筆資料的價值在於它把 平台、JetPack 版本、功耗模式、模型設定、action horizon、backend 與固定 commit 一起留下來。Jetson AI Lab 的公開教學把 OpenPi 固定在 15a9616，並說明 Thor 專用的轉換、TensorRT engine 與相依修補；NVIDIA 的 JetPack 7.2 發布頁則列出 Jetson Linux 39.2、CUDA 13.2.1 與 TensorRT 10.16.2。這讓團隊能先拿同一條件重跑，再討論差異。

但這筆數字不能直接回答「這台機器能不能讓我的機器人上線」：pi05_libero 是教學中的固定模型／工作負載，計時也不是相機擷取、前處理、動作傳送、限制檢查、控制器交接和致動器回饋的完整路徑。OpenPi 的公開 issue 也持續出現不同平台、依賴與推論問題。因此，採用前仍要用自己的 checkpoint、感測器、I/O、熱／功耗條件和安全邊界，留下端到端 trace 與回復測試；不要把教學結果當成本站實測或安全證明。

裝置端 VLA 有什麼價值？

把 VLA 放在機器或場域端，可能帶來：

• 減少網路往返延遲。
• 在不穩定或無網路環境維持基本能力。
• 讓敏感影像與場域資料留在本地。
• 降低每次動作都依賴雲端服務的風險。

代價是模型要配合有限算力、記憶體、功耗和散熱。Google DeepMind 的 Gemini Robotics On-Device 2 正是這類方向，但截至 2026-09-14 仍只提供 trusted testers／early-access waitlist，且沒有公開通用部署硬體、模型大小、延遲或記憶體門檻。官方所稱少於 200 個示例、數小時資料可調整到新雙臂機型，是供應商在特定機型與任務下的結果；不能直接推論任意機器人都能照此成本部署。

On-Device 2 的 model card 也把限制說得更窄：分布外任務與高自由度機器人的泛化仍有限，主要評估是站立式雙臂操作，移動平台與全身控制不在目前主要範圍。這些限制比「可以本機跑」更接近選硬體前真正要知道的事；仍要另外驗證自己的相機、機器狀態格式、動作介面、最差延遲和獨立安全層。

VLA 為什麼不能取代安全控制？

生成式模型可能遇到看錯、聽錯、超時、分布外情境或不合理規劃。即使模型平均表現很好，真實設備仍要處理最差情況。

因此需要：

• 動作範圍、速度、負載和碰撞限制。
• 獨立的急停、安全區與人員偵測。
• 模型超時或感測器失效時的受控降級。
• 人工接管與回安全位置。
• 模型、控制軟體與設備版本記錄。
• 上線前的代表性、邊界與對抗測試。

Google DeepMind 也把 VLA 與低階安全機制組合，並明確說研究功能不等於保證安全等級。

先把 VLA 的端到端延遲拆成可量測預算

「模型推論 40 ms」不能直接回答機器人多久會產生新動作。端到端路徑還可能包含相機擷取與同步、解碼和前處理、網路、服務排隊、動作回傳、限制檢查與控制交接；action chunk、context 與 runtime 也會改變結果。

可以先用本站的 VLA 延遲預算計算器 把每一段毫秒數、目標決策更新頻率與抖動餘裕放在同一張表，再用相同場景的端到端 trace 驗證。工具只做規劃加總，不會把平均值變成 P95，也不會把 VLA 決策頻率誤寫成馬達控制或安全迴路頻率。

評估 VLA 不要只看 Demo

至少要問：

1. 測試涵蓋哪些物件、背景、光線與機器結構？
2. 成功率如何定義？失敗和人工介入有沒有算進去？
3. 最差延遲和控制週期是多少？
4. 遇到沒看過的情境會拒絕、停止還是繼續猜？
5. 模型輸出到馬達中間有哪些限制與安全層？
6. 需要多少示範、模擬與真實資料才能適應新任務？
7. 模型更新後如何回歸測試與快速回復？

如果結果最後只剩「成功率 80%」，但沒有模型 checkpoint、benchmark／環境版本、任務切分、seed、成功與停止定義，以及每次 rollout 的影片或 telemetry，就很難判斷差異來自模型還是測試條件。可以用本站的 VLA 評估紀錄產生器 先鎖定方法，再把 SUCCESS、FAILURE、TIMEOUT、SAFETY_STOP 與 OPERATOR_ASSIST 分開保存；工具只檢查紀錄能否被重查，不替模型宣告通過。

重試後成功，跟一次做好是同一件事嗎？

不是。先固定每回合的停止、重試與復位規則，再把「無回復完成」「自主重試／復位後完成」「人工介入」和「未完成」分開。人工扶正工件或遙操作後雖然完成任務，也不能當成模型自主成功；若缺影片或事件紀錄，先標未知。

本站的 VLA 完成路徑與回復分母說明 提供教學算例，並可在同一份 CSV／JSON 留下分類、觀察到的失敗與原始證據。三種完成比率都以全部已記錄回合為分母，包含失敗、逾時、停止與介入；它不是以每個失敗事件為分母的 recovery rate，也不是安全或上線門檻。

此段方法與工具於 2026-09-08 補充；上方模型／硬體追蹤表仍沿用各筆原查證日，不因本次內鏈與方法更新而視為全表重查。

最後記住：

VLA 讓 AI 從「看懂」往「做到」跨一步；真正能上線，還要把模型、控制、安全與維運接成完整系統。