top of page

AMD와 Google의 표준 베팅, Helios를 Nvidia AI 랙의 맞수로 부상시키다

AMD가 72-GPU 랙 스케일 AI 설계인 Helios를 출시했으며, AMD와 Google의 표준 연계는 단순한 사양 이상의 무게를 Nvidia 도전에 더한다.

Helios는 AMD Instinct MI455X 가속기, EPYC “Venice” CPU, Pensando 네트워킹, ROCm 소프트웨어를 하나의 수랭식 시스템에 결합한다. 출하는 2026년 3분기 말까지 시작될 것으로 예상된다.

바로 이 시점이 실질적인 경쟁 구도를 만든다. AMD는 Nvidia가 이미 다음 플랫폼으로 넘어간 뒤 또 다른 가속기를 내놓는 것이 아니다. 같은 도입 주기에 Nvidia Vera Rubin NVL72와 맞붙겠다는 계획이다.

Google의 역할은 신중하게 정의할 필요가 있다. Google은 Helios 구매자로 발표된 바 없다. 다만 AMD 시스템 내부에 쓰이는 개방형 가속기 인터커넥트인 UALink의 구축을 도왔다.

이 구분은 중요하다. Helios는 Nvidia의 하드웨어뿐 아니라 엄격히 통제된 인프라 모델에 대한 AMD의 대응이기 때문이다. AMD는 구매자를 단일 공급업체의 완전한 기술 스택에 묶어 두지 않고도 개방형 표준이 경쟁력 있는 랙을 뒷받침할 수 있다고 베팅한다.

비교 결과는 아직 정해지지 않았다. AMD가 공개한 수치는 최고 성능, 메모리, 네트워크 용량을 설명하지만, 애플리케이션 성능, 가용성, 신뢰성, 운영 비용은 고객 배치 환경에서 판가름 날 것이다.

따라서 Helios는 단순히 더 빠른 가속기 출시를 뜻하지 않는다. Nvidia의 최대 우위가 더 뛰어난 칩에서 나오는지, 아니면 수천 개 칩이 함께 작동하는 방식을 통제하는 데서 나오는지를 시험한다.

AMD와 Google의 표준, 하나의 시스템에 72개 GPU를 담다

Helios는 AMD의 경쟁 단위를 개별 가속기에서 통합 AI 랙으로 바꾼다.

AMD는 2026년 7월 23일 MI455X를 공식 출시하고 Helios를 생산 단계로 전환했다. Helios specifications에 따르면 72개의 MI455X GPU는 Ethernet 기반 UALink로 연결된다.

랙 스케일 시스템은 랙 전체를 하나의 협조된 컴퓨터로 다룬다. CPU, 가속기, 메모리, 네트워킹, 냉각, 전력 공급, 소프트웨어는 공통의 운영 목표를 중심으로 설계된다.

이 접근법은 독립 GPU 서버를 조립한 뒤 외부 네트워크로 연결하는 방식과 다르다. 기존 서버는 각각 자체 메모리를 제어하므로, 워크로드가 서버 경계를 넘을 때 추가 통신 단계가 발생한다.

반면 Helios는 72개 가속기를 하나의 스케일업 도메인으로 구성한다. 스케일업 네트워킹은 하나의 작업을 수행하는 가속기들을 연결하고, 스케일아웃 네트워킹은 더 큰 클러스터에서 여러 랙을 연결한다.

AMD는 Helios 시스템 하나가 최고 FP4 연산 성능 2.9 엑사FLOPS와 FP8 기준 1.4 엑사FLOPS를 제공한다고 말한다. 이 저정밀 형식은 AI 계산에 사용되는 데이터를 줄여, 모델이 해당 압축을 허용할 때 처리량을 높인다.

설계에는 각 가속기 가까이에 배치되는 고대역폭 메모리인 HBM4 31테라바이트가 포함된다. AMD는 스케일업 총대역폭을 초당 260테라바이트, 스케일아웃 대역폭을 초당 43테라바이트로 제시한다.

MI455X accelerator는 HBM4 432기가바이트와 초당 23.3테라바이트의 메모리 대역폭을 제공한다. AMD의 5세대 CDNA 아키텍처와 칩렛 기반 패키지를 사용한다.

이 수치들은 막대한 메모리 용량과 가속기 간 빈번한 통신이 필요한 모델을 겨냥한다. 프런티어 모델 학습이 한 사례지만, 긴 컨텍스트 추론과 멀티에이전트 워크로드 역시 메모리와 네트워크 용량에 부담을 줄 수 있다.

