달러당 성능이 더 빠르고 저렴해지고 있음

4 hours ago 3
  • 추론 수요가 공급을 앞지르고 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, sglang 3가지였음
    • 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배 증가함
  • 두 번째 문제는 z-ai가 제안한 5/1/6 설정 같은 깊은 speculative decode가 막힌 점임
    • draft depth 4 이상에 필요한 fused multi-step metadata 커널이 ROCm guard 없이 #include <cuda_runtime.h>를 작성함
    • #ifdef USE_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는 실시간으로 약해지고 있다는 결론임
Read Entire Article