엔비디아가 말하는 차량용 AI 에이전트의 정석, 클라우드부터 차 안까지 풀스택으로 묶기

차량 콕핏이 그냥 음성 명령에서 AI 에이전트로 넘어가는 중

• 엔비디아가 말하는 큰 변화는 차량 내 어시스턴트가 룰 기반 명령-응답 시스템에서 에이전틱 멀티모달 AI로 바뀐다는 것임

  • 기존 차량 음성 비서는 정해진 문장을 해석하고, 특정 동작을 실행하고, 다시 초기화되는 패턴에 가까웠음
  • 새 구조에서는 대규모 언어 모델, 비전 언어 모델, 음성 모델이 기억·추론·계획을 맡고, 운전자와 동승자의 맥락까지 이해하는 쪽으로 감

• 차량 AI가 처리해야 할 입력도 훨씬 넓어짐

  • 음성만 듣는 게 아니라 실내 카메라, 외부 카메라, 차량 텔레메트리, 캘린더, 스마트홈, 클라우드 서비스까지 같이 봐야 함
  • 예를 들어 운전자가 “저 식당 영업시간이 어떻게 되지?”라고 물으면, 외부 카메라가 간판을 보고, VLM이 상호를 해석하고, LLM이 답변을 구성하는 식임

차 안에서 LLM을 돌리는 게 어려운 이유

• 차량 내 AI 어시스턴트는 그냥 클라우드 챗봇을 차에 붙이는 문제가 아님

  • 로컬에서 7B 이상 파라미터 모델을 실행해야 하고, 카메라·오디오·텔레메트리 같은 멀티모달 입력도 처리해야 함
  • 응답 시간은 500밀리초 미만, 디코드 처리량은 초당 30토큰 이상을 유지해야 한다고 제시됨
  • 프라이버시 때문에 가능한 한 에지 우선으로 처리해야 하는 조건도 붙음

• 엔비디아는 이 문제를 DRIVE AGX 기반 AI Box로 풀겠다고 설명함

  • AI Box는 기존 인포테인먼트 시스템 옆에 붙는 애드온 ECU 형태임
  • 기존 IVI 시스템을 통째로 갈아엎지 않고도 LLM·VLM 워크로드를 추가할 수 있다는 게 포인트임

• AI Box가 맡는 역할은 꽤 구체적임

  • 실내 카메라로 동승자, 표정, 자세, 제스처를 파악함
  • 외부 카메라로 주변 상황, 간판, 관심 지점, 보안 상황을 해석함
  • IVI 컴퓨터에서 넘어온 오디오와 사용자 컨텍스트를 함께 처리해 UX 애플리케이션에 결과를 넘김

sequenceDiagram
    participant 운전자
    participant 차량어시스턴트
    participant 카메라센서
    participant 로컬AI박스
    participant 클라우드에이전트

    운전자->>차량어시스턴트: 자연어로 요청
    차량어시스턴트->>카메라센서: 실내외 맥락 확인
    카메라센서->>로컬AI박스: 영상·텔레메트리 전달
    로컬AI박스->>로컬AI박스: VLM·LLM 추론
    로컬AI박스->>클라우드에이전트: 웹 정보가 필요한 작업 위임
    클라우드에이전트-->>로컬AI박스: 검색·서비스 결과 반환
    로컬AI박스-->>차량어시스턴트: 응답 생성
    차량어시스턴트-->>운전자: 음성·화면으로 안내

Orin, Thor, MediaTek까지 배포 선택지를 나눠 제시함

• DRIVE AGX Orin 기반 AI Box는 대중 시장 차량용 고성능 AI 옵션으로 소개됨

  • 기존 IVI 시스템을 크게 바꾸지 않고 차량 내 AI 기능을 붙이는 데 초점이 있음
  • 인포테인먼트 SoC와 비교해 더 큰 모델, 더 안정적인 추론 처리량, 격리된 메모리 대역폭을 제공한다고 설명함

• DRIVE AGX Thor는 더 중앙화된 멀티 도메인 AI 컴퓨터 포지션임

  • Blackwell GPU 아키텍처 기반으로 자율주행과 차량 내 AI 워크로드를 한 컴퓨터에서 호스팅하는 그림을 제시함
  • DriveOS 7에서 여러 QNX·Linux 가상 머신을 지원해 안전 등급이 다른 워크로드 간 간섭 차단을 노림

• MediaTek Dimensity AX C-X1과 DRIVE AGX를 결합하는 중앙 카 컴퓨터 구성도 제시됨

  • C-X1 자체도 LLM 추론이 가능한 엔비디아 GPU를 포함하지만, DRIVE AGX와 묶으면 AI 워크로드를 분산할 수 있음
  • 영상·오디오 같은 고대역폭 데이터는 DriveOS NvStreams API로 PCIe 링크 위에서 공유하는 구조임