AMD는 Meta와 Open Compute Project를 통해 도입된 더블와이드 설계인 Open Rack Wide 폼팩터를 중심으로 Helios를 구축했다. 추가 폭은 수랭식 냉각, 더 높은 전력 공급, 넓은 컴퓨팅 트레이, 용이한 부품 접근을 지원한다.

Helios는 AMD가 직접 완성 랙으로 판매하는 제품이 아니라 레퍼런스 설계이기도 하다. OEM 및 ODM 업체가 이 청사진을 바탕으로 시스템을 구축하므로, 다양한 구성과 공급업체가 참여할 여지가 생긴다.

이 모델은 AMD와 Google의 표준 전략을 Nvidia의 접근법과 구분한다. Google은 UALink 구축에 참여했지만, 이 표준은 AMD, Meta, Microsoft, Intel 등을 포함한 더 폭넓은 업계 그룹에 속한다.

공유 표준은 Nvidia의 독점 NVLink 패브릭에 대한 대안을 만드는 것을 목표로 한다. 참여 기업들은 단일 칩 제조업체가 모든 인터페이스를 통제하지 않아도 가속기, 스위치, 주변 인프라가 발전할 수 있기를 바란다.

개방성이 자동으로 더 빠르고, 저렴하고, 쉬운 것을 뜻하지는 않는다. 하지만 하이퍼스케일러와 장비 제조업체에 부품 선택과 향후 업그레이드에 대한 더 큰 영향력을 제공한다.

AMD에게 이 개방성은 전략적 문제도 해결한다. 회사가 Nvidia의 구축된 소프트웨어 및 네트워킹 기반을 하룻밤 사이에 재현할 수는 없지만, 다른 인프라 경로를 원하는 파트너를 모을 수는 있다.

Helios는 이 연합을 물리적 시스템으로 구현한다. 남은 질문은 이 연합이 데이터센터 규모에서 일관된 시스템을 제공할 수 있는지다.

Helios, 랙 수준에서 Nvidia를 압박하다

Nvidia는 이제 Vera Rubin과 동일한 구매 주기, 시스템 규모, 프런티어 워크로드를 겨냥한 AMD 플랫폼에 맞서게 됐다.

AMD는 수년간 Nvidia 가속기와 경쟁하면서 메모리 용량, 공급 가능성, 또는 가치에 자주 초점을 맞췄다. 하지만 Nvidia는 일반적으로 AMD 제품이 비슷한 수준의 배치에 도달하기 전에 플랫폼 의제를 정했다.

Helios는 이 주기를 바꾼다. AMD는 두 플랫폼이 2026년 후반 고객 설치를 준비하는 가운데, Helios를 Vera Rubin NVL72의 경쟁 상대로 포지셔닝하고 있다.

이 시점은 AMD의 제안에서 익숙한 약점 하나를 제거한다. 구매자가 경쟁 세대의 시설, 전력, 네트워킹, 소프트웨어에 투자하기 전에 평가할 수 있을 때 경쟁력 있는 사양은 더 큰 의미를 갖는다.

목표는 Nvidia의 풀스택 우위다. Nvidia는 단지 GPU만 판매하지 않는다. 프로세서, NVLink 스위치, 네트워크 어댑터, 소프트웨어 라이브러리, 개발 도구, 검증된 서버 설계를 결합한다.

CUDA는 그 우위의 핵심으로 남아 있다. 수년간의 프로덕션 사용을 통해 구축된 성숙한 프로그래밍 플랫폼, 최적화 라이브러리, 광범위한 문서를 개발자에게 제공한다.

GPU 컴퓨팅을 위한 AMD의 개방형 소프트웨어 플랫폼인 ROCm은 프레임워크와 대규모 모델 워크로드 전반에서 개선돼 왔다. 그러나 호환성 주장이 프로덕션 소프트웨어를 튜닝하고 장애를 진단하는 데 필요한 엔지니어링 작업까지 없애지는 않는다.

Nvidia는 조직적 친숙성의 혜택도 받는다. 클라우드 운영자, AI 연구소, 기업 팀은 이미 Nvidia 시스템을 프로비저닝하고, 워크로드를 모니터링하며, 경험 있는 엔지니어를 찾는 방법을 알고 있다.

