Physical AI 工程工具

車載/機器人端側 VLA 算力·延遲·儲存預算計算機

面向越野/城區自動駕駛與具身移動機器人的車端 VLA 預算估算工具：即時計算推論算力、預填充與動作解碼延遲、記憶體佔用、車載儲存分級與資料回傳流量，並量化對比純視覺與視覺+光達方案。

1. 預設方案與參數配置

選擇預設方案後，手動調整下方任意參數將自動切換為自訂模式。

1. 模型結構
2. 每步感測器輸入（視覺 & 光達）

開啟串流 KV 快取重用後，歷史幀特徵直接從快取讀取，每步僅對新到達的 1 幀進行 Prefill。

3. 執行頻率與車端晶片
40%

受記憶體頻寬與算子排程影響，車端真實利用率通常在 0.30–0.50 之間。

4. 觸發採集 · 車載儲存 · 資料回傳
50%

2. 車端預算評估結果

車端晶片佔用率 --
單步推論延遲 --
持續算力 (FP16 等效) --
記憶體合計（權重+KV+活化） --
車載 SSD 儲存建議 --
月度資料回傳 --
車端即時可行性評估 --
上下文快取 Token --
每步新輸入 Token --
每步總 Token（含動作） --
每步推論 FLOPs --
所需 INT8 TOPS / 當前晶片 --
延遲拆分（預填充 / 解碼 / 合計） --
記憶體拆分（權重 / KV / 活化 / 合計） --
事件資料位元率 / 單事件大小 --

3. 純視覺 vs 視覺+光達 對比（當前參數）

對比僅切換光達開關，其餘參數保持不變，量化評估引入光達點雲對算力、延遲與儲存回傳的增幅（Δ）。

對比指標 純視覺 (Vision) 視覺+光達 (Vision+LiDAR) 增幅 (Δ)

* 說明：計算結果為數量級工程參考（容差 ±2 倍），不含安全保底小模型的算力佔用，跨廠商晶片對比建議額外預留 10–20% 餘裕。

車端 VLA 預算計算口徑與工程設計指南

在越野或城市自動駕駛車輛及移動機器人上部署 7B–20B 規模的 VLA（視覺-語言-動作）模型時，工程團隊必須同時平衡四項強耦合指標：控制幀率下的持續 TOPS 算力、單步預填充與動作解碼延遲、權重與多幀 KV 快取記憶體，以及車隊事件觸發儲存與回傳頻寬。

1. 核心計算公式與口徑

每 Token 前向計算量按 2N FLOPs 估算；INT8/FP8 吞吐按 FP16 等效的 2 倍乘以實際利用率（η_util）折算：

T_ctx = (C_cam × T_cam + I_lidar × T_lidar) × W_win T_new = (C_cam × T_cam + I_lidar × T_lidar) × (1 if KV_reuse else W_win) FLOPs_step ≈ 2 × N × (T_new + T_action) · P_sustained = FLOPs_step × f_Hz TOPS_int8_req = P_sustained ÷ (2 × η_util) · Occupancy = TOPS_int8_req ÷ TOPS_SoC t_step = t_prefill + t_decode = FLOPs_step ÷ (TOPS_SoC × 2 × η_util × 10^12) × 1000 [ms] M_KV = 2 × H_kv × d_head × L × b_kv × T_ctx ÷ 10^9 [GB] · M_total = M_weights + M_KV + M_act

* 模型權重記憶體含 5% 量化中繼資料開銷；車上儲存按 OTA A/B 雙版本（2 × M_weights + 1.5 GB）與 30 GB 系統預留空間計入。

2. 串流 KV 快取重用與多模態 Token 瓶頸

多路環視相機加光達點雲在多幀融合視窗下的上下文動輒超過上萬 Token。若每步都對整個時間視窗重新 Prefill，即便 2000 TOPS 級晶片也難以支撐 10Hz 閉迴路。開啟串流 KV 重用後，每步僅預填充新進入的 1 幀感測器 Token，大幅降低延遲。

3. 事件觸發環形快取與車隊回傳規劃

量產車隊通常採用環形緩衝區（Ring Buffer）按觸發事件錄製 60 秒片段，在車端 SSD 留存 7–14 天，並按比例（如 50%）回傳雲端用於資料閉迴路訓練。

4. 常見問題 (FAQ)

為什麼計算所需 INT8 TOPS 時要將持續 FP16 等效算力除以 2？

Transformer 前向公式（2N FLOPs/Token）對應 FP16 基準運算量。車載 SoC 標稱的 INT8/FP8 TOPS 在同頻下吞吐約為 FP16 的 2 倍，因此除以 2 再除以實際硬體利用率即可得到所需的標稱 INT8 TOPS。

引入光達點雲 Token 對哪項預算影響最顯著？

每幀增加 2048–4096 個點雲 Token 會使每步預填充 Token 增加 35%–60%，直接推高單步延遲與晶片佔用率；同時光達約 0.5 MB/s 的資料流也會顯著增加單事件體積與每月車隊回傳流量。

為什麼實際硬體利用率建議設在 0.30–0.50 之間？

晶片廠商公佈的 TOPS 多為包含稀疏特性的理論峰值。實際執行多相機視覺編碼、GQA KV 快取讀取與逐 Token 動作解碼時受限於記憶體頻寬與算子開銷，真實利用率通常在 30%–50% 左右。

Physical AI Portal 相關文章(英文)

參考的第一手資料

資料與公式核實日期：2026-10-26 · 營運者：Huni ([email protected])