Microsoft Maia 100에서 Maia 200까지: Azure가 선택한 Ethernet 추론 공장

🆓 무료 글 · 누구나 무료로 읽을 수 있는 글입니다

이 글은 cloud AI accelerator의 세대별 architecture와 system economics를 비교해 구매·투자·공급망 판단을 내리려는 독자를 위한 글이다. 읽고 나면 peak 수치와 실제 model-level TCO를 분리하고, 다음 세대에서 검증할 지표를 선택할 수 있다.

자료 기준일: 2026-08-02

TL;DR

Microsoft의 자체 AI 가속기 역사는 Maia 100 발표보다 오래됐다. Project Brainwave는 FPGA에 soft NPU를 올려 batch 1 실시간 추론과 재구성 가능성을 실험했다. Maia 100은 5 nm, 1,050억 transistor, 약 820 mm², CoWoS-S, custom Ethernet, liquid cooling으로 Azure가 full-stack ASIC을 실제 데이터센터에 넣는 법을 배운 세대다. Maia 200은 3 nm, 1,400억 이상 transistor, FP4 10 PFLOPS 이상, FP8 5 PFLOPS 이상, 216 GB HBM3e·7 TB/s, 272 MB on-chip SRAM, 2.8 TB/s scale-up을 갖춘 inference-focused system으로 바뀌었다.

Maia의 핵심은 NVIDIA를 완전히 대체하는 것이 아니다. OpenAI와 Copilot의 반복 추론 workload를 Azure가 통제하는 silicon·network·runtime에 옮겨 가장 비싼 token의 원가와 공급 위험을 낮추는 것이다. Microsoft의 약점은 첫 세대 software ecosystem과 외부 customer access의 제한이다. 강점은 OpenAI workload, Azure fleet, Ethernet networking, PyTorch·Triton을 한 회사 안에서 공동 설계할 수 있다는 점이다.

Generation map

Maia 100의 공개 자료는 die, process, network와 software를 상세히 설명하지만 HBM 용량·대역폭과 compute peak를 일관된 공식 표로 제공하지 않는다. 확인되지 않은 수치를 다른 출처에서 채워 넣지 않았다.

Project Brainwave: ASIC 이전의 설계 철학

2017년 공개된 Project Brainwave는 Intel Stratix 10 FPGA 위에 Microsoft가 설계한 soft DNN processing unit을 올렸다. pre-production device에서 80,000개의 Microsoft floating-point 8-bit MAC을 300 MHz로 동작시켜 48 TFLOPS peak를 제시했다. 목표는 학습 peak가 아니라 batch 없이 들어오는 request를 낮은 latency로 처리하는 것이었다.

FPGA를 쓴 이유는 model architecture와 number format이 빠르게 변하던 시기에 hardware data path를 재구성할 수 있기 때문이다. Microsoft는 graph intermediate representation을 두고 TensorFlow와 Cognitive Toolkit model을 compile했다. 여러 FPGA의 on-chip memory에 model을 분산해 pinning함으로써 외부 DRAM access를 줄이는 system architecture를 만들었다.

Brainwave에서 Maia로 이어진 세 가지 유산이 있다. 첫째, batch를 키워 benchmark throughput을 만드는 대신 real-time SLO를 우선한다. 둘째, low precision format을 hardware와 model training이 함께 정한다. 셋째, single device보다 datacenter fabric과 compiler가 중요하다고 본다. ASIC으로 전환한 뒤에도 이 설계 철학은 inference와 custom Ethernet으로 남았다.

FPGA의 한계도 분명하다. programmable routing과 configuration logic 때문에 동일 공정 ASIC보다 area, frequency, energy efficiency가 불리하다. production workload와 number format이 충분히 안정되고 volume이 커지면 fixed silicon의 높은 개발비를 amortize할 수 있다. Copilot, Bing, GitHub, Azure OpenAI의 token volume이 그 전환점을 만들었다.

Maia 100: 첫 ASIC의 목표는 최고 사양보다 Azure 착륙