따라서 AMD는 두 수준에서 승리해야 한다. 경쟁력 있는 하드웨어가 필요하고, 덜 확립된 랙 스케일 플랫폼 도입에 따른 운영 위험을 낮춰야 한다.

회사의 공개 비교는 첫 번째 요건을 직접 겨냥한다. AMD는 Helios가 Vera Rubin NVL72보다 최고 FP4 연산 성능이 15% 높다고 주장한다.

AMD는 또한 HBM 용량이 50% 더 많고, HBM 대역폭은 6% 더 높으며, 스케일아웃 대역폭은 50% 더 크다고 주장한다. 이 결과는 독립적인 프로덕션 벤치마크가 아니라 AMD의 계산과 모델링에 기반한다.

이 단서는 필수적이다. 최고 부동소수점 처리량은 이론적 상한을 설명할 뿐이며, 실제 모델 성능은 메모리 접근, 통신, 커널, 소프트웨어, 워크로드 설계에 따라 달라진다.

Nvidia 역시 일부 추론 워크로드에 적응형 압축을 사용한다. 모델이 해당 데이터 형식과 소프트웨어 경로를 수용할 경우, 이 기능은 비교 결과를 바꿀 수 있다.

물리적 비교에는 또 다른 절충점도 있다. Helios는 폭 약 1.2미터의 더블와이드 랙을 사용하는 반면, Nvidia의 NVL72 설계는 더 좁은 공간에 72개 GPU를 담는다.

AMD는 추가 공간을 전력, 냉각, 네트워킹, 정비 가능한 컴퓨팅 트레이에 사용한다. 구매자는 이러한 운영상 이점이 기존 시설에서의 낮은 랙 밀도를 상쇄하는지 판단해야 한다.

그 판단은 데이터센터마다 달라질 것이다. 신규 AI 캠퍼스는 Open Rack Wide를 중심으로 바닥 설계를 할 수 있지만, 오래된 시설은 상당한 공간, 냉각, 전력 개조가 필요할 수 있다.

Helios가 이제 신뢰할 수 있는 시스템 수준 대안을 제시하기 때문에 Nvidia는 압박을 받는다. Helios가 협상, 로드맵, 조달 결정에 영향을 주기 위해 CUDA를 모든 곳에서 대체할 필요는 없다.

두 번째로 검증된 공급업체는 구매자에게 공급 가능성, 구성, 지원 조건, 향후 인프라 통제권에 대한 협상력을 제공할 수 있다. 또한 단일 공급업체의 연간 제품 일정에 대한 의존도를 줄일 수 있다.

AMD와 Google의 관계는 바로 이 구조적 수준에서 가장 큰 의미를 갖는다. Google의 UALink 참여는 공개된 Helios 구매가 없더라도 이 인터커넥트를 진정한 업계 공동 노력으로 만드는 데 도움이 된다.

Nvidia는 여전히 가장 성숙한 통합 스택을 통제한다. Helios는 통합이 곧 한 벤더에 대한 의존을 뜻해야 한다는 생각에 도전함으로써 그 위치를 압박한다.

진짜 경쟁은 개방형 패브릭과 Nvidia의 통제력 사이에 있다

Helios는 개방형 인터페이스가 Nvidia의 수직 통합 시스템만큼 안정적으로 랙을 조율할 수 있을 때에만 성공한다.

AMD의 핵심 메커니즘은 하나의 탁월한 칩이 아니다. 여러 벤더가 구현할 수 있는 표준을 통해 프로세서, 메모리, 네트워킹, 냉각, 펌웨어, 소프트웨어를 조율하는 방식이다.

Helios 내부에서는 Ethernet 기반 UALink가 스케일업 도메인의 가속기를 연결한다. Ultra Ethernet은 클러스터 전체에서 랙을 연결하는 더 넓은 스케일아웃 접근법을 지원한다.

AMD는 Pensando Vulcano 네트워크 인터페이스 카드 등을 포함해 프로세서와 핵심 네트워크 구성요소를 제공한다. 이후 OEM 및 ODM 파트너는 레퍼런스 설계를 실제 배치 가능한 제품으로 전환할 수 있다.

Meta는 Helios의 기반이 되는 Open Rack Wide 사양을 Open Compute Project에 기여했다. AMD는 2025년 10월 해당 설계를 기반으로 제작된 정적 Helios 랙을 처음 공개했다.

open-rack blueprint는 공통의 기계적, 전력, 냉각 규약을 만든다. 이러한 규약은 운영자가 새로운 가속기 세대마다 일회성 인프라를 구축하는 일을 피하는 데 도움을 줄 수 있다.

