• 추론 수요가 공급을 앞지르고 NVIDIA GPU와 토큰 비용이 오르는 가운데,
  AMD MI355X는 B300 대비 GPU당 평균 약 2.75배 저렴해 저비용 추론 대안으로 부상함 - AMD Instinct MI350 계열은 Blackwell과 실리콘 수준에서 경쟁하지만, NVIDIA의
  소프트웨어 우위와 day-0 지원이 실제 서빙 속도와 도입 난이도를 좌우함 - Wafer는 GLM-5.2를 MI355X에서 최적화해 20k 입력/1k 출력, 60% 캐시 히트율 워크로드에서
  2626 tok/s/node와 2.4 rps를 달성했으며, 이는 B200 측정 성능의 80% 수준임 - 단일 스트림 기준으로는 10k 입력 토큰/1.5k 출력 토큰에서
  213 tok/s를 기록했고, 리더보드 최상위는 아니지만 성능당 비용에서는 우위가 있다고 봄 - 이번 결과는 커스텀 커널 없이 프레임워크 버그 수정, 양자화, speculative decode, MoE 커널 선택 튜닝으로 나온 것이어서 AMD의 과제는 점점
  소프트웨어 자체보다 지원 문제에 가까워짐

AMD 추론 비용과 NVIDIA 소프트웨어 격차

• 추론 수요는 빠르게 늘고 공급을 앞지르고 있으며, Claude Fable, GLM-5.2, Minimax M3 같은 최전선 모델이 거의 격주로 나오면서 토큰 수요도 커지고 있음
• Blackwell 공급이 충분하지 않아 NVIDIA GPU 가격과 토큰 비용이 함께 비싸지는 흐름임
  AMD MI355X는 B300 대비 GPU당 평균 약 2.75배 저렴하고, 하드웨어 사양은 비교 가능한 수준임- AMD Instinct MI350 계열은 실리콘 수준에서 Blackwell과 경쟁하지만, NVIDIA는
  day-0 지원과 소프트웨어 생태계 덕분에 최신 모델 추론을 더 빠르고 적은 마찰로 서빙할 수 있음 - MI355X와 ROCm 스택에서는 최신 최전선 모델의 SOTA 성능이 기본으로 나오지 않는 경우가 많고, 실행 가능한 이미지조차 찾기 어려울 수 있음
• day-0 지원이 없으면 최신 모델을 빌드하고 최적화하는 데 몇 주의 엔지니어링과 컴퓨트가 필요하며, 그 사이 더 새로운 모델이 나와 AMD가 계속 따라잡는 구도가 됨

GLM-5.2 on MI355X 성능

• Wafer는 에이전트가 커널과 모델 최적화에서 개선되면서 AMD와 NVIDIA 사이의 실전 격차가 줄고 있다고 봄
• 20k 입력/1k 출력, 60% 캐시 히트율 워크로드에서
  2626 tok/s/node를 달성함- 지속 RPS는 2.4 rps
• 정의한 knee는 TTFT 5초 이하
• B200에서 측정한 성능의 80% 수준
• MI355X는 2배 이상 저렴함

지속 RPS	집계 tok/s/node	TTFT p50 / p95	성공률
0.5	449	0.59s / 0.60s	100%
1.0	974	0.60s / 0.81s	100%
1.5	1913	0.62s / 1.03s	100%
2.0	1944	0.62s / 1.05s	100%
2.25	2089	0.63s / 1.23s	100%
2.4 포화
2626
0.81s / 2.22s
100%

• Artificial Analysis 기준에 따라 GLM-5.2 단일 스트림에서 10k 입력 토큰/1.5k 출력 토큰 기준
  213 tok/s를 달성함 - 이 수치는 Artificial Analysis 리더보드 최상위는 아니지만, 성능당 비용에서는 우위가 있다고 봄
• 테스트는 TensorWave의 AMD MI355X 용량에서 서빙됨

양자화와 추론 프레임워크 선택

• 첫 단계는 양자화와 프레임워크 선택이었고, Wafer는 bf16 기반 GLM-5.2를 AMD Quark로
  MXFP4양자화함 - z-ai의 공식 FP8 양자화와 비교해 MXFP4는 GPQA-Diamond, tau2, GSM8K에서 손실이 없는 수준으로 평가됨

