--- title: "AMD MI355X에서 GLM5.2 추론을 블랙웰보다 2배 이상 싸게 굴린 사례" published: 2026-07-03T21:49:06.000Z canonical: https://jeff.news/article/4628 --- # AMD MI355X에서 GLM5.2 추론을 블랙웰보다 2배 이상 싸게 굴린 사례 Wafer가 AMD MI355X에서 GLM5.2를 서빙하며 노드당 2626 tok/s, 싱글 스트림 213 tok/s를 달성했다고 공개했다. NVIDIA Blackwell 대비 성능은 일부 낮지만 GPU 비용이 훨씬 낮아 성능 대비 비용에서는 AMD가 유리하다는 주장이다. ## 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등 숫자는 아니어도, 성능 대비 비용으로는 이긴다는 논리임 > [!IMPORTANT] > 같은 워크로드에서 Blackwell 측정치는 3192 tok/s/node @ 3.0 rps였고, MI355X는 튜닝 후 2626 tok/s/node @ 2.4 rps까지 올라감. 절대 성능보다 ‘달러당 토큰’이 이 글의 진짜 포인트임. ## 문제는 하드웨어보다 소프트웨어 지원이었음 - 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로 언급됨 > [!NOTE] > 결론은 “AMD가 무조건 빠르다”가 아님. 최신 모델을 AMD에서 잘 굴리려면 아직 프레임워크와 커널 경로를 직접 확인해야 하지만, 그 마찰이 예전보다 훨씬 줄고 있다는 쪽에 가까움. --- ## 기술 맥락 - 이 글의 핵심 선택은 NVIDIA Blackwell 대신 AMD MI355X에서 최신 MoE 모델을 비용 효율적으로 서빙하는 거예요. 추론 수요가 폭증하면서 GPU 단가가 중요해졌고, 절대 성능보다 달러당 처리량이 더 중요한 워크로드가 많아졌기 때문이에요. - MXFP4 양자화를 먼저 잡은 이유는 메모리와 연산 비용을 동시에 낮춰야 했기 때문이에요. 다만 양자화는 품질 손실이 나면 의미가 없어서, GPQA-Diamond, tau2, GSM8K에서 손실이 없었다는 검증이 같이 붙어야 설득력이 생겨요. - sglang을 고른 건 프레임워크 선택이 성능만의 문제가 아니라 지원 경로의 문제였기 때문이에요. vLLM은 필요한 MXFP4 경로가 없었고, ATOM은 긴 컨텍스트 품질이 흔들렸으니, 덜 막히는 쪽을 고르는 게 더 현실적인 선택이었어요. - TP8에서 TP4×DP2로 바꾼 대목은 워크로드를 보고 병렬화 전략을 바꿔야 한다는 걸 보여줘요. 싱글 스트림 디코딩에 좋은 구성이 긴 입력 prefill 중심 트래픽에서도 좋은 건 아니거든요. - 마지막 MoE 커널 튜닝은 AMD 생태계의 현재 위치를 잘 보여줘요. 하드웨어가 부족해서가 아니라, 특정 모델 shape에 맞는 튜닝 설정이 빠져서 느린 fallback으로 떨어졌고, 그걸 찾아내자 처리량이 확 올라갔어요. ## 핵심 포인트 - MI355X는 B300 대비 GPU당 평균 약 2.75배 저렴하다고 설명됨 - 20k 입력·1k 출력·60% 캐시 히트율 워크로드에서 2626 tok/s/node와 2.4 rps를 기록함 - MXFP4 양자화, sglang 선택, speculative decode 수정, MoE 커널 튜닝이 주요 최적화 포인트였음 ## 인사이트 ‘CUDA 해자가 무너진다’는 말을 숫자와 삽질 로그로 보여주는 글에 가깝다. AMD 추론은 아직 day-0 경험이 매끄럽지 않지만, 프레임워크 버그 몇 개와 커널 선택만 잡아도 비용 효율이 꽤 현실적인 수준까지 올라온다는 게 포인트임.