NVIDIA 베라 CPU, 경쟁 제품에 대항해 강력한 경쟁력 보여

에이전틱 AI 워크로드는 기존 학습/추론 중심의 GPU 부하와 성격이 다릅니다. 다수의 에이전트가 도구를 호출하고, 컨텍스트를 오케스트레이션하며, 짧은 추론을 빠르게 반복하는 과정에서 CPU 쪽의 직렬 처리 성능과 메모리 대역폭이 병목이 됩니다. NVIDIA Vera는 이 요구에 맞춰 설계된 Arm 기반 커스텀 CPU로, Grace의 후속이자 Rubin GPU와 짝을 이루는 Vera Rubin 플랫폼의 한 축입니다. 핵심은 세 가지입니다 — 빠른 단일 코어 성능, 대용량 메모리 대역폭, 그리고 모든 코어가 동시에 활성화된 상태에서도 클럭이 떨어지지 않고 성능을 지속(sustained all-core)하는 능력입니다. 마지막 항목이 특히 중요한데, 데이터센터 CPU는 전체 코어를 풀로드하면 전력·발열 한계로 클럭을 낮추는(throttling) 경우가 많아 벤치마크 피크 수치와 실제 지속 처리량 사이에 괴리가 생기기 때문입니다. Phoronix가 공개한 초기 벤치마크는 Vera가 이 지속 성능 구간에서 경쟁 제품 대비 강점을 보인다는 점을 시사합니다.

기술적으로 Vera가 의미를 갖는 이유는 CPU가 단독 칩이 아니라 GPU와 코히런트하게 연결된 "AI 팩토리"의 일부로 동작하기 때문입니다. NVLink 기반 칩 간 인터커넥트로 CPU와 GPU가 메모리를 일관성 있게 공유하면, GPU가 추론을 도는 동안 CPU가 데이터 전처리·KV 캐시 관리·에이전트 라우팅·도구 실행을 맡는 분업이 PCIe 복사 오버헤드 없이 매끄럽게 이뤄집니다. 즉 Vera의 가치는 CPU 벤치마크 점수 자체보다, GPU를 놀리지 않고 지속적으로 먹여 살리는(feed the GPU) 시스템 차원의 처리량에 있습니다. 다만 현재 공개된 것은 "first public look"의 제한된 벤치마크 범위라는 점, 그리고 Arm 아키텍처라는 점은 분명히 인지해야 합니다.

엔지니어 입장에서 실질적인 영향은 대부분 클라우드 인스턴스 형태로 다가옵니다. 직접 칩을 사는 개발자는 드물지만, 향후 클라우드 사업자가 Vera Rubin 기반 인스턴스를 제공하면 LLM 추론·에이전트 서빙의 비용 대비 처리량(throughput/$)이 달라질 수 있고, 이는 서비스 아키텍처와 SLA 설계에 직접 반영됩니다. 또 하나 놓치기 쉬운 포인트는 ISA 전환입니다. Vera는 x86이 아닌 Arm 코어이므로, 네이티브 확장이나 인텔 전용 명령어(AVX-512 등)에 의존하는 바이너리, 혹은 x86 전용으로 빌드된 컨테이너 이미지는 그대로 돌지 않습니다. Grace·Graviton 등 기존 Arm 서버에서 이미 검증된 멀티 아키텍처 빌드 관행이 여기서도 그대로 요구됩니다.

따라서 지금 당장 할 일은 두 가지로 정리됩니다. 첫째, 컨테이너 이미지를 멀티 아키텍처(`linux/amd64`, `linux/arm64`)로 빌드·배포하는 파이프라인을 갖추고, 네이티브 의존성(파이썬 휠, JNI, CGO 등)이 arm64 휠/빌드를 제공하는지 미리 점검하는 것입니다. 둘째, 벤치마크 수치는 워크로드 의존성이 크므로 NVIDIA·Phoronix의 피크 발표를 그대로 신뢰하기보다, 실제 에이전트 서빙 파이프라인을 대상으로 지속 부하(sustained load) 기준의 처리량·지연·전력당 성능을 직접 측정해 비교하는 자세가 필요합니다. 현 단계는 발표·초기 벤치마크 단계이므로, 마이그레이션을 서두르기보다 Arm 호환성 점검과 후속 정식 벤치마크 추적에 무게를 두는 것이 합리적입니다.