평가	FP8 기준	MXFP4	Δ
GSM8K, 200문항, 5-shot, greedy	0.965 ± 0.013	0.955 ± 0.014	−0.010
GPQA-Diamond, 198문항 × 2 seeds, temp 1.0	0.9217 ± 0.027	0.9026 ± 0.029	−0.019
tau2 macro	0.819	0.834	+0.015

• 추론 프레임워크 후보는
  vLLM,ATOM,sglang3가지였음- vLLM은 MXFP4 + GlmMoeDsa 경로가 동작하지 않아 MXFP4 가중치의 이점을 활용하지 못함
• ATOM은 긴 컨텍스트에서 출력 품질이 저하됨
• sglang은 네이티브 지원까지의 마찰이 가장 적고, 양자화를 활용하면서도 일관된 출력을 유지함

speculative decode를 막던 두 가지 문제

• 처리량 개선을 위해 sglang에서
  speculative decode를 활성화하려 했지만, sglang ROCm 이미지는 이를 기본 지원하지 않았음 - MTP가 제대로 동작하려면 두 가지 수정이 필요했음
• 첫 번째 문제는 MTP head의 shared expert가 bf16으로 저장되지만, sglang의 양자화 조회가 모듈 prefix 불일치 때문에 이를 MXFP4로 빌드하려 한 점임
• Quark는 bf16 shared expert를
  model.layers.78.mlp.shared_experts.*

로 이름 붙임 - MTP layer의 실제 prefix는
model.decoder.*

임 - 이 불일치 때문에 로드 시 full-width bf16 가중치를 half-width 4-bit 슬롯에 읽으려 하며 shape mismatch로 초기화가 실패함

• Wafer는 layer 78 항목을 sglang이 실제 사용하는 decoder 이름으로 한 번 더 복사해 speculative decode를 열었고, 단일 스트림 처리량이 거의
  3배증가함

• Quark는 bf16 shared expert를

• 두 번째 문제는 z-ai가 제안한 5/1/6 설정 같은 깊은 speculative decode가 막힌 점임

• draft depth 4 이상에 필요한 fused multi-step metadata 커널이 ROCm guard 없이
  #include <cuda_runtime.h>

를 작성함 #ifdef USE_ROCM

guard 하나로 수정함

• draft depth 4 이상에 필요한 fused multi-step metadata 커널이 ROCm guard 없이
• speculative decode가 정상 동작한 뒤
  --kv-cache-dtype fp8_e4m3

,--enable-aiter-allreduce-fusion

같은 설정 최적화를 더해 단일 스트림 디코드213 tok/s에 도달함

집계 처리량 병목과 MoE 튜닝

• 정의한 워크로드에서는 디코드 최적화만으로 충분하지 않았고, 20k 입력과 60% 캐시 조건에서 주된 병목은
  prefill이었음 - 단일 스트림 디코드에 맞춘 TP8 구성에서 MI355X는 GLM-5.2-MXFP4를
  1461 tok/s/node로 실행함 - TP4×DP2로 전환하자 같은 워크로드에서
  1944 tok/s/node와 2.0 RPS를 달성함 - 다만 Wafer가 측정한 Blackwell 성능은 3.0 RPS에서
  3192 tok/s/node였고, MI355X의 prefill 성능은 상대적으로 느렸음 - sglang 이미지에서 GLM-5.2의 fp4 MoE가 느린 FlyDSL 휴리스틱 fallback으로 조용히 떨어진 점이 큰 이유였음
• aiter는 a8w8/fp8 경로에 대해서만 튜닝된 설정을 제공함
• Wafer는 GLM의 fp4 shape에 맞춰 MoE 커널 선택을 직접 튜닝함
• 대상 shape는
  model_dim 6144

,moe_inter 2048

,E=256

,topk=8

• 이 튜닝으로 집계 처리량은
  2626 tok/s/node와 2.4 RPS에 도달함

AMD에서 SOTA 성능을 내는 데 필요한 것

• MI355X에서 최고 성능당 비용을 달성하는 과정에는 어느 정도 마찰이 있었지만, 특별히 어렵지는 않은 수준으로 평가됨
• Qwen3.5 397B 작업과 달리 이번에는
  커스텀 커널을 작성하지 않았음 - 이번 연구는 멀티 노드 성능을 고려하지 않았지만, 단일 노드 배포는 실제 환경에서 여전히 널리 쓰임
• AMD에서 SOTA 성능을 내는 문제는 점점 소프트웨어 자체보다
  지원의 문제가 되고 있음 - CUDA moat는 실시간으로 약해지고 있다는 결론임