이 지점에서 AMD와 Google이라는 표현은 더 광범위한 연합을 가리킨다. Google은 공통 가속기 연결 방식으로서 UALink를 지원하는 여러 기업 중 하나다.

Google은 자체 텐서 처리 장치를 운영하므로 Nvidia가 관장하지 않는 인터페이스를 지원할 이유도 있다. 내부 AI 실리콘을 개발하는 클라우드 제공업체에도 같은 논리가 적용된다.

개방형 인터페이스는 공급업체 선택지를 넓힐 수 있다. 고객은 프로세서, 스위치, 네트워킹 장비, 랙, 냉각 하드웨어, 관리 구성요소를 더 폭넓은 그룹에서 조달할 수 있다.

이러한 유연성은 일부 설계 주기를 단축하고 단일 부품 로드맵이 전체 클러스터를 좌우하는 일을 막을 수 있다. 또한 운영자가 이미 정착된 데이터센터 관행에 맞춰 시스템을 조정할 수 있게 한다.

하지만 표준은 통합 책임을 없애는 대신 옮긴다. 누군가는 여전히 펌웨어 조합, 케이블, 스위치, 열 특성, 장애 복구, 소프트웨어 호환성을 검증해야 한다.

Nvidia는 통제된 제품 스택 안에서 이러한 작업의 상당 부분을 흡수한다. 이 모델은 일부 선택지를 제한하지만, 시스템 동작에 책임지는 주체를 하나로 만든다.

AMD의 레퍼런스 아키텍처는 AMD, 제조업체, 네트워크 공급업체, 클라우드 운영자, 표준 단체에 작업을 분산한다. 이 구조는 배치 환경에서 장애가 발생할 때 명확한 지원 경계가 필요하다.

첫 번째 프로덕션 시스템은 OEM 구현이 일관되게 작동하는지를 보여줄 것이다. 펌웨어, 냉각, 케이블링 또는 관리 도구의 작은 차이도 공급업체 간 운영 편차를 만들 수 있다.

이런 세부 사항은 하나의 랙에 72개의 가속기와 31테라바이트의 HBM4가 들어갈 때 중요해진다. 신뢰할 수 없는 단일 링크가 값비싼 분산 학습 작업 전체에 영향을 줄 수 있다.

서비스 용이성은 하나의 해답이다. AMD는 Helios가 광범위한 재케이블링 없이 구성 요소를 교체할 수 있도록 모듈식 트레이와 통합 연결 방식을 사용한다고 말한다.

더블 와이드 형식은 기술자에게 밀집한 액체 냉각 장비 주변의 더 넓은 작업 공간도 제공한다. 이는 기존 행에 들어갈 수 있는 시스템 수를 줄이더라도 유지보수를 개선할 수 있다.

따라서 기술적 메커니즘에는 비즈니스상의 절충이 포함된다. 구매자는 Nvidia의 통제된 환경 대신 더 많은 선택지를 얻는 한편, 검증과 통합에 대한 더 큰 책임을 떠안는다.

대형 클라우드 제공업체가 이러한 교환을 수행하기에 가장 유리한 위치에 있다. 이들은 하드웨어 팀을 운영하고, 맞춤형 네트워크를 운영하며, 칩 및 장비 공급업체와 직접 협상한다.

소규모 기업은 일반적으로 클라우드 서비스나 완전 지원형 OEM 시스템을 통해 Helios를 접하게 될 것이다. 이들이 직접 개방형 가속기 패브릭을 설계할 가능성은 낮다.

Microsoft의 도입은 AMD가 이들 고객에게 도달할 수 있는 중요한 경로를 제공한다. Microsoft는 배포 규모를 공개하지 않았지만, 내부 워크로드와 Azure 서비스를 위해 Helios를 대규모로 배포할 것이라고 밝혔다.

Azure commitment은 개발자가 랙 인프라를 직접 보유하지 않고도 Helios를 시험할 수 있음을 의미한다. 또한 AMD에 소프트웨어 및 신뢰성 문제를 조기에 드러낼 수 있는 까다로운 운영자를 제공한다.

이 피드백 순환은 이후 구매자를 위해 ROCm, 펌웨어, 오케스트레이션 도구를 강화할 수 있다. 반대로 개방형 구성 요소가 예상보다 더 많은 조율을 요구한다는 사실을 드러낼 수도 있다.

