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