AMD MI355X에서 GLM5.2 추론을 블랙웰보다 2배 이상 싸게 굴린 사례

AMD 추론이 ‘싸지만 귀찮은 선택지’에서 꽤 현실적인 선택지로 가는 중

• Wafer가 AMD MI355X에서 GLM5.2 추론을 최적화한 결과를 공개함

  • 20k 입력 토큰, 1k 출력 토큰, 60% 캐시 히트율 워크로드에서 2626 tok/s/node를 기록함
  • 요청률은 2.4 rps였고, TTFT는 5초 이하를 기준으로 잡음
  • 싱글 스트림 기준으로는 10k 입력, 1.5k 출력에서 213 tok/s를 냄

• 비용 쪽 주장이 핵심임

  • MI355X는 B300 대비 GPU당 평균 약 2.75배 저렴하다고 설명함
  • GLM5.2 워크로드에서 B200 측정 성능의 약 80%까지 갔지만, 비용은 2배 이상 낮다고 주장함
  • Artificial Analysis 리더보드 1등 숫자는 아니어도, 성능 대비 비용으로는 이긴다는 논리임

문제는 하드웨어보다 소프트웨어 지원이었음

• AMD MI350 계열은 실리콘 스펙만 보면 Blackwell과 경쟁할 수 있다고 봄

  • 하지만 NVIDIA는 CUDA 생태계와 day-0 지원이 강함
  • 최신 프론티어 모델이 거의 격주로 나오는데, AMD 쪽은 바로 실행되는 이미지조차 찾기 어려울 때가 있다고 함
  • 그래서 AMD에서는 최신 모델 최적화에 몇 주의 엔지니어링과 컴퓨트가 들어갈 수 있음

• Wafer는 이 격차가 줄고 있다고 봄

  • 커널과 모델 최적화를 도와주는 에이전트가 좋아지면서 catch-up 시간이 줄어든다는 주장임
  • 이번 GLM5.2 사례에서는 커스텀 커널을 새로 쓰지 않았다고 강조함
  • 프레임워크 버그와 설정, 커널 선택만 잡아도 꽤 올라왔다는 게 메시지임

양자화와 프레임워크 선택부터 갈림

• GLM-5.2 bf16 모델을 AMD Quark로 MXFP4 양자화함

  • z-ai 공식 FP8 양자화와 비교했을 때 GPQA-Diamond, tau2, GSM8K에서 손실이 없었다고 함
  • 4비트 계열로 줄이면서도 품질 손실이 없었다는 주장이 비용 효율의 출발점임

• 추론 프레임워크는 vLLM, ATOM, sglang 중 sglang을 골랐음

  • vLLM은 MXFP4 + GlmMoeDsa 경로가 동작하지 않아 MXFP4 가중치 이점이 없었음
  • ATOM은 긴 컨텍스트에서 출력 품질이 망가졌다고 함
  • sglang은 네이티브 지원까지 마찰이 가장 적고, 양자화 이점을 살리면서도 출력이 일관적이었다고 설명함

speculative decode를 켜는 데도 버그 두 개를 밟음

• 첫 번째 문제는 MTP head의 shared expert가 bf16으로 남아 있어야 하는데, sglang이 MXFP4로 잘못 만들던 것임

  • Quark는 양자화하지 않을 레이어 이름 목록을 갖고 있음
  • 그런데 메인 디코더 스택과 MTP 레이어의 모듈 prefix가 달라 lookup이 실패함
  • 결과적으로 bf16 가중치를 4비트 슬롯에 읽으려다 shape mismatch로 초기화가 터짐
  • 해결은 layer 78 항목을 sglang이 실제로 쓰는 decoder 이름 아래 한 번 더 복사하는 것이었음

• 두 번째 문제는 깊은 speculative decode에서 CUDA 헤더가 그대로 박혀 있던 것임

  • draft depth 4 이상에 필요한 fused multi-step metadata kernel이 cuda_runtime.h를 include하고 있었음
  • ROCm guard가 없어서 막혔고, USE_ROCM 조건부 처리를 추가해 해결함

• 이 두 수정 뒤 싱글 스트림 처리량이 크게 뜀

  • speculative decode가 제대로 켜지면서 싱글 스트림 처리량이 거의 3배 가까이 좋아졌다고 함
  • 추가로 --kv-cache-dtype fp8_e4m3, --enable-aiter-allreduce-fusion 같은 설정도 사용함

aggregate throughput은 prefill 병목을 따로 봐야 했음

• 싱글 스트림 최적화만으로는 20k 입력 워크로드를 해결할 수 없었음

  • 20k 입력에 60% 캐시 히트율이면 디코딩보다 prefill이 더 큰 병목임
  • TP8 구성에서는 GLM5.2-MXFP4가 1461 tok/s/node에 그침

• 병렬화 구성을 TP4×DP2로 바꾸자 처리량이 크게 올랐음

  • 2.0 rps에서 1944 tok/s/node까지 상승함
  • 그래도 Blackwell의 3192 tok/s/node @ 3.0 rps보다는 느렸음

• 마지막 병목은 GLM-5.2 fp4 MoE 커널 선택이었음

  • sglang 이미지에서 fp4 MoE가 느린 FlyDSL heuristic fallback으로 조용히 빠지고 있었음
  • aiter가 a8w8/fp8 경로에만 튜닝 설정을 제공했기 때문이라고 설명함
  • Wafer가 GLM fp4 shape에 맞춰 MoE 커널 선택을 직접 튜닝함
  • shape는 model_dim 6144, moe_inter 2048, E=256, topk=8로 언급됨

---

기술 맥락

• 이 글의 핵심 선택은 NVIDIA Blackwell 대신 AMD MI355X에서 최신 MoE 모델을 비용 효율적으로 서빙하는 거예요. 추론 수요가 폭증하면서 GPU 단가가 중요해졌고, 절대 성능보다 달러당 처리량이 더 중요한 워크로드가 많아졌기 때문이에요.

• MXFP4 양자화를 먼저 잡은 이유는 메모리와 연산 비용을 동시에 낮춰야 했기 때문이에요. 다만 양자화는 품질 손실이 나면 의미가 없어서, GPQA-Diamond, tau2, GSM8K에서 손실이 없었다는 검증이 같이 붙어야 설득력이 생겨요.

• sglang을 고른 건 프레임워크 선택이 성능만의 문제가 아니라 지원 경로의 문제였기 때문이에요. vLLM은 필요한 MXFP4 경로가 없었고, ATOM은 긴 컨텍스트 품질이 흔들렸으니, 덜 막히는 쪽을 고르는 게 더 현실적인 선택이었어요.

• TP8에서 TP4×DP2로 바꾼 대목은 워크로드를 보고 병렬화 전략을 바꿔야 한다는 걸 보여줘요. 싱글 스트림 디코딩에 좋은 구성이 긴 입력 prefill 중심 트래픽에서도 좋은 건 아니거든요.

• 마지막 MoE 커널 튜닝은 AMD 생태계의 현재 위치를 잘 보여줘요. 하드웨어가 부족해서가 아니라, 특정 모델 shape에 맞는 튜닝 설정이 빠져서 느린 fallback으로 떨어졌고, 그걸 찾아내자 처리량이 확 올라갔어요.