AI VIDEO BRIEFING

엔비디아 베라 CPU: AI 에이전트의 다음 병목은 GPU가 아니라 CPU인가, 벤치마크의 한계까지

에이전트가 테스트를 돌리는 동안 GPU는 이미 할 일을 끝냈습니다. 엔비디아가 내놓은 ARM 기반 CPU 베라와 벤치마크의 한계, 네트워크 지연 문제를 짚었습니다. 코어를 늘려도 임계 경로는 줄지 않는다는 암달의 법칙이 핵심입니다.

에이전트가 기다리는 것은 GPU가 아니다, 엔비디아가 CPU를 꺼낸 이유 영상 대표 이미지

핵심 메시지

  • 챗봇은 모델 안에서 끝나지만 에이전트는 코드를 실행하고 결과를 되돌려 받는 루프를 수십에서 수백 번 반복하며, 그 사이 세계를 굴리는 것은 GPU가 아니라 CPU다.
  • 엔비디아는 이 구간을 임계 경로로 규정하고 ARM 기반 CPU 베라를 '에이전트 시대의 CPU'로 내세웠다. 올림푸스 코어 88개에 스레드 176개, 메모리 대역폭 최대 1.2TB/s 구성이다.
  • 코어를 늘리면 병렬화 가능한 일은 빨라지지만 다음 단계가 앞 단계 결과에 의존하면 코어 수로 해결되지 않는다. 암달의 법칙이 여전히 상한을 정한다.
  • 엔비디아 자체 수치는 에이전트 실행 워크로드에서 x86 대비 코어당 지속 성능 1.8배, 퍼플렉시티 코딩 워크플로에서 1.5배, 샌드박스 동시 실행 시 1.9배지만 모두 CPU 병목 작업에 한정된 결과다.
  • CPU와 GPU가 같은 시스템에 붙는 구성과 별도 랙으로 떨어지는 구성에서 지연 특성이 달라지므로, 빠른 CPU 하나가 빠른 에이전트를 보장하지는 않는다.

쉽게 이해하기

에이전트가 '테스트 실행 중'이라는 메시지를 띄우고 멈춰 있을 때, 실제로는 격리된 환경이 뜨고 프로젝트가 로드되고 코드가 실행되며 무엇이 깨지는지 확인되는 중입니다. 이 지연은 GPU와 거의 관계가 없습니다. GPU는 이미 할 일을 끝냈고 에이전트는 CPU를 기다리고 있습니다. 지난 몇 년의 질문이 'AI가 얼마나 빨리 답을 만드는가'였다면, 에이전트는 'AI가 그 답에 도달하기 위한 일을 얼마나 빨리 해내는가'라는 다른 질문을 던집니다.

챗봇은 모델을 한 번 호출하면 끝나지만 코딩 에이전트는 결정하고 실행하고 결과를 되돌려 받는 루프를 수십에서 수백 번 지나갑니다. 여기서 임계 경로라는 개념이 등장하는데, 패치를 쓴 에이전트는 테스트가 끝나기 전에 결과를 볼 수 없고 오류가 나타나기 전에 고칠 수 없습니다. 일부는 겹칠 수 있어도 의존적인 단계의 사슬은 남고, 한 단계에서 0.5초를 아끼는 것이 사소해 보여도 루프가 반복되면 누적되어 모델은 빠른데 에이전트는 이상하게 느리다고 느껴집니다.

'요즘 프로그램은 멀티스레드가 아니냐'는 반론에 대해 진행자는 원래 자기 주장을 정정합니다. 하나의 에이전트도 여러 코어로 독립적인 도구나 테스트를 동시에 돌릴 수 있습니다. 다만 다음 단계가 현재 단계의 결과에 의존하면 코어를 늘려도 그 의존은 사라지지 않고, 병렬화되지 않는 구간이 결국 상한을 정한다는 암달의 법칙이 남습니다. 요리사를 아홉 명 붙여도 달걀 하나를 10초에 삶을 수는 없다는 비유가 이어집니다.

그래서 베라가 내세우는 것은 단순한 단일 스레드 성능이 아니라 '규모에서의 최대 단일 스레드 성능', 즉 프로세서 전체가 수많은 에이전트로 바쁠 때에도 개별 코어가 빠르게 유지되는 것입니다. 구성은 ARM 명령어 집합 기반으로 엔비디아가 직접 설계한 올림푸스 코어 88개에 코어당 2스레드, 총 176스레드이며, 코어 수 경쟁 대신 데이터 공급에 초점을 맞춰 최대 1.2TB/s 메모리 대역폭과 단일 다이·고속 내부 패브릭을 택했습니다. 사이클당 명령 처리량은 이전 세대 그레이스보다 최대 50% 높다고 밝혔지만, 이것이 모든 애플리케이션이 50% 빨라진다는 뜻은 아닙니다. 다만 코드 조각 사이를 뛰어다니고 예측하기 어려운 분기를 따라가는 에이전트 소프트웨어의 지저분한 성격이 올림푸스가 겨냥한 작업 유형과 맞습니다.

