Physical AI 엔지니어링 도구

온보드 VLA 연산·지연·스토리지 예산 계산기

자율주행·오프로드 차량 및 모바일 로봇에 탑재되는 대규모 비전-언어-행동(VLA) 모델의 스텝당 추론 연산량, 지연시간, 통합 메모리, 온보드 SSD 스토리지 및 클라우드 데이터 오프로드 예산을 설계하고 순수 비전(Vision-only) 대 비전+라이다(Vision+LiDAR) 멀티모달 비용을 비교합니다.

1. 시나리오 및 파라미터 설정

프리셋을 선택한 뒤 개별 파라미터를 수정하면 자동으로 직접 입력 모드로 전환됩니다.

1. 모델 아키텍처
2. 스텝당 센서 입력 (비전 & 라이다)

스트리밍 추론에서 이전 프레임의 KV 캐시를 재사용하면 스텝당 프리필 연산량이 프레임 윈도우 배수만큼 감소합니다.

3. 추론 주기 & 온보드 SoC
40%

온보드 실시간 스트리밍 추론 시 메모리 대역폭 및 커널 오버헤드로 인해 실효 이용률은 통상 30%~50% 수준입니다.

4. 이벤트 로깅 · 차량 스토리지 · 오프로드
50%

2. 온보드 예산 산출 결과

온보드 SoC 점유율 --
단일 스텝 지연시간 --
지속 추론 연산량 (FP16 등가) --
온보드 메모리 (가중치+KV+활성화) --
권장 차량 내 스토리지 등급 --
월간 데이터 오프로드 --
온보드 실시간 운용 진단 --
컨텍스트 토큰 (캐시 유지) --
스텝당 신규 입력 토큰 --
스텝당 총 처리 토큰 (액션 포함) --
스텝당 추론 연산량 (FLOPs) --
필요 INT8 TOPS / 선택 SoC --
지연시간 (프리필 / 디코드 / 합계) --
메모리 (가중치 / KV / 활성화 / 합계) --
이벤트 데이터 속도 / 1회 용량 --

3. 순수 비전 vs 비전+라이다 비교 (현재 파라미터 기준)

나머지 설정을 고정한 상태에서 라이다 포인트 클라우드 융합 유무에 따른 연산·지연·메모리·데이터 오프로드 증감률(Δ)을 비교합니다.

비교 지표 순수 비전 (Vision) 비전 + 라이다 (Vision+LiDAR) 증감률 (Δ)

* 안내: 본 도구는 오더-오브-매그니튜드(±2배 허용 오차) 아키텍처 예산 산출용 계산기이며, 안전 폴백(Safety Fallback) 소형 제어 모델의 연산 점유율은 별도로 여유분을 두어야 합니다.

온보드 VLA 연산·지연·스토리지 산출 원리 및 엔지니어링 가이드

야지(Off-road) 및 도심 자율주행 차량이나 모바일 로봇에 7B~20B급 비전-언어-행동(VLA) 모델을 탑재할 때는 단일 GPU VRAM뿐만 아니라 제어 주기(Hz) 내에 프리필과 액션 디코딩을 마칠 수 있는 지속 TOPS 예산, 멀티프레임 KV 캐시 용량, 그리고 플릿 데이터 수집 루프의 SSD·통신 대역폭을 동시에 설계해야 합니다.

1. 핵심 예산 산출 공식

토큰당 순전파 연산량을 약 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)과 OS/시스템 예약 영역(30 GB)을 기본 반영합니다.

2. 스트리밍 KV 캐시 재사용과 멀티모달 토큰 병목

6~8대의 고해상도 카메라와 3D 라이다 포인트 클라우드를 2~4프레임 윈도우로 융합하면 컨텍스트 토큰이 수만 개에 달합니다. 매 제어 스텝마다 전체 윈도우를 다시 프리필하면 DRIVE Thor급 SoC에서도 10Hz(100ms 예산) 달성이 불가능해지므로, 이전 프레임의 KV 캐시를 고정하고 스텝당 새로 유입된 1프레임의 토큰만 프리필하는 스트리밍 KV 재사용 아키텍처가 필수적입니다.

3. 플릿 이벤트 트리거 스토리지 및 월간 오프로드 설계

상시 전체 센서 원본을 기록하는 대신 코너 케이스·개입(Intervention) 이벤트를 60초 단위로 링버퍼에서 추출해 로컬 SSD에 7~14일간 보관하고, 선별된 비율(예: 50%)만 기지국/Wi-Fi로 업로드하면 플릿 통신 비용과 온보드 NVMe SSD 수명(TBW)을 균형 있게 관리할 수 있습니다.

4. 자주 묻는 질문 (FAQ)

왜 INT8/FP8 필요 TOPS를 계산할 때 지속 FLOPs를 2로 나누나요?

트랜스포머 순전파 공식(2N FLOPs/token)은 기본적으로 FP16 기준 연산량입니다. 차량용 SoC가 발표하는 INT8/FP8 TOPS 규격은 동일 클럭에서 FP16 대비 약 2배의 연산 처리량을 가지므로, FP16 등가 연산량을 2와 실효 이용률(util)로 나누어 필요 INT8 TOPS를 도출합니다.

라이다(LiDAR) 토큰을 추가하면 온보드 예산의 어디에 가장 큰 영향을 주나요?

프레임당 2,048~4,096개의 라이다 포인트 토큰이 추가되면 스텝당 프리필 토큰 수가 35%~60% 증가하여 단일 스텝 지연시간과 SoC 점유율이 비례해서 상승하며, 이벤트 로깅 시 카메라 압축 스트림 대비 높은 비트레이트(약 0.5 MB/s 이상)로 인해 차량 내 캐시와 월간 업로드 데이터양도 크게 늘어납니다.

실효 이용률(Real Utilization)을 0.3~0.5로 설정하는 이유는 무엇인가요?

제조사가 공개하는 SoC TOPS(예: Thor 2000 TOPS)는 희소성(Sparsity)을 포함한 이론적 피크 수치입니다. 실제 차량 온보드에서 멀티카메라 비전 인코더, GQA 어텐션 KV 캐시 읽기, 자기회귀 액션 토큰 디코딩을 실행하면 메모리 대역폭 병목으로 인해 피크 대비 30~50% 수준의 실효 처리량을 보이므로 이를 반영해야 현실적인 설계가 가능합니다.