엔비디아 ‘베라’ CPU, 에이전트 AI 오케스트레이션 전담해 x86보다 1.8배 빠르다

엔비디아(NVIDIA)가 스페이스X AI(SpaceX AI)의 차세대 에이전트형 AI(Agentic AI, 스스로 계획하고 실행까지 하는 AI) 인프라에 신형 CPU ‘베라(Vera)’를 공급한다고 발표했다. 스페이스XAI는 AI 챗봇 ‘그록(Grok)’ 인프라도 엔비디아의 ‘베라 루빈(Vera Rubin)’ 플랫폼으로 확장하기로 했다. 1세대 AI 위성 ‘스타마인드(Starmind)’에도 같은 아키텍처를 적용해 지상을 넘어 우주 궤도 컴퓨팅까지 나선다. 엔비디아 하이퍼스케일·고성능 컴퓨팅 부문 부사장 이언 벅(Ian Buck)은 “에이전트형 AI는 답을 생성하는 데 그치지 않고 실제 행동에 나서는 새로운 컴퓨팅 시스템을 요구한다”고 말했다. 이번 발표는 일론 머스크가 스페이스XAI의 AI 사업에 엔비디아 GPU만 쓰겠다고 공언한 지 몇 주 만에 나왔다.

왜 에이전트 AI엔 새로운 CPU가 필요한가

에이전트형 AI는 답변 하나를 내놓는 게 끝이 아니다. 모델이 답을 도출하는 사이사이 도구를 호출하고 코드를 실행하고 데이터를 처리하며 시뮬레이션을 돌리는 작업이 끊임없이 이어진다. 이 오케스트레이션(작업 조율) 부담은 GPU가 아니라 CPU가 떠안는다. 엔비디아는 베라를 “AI 에이전트를 위해 설계된 최초의 CPU”라고 소개했다.

베라는 엔비디아가 자체 설계한 올림푸스(Olympus) 코어 88개를 탑재했다. 여기에 엔비디아 스페이셜 멀티스레딩(Spatial Multithreading) 기술과 고대역폭 LPDDR5X 메모리를 결합해 최대 1.2TB/s의 메모리 대역폭을 낸다. 엔비디아에 따르면 베라는 에이전트형 AI와 강화학습, 데이터 처리 작업에서 기존 x86 CPU보다 작업 완료 속도가 최대 1.8배 빠르다. 스페이스XAI 대표 마이크 니콜스(Mike Nicolls)는 “베라는 GPU가 본연의 일에 집중하도록 하면서 방대한 양의 오케스트레이션과 코드·데이터 처리를 수행할 CPU 성능과 메모리 대역폭을 제공한다”며 “이는 더 높은 성능의 AI 에이전트와 와트(W)당 더 많은 유효 작업으로 이어진다”고 말했다.

그록부터 우주 위성까지, 하나의 아키텍처로 지상과 궤도를 잇다

스페이스XAI는 그록의 AI 인프라를 기가와트급 컴퓨팅 용량으로 확장하는 과정에서 베라 루빈 플랫폼을 채택한다. 베라 루빈은 컴퓨팅·네트워킹·소프트웨어를 하나로 설계하는 ‘익스트림 코디자인(Extreme Codesign)’ 방식이 특징이다. 스페이스XAI는 여기서 한발 더 나가 1세대 AI 위성 스타마인드에 최적화한 베라 루빈 NVL72 랙스케일 시스템을 적용하기로 했다. 지상의 AI 팩토리를 구동하는 것과 동일한 아키텍처를 우주로 확장하는 시도다.

