Devlery
Blog/AI

Vera 88코어 첫 출하, OpenAI가 받은 에이전트용 CPU

NVIDIA가 Vera CPU 첫 시스템을 OpenAI·Anthropic·OCI에 전달했습니다. 에이전트 실행에서 CPU가 맡는 도구 호출, 샌드박스, 파이썬 병목을 짚습니다.

Vera 88코어 첫 출하, OpenAI가 받은 에이전트용 CPU
AI 요약
  • 무슨 일: NVIDIA가 88코어 Vera CPU 첫 시스템을 Anthropic, OpenAI, SpaceXAI, OCI에 전달했습니다.
    • 공식 공개일은 2026년 5월 18일이며, Vera는 NVIDIA의 첫 자체 설계 데이터센터 CPU입니다.
  • 개발자 의미: 에이전트 워크로드의 병목이 GPU 추론만이 아니라 Python, 도구 호출, 샌드박스, KV 캐시 관리로 넓어졌습니다.
  • 주의점: Phoronix 초기 벤치마크는 강했지만 NVIDIA가 허용한 테스트 범위였고 전력·주파수·가격은 아직 공개 검증이 부족합니다.

NVIDIA가 2026년 5월 18일 Vera CPU 첫 고객 시스템을 Anthropic, OpenAI, SpaceXAI, Oracle Cloud Infrastructure에 전달했다고 공개했습니다. 발표 자체는 서버 칩 뉴스처럼 보이지만, AI 개발자에게는 더 좁고 실무적인 질문을 던집니다. 에이전트가 코드를 실행하고, 도구를 호출하고, 파일을 읽고, 샌드박스 안에서 수십 분 동안 상태를 유지할 때 병목은 GPU 하나로 끝나지 않습니다. Vera는 그 GPU 밖 작업을 겨냥한 NVIDIA의 첫 자체 설계 데이터센터 CPU입니다.

공식 블로그에 따르면 첫 배송은 2026년 5월 15일 금요일 Anthropic, OpenAI, SpaceXAI에서 시작됐고, 5월 18일 월요일 OCI로 이어졌습니다. NVIDIA의 Hyperscale and High-Performance Computing 담당 부사장 Ian Buck이 직접 시스템을 전달했습니다. NVIDIA는 Vera를 "agentic AI"용 CPU라고 부릅니다. 이 표현은 마케팅 문구로만 읽으면 흐릿하지만, 블로그가 열거한 작업은 구체적입니다. 에이전트 샌드박스, 도구 호출, 오케스트레이션, 장문 상태 관리, 데이터 분석, 강화학습 파이프라인은 모두 GPU 연산 사이에 CPU를 계속 깨웁니다.

NVIDIA가 공개한 Vera CPU 첫 고객 전달용 공식 사진

Vera의 숫자는 데이터센터 CPU 경쟁을 직접 겨냥합니다. NVIDIA 제품 페이지는 Vera가 88개 NVIDIA 설계 Olympus 코어, 최대 176개 스레드, Armv9.2 호환성, 최대 1.2TB/s LPDDR5X 메모리 대역폭, 최대 1.5TB 메모리, 2세대 SCF, NVLink-C2C, confidential computing 지원을 갖춘다고 설명합니다. NVIDIA는 기존 CPU 인프라 대비 소프트웨어 환경을 최대 50% 빠르게 실행하고 에너지 효율은 2배라고 주장합니다. Vera CPU Rack은 최대 256개 Vera CPU로 2만2500개 이상의 동시 환경을 돌리는 구성을 내세웁니다.

이 사양에서 개발자가 먼저 볼 항목은 코어 수보다 메모리와 단일 스레드 성능입니다. 에이전트가 브라우저를 띄우고 테스트를 실행하고 Python 코드를 생성하며 결과 파일을 읽는 과정은 대형 행렬곱만으로 구성되지 않습니다. 작은 프로세스가 많이 생기고, 파일 시스템과 네트워크 호출이 얽히며, 도구 실행 결과를 다시 모델 컨텍스트로 넣는 제어 흐름이 반복됩니다. Vera가 "GPU를 먹여 살리는 CPU"가 아니라 "에이전트 실행 환경을 유지하는 CPU"로 포지셔닝되는 이유가 여기에 있습니다.