Maia 100은 TSMC N5, 1,050억 transistor, 약 820 mm²의 reticle-limit급 die와 CoWoS-S interposer를 사용한다. Microsoft는 training과 inference를 모두 target으로 제시했고 OpenAI model, Bing, GitHub Copilot, ChatGPT workload를 언급했다. 첫 세대에서 중요한 것은 peak FLOPS 하나가 아니라 대형 package를 yield 있게 생산하고, Azure rack에 전력·냉각·network·host software를 함께 넣는 것이었다.

Maia 100은 software-managed L1·L2 scratchpad와 compression engine을 사용한다. cache coherence와 hardware replacement policy보다 compiler가 tensor lifetime과 placement를 명시적으로 제어하는 방식이다. 잘 compile된 static graph에서는 data movement를 줄일 수 있지만 dynamic shape, irregular access, compiler miss에 취약하다. lower-precision storage와 data compression은 inference의 weight bandwidth와 capacity를 낮추는 방향이다.

network는 custom Ethernet-based protocol로 accelerator당 aggregate 4.8 Tb/s all-gather·scatter-reduce, 1.2 Tb/s all-to-all을 지원한다고 Microsoft가 설명한다. RoCE와 유사하지만 reliability와 traffic balance를 AI collective에 맞게 조정하고 AES-GCM encryption을 제공한다. scale-up과 scale-out에 unified backend network를 사용해 direct connection과 switched connection을 모두 지원한다.

이 선택은 전략적이다. NVLink·InfiniBand에 의존하면 NVIDIA platform과 공급망을 그대로 따라가야 한다. Microsoft는 Ethernet switch, NIC, transport와 datacenter operations 경험이 있어 open physical ecosystem 위에 proprietary transport를 얹을 수 있다. 다만 Ethernet이 곧 open system을 뜻하지는 않는다. packet format, congestion control, collective library, topology management가 Maia-specific이면 실질적 lock-in은 여전히 존재한다.

Maia 100은 custom rack-level power distribution과 closed-loop liquid cooling을 함께 도입했다. dedicated cooling sidekick으로 accelerator와 host CPU를 냉각해 기존 datacenter footprint에 고밀도 system을 넣었다. 첫 generation의 success metric은 chip benchmark보다 wafer-to-rack qualification, coolant reliability, firmware update, fleet telemetry, model onboarding이었을 가능성이 높다.

Maia SDK: PyTorch와 Triton을 입구로 삼다

Maia SDK는 PyTorch eager·graph mode, Triton, compiler, optimized kernel·collective library, host-device runtime, debugger·profiler·quantization tool을 포함한다. Triton은 hardware-agnostic kernel language의 형태를 제공하고, Maia API는 최고 성능을 위한 low-level path를 제공한다. portability와 peak tuning 사이에 두 개의 programming model을 둔 셈이다.

Maia 100은 OCP Microscaling format의 첫 구현으로 소개됐다. MXFP8, MXFP6, MXFP4, MXINT8은 작은 block 단위 shared scale을 사용해 낮은 bit width에서도 dynamic range를 유지하려 한다. hardware multiplier 면적과 memory traffic을 줄이지만 block size, scale computation, accumulation, outlier가 model accuracy에 영향을 준다. Microsoft가 AMD, Arm, Intel, Meta, NVIDIA, Qualcomm과 표준화한 이유는 model checkpoint와 software tool이 특정 chip format에 갇히는 비용을 낮추기 위해서다.

첫 세대 software의 최대 위험은 operator coverage다. OpenAI의 핵심 Transformer workload는 최적화할 수 있어도 Azure customer의 다양한 vision, recommender, scientific model까지 같은 품질로 지원하기 어렵다. 그래서 Maia 100은 처음부터 broad public instance보다 Microsoft internal service와 selected partner workload에서 학습하는 방식이 합리적이다.

Maia 200: 학습·추론 범용에서 inference economics로