수치는 검증의 한계와 함께 제시됩니다. 엔비디아는 x86 대비 코어당 지속 성능 1.8배를, 퍼플렉시티는 코딩 워크플로에서 약 1.5배와 샌드박스 동시 실행 시 1.9배를 보고했고, 초기 외부 테스트에서는 AMD의 고주파 EPYC 제품보다 약 10% 앞섰지만 모두 '엔비디아가 허용한 워크로드' 범위였습니다. ARM 이전 비용은 실재하지만 베라가 겨냥하는 곳은 소프트웨어 환경을 스스로 통제하는 신규 AI 인프라여서, 초기 시스템이 오픈AI·앤스로픽·스페이스X·오라클에 전달되고 오라클은 수십만 개 배치를 계획한다고 합니다. 결국 이 발표는 CPU 하나의 이야기가 아니라, 비싼 GPU가 CPU를 기다리지 않게 만들어 플랫폼 전체로 영역을 넓히는 움직임이며, 병목은 워크플로에 따라 옮겨 다니므로 이제 AI 성능을 모델이나 GPU만 보고 이해할 수 없다는 것이 요지입니다.

주요 인사이트

  • 에이전트 시대의 성능 지표는 초당 토큰이 아니라 루프 한 바퀴의 지연이다. 모델이 아무리 빨라도 도구 실행과 결과 회수가 느리면 사용자가 체감하는 속도는 개선되지 않는다.
  • '규모에서의 단일 스레드 성능'이라는 표현은 마케팅이 아니라 설계 제약의 선언이다. 수천 개 샌드박스가 동시에 도는 환경에서 개별 코어의 응답성을 유지하려면 빠른 코어만으로는 부족하고 이를 먹일 메모리 시스템이 필요하다.
  • 벤더가 제시한 배수는 그 벤더가 가속하도록 설계한 워크로드에서 측정된 값이다. 제약 없는 표준 벤치마크와 전력·가격, 그리고 모델 호출 사이 구간 전체를 측정한 수치가 나오기 전까지는 범주의 신설로 보기 어렵다.
  • ARM 이전 비용은 신규 인프라에서는 장벽이 아니라 선택 사항이 된다. 엔비디아가 기존 엔터프라이즈 전체가 아니라 소프트웨어 환경을 통제하는 소수의 대형 고객만 필요하다는 점이 이 전략의 핵심이다.
  • 토폴로지가 성능의 일부다. CPU, GPU, 메모리, 네트워크가 서로를 기다리지 않도록 시스템 전체를 설계해야 하며, 고립된 상태에서 빠른 CPU가 빠른 에이전트를 보장하지는 않는다.

자주 묻는 질문

에이전트가 느려지는 원인이 GPU가 아니라는 근거는 무엇인가요?

모델이 결정을 내린 뒤 코드를 실행하고 샌드박스를 띄우고 결과를 되돌려 받는 구간은 GPU가 아니라 주변 컴퓨터, 즉 CPU가 담당합니다. 코딩 에이전트는 이 루프를 수십에서 수백 번 반복하므로 한 단계의 작은 지연이 누적되어 전체 작업 시간을 지배하게 됩니다.

코어 수를 늘리면 해결되는 문제가 아닌가요?

하나의 에이전트도 여러 코어를 써서 독립적인 도구나 테스트를 동시에 돌릴 수 있어 부분적으로는 빨라집니다. 다만 다음 단계가 현재 단계의 결과에 의존하면 코어를 늘려도 그 의존은 사라지지 않고, 병렬화되지 않는 구간이 속도 향상의 상한을 정합니다.

공개된 성능 수치는 얼마나 신뢰할 수 있나요?

엔비디아는 에이전트 실행 워크로드에서 x86 대비 코어당 지속 성능 1.8배, 퍼플렉시티는 코딩 워크플로에서 약 1.5배와 샌드박스 동시 실행 시 1.9배를 보고했습니다. 모두 베라가 가속하도록 설계된 CPU 병목 작업이며, 초기 외부 테스트도 엔비디아가 허용한 워크로드 범위에서만 이뤄졌습니다.

ARM 기반이라는 점이 걸림돌이 되지 않을까요?

x86용 바이너리와 컨테이너 이미지, 네이티브 의존성을 다시 빌드해야 하므로 오래된 엔터프라이즈 시스템에서는 비용이 큽니다. 다만 겨냥하는 대상은 소프트웨어 환경을 스스로 통제하는 신규 AI 인프라와 클라우드 업체여서, 시장 전체가 아니라 대형 고객 몇 곳만 움직여도 사업이 성립한다는 계산입니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식