OpenAI와 Anthropic의 이름이 붙은 것도 단순한 레퍼런스 로고가 아닙니다. 두 회사 모두 2026년 들어 코딩 에이전트와 장기 실행 에이전트 사용량을 제품 전면에 두고 있습니다. Claude Code, Cowork, Codex, API 기반 도구 호출은 모두 모델 응답을 넘어 실제 실행 환경을 요구합니다. 에이전트가 저장소를 클론하고 테스트를 돌리고 로그를 읽는다면 GPU는 추론을 처리하지만, 그 사이의 프로세스 관리는 CPU와 운영체제 몫입니다. Vera의 첫 고객이 모델 연구소와 클라우드 사업자인 이유는 이 작업이 연구와 제품 운영 양쪽에서 동시에 커졌기 때문입니다.

OCI 발언은 이 시장의 규모를 더 노골적으로 보여줍니다. NVIDIA 블로그에서 OCI의 Karan Batta는 2026년부터 Vera CPU 수십만 개를 배치할 계획이라고 말했습니다. OCI는 Vera를 기업용 agentic AI 인프라의 고처리량 reasoning 워크로드에 맞춘 아키텍처로 설명했습니다. 이 숫자가 실제 구매, 배치 일정, 고객 워크로드로 어떻게 연결되는지는 별도 확인이 필요합니다. 그래도 "수십만 개 CPU"라는 단위는 Vera가 연구용 평가 키트가 아니라 AI 클라우드 공급망의 한 부품으로 들어가고 있음을 보여줍니다.

OpenAI Mission Bay 본사에서 진행된 NVIDIA Vera 시스템 전달 장면

Vera가 흥미로운 이유는 NVIDIA가 GPU 회사에서 CPU 회사로 단순 확장한다는 데 있지 않습니다. 이미 Grace CPU와 Grace Hopper 시스템이 있었고, 클라우드 사업자들도 Arm 기반 자체 CPU를 오래 운영했습니다. Vera의 차이는 NVIDIA가 Arm Neoverse 코어를 가져다 쓰는 대신 Olympus라는 자체 코어를 설계했다는 점입니다. Phoronix는 Vera가 Grace와 달리 NVIDIA 자체 Olympus 코어를 사용하고, Armv9.2 ISA, FP8, 176개 스레드, 2MB L2 캐시 per core, 164MB 통합 L3 캐시, PCIe Gen 6, CXL 3.1을 지원한다고 정리했습니다.

Phoronix가 2026년 5월 26일 공개한 초기 Linux 벤치마크는 이 발표에 숫자를 붙였습니다. Michael Larabel은 NVIDIA Santa Clara 본사에서 Vera 시스템을 테스트했고, 결론 페이지에서 허용된 여러 워크로드의 지오메트릭 평균 기준 Vera가 AMD EPYC 9575F 5.0GHz 고주파 프로세서보다 10% 높았다고 썼습니다. Grace 대비 1.63배, Intel Xeon 6980P 대비 1.55배라는 요약도 나왔습니다. 컴파일, Python, Java, ClickHouse, regex, 압축 같은 테스트에서 Vera는 기존 Arm 서버 CPU보다 훨씬 강한 모습을 보였습니다.

항목공식 주장과 초기 결과아직 확인할 부분
아키텍처88개 Olympus 코어, Armv9.2, 176개 스레드실제 서버 섀시별 클럭, 전력, 냉각 조건
메모리LPDDR5X 기반 최대 1.2TB/s 대역폭대규모 고객 워크로드의 지속 성능과 비용
초기 벤치마크Phoronix 지오메트릭 평균에서 EPYC 9575F 대비 10% 우위NVIDIA가 허용한 워크로드 범위, 전력·주파수 미공개
개발자 영향컴파일, Python, 샌드박스, 도구 실행에 맞춘 CPU 성능가격, 클라우드 접근성, hyperscaler 외 가용성

숫자는 강하지만, 같은 기사 안의 단서도 같이 읽어야 합니다. Phoronix는 NVIDIA가 이 초기 라운드에서 특정 워크로드만 허용했고, CPU 전력 소비와 주파수 모니터링을 허용하지 않았다고 밝혔습니다. 테스트 장비도 출시 전 open-platform 시스템이었고, 생산 서버 섀시의 전력 튜닝과는 다를 수 있습니다. 따라서 "Vera가 모든 서버 CPU를 이긴다"보다 "NVIDIA가 의도한 에이전트형 데이터센터 워크로드에서 x86 상위 제품과 경쟁 가능한 결과를 보였다"가 더 정확한 문장입니다.