하이브리드 에지-클라우드가 핵심 아키텍처

• 엔비디아는 차량 AI가 전부 로컬에서만 돌 수는 없다고 봄

  • 웹 리서치, 소셜 미디어 상호작용, 여행 계획 같은 작업은 외부 API와 클라우드 에이전트가 필요함
  • 반대로 지연 시간, 프라이버시, 차량 제어와 가까운 작업은 로컬 처리가 더 적합함

• 그래서 필요한 게 에이전트 오케스트레이션임

  • 사용자 의도와 현재 맥락에 따라 로컬 에이전트와 클라우드 에이전트 중 어디로 보낼지 결정함
  • 여행 계획 예시에서는 로컬 내비게이션 에이전트, 클라우드 맛집·관광지 검색 에이전트, 로컬 지식 에이전트가 같이 동작할 수 있음

• UX 투명성도 중요한 요구사항으로 제시됨

  • 클라우드 호출은 시간이 걸리고, 인터넷 연결이 끊기면 결과가 돌아오지 않을 수 있음
  • 차량 AI는 비동기 작업 상태, 예상 완료 시간, 연결 상태, 폴백 메커니즘을 사용자에게 자연스럽게 반영해야 함

개발 파이프라인은 AI 팩토리에서 차 안 배포까지 이어짐

• 엔비디아가 제시하는 개발 흐름은 클라우드에서 만들고, 최적화해서, 차량에 배포하는 방식임

  • NeMo와 NIM으로 클라우드에서 프로토타입을 만들고, TensorRT-LLM으로 서버 측 추론을 최적화함
  • NeMo Agent Toolkit으로 오케스트레이터와 도구 통합을 만들고, DRIVE AGX DevKit에서 TensorRT Edge-LLM으로 배포함

• 차량 내 에이전틱 AI 파이프라인의 구성 요소도 명확히 나뉨

  • ASR은 캐빈 마이크 오디오를 텍스트로 바꾸고, 잡음 억제와 웨이크 워드 처리를 포함할 수 있음
  • 오케스트레이터는 의도 라우팅, 세션 상태, 도구 선택, 타임아웃, 폴백, 차량 제어 권한 정책을 담당함
  • LLM 추론 엔진은 토크나이즈, 배칭, KV 캐시 관리, 하드웨어 가속 실행을 처리함
  • TTS는 최종 답변을 운전 상황에 맞는 음성으로 내보냄

• 파트너 생태계까지 이미 깔아둔 점도 눈에 띔

  • 하드웨어와 소프트웨어 플랫폼 파트너로 Bosch, Desay SV, Lenovo, PATEO, ThunderSoft, Visteon이 언급됨
  • 모델과 파이프라인 쪽 파트너로 Amazon Alexa, ArcherMind, Cerence AI, Volcano Engine이 제시됨

기술 맥락

• 엔비디아가 이 글에서 고른 핵심 선택은 차량 AI를 순수 클라우드 서비스로 만들지 않고, 에지와 클라우드를 나누는 구조예요. 왜냐하면 차 안에서는 지연 시간과 프라이버시가 너무 중요하고, 동시에 웹 검색이나 여행 계획처럼 클라우드가 더 잘하는 작업도 분명히 있기 때문이에요.

• AI Box라는 애드온 ECU 방식도 현실적인 선택이에요. 기존 IVI 시스템을 전면 재설계하면 비용, 인증, 출시 일정이 다 커지거든요. 그래서 기존 콕핏 컴퓨터 옆에 AI 전용 컴퓨트 박스를 붙이고, 오디오·카메라·컨텍스트만 주고받는 방식이 양산차에는 더 설득력 있어요.

• Orin과 Thor를 나눠 제시한 것도 차량 세그먼트 차이를 의식한 설계예요. 대중 차량에는 Orin 기반 AI Box로 필요한 성능을 맞추고, 프리미엄 차량이나 중앙집중형 아키텍처에는 Thor로 자율주행과 차량 내 AI를 함께 올리는 그림이죠.

• TensorRT Edge-LLM이 중요한 이유는 모델을 그냥 작게 만드는 것만으로는 차량 요구사항을 못 맞추기 때문이에요. 7B 이상 모델, 500밀리초 미만 응답, 초당 30토큰 이상 같은 조건을 맞추려면 런타임의 KV 캐시 관리, 배칭, 하드웨어 가속 최적화가 같이 들어가야 해요.

• 개발 조직 관점에서는 이 아키텍처가 클라우드 AI 팀과 임베디드 차량 팀을 하나의 파이프라인으로 묶는다는 점이 커요. NeMo에서 학습·평가한 모델을 TensorRT 계열로 최적화해 차량에 배포하는 흐름이 있어야, 데모가 아니라 반복 업데이트 가능한 제품이 되거든요.