AMD Helios란? GPU 72개와 31TB HBM4로 NVIDIA Rubin에 도전하다
AMD가 2026년 7월 23일 Helios를 공개했습니다. Instinct MI455X GPU 72개와 HBM4 31TB를 한 랙에 담고, 랙 내부에는 260TB/s의 scale-up 네트워크를 구성했습니다. 숫자와 형태 모두 NVIDIA Vera Rubin NVL72를 정면으로 겨냥합니다.
AMD는 이번에 개별 GPU를 넘어 랙 전체를 하나의 제품으로 제시했습니다. GPU와 CPU뿐 아니라 랙 내부 네트워크, 전력 분배, 액체냉각과 소프트웨어까지 한 설계에 담았습니다. NVIDIA가 NVL72로 선점한 랙 스케일 AI 시스템 시장에 직접 비교할 만한 구성을 내놓은 셈입니다.
다만 AMD가 발표한 FP4 15% 우위와 tokens/$ 최대 30% 우위만으로 승자를 정하기에는 이릅니다. 두 수치는 서로 다른 FP4 형식의 이론 성능과 AMD가 추정한 처리량·가격을 바탕으로 계산됐습니다. 먼저 공식 사양끼리 비교하고, 이어서 두 성능 주장의 계산 조건을 확인하겠습니다.
GPU 72개를 하나의 시스템처럼 묶는다
Helios는 MI455X GPU 72개와 CPU, 네트워크, 전력과 냉각을 함께 구성한 AMD의 첫 랙 스케일 AI 설계입니다. Meta가 Open Compute Project에 제안한 Open Rack Wide 규격을 따르며, OEM과 ODM은 이 설계를 바탕으로 시스템을 제작하거나 구성을 바꿀 수 있습니다.
랙 하나에는 컴퓨트 트레이 18개가 들어갑니다. 트레이마다 MI455X GPU 4개와 6세대 EPYC Venice CPU 1개가 실리므로 랙 전체는 GPU 72개와 CPU 18개로 구성됩니다. GPU 사이의 scale-up 통신은 스위치 트레이 6개가 맡습니다. 외부 네트워크용 Pensando NIC, 전력 선반과 냉각 매니폴드도 랙에 포함됩니다. MI455X와 스위치 트레이는 직접 액체냉각(DLC)으로 식힙니다.
대형 AI 모델은 가중치와 연산을 여러 GPU에 나눕니다. GPU가 계산을 마칠 때마다 중간 결과를 주고받아야 하므로 GPU 수만 늘려서는 성능이 비례해 오르지 않습니다. 통신이 늦으면 나머지 GPU가 기다리고, 전력이나 냉각이 부족하면 최대 성능을 오래 유지하기 어렵습니다. 랙 스케일 설계는 이 연결과 운영 조건까지 미리 맞춘 하나의 배포 단위입니다.
Vera Rubin NVL72와 직접 비교되는 사양
Helios와 Vera Rubin NVL72는 모두 GPU 72개를 한 랙에 묶습니다. 공식 사양에서 같은 단위로 비교할 수 있는 항목은 HBM4 용량과 대역폭, 랙 내부 scale-up 대역폭입니다.
| 항목 | AMD Helios | NVIDIA Vera Rubin NVL72 |
|---|---|---|
| GPU | Instinct MI455X 72개 | Rubin GPU 72개 |
| GPU당 HBM4 | 432GB | 288GB |
| 랙 전체 HBM4 | 약 31.1TB | 20.7TB |
| GPU당 HBM4 대역폭 | 23.3TB/s | 22TB/s |
| 랙 전체 HBM4 대역폭 | 약 1.68PB/s | 1.58PB/s |
| 랙 내부 scale-up 대역폭 | 260TB/s | 260TB/s |
| scale-up 연결 | UALink over Ethernet | NVLink 6 |
2026년 8월 4일 AMD Helios·MI455X와 NVIDIA Vera Rubin NVL72 공식 사양 기준입니다. NVIDIA는 Rubin 사양을 예비 정보로 표시하고 있습니다. 랙 전체 HBM 대역폭은 GPU당 수치에 72를 곱한 값입니다.
가장 분명한 차이는 HBM4 31TB다
MI455X 한 개에는 HBM4 432GB가 들어갑니다. Rubin GPU의 288GB보다 50% 큽니다. 같은 72개를 묶으면 Helios는 약 31.1TB, Vera Rubin NVL72는 20.7TB의 GPU 메모리를 갖습니다.
Helios가 더 확보한 약 10.4TB는 모델 가중치, KV 캐시와 연산용 메모리에 사용할 수 있습니다. 가중치가 GPU 메모리에 들어가지 않으면 더 많은 랙에 모델을 나누거나, 정밀도를 낮추거나, 일부 데이터를 시스템 메모리와 스토리지에서 가져와야 합니다. 어느 방법이든 통신과 데이터 이동이 늘어날 수 있습니다. 랙 하나의 HBM이 클수록 같은 모델을 더 여유 있게 배치할 수 있습니다.
추론에서는 요청마다 KV 캐시가 생깁니다. 입력 문맥이 길수록 캐시가 커지고, 동시에 처리하는 요청이 많으면 각 요청의 캐시가 함께 쌓입니다. HBM 31TB는 긴 문맥과 높은 동시성을 수용할 여지를 넓혀 줍니다. 실제 수용량은 모델 구조, 캐시 정밀도, 서빙 엔진과 목표 응답시간에 따라 달라집니다.
HBM 31TB는 72개 GPU에 나뉘어 있습니다. 모델과 KV 캐시도 GPU별로 배치해야 합니다. Tensor parallelism이나 expert parallelism을 어떻게 구성하는지에 따라 GPU 사이 통신량이 달라집니다. 큰 메모리와 빠른 인터커넥트가 함께 필요한 이유입니다.
AMD의 15%와 30%는 어떤 조건에서 나왔나
AMD는 Helios가 경쟁 시스템보다 FP4 이론 성능이 15% 높다고 발표했습니다. 이때 기준이 된 GPU당 이론 최고치는 MI455X의 OCP MXFP4 40.3PFLOPS와 Rubin GPU의 NVFP4 Dense Training 35PFLOPS입니다. 랙 전체로 환산하면 약 2.9EFLOPS와 2.52EFLOPS입니다.
NVIDIA는 같은 Rubin GPU에 NVFP4 Inference 50PFLOPS를 별도로 제시합니다. OCP MXFP4와 NVFP4는 형식이 다르고, NVIDIA의 학습·추론 수치도 구분돼 있습니다. 따라서 AMD의 15%를 모든 FP4 추론에서 Helios가 더 빠르다는 뜻으로 넓혀 읽을 수는 없습니다. 이 수치는 특정 데이터 형식의 이론 최고치를 비교한 결과입니다.
최대 30% 더 높은 tokens/$에도 조건이 붙습니다. AMD는 Kimi K2 Thinking을 입력 32K·출력 8K로 실행할 때를 가정했습니다. 응답 속도 목표별 처리량은 모델링으로 추정했고, 비용에는 2026년 7월 시장 상황을 반영한 시간당 GPU 예상 가격을 넣었습니다. 따라서 30%는 두 랙을 같은 환경에서 측정한 실측값이 아니라 AMD가 계산한 추정치입니다.
도입 검토에서는 같은 모델과 정밀도, 서빙 엔진, 입력·출력 길이와 응답시간 목표를 맞춰야 합니다. 여기에 랙 전력과 냉각 전력, 장비 가격까지 넣어야 실제 tokens/$가 나옵니다. AMD가 제시한 30%를 다른 모델과 트래픽 조건에 그대로 적용할 수 없는 이유입니다.
260TB/s를 만드는 방식은 서로 다르다
Scale-up은 한 랙 안의 GPU를 묶는 연결입니다. 하나의 모델을 여러 GPU에 나눌 때 중간 결과를 옮기며, MoE 모델에서는 expert 사이의 통신도 처리합니다. Scale-out은 여러 랙을 연결해 더 큰 학습·추론 클러스터를 만드는 네트워크입니다.
Vera Rubin NVL72는 랙 안에서 NVIDIA의 NVLink 6를 사용합니다. Helios는 UALink over Ethernet, 줄여서 UALoE로 72개 MI455X를 연결합니다. 두 회사가 발표한 랙 전체 scale-up 대역폭은 모두 260TB/s입니다.
UALink는 가속기끼리 메모리를 직접 읽고 쓰며 atomic operation을 수행하도록 만든 개방형 scale-up 규격입니다. Helios에는 일반적인 서버 LAN 대신 랙 내부 통신을 위한 전용 UALoE 스위치 트레이가 들어갑니다. AMD는 72개 GPU를 one-hop 구조로 연결하고, 일부 경로에 장애가 생겨도 통신을 이어갈 수 있도록 여러 경로를 마련했습니다.
NVLink가 NVIDIA GPU와 스위치, 소프트웨어를 수직으로 통합한다면 UALink는 여러 가속기와 시스템 업체가 참여할 수 있는 공통 규격을 지향합니다. Helios도 Open Rack Wide, UALink와 Ultra Ethernet Consortium 계열 규격을 설계의 중심에 두었습니다. 호환 제품이 충분히 공급되면 사용자는 한 회사 밖에서도 랙과 네트워크 장비를 선택할 수 있습니다.
다만 규격이 열려 있다는 사실만으로 모든 부품이 곧바로 호환되지는 않습니다. ROCm, 집합 통신 라이브러리, fabric manager와 장애 복구까지 실제 구성으로 검증해야 합니다. Helios의 개방성이 시장의 선택지로 자리 잡을지는 하드웨어 공급과 소프트웨어 성숙도가 함께 결정합니다.
한국에서는 이종 AI 인프라의 흐름을 볼 수 있다
Helios 발표 나흘 뒤 AMD와 과학기술정보통신부는 한국의 소버린 AI 생태계를 위한 전략적 협력을 발표했습니다. 양측은 AMD CPU·GPU와 국내 NPU를 함께 쓰는 개방형 이종 AI 인프라, 소프트웨어, 연구와 인재 양성을 협력 범위로 제시했습니다. AMD는 한국에 AI 연구·협력 거점인 Center of Excellence를 세우는 계획도 밝혔습니다.
발표문은 협력의 방향을 담았으며 구체적인 Helios 장비 수량이나 구축 일정은 제시하지 않았습니다. 현재 확인되는 구상은 단일 공급업체에 묶이지 않고 AMD GPU와 국내 NPU를 워크로드에 맞춰 조합하는 것입니다.
이종 인프라는 가속기를 여러 종류 구매하는 데서 끝나지 않습니다. 각 모델이 지원되는지 확인하고, 서로 다른 장비에 워크로드를 배치할 기준을 정해야 합니다. 네트워크와 스토리지, 전력과 냉각도 장비별 요구조건에 맞춰야 합니다. Helios의 개방형 랙 설계와 이번 한·AMD 협력은 AI 인프라 경쟁이 GPU 한 종류의 성능에서 전체 시스템의 선택과 통합으로 넓어지고 있음을 보여 줍니다.
이제 AMD도 랙 단위로 경쟁한다
Helios는 AMD가 NVIDIA NVL72와 같은 단위에서 내놓은 첫 본격적인 답입니다. 72개 GPU, 260TB/s scale-up과 직접 액체냉각이라는 뼈대는 닮았습니다. GPU당 432GB, 랙당 31TB의 HBM4와 UALoE 기반의 개방형 설계는 분명한 차이입니다.
어느 쪽이 더 빠르고 경제적인지는 실제 서비스 조건의 독립적인 측정이 쌓여야 판단할 수 있습니다. 지금 확인할 수 있는 변화는 NVL72와 같은 제품 단위에 개방형 대안이 등장했다는 점입니다. 대형 AI 시스템을 검토하는 조직은 모델과 소프트웨어 생태계, 메모리, 네트워크, 전력과 냉각을 묶어 비교할 수 있게 됐습니다.
매니코어소프트는 GPU와 NPU를 함께 쓰는 AI/HPC 인프라를 서버, 네트워크, 스토리지, 액체냉각과 운영 소프트웨어까지 묶어 설계하고 구축합니다. 이종 가속기를 어떤 규모로 구성할지, 현재 시설에서 전력과 냉각을 어떻게 마련할지 검토하고 있다면 AI 인프라 구축·협업 문의로 목표 워크로드와 규모를 알려 주세요. 장비를 정하기 전에 확인할 조건부터 함께 정리하겠습니다.