이 단서는 커뮤니티 반응에서도 반복됐습니다. r/hardware와 Phoronix 댓글 흐름은 Vera 성능을 놀랍게 보면서도 NVIDIA가 고른 벤치마크, 전력 수치 부재, 실제 가격, AMD EPYC Venice 출시 시점, 일반 개발자가 접근할 수 있는지 여부를 함께 물었습니다. 일부 사용자는 Vera를 범용 서버 CPU라기보다 AI 서버 안에서 Python-heavy orchestration, agentic inference, RL 환경을 빠르게 돌리기 위한 특화 CPU로 해석했습니다. 이 반응은 발표의 약점을 찌르지만, 동시에 NVIDIA가 노리는 범위를 잘 짚습니다.

Linux 지원은 개발자에게 긍정적인 신호입니다. Phoronix는 Vera가 Device Tree 대신 ACPI를 사용하고 Arm 서버 표준을 따르며, 주요 AArch64 Linux 배포판에서 작동할 기반이 이미 갖춰졌다고 평가했습니다. GCC 16.1 이상과 LLVM Clang 21 이상에는 Olympus 코어 최적화 지원이 들어갔습니다. AI 서버가 빠르더라도 커널, 컴파일러, 드라이버, 배포판 지원이 늦으면 운영 비용이 올라갑니다. Vera는 출시 전부터 upstream 쪽 준비가 진행됐다는 점에서 Grace 시절보다 더 일반 서버 시장에 가까운 자세를 취합니다.

에이전트 개발팀 입장에서 Vera의 메시지는 모델 선택표 바깥에 있습니다. 지금 코딩 에이전트나 데이터 분석 에이전트를 운영하면 비용표는 대개 입력 토큰, 출력 토큰, GPU 추론, 저장소, 네트워크로 나뉩니다. 그러나 실제 장애는 다른 곳에서 납니다. 테스트가 느리고, 브라우저 샌드박스가 터지고, Python 패키지 설치가 오래 걸리고, 로그 수집이 누락되고, 여러 에이전트가 동시에 같은 워크스페이스를 건드리며 파일 잠금이 생깁니다. 이 문제들은 모델 품질보다 실행 환경의 CPU와 I/O, 격리 정책에 더 가깝습니다.

Vera가 강화학습과 agentic AI를 같이 말하는 것도 같은 이유입니다. RL 환경은 많은 병렬 시뮬레이션을 만들고, 평가 루프를 돌리고, 상태를 저장하고, 모델 업데이트와 추론 사이를 오갑니다. NVIDIA 제품 페이지는 Vera CPU Rack이 2만2500개 이상의 동시 환경을 실행할 수 있다고 설명합니다. 이 수치는 로봇 시뮬레이션, 코드 실행 평가, 에이전트 행동 평가처럼 "작은 환경을 매우 많이 돌리는" 워크로드를 겨냥합니다. GPU가 정책이나 모델을 계산하는 동안 CPU는 환경과 제어 흐름을 계속 밀어 넣어야 합니다.

KV 캐시 관리도 Vera가 겨냥한 CPU 작업으로 등장합니다. 장문 컨텍스트와 다중 턴 에이전트는 단순히 큰 모델 하나를 한 번 호출하는 구조가 아닙니다. 이전 대화, 파일 검색 결과, 도구 실행 결과, 생성한 코드, 테스트 로그가 계속 컨텍스트와 외부 저장소 사이를 오갑니다. NVIDIA는 Vera가 GPU를 계속 활용하도록 데이터 이동과 제어를 맡는다고 설명합니다. 이 설명을 과장 없이 읽으면, Vera는 LLM의 두뇌라기보다 AI 공장의 작업대와 컨베이어 역할을 노립니다.

클라우드 비용 관점에서는 OCI가 중요한 관찰 지점입니다. Vera가 개별 기업에 바로 팔리는 칩인지, OCI 같은 대형 클라우드와 AI 연구소를 통해 간접 제공되는 인프라인지에 따라 개발자 접근성이 달라집니다. Phoronix도 Vera의 가격과 hyperscaler, AI 회사, 대형 고객 밖 가용성이 큰 미지수라고 썼습니다. API 개발자에게 중요한 것은 칩 이름보다 인스턴스 타입, 시간당 가격, 예약 가능 지역, 네트워크와 스토리지 결합, 컨테이너 시작 시간입니다. Vera가 의미 있으려면 이 숫자들이 실제 제품으로 내려와야 합니다.