Maia 200은 TSMC 3 nm, 1,400억 개 이상의 transistor, native FP8·FP4 tensor core를 사용한다. peak는 FP4 10 PFLOPS 이상, FP8 5 PFLOPS 이상이다. memory는 216 GB HBM3e, 7 TB/s, on-chip SRAM 272 MB다. 이 조합은 단일 chip에 더 큰 model partition과 KV cache를 담고, token decode에서 weight를 지속 공급하는 데 초점을 둔다.

Maia 100에서 200으로 가장 큰 변화는 role의 명시적 분화다. Maia 100은 training과 inference를 모두 말했지만 Maia 200은 large-scale token generation economics를 전면에 둔다. frontier pretraining의 dense GEMM peak보다 serving의 HBM bandwidth, SRAM reuse, data movement, low precision, batch-1 latency와 fleet utilization을 최적화한다.

216 GB capacity는 특히 중요하다. 4-bit weight만 단순 계산하면 400B parameter가 약 200 GB지만 scale, metadata, KV cache, runtime buffer를 고려하면 더 작아진다. 그래도 70B·100B급 dense model 또는 큰 MoE partition을 한 chip에 더 많이 담을 수 있어 tensor parallel degree와 collective hop을 줄인다. HBM bandwidth 7 TB/s를 단순 weight streaming 상한으로 보면 memory-bound decode의 theoretical token throughput이 정해지지만, 실제는 KV access, attention, quantization, scheduling이 차감한다.

272 MB on-chip SRAM은 hot tensor, tile, scale과 intermediate를 HBM round trip 없이 유지하는 역할을 한다. SRAM은 HBM보다 빠르고 에너지 효율적이지만 die area가 크다. 3 nm transistor budget을 compute에만 쓰지 않고 SRAM과 data movement engine에 배분했다는 것은 inference가 arithmetic보다 movement 문제라는 판단이다.

Two-tier Ethernet scale-up

Maia 200은 accelerator당 2.8 TB/s bidirectional dedicated scale-up bandwidth를 제공한다. tray 안의 4개 accelerator는 non-switched direct link로 fully connected되고, 같은 Maia AI transport protocol을 rack과 cluster에도 사용한다. cluster는 최대 6,144개 accelerator의 collective를 지원한다.

local 4-way full mesh는 가장 빈번한 tensor parallel traffic을 switch 없이 처리해 latency와 power를 낮춘다. 그 밖의 traffic은 tier-2 Ethernet fabric로 넘어간다. topology-aware sharding이 4-device group을 기본 단위로 쓰면 direct bandwidth를 최대화할 수 있다. 반대로 model partition이 group boundary를 자주 넘으면 switch hop과 contention이 증가한다.

Microsoft는 Maia 200이 existing system 대비 performance per dollar 30% 개선이라고 발표했다. 무엇을 baseline으로 했는지, model·precision·latency SLO·cluster size가 동일한지 공개 범위가 제한적이므로 절대 우위로 해석하면 안 된다. 회사가 말하는 performance per dollar는 Azure fleet의 capex·power·network·utilization을 포함할 수 있지만 외부 고객의 migration cost와 availability는 별도다.

왜 Microsoft는 NVIDIA를 계속 사면서 Maia를 만드는가

Azure는 heterogeneous fleet가 필요하다. NVIDIA GPU는 frontier research, CUDA-only model, 외부 customer demand에 필요하다. AMD와 다른 accelerator도 supply와 price leverage를 제공한다. Maia는 OpenAI와 Copilot처럼 반복량이 크고 model stack을 통제할 수 있는 workload에서 vendor margin과 supply risk를 낮춘다.

따라서 Maia의 점유율이 Azure accelerator의 전부가 될 필요는 없다. 전체 token의 일부만 자체 silicon으로 옮겨도 규모가 크고, NVIDIA와의 구매 협상력, datacenter design autonomy, workload-specific efficiency를 얻는다. chip program의 ROI는 external instance revenue뿐 아니라 avoided GPU cost와 improved service gross margin으로 계산해야 한다.

