Physical AI Engineering-Tools

Onboard-VLA Rechen-, Latenz- & Speicher-Budgetrechner

Dimensionieren Sie das komplette Onboard-Budget für autonome Fahrzeuge, Offroad-Roboter und mobile Plattformen mit Vision-Language-Action-(VLA)-Modellen – inklusive TOPS-Auslastung, Prefill-/Decode-Latenz, Speicher, Fahrzeug-SSD und Vision-only vs. Vision+LiDAR-Vergleich.

1. Szenario & Parameter

Wählen Sie eine Vorlage oder passen Sie beliebige Werte unten an.

1. Modellarchitektur
2. Sensoreingabe pro Schritt (Vision & LiDAR)

Streaming-KV-Reuse speichert frühere Frames im Cache, sodass pro Regelschritt nur 1 neuer Frame berechnet wird.

3. Laufzeitfrequenz & Fahrzeug-SoC
40%

Reale Auslastung liegt wegen Speicherbandbreite meist zwischen 0,30 und 0,50.

4. Ereignis-Logging, Fahrzeugspeicher & Upload
50%

2. Berechnete Onboard-Budgets

SoC-Auslastung --
Latenz pro Schritt --
Dauerrechenleistung (FP16-Äq.) --
Speicher (Gewichte+KV+Akt.) --
Empfohlene Fahrzeug-SSD --
Monatlicher Daten-Upload --
Echtzeit-Machbarkeit --
Gecachte Kontext-Tokens --
Neue Eingabetokens / Schritt --
Gesamttokens / Schritt (inkl. Aktion) --
Inferenz-FLOPs / Schritt --
Benötigte INT8 TOPS / SoC --
Latenz (Prefill / Decode / Gesamt) --
Speicher (Gewichte / KV / Akt. / Gesamt) --
Ereignis-Datenrate / Clipgröße --

3. Vergleich: Vision-Only vs. Vision+LiDAR

Vergleicht alle 10 Kennzahlen bei identischen Parametern mit deaktiviertem bzw. aktiviertem LiDAR.

Kennzahl Vision-Only Vision + LiDAR Differenz (Δ)

* Hinweis: Größenordnungsschätzung (±2× Toleranz). Planen Sie zusätzliche Reserven für Sicherheits-Fallback-Regler ein.

Methodik & Engineering-Leitfaden für Onboard-VLA-Budgets

Beim Einsatz großer VLA-Modelle (7B–20B) im Fahrzeug müssen Dauer-TOPS, Schrittlatenz, KV-Cache-Speicher und SSD-/Upload-Volumen gemeinsam ausgelegt werden.

1. Berechnungsformeln

Der Vorwärtspass wird mit 2N FLOPs pro Token angenähert; INT8/FP8-Durchsatz zählt als 2× FP16-Äquivalent multipliziert mit der effektiven Auslastung (η_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

* Gewichtsspeicher enthält 5 % Overhead; Fahrzeugspeicher berücksichtigt A/B-Modellslots (2 × M_weights + 1,5 GB) sowie 30 GB für das Betriebssystem.

2. Streaming-KV-Reuse & Multimodale Tokens

Durch Wiederverwendung des KV-Caches vergangener Frames muss pro Regeltakt nur der neueste Frame im Prefill verarbeitet werden, was die Latenz drastisch senkt.

3. Ringpuffer-Aufzeichnung & Flotten-Upload

Ereignisgesteuerte 60-Sekunden-Clips reduzieren lokalen SSD-Verschleiß und Mobilfunkkosten gegenüber Daueraufzeichnung erheblich.

4. Häufig gestellte Fragen (FAQ)

Warum wird die FP16-Rechenleistung für INT8 TOPS durch 2 geteilt?

2N FLOPs/Token bezieht sich auf FP16. Da INT8/FP8-Tensorkerne pro Takt etwa den doppelten Durchsatz von FP16 liefern, ergibt die Division durch 2 und durch die Auslastung den benötigten INT8-TOPS-Wert.

Welchen Mehraufwand verursacht die LiDAR-Fusion?

2.048–4.096 zusätzliche LiDAR-Tokens erhöhen die Prefill-Last und Schrittlatenz oft um 35 %–60 % sowie das Ereignis- und Upload-Datenvolumen.

Warum liegt die reale Hardware-Auslastung meist bei 0,30–0,50?

Hersteller-TOPS sind theoretische Spitzenwerte. Speicherbandbreite und serielles Token-Decoding begrenzen die reale Auslastung im Fahrzeug typischerweise auf 30 %–50 %.