승자는 어떤 인터커넥트 사양이 더 개방적으로 보이느냐로 결정되지 않을 것이다. 필요한 규모에서 유용한 작업을 얼마나 예측 가능하게 완료하느냐가 결정할 것이다.

AMD의 최고 성능 랙 주장은 여전히 프로덕션 검증이 필요하다

AMD는 사양 수준의 신뢰성은 확보했지만, 아직 Nvidia 대비 프로덕션 우위를 입증하지는 못했다.

AMD는 Helios를 업계 선도 랙이라고 부르며, MI455X가 선도적 성능을 제공한다고 말한다. 이 주장은 피크 수치와 회사 자체 모델링 비교에 크게 의존한다.

독립 운영업체들은 아직 출하된 Helios 클러스터의 광범위한 결과를 공개하지 않았다. 따라서 구매자가 AMD의 우위를 확립된 사실로 받아들이기 전에 몇 가지 중요한 질문이 여전히 답을 기다리고 있다.

첫 번째는 실제 모델 성능에 관한 것이다. 학습 처리량은 애플리케이션이 광고된 연산 성능, 메모리 대역폭, 네트워크 용량을 얼마나 효율적으로 활용하는지에 달려 있다.

랙은 피크 FP4 연산에서 앞설 수 있지만, 동기화, 데이터 이동, 커널 공백 또는 소프트웨어 오버헤드로 시간을 잃을 수 있다. 모델 아키텍처에 따라 승자가 달라질 수도 있다.

두 번째 질문은 하나의 랙을 넘어선 확장에 관한 것이다. Helios는 상당한 스케일아웃 대역폭을 제공하지만, 대규모 프런티어 워크로드는 수백 또는 수천 개의 가속기에 걸쳐 분산될 수 있다.

그 정도 규모에서는 통신 라이브러리, 혼잡 제어, 토폴로지, 장애 처리가 각 네트워크 어댑터의 정격 속도만큼 중요하다. 지속 부하에서의 성능은 여전히 결정적인 시험이다.

세 번째 질문은 소프트웨어 성숙도다. ROCm은 주요 AI 프레임워크와 일반적인 모델 아키텍처를 지원하지만, 지원한다고 해서 모든 워크로드에 대해 동등한 최적화가 보장되지는 않는다.

팀은 커널, 컨테이너, 모니터링 도구 또는 배포 프로세스를 수정해야 할 수 있다. 또한 장애가 소프트웨어, 펌웨어, 네트워크 경계를 넘나들 때 신뢰할 수 있는 디버깅이 필요하다.

이 전환 부담은 CUDA 지식이 널리 퍼져 있는 Nvidia에 유리하게 작용한다. 기업은 관련 경험을 갖춘 엔지니어를 채용하고 확립된 운영 관행을 재사용할 수 있다.

AMD는 클라우드 제공과 주요 AI 연구소와의 협력을 통해 이 부담을 줄일 수 있다. Microsoft, Meta, OpenAI, Anthropic, Oracle은 회사에 최적화를 위한 가치 있는 환경을 제공한다.

하지만 고객사 이름에는 맥락이 필요하다. 구매 약정은 실제 프로덕션 트래픽이 얼마나 이동할지, 어떤 워크로드가 실행될지, 용량이 얼마나 빨리 제공될지를 보여주지 않는다.

Microsoft는 물량 기반 배포를 설명했지만, 와트, 랙 또는 가속기 수는 공개하지 않았다. 이런 세부 사항이 없다면, 이 발표는 측정된 도입보다는 관심을 검증하는 것이다.

관련된 또 다른 불확실성은 제조 및 시스템 납품이다. Helios는 고급 GPU, HBM4, 프로세서, 네트워크 구성 요소, 액체 냉각, 특수 랙 하드웨어를 결합한다.

가용성은 AMD의 실리콘 공급만으로 결정되지 않는다. 제조업체는 완성 시스템을 조립, 테스트, 출하, 지원해야 하며, 운영업체는 호환 가능한 전력 및 냉각 설비를 준비해야 한다.

AMD는 Helios가 본격 생산에 들어갔으며 3분기 말까지 출하를 예상한다고 말한다. production schedule은 시장에 단기적인 검증 시점을 제공한다.

시스템의 물리적 폭은 또 다른 실질적 제약을 도입한다. 더블 와이드 랙은 서비스 용이성을 개선할 수 있지만, 플로어 계획과 랙 수를 기준으로 한 비교 방식을 바꾼다.