우주용으로 설계된 ‘스페이스-1 베라 루빈(Space-1 Vera Rubin)’ 모듈은 GPU와 CPU를 긴밀하게 통합하고 고대역폭 인터커넥트를 갖췄으며 태양광만으로 전력을 공급받는다. 궤도 워크로드 기준으로 이전 세대 H100 GPU 대비 최대 25배의 AI 컴퓨팅 성능을 낸다는 게 엔비디아 설명이다. 지구 관측 정보 분석, 자율 운영, 궤도상 실시간 분석 등에 쓰일 예정이며 에더플럭스(Aetherflux), 액시엄 스페이스(Axiom Space), 플래닛 랩스(Planet Labs) 등이 도입을 계획하고 있다. 앞서 일론 머스크는 스페이스XAI의 AI 사업에 엔비디아 GPU만 쓰겠다고 공언하며 그 이유로 “최고이기 때문”이라고 말했다. 그는 2027년까지 10메가와트(MW) 규모의 AI 컴퓨팅 구축을 확인한 바 있다. 이언 벅 부사장은 “스페이스XAI는 이 아키텍처를 거대한 AI 팩토리에서 궤도라는 컴퓨팅의 다음 개척지로 옮겨가고 있다”고 평가했다.

실측 성능, 와트당 처리량 최대 30배·토큰 비용 최대 35배 절감

엔비디아가 공개한 새 실측 데이터에 따르면 베라 루빈 NVL72 시스템은 에이전트형 워크로드에서 이전 세대 GB300 NVL72보다 메가와트당 처리량이 최대 30배 높다. 이 수치는 세미애널리시스(SemiAnalysis)의 ‘에이전트X(AgentX)’ 워크로드로 측정됐다. 실제 에이전트형 코딩 세션을 그대로 기록해 맥락 증가와 도구 호출, 서브 에이전트 생성까지 재현한 벤치마크다. 엔비디아는 이 결과가 세미애널리시스의 검토를 아직 거치는 중이며 베라 CPU의 도구 호출 성능은 반영되지 않았다고 밝혔다. 전력이 제한된 AI 팩토리 입장에서 메가와트당 처리량이 30배 높아진다는 것은 같은 에너지로 30배 더 많은 에이전트 작업을 처리할 수 있다는 의미다.

앞서 GB300 NVL72는 딥시크 V4 프로(DeepSeek V4 Pro) 모델 기준으로 이전 호퍼(Hopper) 아키텍처보다 메가와트당 처리량이 최대 15배 높았다. 베라 루빈은 여기서 성능 곡선 전체를 끌어올려 GB300 NVL72 대비 최대 30배까지 격차를 벌렸다. 토큰 100만 개당 비용은 GB300 NVL72보다 최대 35배 낮아 에이전트를 대규모로 상시 가동해도 비용 부담이 줄어든다는 설명이다. 오픈라우터(OpenRouter) 데이터를 보면 에이전트형 워크로드는 단순 대화형 요청보다 토큰을 15배 더 많이 소비한다. 엔비디아는 GPU와 랙, 워크로드 단위로 전력을 관리하는 ‘DSX 맥스LPS(DSX MaxLPS)’ 기술로 같은 메가와트 예산 안에서 GPU를 최대 40% 더 배치할 수 있다고 덧붙였다.

16만 건 텔레메트리로 본 CPU 설계 철학

엔비디아 개발자 블로그는 실제 에이전트 세션 16만3594건의 텔레메트리(원격 측정 데이터)를 분석한 결과를 공개했다. 그 결과 97% 이상의 세션이 서로 다른 실행 궤적(trajectory)을 보였다. 워크로드가 워낙 다양해 특정 시나리오에 맞춘 여러 종류의 전용 CPU로 함대를 구성하는 방식은 비효율적이라는 게 엔비디아 결론이다.

실제 클로드 코드(Claude Code) 세션 사례에서 33분간 진행된 작업은 대부분 순차적인 추론 경로를 따라가면서 중간중간 서브 에이전트의 병렬 작업이 짧게 몰아치는 패턴을 보였다. 순차 경로는 전체 세션 완료 시간을 좌우하는 지연 민감 구간이고 병렬 구간은 일시적이지만 동시 처리 능력을 요구한다. 엔비디아는 단일 스레드 성능을 높이려 일부 코어를 끄면 코어당 8GB, 최대 1.5TB에 이르는 메모리 용량이 방치될 수 있다고 지적했다. 베라는 이런 균형을 위해 설계됐다는 게 회사 설명이다. 코어 하나하나의 처리 속도와 다수 코어의 동시 처리 능력을 함께 갖춰야 완료되는 에이전트 작업의 총량, 즉 함대 전체의 경제성을 극대화할 수 있다는 논리다.