AMD Helios는 MI455X 사양 72개를 더한 값이 아니라 랙 설계로 평가해야 합니다. 4-GPU 트레이, HBM4 31TB, Ethernet 위의 UALink(UALoE), 선택 가능한 AI NIC가 소프트웨어의 서비스·통신 경계를 결정합니다. MXFP4와 메모리 합산값은 용량을 설명하지만, 실제 학습·추론 처리량은 집합 통신 효율과 전력, 냉각, 장애 복구에 달려 있습니다.
시스템 경계를 바꾼 발표
고성능 가속기는 큰 모델을 담을 수 있지만 스케일업 영역을 반복 배치하거나 배선·정비하기 어렵다면 학습과 분산 추론이 느려집니다. 특정 세대에 맞춘 전용 랙은 성능을 높일 수 있어도, 가속기가 바뀔 때마다 네트워크와 관리 방식을 다시 설계하게 만들 수 있습니다. AMD의 가장 큰 숫자를 경쟁 제품과 곧바로 비교하면 이번 설계의 핵심을 놓치게 됩니다. 소프트웨어 상태, 메모리 소유권, 통신, 정비가 함께 움직이는 범위를 먼저 확인해야 하며, 피크 사양은 실제 부하에서도 그 범위를 유지할 때 의미가 있습니다.
MI455X는 3D 하이브리드 본딩으로 연결한 연산 칩렛 8개와 별도 I/O 다이를 사용합니다. 장치 하나에 HBM4 스택 12개를 넣어 432GB와 23.3TB/s를 제공합니다. Helios는 4-GPU 트레이를 반복해 GPU 72개를 전 연결·단일 홉 UALoE 패브릭으로 묶습니다. 확장 가속기 모듈은 PCIe 6 호환 NIC 2개 또는 AMD AI NIC 3개를 선택할 수 있어 스케일업과 스케일아웃 접속을 구분합니다. 이 값은 AMD이 공개한 구성 사양입니다. 독립 기관이 측정한 결과가 아니며 모든 작업이 그대로 사용할 수 있는 성능으로 해석해서는 안 됩니다.
분모가 다른 사양의 구분
공개된 기준값은 GPU당 432GB·23.3TB/s, 랙당 31TB·1.67PB/s, 최대 2.9EFLOP/s 피크 MXFP4입니다. 각 수치는 서로 다른 질문에 답합니다. 장치 용량은 모델이나 애플리케이션 상태를 가까이 둘 수 있는지를 보여 주고, 링크와 메모리 대역폭은 프로토콜·접근 패턴·경합이 생기기 전의 상한을 제시합니다. 코어 수나 연산량은 사용할 수 있는 자원을 설명하지만 실제 작업 완료율은 활용률과 동기화에 달려 있습니다. 이 값을 단순히 더하면 큰 랙 숫자는 만들 수 있어도 재현 가능한 서비스 성능은 얻지 못합니다.
공급사가 공개한 자료는 구현 사실을 확인하는 1차 근거로 유용합니다. 반면 비교 경제성에서는 공급사가 비교 시스템과 소프트웨어, 운용점을 선택하므로 증거 범위가 좁습니다. 따라서 발표 수치를 그대로 기록하되 예상치, 지원 상한, 회사 자체 시험 결과를 구분해야 합니다. 공정한 비교에는 요청 구성, 소프트웨어 성숙도, 시설 전력, 가용성 목표가 같아야 합니다.
제품 세대보다 오래 남을 메커니즘
랙 합산 사양보다 중요한 단위는 4-GPU 트레이입니다. 반복 가능한 트레이는 제조, 케이블 길이, 냉각 배관, 교체 절차에 고정된 경계를 제공하고, UALoE 스위치 패브릭은 그 범위를 GPU 72개까지 확장합니다. 구매 전에는 모듈 하나가 고장 났을 때 집합 통신 토폴로지를 유지하면서 격리할 수 있는지, 72개 GPU 작업 전체를 다시 시작해야 하는지 확인해야 합니다.
이 메커니즘은 조율이 일어날 위치를 정한다는 점에서 첫 제품 세대 이후에도 남을 수 있습니다. 동시에 같은 범위의 계측이 필요합니다. 대기열, 메모리 압력, 링크 사용률, 스로틀링, 장애를 서비스 단위와 같은 해상도로 보여 주지 못하면 애플리케이션이 느려졌다는 사실만 알 수 있을 뿐, 원인이 실리콘 포화인지 배치·통신·복구 비용인지 구분하기 어렵습니다.
공개 자료가 입증하지 않은 범위
AMD는 Helios를 파트너와 공유하는 참조 설계로 설명하며 2026년 하반기 대규모 배치를 예상합니다. 2.9EFLOP/s, 1.4EFLOP/s, 1.67PB/s는 피크 합산 사양이며 애플리케이션 실측값이 아닙니다. 메시지 크기별 집합 통신 곡선, 랙 입력 전력, 냉각 조건, 작업 완료율, 일부 경로가 빠진 상태의 동작은 공개되지 않았습니다.
이 수치가 없다고 해서 설계가 실패했다는 뜻은 아닙니다. 다음 검증 항목이 무엇인지 정해 줍니다. 로드맵은 출하 제품과, 피크 사양은 지속 애플리케이션 처리량과, 공급사 비교는 독립 재현과 분리해야 합니다. AI 인프라는 랙 구성요소 하나만 빠져도 성능과 전력의 분모가 모두 달라지므로 이 구분이 중요합니다.
실제 도입을 위한 검증 순서
평가는 하나의 합성 피크 대신 세 종류의 작업으로 시작하는 편이 적절합니다. 첫 번째는 로컬 용량에 상태가 들어가는 연산 중심 작업, 두 번째는 실제 접근 편향을 반영해 메모리 용량과 대역폭을 압박하는 작업, 세 번째는 운영 환경의 메시지 크기와 동시성을 사용해 의도한 통신 경계를 넘는 작업입니다. 세 시험 모두 평균 장치 사용률뿐 아니라 완료된 작업의 p50·p95·p99 지연시간을 보고해야 합니다.
전력은 랙 입력에서 측정하고 연산, 메모리, 네트워크, 호스트, 냉각, 유휴 부품으로 나누어야 합니다. 교체 가능한 모듈 하나와 링크 하나, 네트워크 경로 하나를 제거한 뒤 시험을 반복하면 장애 격리, 재배치, 서비스 목표 회복 시간을 알 수 있습니다. 정상 상태의 피크가 낮더라도 정비 중 손실 작업이 적으면 실제 제공 용량은 더 클 수 있습니다.
소프트웨어 검증에는 컴파일러와 런타임 버전, 지원 커널 범위, 모델 변경, 대체 경로, 최적화 시간을 기록해야 합니다. 이미 실행되는 소프트웨어와 제품별로 다시 작성해야 하는 소프트웨어를 구분하고, 계측값이 장치 사용률뿐 아니라 시간과 에너지가 쓰인 위치를 설명하는지도 확인해야 합니다.
구매 단계에서는 랙 시간당 유효 작업, 시설 전력량당 유효 작업, 부품 고장 중 제공 가능한 용량, 새 작업당 엔지니어링 시간을 함께 비교할 수 있습니다. 이 네 분모를 사용하면 AMD의 구조적 기여를 축소하지 않으면서도 발표 사양을 실제 운영 판단으로 바꿀 수 있습니다.
Hot Chips 이후의 판단
AMD의 발표는 하나의 완결된 연산 단위를 만들고 관리하는 위치를 바꿨다는 점에서 의미가 있습니다. 지원 부품을 모두 포함한 뒤에도 데이터 이동과 운영 분리가 줄어드는지가 최종 판단 기준입니다. 구매자는 새 경계에서 빠진 실측값을 요구하고, 소프트웨어 팀은 가장 큰 사양을 배치 가능한 용량으로 보기 전에 배치 정책과 장애 동작을 먼저 시험해야 합니다.
장치 사양 밖의 통합 비용
실제 시스템은 관리, 이중화, 정비를 위해 일부 용량을 남겨 둡니다. 물리적으로 존재하는 코어, 링크, 메모리 채널도 장애 영역을 보호하거나 제어 트래픽을 처리하면 사용자 작업에 모두 배정할 수 없습니다. 정상 상태뿐 아니라 부품을 정비 대상으로 비울 때와 장애가 발생한 뒤에도 물리 용량과 실제 배정 가능한 용량의 차이를 측정해야 합니다.
토폴로지는 소프트웨어 비용도 바꿉니다. 컴파일러가 가까운 메모리와 장치를 하나의 자원처럼 보더라도 실제 시스템에는 지연시간과 대역폭이 다른 여러 계층이 있습니다. 런타임은 그 차이에 맞춰 상태와 집합 연산을 배치하고 더 긴 경로로 우회했을 때 이를 드러내야 합니다. AMD이 제공해야 할 결과는 장치 API뿐 아니라 애플리케이션 상태를 물리 계층에 배치하는 재현 가능한 규칙입니다.
수명주기 비용은 설치 전부터 발생합니다. 펌웨어 서명, 보안 부팅, 격리, 오류 보고, 메모리·네트워크 검증, 기존 오케스트레이션 통합에는 엔지니어링 시간이 필요합니다. 공급사가 전체 스택을 통제하면 여러 계층을 함께 최적화할 수 있지만 성능이 한 회사의 배포 일정에 묶일 수도 있습니다. 지원 버전 조합, 이전 버전 복귀 절차, 일부 기능이 빠진 상태의 운용 방식을 함께 확인해야 합니다.
보안과 신뢰성도 새 시스템 경계에서 시험해야 합니다. 주소의 소유자, 작업 제출 권한, 오류가 멈추는 범위, 다른 부품을 재설정할 수 있는 주체를 확인하고 데이터 손상, 시간 초과, 링크 단절, 일부 재시작을 주입할 필요가 있습니다. 높은 장치 사용률이 서비스 완료율을 보장하지 않으므로 애플리케이션 추적, 하드웨어 카운터, 전력 기록을 같은 시각에 연결해야 데이터 이동을 실제로 줄였는지 확인할 수 있습니다.
용량 계획에서는 평균 부하보다 증가 속도를 먼저 확인해야 합니다. 모델 크기, 문맥 길이, 동시 사용자, 장애 대비 여유가 서로 다른 비율로 늘기 때문에 첫해에 맞았던 연산·메모리·네트워크 비율이 다음해에는 틀릴 수 있습니다. 확장 단위를 하나 더 넣을 때 세 자원이 함께 늘어나는지, 특정 자원만 증설할 수 있는지, 남는 자원을 다른 작업에 배정할 수 있는지를 비용표에 반영해야 발표 당시의 피크가 아니라 실제 서비스 증가에 맞춘 도입 순서를 정할 수 있습니다.
출처와 저작권 안내
이 글은 AMD의 공식 발표와 아래 1차 자료를 바탕으로 Silicon & Systems가 작성한 독립 편집 다이제스트입니다. 아키텍처와 사양, 한계를 우리 표현으로 다시 썼으며 회사의 슬라이드, 표, 도판, 홍보 이미지를 재수록하지 않았습니다. 하드웨어 도판과 카드 모티프는 권리 기록이 있는 무문자 재질 원판을 바탕으로 이 글을 위해 만들었고 정확한 라벨은 코드로 합성했습니다. 인용한 자료의 저작권은 각 권리자에게 있습니다(2026).