구매자는 메가와트당 성능, 바닥 면적 단위당 성능, 완료된 워크로드당 성능을 비교해야 한다. 단순한 랙 대 랙 비교는 이러한 시설 차이를 가릴 수 있다.

AMD의 달러당 토큰 수 우위 주장에도 같은 주의가 필요하다. 조달 조건은 비공개이며, 가동률, 네트워킹, 에너지, 지원, 엔지니어링이 총 운영 비용에 영향을 미친다.

공개된 구성 요소 사양만으로는 이러한 변수를 결론낼 수 없다. 비교 가능한 모델과 서비스 목표 전반의 프로덕션 측정만이 이를 판단할 수 있다.

Nvidia 역시 소프트웨어 개선, 가격, 공급 약정 또는 신규 시스템 구성으로 대응할 여지가 있다. 대규모 설치 기반은 AMD가 이제 막 진입하는 워크로드에서 얻은 데이터를 제공한다.

따라서 회의론자의 주장은 간단하다. Helios는 문서상 경쟁력 있어 보이지만, Nvidia의 우위에는 사양으로 표현할 수 없는 배포 지식이 포함된다.

그렇다고 AMD의 출시가 중요하지 않다는 뜻은 아니다. 같은 세대에서 사양 동등성에 도달하는 것은 의미 있는 점유율 확보를 위한 필수 단계다.

rack comparison은 또한 AMD에 이런 위치가 얼마나 이례적인지 보여준다. 이전 Instinct 제품은 Nvidia의 동급 플랫폼이 이미 탄력을 얻은 뒤에 출시되는 경우가 많았다.

Helios는 결과가 확정되기 전에 진입한다. 이제 위험은 명백한 하드웨어 열세가 아니라, AMD와 파트너들이 경쟁력 있는 구성 요소를 신뢰할 수 있는 인프라로 전환할 수 있느냐에 달려 있다.

고객은 Helios를 청사진에서 시장으로 전환한다

실명이 공개된 고객은 Helios에 신뢰성을 더하지만, 시장을 바꿀지는 워크로드 규모와 반복 배포가 결정할 것이다.

Microsoft는 데이터센터 내부와 Azure 서비스를 통해 프런티어 모델 워크로드에 Helios를 사용할 계획이다. 이는 학습, 추론, 기업 접근성을 위한 중요한 검증 환경을 만든다.

Oracle도 AMD 랙 스케일 시스템 기반 인프라를 논의했다. HPE는 Helios 기반 제품군을 계획하고 있어, 기업 고객에게 지원되는 배포로 가는 또 다른 경로를 제공한다.

Meta의 역할은 조달을 넘어선다. Meta의 Open Rack Wide 기여는 Helios가 설계된 기계적·인프라 기반을 제공한다.

이러한 관계는 Nvidia의 우위 중 서로 다른 부분을 겨냥한다. 클라우드 약정은 수요를 검증하고, 장비 파트너는 유통을 확장하며, 개방형 표준은 공급업체 기반을 넓힌다.

Cerebras는 또 다른 사용 사례를 더한다. 양사는 Helios와 Cerebras 웨이퍼 스케일 시스템 사이에 AI 추론을 분할할 계획이다.

이 설계에서 AMD 하드웨어는 프롬프트 처리와 대규모 컨텍스트 윈도우를 담당한다. 이후 Cerebras 프로세서는 모델의 내부 연산을 출력으로 전환하는 토큰 생성에 집중한다.

AMD CEO Lisa Su는 이 방향을 “더 많은 워크로드 분리”라고 설명했다. 이는 하나의 워크로드 내 서로 다른 단계를 각 작업에 적합한 프로세서에 할당한다는 뜻이다.

split inference plan은 이기종 컴퓨팅을 기능으로 취급한다는 점에서 주목할 만하다. Nvidia는 일반적으로 전체 워크플로 전반에서 하나의 긴밀하게 최적화된 플랫폼을 강조한다.

Cerebras는 자사 데이터센터에 Helios를 배포하고, 2026년 후반에 자사 클라우드를 통해 공동 서비스를 제공할 계획이다. 이 일정은 상호운용성과 운영 준비 상태를 시험할 또 다른 기회를 제공한다.

이 협력은 메모리 용량이 중요한 이유도 보여준다. 토큰 생성이 시작되기 전에 긴 프롬프트와 대규모 컨텍스트 윈도우가 상당한 가속기 메모리를 소비할 수 있다.