Maia 200이 GPT-5.2, Microsoft Foundry와 Microsoft 365 Copilot을 target으로 언급한 것은 anchor workload가 이미 있다는 뜻이다. 이 traffic이 software optimization과 yield ramp를 흡수한다. 외부 customer에게 broad access를 열기 전에 내부 service가 안정적인 utilization과 failure data를 제공할 수 있다.

Watch points

1. Maia 200의 FP4가 실제 OpenAI model quality와 SLO에서 얼마나 넓게 적용되는가.
2. 216 GB HBM과 7 TB/s가 prefill, decode, long-context에서 각각 어떤 병목을 남기는가.
3. 6,144-device Ethernet cluster의 effective collective bandwidth와 tail latency가 공개되는가.
4. Maia SDK가 Azure customer에게 얼마나 개방되고, public instance 또는 managed endpoint의 가격이 제시되는가.
5. Maia 100이 training 역할을 유지하는지, 향후 training-focused 별도 generation이 등장하는지.

Contrarian read: Maia는 Azure 내부 비용 절감에는 성공해도 platform은 아닐 수 있다

Maia가 OpenAI와 Copilot에 매우 효율적이어도 외부 developer가 자유롭게 program하는 accelerator platform이 되지 못할 수 있다. selected model에서 높은 utilization을 얻는 것과 long-tail Azure workload의 operator, debugger, library를 지원하는 것은 다른 문제다. public access가 제한되면 Maia의 성공을 independent benchmark로 검증하기 어렵고 customer lock-in 우려도 남는다.

반대 가설은 managed AI가 hardware platform 경쟁을 무의미하게 만든다는 것이다. 고객이 Foundry endpoint와 Copilot을 구매할 뿐 device를 보지 않는다면 Microsoft는 내부에서 GPU와 Maia를 교체해도 된다. 이 경우 software ecosystem의 목표는 CUDA 대체가 아니라 몇 개의 대형 service graph를 최고 효율로 실행하는 것이다. Maia가 merchant accelerator가 되지 않아도 경제적으로 성공할 수 있다.

Korean lens

Maia는 한국 기업에 Ethernet scale-up의 기회를 보여준다. proprietary GPU link를 그대로 복제하기 어려워도 NIC, switch, retimer, optical module, congestion control, collective offload를 공동 설계하면 rack-scale system을 만들 수 있다. 그러나 표준 Ethernet PHY를 쓴다는 사실만으로 training fabric가 되는 것은 아니다. deterministic latency, loss recovery, topology, telemetry와 software collective가 함께 필요하다.

216 GB HBM3e와 7 TB/s는 HBM 공급사에 큰 기회지만 custom qualification 부담도 높다. accelerator package의 signal integrity, thermal coupling, base die, interposer와 yield가 모두 맞아야 한다. Maia 100의 CoWoS-S와 liquid cooling 경험이 3 nm 대형 die·HBM3e system의 ramp risk를 낮추는 자산이다. 국내 공급사는 chip spec보다 rack deployment cadence와 qualified package output을 추적해야 한다.

Sources

• Project Brainwave for real-time AI
• Project Brainwave IEEE Micro preprint
• Microsoft Azure Maia 100 introduction
• Azure Maia from silicon to systems
• Inside Maia 100
• OCP Microscaling Formats
• Maia 200 official introduction

Disclosure

본 글은 정보 제공만을 목적으로 하며, 특정 증권의 매수 또는 매도를 권유하는 것이 아닙니다. 본 글에 포함된 수치와 사실은 기업 공시, 언론 보도, 시장 조사 등 공개적으로 이용 가능한 자료를 바탕으로 작성되었으며, 해당 자료 또는 작성 과정에서 오류가 발생할 수 있습니다. 필자는 언급된 기업의 주식을 보유하고 있을 수 있습니다. 모든 투자 결정 및 그에 따른 결과는 독자의 책임입니다.