경쟁사는 AMD와 Intel만이 아닙니다. AMD EPYC와 Intel Xeon은 범용 서버 CPU의 직접 비교 대상입니다. 하지만 AI 에이전트 인프라에서는 AWS Graviton, Google과 Microsoft의 자체 Arm 서버, 데이터센터별 커스텀 CPU, 서버리스 샌드박스, GPU 클라우드의 orchestration 계층도 경쟁합니다. 개발자는 "Vera냐 EPYC냐"보다 "에이전트 1000개를 동시에 실행할 때 워크스페이스 생성, 패키지 설치, 테스트 실행, 로그 보존, 권한 격리가 얼마에 끝나는가"를 봅니다.

NVIDIA에는 이 경쟁을 묶을 수 있는 장점이 있습니다. Rubin GPU, BlueField DPU, Spectrum-X 네트워킹, MGX 랙 아키텍처, NVLink-C2C를 한 회사 로드맵 안에서 결합할 수 있습니다. 제품 페이지는 Vera와 Rubin이 unified memory architecture로 연결돼 GPU 활용률을 유지한다고 설명합니다. 이 통합은 고객 락인과 가격 협상력 문제를 만들 수 있지만, 대형 AI 연구소와 클라우드 사업자에게는 랙 단위 최적화라는 실무적 장점도 줍니다. 에이전트 워크로드가 커질수록 칩 하나보다 랙 전체의 지연시간과 전력, 냉각, 관측성이 중요해집니다.

한국 AI 개발팀이 지금 당장 Vera를 구매할 가능성은 높지 않습니다. 대신 이 뉴스는 인프라 체크리스트를 바꿉니다. 에이전트 제품을 만들 때 모델 API만 비교하지 말고 실행 환경의 CPU 시간, 컨테이너 시작 시간, 파일 I/O, 테스트 실행 시간, 패키지 캐시, 로그 보존, sandbox reset 비용을 함께 측정해야 합니다. 모델이 빠른데 도구 실행이 느리면 사용자는 "AI가 느리다"고 느낍니다. 그 지연의 상당 부분은 토큰 생성이 아니라 GPU 밖의 시스템 호출에서 생깁니다.

보안 관점에서도 CPU는 부차적인 부품이 아닙니다. 에이전트가 코드를 실행하고 네트워크를 호출하는 순간, 격리와 권한, 감사 로그가 실행 환경에 들어갑니다. Anthropic이 최근 Claude 제품군의 containment를 공개하며 VM 격리와 egress 제어를 설명한 것도 같은 배경입니다. Vera가 confidential computing과 서버 표준을 내세우는 이유는 AI 실행 환경이 더 민감한 권한을 갖게 되기 때문입니다. 빠른 CPU가 필요한 작업과 안전한 CPU 격리가 필요한 작업은 같은 샌드박스 안에서 만납니다.

이번 발표를 과대평가하지 않으려면 세 가지를 남겨야 합니다. 첫째, Phoronix 결과는 초기 벤치마크이며 전력과 주파수 데이터가 비어 있습니다. 둘째, 실제 고객이 Vera를 어떤 워크로드에 얼마나 배치하는지는 2026년 하반기 ramp와 클라우드 인스턴스 공개를 봐야 합니다. 셋째, AMD EPYC Venice와 Intel 차세대 Xeon이 나오면 범용 CPU 비교표는 다시 바뀔 수 있습니다. Vera의 강점은 "모든 서버 작업"보다 에이전트 실행, RL 환경, AI factory control plane에 있습니다.

그래도 Vera의 첫 출하는 AI 인프라 논의에서 한 가지 기준선을 움직입니다. 에이전트가 답변 생성기를 넘어 작업 실행기로 바뀌면, 병목은 모델 추론과 GPU 메모리에만 머물지 않습니다. CPU는 코드 컴파일, Python, 브라우저, 데이터베이스, regex, 파일 검색, 네트워크 정책, 샌드박스 수명주기를 맡습니다. OpenAI와 Anthropic이 받은 Vera 시스템은 그 병목을 NVIDIA가 별도 시장으로 본다는 물증입니다.

개발자에게 남는 실무 질문은 단순합니다. 지금 운영 중인 에이전트의 대기 시간이 모델 호출 때문인지, 도구 실행 때문인지, 샌드박스 준비 때문인지, 로그와 파일 I/O 때문인지 나눠서 측정하고 있습니까. Vera가 성공하면 클라우드 사업자는 이 질문에 맞춘 새 인스턴스와 가격표를 내놓을 것입니다. 실패하더라도 같은 질문은 사라지지 않습니다. 에이전트 제품의 체감 속도는 GPU 밖 실행 환경에서 이미 상당 부분 결정되고 있기 때문입니다.