31테라바이트의 HBM4를 탑재한 Helios 랙은 더 많은 모델 상태와 컨텍스트를 가속기 가까이에 유지할 수 있다. 이것이 서비스 우위로 이어지는지는 소프트웨어와 워크로드 동작에 달려 있다.

개발자에게는 랙 다이어그램보다 클라우드 접근성이 더 중요하다. 대부분의 팀은 모델 처리량, 지연 시간, 가용성, 마이그레이션 노력으로 Helios를 평가할 것이다.

추론을 운영하는 팀은 AMD 용량이 대기 시간을 줄이거나 배포당 메모리를 늘리는지 물을 것이다. 또한 기존 컨테이너와 프레임워크가 광범위한 변경 없이 작동하는지도 시험할 것이다.

학습 팀은 확장 효율성과 작업 신뢰성에 초점을 맞출 것이다. 분산 실행이 더 자주 실패하거나 더 긴 튜닝 주기를 요구한다면, 명목상 더 빠른 랙은 가치가 거의 없다.

기업 구매자는 추가적인 우려에 직면한다. 이들은 실험적 가속기 용량에 대한 접근만이 아니라 안정적인 지원과 예측 가능한 배포 경로가 필요하다.

OEM 시스템과 클라우드 서비스는 일부 인프라 복잡성을 숨길 수 있다. 하지만 모델 호환성, 관측 가능성, 워크로드 경제성의 차이까지 숨길 수는 없다.

이러한 테스트를 문서화하는 조직에는 구성, 오류, 벤치마크 조건, 의사결정에 대한 지속 가능한 기록이 필요하다. searchable knowledge base는 하드웨어 평가 전반에서 이러한 근거를 보존할 수 있다.

amd google standards connection은 상호운용성이 실질적인 결과를 낳기 때문에 여기서 관련성이 있다. 진정한 생태계라면 도구, 공급업체, 운영 지식이 구현체 간에 이동할 수 있어야 한다.

그럼에도 Google은 공개된 Helios 고객이 아니라 표준 참여자다. 이를 다르게 제시하면 AMD 출시를 뒷받침하는 상업적 근거를 과장하게 된다.

현재 가장 강력한 검증은 배포를 발표한 고객에서 나온다. 그럼에도 공개 약정은 설치된 시스템과 반복적인 워크로드 사용으로 이어져야 한다.

세 가지 도입 신호가 중요할 것이다. 첫째, 클라우드 제공업체는 지역 전반의 명확한 가용성과 함께 프로덕션 인스턴스를 제공해야 한다.

둘째, AI 연구소는 제한된 평가 클러스터를 넘어선 지속적인 사용을 보고해야 한다. 셋째, 장비 제조업체는 운영자가 일관되게 서비스할 수 있는 시스템을 출하해야 한다.

이런 신호가 나타난다면 Nvidia는 단순한 벤치마크 경쟁자 이상의 상대와 맞서게 될 것이다. 실제 배포 경험을 갖춘 대안적 공급 및 인프라 네트워크와 경쟁하게 될 것이다.

그렇지 않다면 Helios는 개방성이 워크로드 소유자보다 파트너에게 더 매력적인 강력한 레퍼런스 설계로 남을 수 있다.

첫 Helios 출하 이후 주목할 점

다음 분기는 Helios가 출하되는 플랫폼인지, 신뢰할 수 있는 프로덕션 시스템인지, 아니면 주로 대형 구매자를 위한 협상 도구인지를 보여줄 것이다.

첫 번째 신호는 출하 일정이다. AMD는 2026년 3분기 말까지 고객 출하를 예상하고 있어, 제조업체가 완성형 시스템을 제공할 수 있는 기간은 제한적이다.

정시 납품은 Helios가 단순한 시연 단계를 넘어섰다는 AMD의 주장을 뒷받침할 것이다. 반대로 지연은 기반 하드웨어의 경쟁력이 유지되더라도 Vera Rubin에 대한 동세대 경쟁 구도를 약화시킬 수 있다.

출하 발표에는 단순한 일반 공급 개시 선언 이상의 내용이 포함돼야 한다. 유의미한 근거로는 실명 공개된 시스템 제조업체, 운영 중인 클라우드 리전, 설치된 랙 수, 실제 운영 워크로드 등이 있다.

두 번째 신호는 독립적인 애플리케이션 성능이다. 구매자는 최고 FP4 및 FP8 처리량뿐 아니라 실제 모델에 대한 측정 결과를 필요로 한다.

