본문으로 건너뛰기

[sglang] AMD MI355X에서 GLM-5.2 성능 극대화하기: 왜 다시 HIP Top-K인가?

PR 링크: sgl-project/sglang#40148 상태: Merged | 변경: +6 / -6

들어가며: 최신 하드웨어와 최적화의 역설

LLM(Large Language Model) 추론 엔진의 세계에서 '최신 기술'이 항상 '최고의 성능'을 보장하는 것은 아닙니다. 특히 하드웨어 가속기(GPU)와 소프트웨어 커널이 밀접하게 맞물려 돌아가는 환경에서는 더욱 그렇습니다.

최근 SGLang 프로젝트에서 진행된 이 PR(Pull Request)은 AMD의 차세대 가속기인 MI355X 환경에서 GLM-5.2 모델(MXFP4 양자화 버전)의 성능을 최적화하는 과정을 담고 있습니다. 흥미로운 점은, 이전에 도입했던 'Fused Top-K v2' 커널을 제거하고 다시 기존의 precompiled HIP Top-K 경로로 회귀했다는 점입니다.

이 변경을 통해 SGLang은 동시성(Concurrency) 8 환경에서 P90 Interactivity(지연시간)를 10% 개선하는 성과를 거두었습니다. 본 글에서는 실제 코드 변경 사항을 통해 왜 이러한 '회귀'가 실제로는 '진보'였는지 분석해 보겠습니다.

코드 분석: 설정의 단순화와 이미지 갱신

1. Docker 이미지 업데이트 (환경의 안정성 확보)

가장 먼저 눈에 띄는 변화는 베이스 이미지의 태그 변경입니다. AMD ROCm 환경은 소프트웨어 스택의 변화가 빠르기 때문에, 검증된 최신 빌드를 사용하는 것이 중요합니다.

Before:

// docs/src/snippets/configs/zai-org/glm-5.2.jsx
mi355x: "lmsysorg/sglang-rocm:v0.5.13.post1-rocm720-mi35x-20260618",
"mi355x|mxfp4": "lmsysorg/sglang-rocm:v0.5.19-rocm720-mi35x-20260913",

After:

// docs/src/snippets/configs/zai-org/glm-5.2.jsx
mi355x: "lmsysorg/sglang-rocm:v0.5.13.post1-rocm720-mi35x-20260618",
"mi355x|mxfp4": "lmsysorg/sglang-rocm:v0.5.19-rocm720-mi35x-20260916",

단순히 날짜가 0913에서 0916으로 바뀐 것처럼 보이지만, 이 내부에는 sgl-project/sglang#39155 및 #39631과 같은 중요한 버그 수정과 최적화 패치가 포함되어 있습니다. 특히 gfx950(MI355X) 아키텍처에서 발생하던 컴파일러 이슈를 해결한 버전입니다.

2. Top-K 구현체 변경 (핵심 최적화)

이번 PR의 핵심은 SGLANG_OPT_USE_TOPK_V2 옵션을 제거한 것입니다. SGLang에서 이 옵션이 false(기본값)일 경우, 미리 컴파일된(precompiled) HIP Top-K 경로를 사용하게 됩니다.

Before:

// docs/src/snippets/configs/zai-org/glm-5.2.jsx
{
  match: { hw: "mi355x", variant: "default", quant: "mxfp4", strategy: "low-latency", nodes: "single" },
  verified: false,
  env: ["SGLANG_OPT_USE_TOPK_V2=true"],
  // ...
}

After:

{
  match: { hw: "mi355x", variant: "default", quant: "mxfp4", strategy: "low-latency", nodes: "single" },
  verified: false,
  env: [],
  // ...
}

이 변경은 low-latency, balanced, high-throughput, mtp-314 등 모든 MXFP4 전략에 공통적으로 적용되었습니다.

3. 문서 및 가이드 업데이트

코드 변경에 맞춰 사용자 가이드(Cookbook)에서도 관련 설명이 수정되었습니다. 이전에는 TOPK_V2가 성능 향상의 핵심인 것처럼 묘사되었으나, 최신 벤치마크 결과에 따라 해당 내용이 삭제되었습니다.

Before (GLM-5.2.mdx):

The 20260913 image also enables SGLANG_OPT_USE_TOPK_V2=true (v2 fused top-k kernel for GLM-5.x on ROCm...)

After (GLM-5.2.mdx):

(해당 문구 삭제 및 이미지 태그 20260916으로 업데이트)

왜 이게 좋은 최적화인가?

1. 실질적인 지연시간(Latency) 감소

PR 설명에 따르면, 동시성 8(Concurrency 8) 환경에서 P90 Interactivity가 10.0% 향상되었습니다. LLM 서비스에서 P90 지연시간은 사용자 경험을 결정짓는 가장 중요한 지표 중 하나입니다.

반면, 처리량(Throughput) 감소는 -0.15%에 불과했습니다. 즉, 전체적인 연산량은 거의 동일하게 유지하면서도 특정 상황에서 발생하는 병목(Tail Latency)을 획기적으로 줄인 것입니다.

2. 하드웨어 특화 커널의 승리

TOPK_V2는 여러 연산을 하나로 합친(fused) 커널로, 이론적으로는 메모리 대역폭을 절약할 수 있습니다. 하지만 AMD의 HIP(Heterogeneous-compute Interface for Portability) 환경에서 미리 컴파일된(precompiled) Top-K 경로는 하드웨어 아키텍처에 더욱 최적화되어 있을 가능성이 높습니다.

특히 MI355X와 같은 최신 하드웨어에서는 컴파일러의 최적화 수준이나 레지스터 사용량 등에 따라 커스텀 Fused 커널보다 제조사가 제공하거나 고도로 튜닝된 라이브러리 경로가 더 나은 성능을 보여주기도 합니다.

3. 복잡성 제거 (Simplicity)

환경 변수(SGLANG_OPT_USE_TOPK_V2=true)를 명시적으로 관리해야 했던 복잡성을 제거하고, 시스템의 기본값(Default)을 최적의 경로로 설정했다는 점에서 유지보수 측면의 이점도 큽니다.

결론 및 교훈

이 PR은 우리에게 두 가지 중요한 교훈을 줍니다.

  1. 벤치마크는 거짓말을 하지 않는다: 이론적으로 더 우수해 보이는 'Fused Kernel'이라 할지라도, 실제 타겟 하드웨어와 워크로드(Concurrency 8 등)에서의 측정 결과가 우선되어야 합니다.
  2. 최적화는 반복적인 과정이다: 한때 성능을 높여주었던 옵션(TOPK_V2)이 소프트웨어 스택(ROCm 7.2 등)이나 하드웨어가 변함에 따라 오히려 방해가 될 수 있음을 인지하고, 과감히 되돌릴 줄 알아야 합니다.

AMD MI355X와 MXFP4라는 최첨단 환경에서 GLM-5.2 모델을 구동하려는 엔지니어들에게 이번 업데이트는 지연시간 최적화의 정석을 보여주는 좋은 사례가 될 것입니다.

참고 자료

⚠️ 알림: 이 분석은 AI가 실제 코드 diff를 기반으로 작성했습니다.

댓글

관련 포스트

PR Analysis 의 다른글