관련 테스트는 학습 효율, 장문 컨텍스트 추론, 인터랙티브 성능, 멀티랙 확장성, 에너지 사용량, 장애 복구를 포괄해야 한다. 또한 모델 설정과 소프트웨어 버전도 공개해야 한다.

Microsoft Azure의 결과는 특히 유용한 정보를 제공할 것이다. 폭넓게 접근 가능한 클라우드 서비스는 개발자가 벤더 시연에만 의존하지 않고 Nvidia와 AMD 하드웨어를 비교할 수 있게 해준다.

성능 동등성은 개방형 랙 스케일 시스템이 Nvidia의 통합 스택과 경쟁할 수 있다는 근거를 강화할 것이다. 지속적인 소프트웨어 또는 신뢰성 격차는 이를 약화시킬 것이다.

세 번째 신호는 Nvidia의 대응이다. Nvidia는 Vera Rubin의 핵심 아키텍처를 변경하지 않고도 시스템 로드맵, 소프트웨어 최적화, 공급 약속, 상업적 포지셔닝을 조정할 수 있다.

개방형 Ethernet, 더 쉬운 통합, 또는 더 유연한 시스템 구성에 대한 강조가 강화된다면 Helios가 고객 논의에 영향을 미치고 있음을 시사할 것이다.

반대로 경쟁 대응이 제한적이라면 Nvidia가 수요에 거의 위협이 없다고 판단한다는 의미일 수 있다. CUDA와 배포 성숙도가 여전히 결정적이라는 자신감을 반영하는 것일 수도 있다.

AMD와 Google의 표준 전략 역시 발표가 아니라 참여를 통해 더 명확해질 것이다. 새로운 UALink 제품, 검증된 스위치, 상호운용 가능한 시스템은 이 연합이 실제로 사용할 수 있는 인프라를 만들어 내고 있음을 보여줄 것이다.

표준은 제조업체가 예외 상황에 맞닥뜨리기 전까지 가장 강력해 보이는 경우가 많다. 공동 규정 준수 테스트와 공개적인 구현 경험은 UALink가 파편화를 피할 수 있는지 드러낼 것이다.

결정적인 결과는 단일 벤치마크 승리가 아니다. 클라우드, AI 연구소, 엔터프라이즈 시스템 전반에서 반복적으로 배포되는 것이 핵심이다.

AMD는 Vera Rubin과 비교할 만한 랙을 제시함으로써 이미 중요한 문턱을 넘었다. 이제 파트너들이 그 랙을 일관되게 구축하고, 출하하고, 운영할 수 있음을 입증해야 한다.

Nvidia는 하드웨어, 소프트웨어, 배포 기반이 서로를 강화하기 때문에 여전히 기준 플랫폼으로 남아 있다. Helios는 개방성을 정책적 주장에 그치지 않고 완전한 시스템으로 구현함으로써 이 위치에 도전한다.

개발자와 구매자에게 다음 단계는 근거를 수집하는 일이다. 클라우드 가용성을 추적하고, 동일한 워크로드를 벤치마크하며, 마이그레이션에 드는 노력을 기록하고, 지속 사용 환경에서의 신뢰성을 비교해야 한다.

결정을 AMD 대 Nvidia라는 브랜드 대결로 축소하지 말아야 한다. 각 시스템이 통합 작업을 어디에 배분하는지, 장애를 어떻게 처리하는지, 향후 업그레이드를 어느 공급업체가 통제하는지를 살펴봐야 한다.

AMD와 Google의 연결은 Helios에 개방형 대안으로서 제도적 지원을 제공하지만, 표준 참여가 생산 성공을 보장하지는 않는다. 이제는 출하와 워크로드가 그 주장을 뒷받침해야 한다.

분기 말 전에 실제 서비스에 투입되는 것이 무엇인지 지켜본 뒤, 한 가지 실용적인 질문을 던져야 한다. Helios는 공급업체 선택권을 현실화할 만큼 안정적으로 당신의 워크로드를 완수하는가?

 
 

무료로 시작하세요

개인 지식 관리 기능을 갖춘 로컬 우선 AI 어시스턴트

더 나은 AI 경험을 위해

현재 remio는 Windows 10+ (x64)M-Chip Macs만 지원합니다.

​머릿속에 검색창을 추가하세요

remio에게 물어보기만 하면 됩니다

모든 것을 기억하세요

정리는 필요 없습니다

bottom of page