AWS가 10월 13일 SageMaker AI의 MoE 커널 최적화 결과를 공개했습니다. 모델 발표가 아니라 커널 손질 이야기라 조용해 보이지만, 대형 모델을 직접 서빙하는 팀에는 더 와닿는 숫자입니다.

처리량: 최대 10% 증가 (H200, FP8 MoE)
첫 토큰(TTFT): 최대 9% 단축 (H200, 8-way 병렬)
공개: vLLM·LMI 컨테이너에 오픈소스로 반영
단서: 모델·하드웨어 구성에 따라 달라짐

세 가지 손질을 하나씩 뜯어보겠습니다.

① 행렬 뒤집기: WGMMA에 맞게 눕혔다 (2~4%)

Hopper GPU의 WGMMA 명령은 행렬 행(M) 방향으로 최소 64줄을 기대합니다. 그런데 MoE 디코드 단계에서는 토큰을 하나씩 처리하느라 M=1이 자주 나옵니다.

기대: M=64줄 가득 채워 Tensor Core 밀도 최대
현실: M=1이라 대부분 유휴

AWS의 처방은 곱셈 전에 행렬을 뒤집어 큰 expert 차원(N=8192)을 앞 operand에 놓는 것입니다. 큰 덩어리가 앞에 오니 64줄 기준을 쉽게 넘기고, 비동기 프리페치까지 매끈해집니다. 대규모 MoE에서 출력 처리량 2~4% 개선, vLLM 0.24.0부터 사용 가능합니다.

② 백엔드 라우팅: CUTLASS 대신 Triton (10%)

가장 큰 한 방은 코드 수정이 아니라 설정 변경이었습니다. FP8 양자화 MoE에서 기본 FLASHINFER_CUTLASS 경로 대신 Triton 백엔드로 돌렸더니 끝단 처리량이 10% 올랐습니다.

CUTLASS: 스케일링·곱셈·집계를 단계별로, 전역 메모리 왕복 발생
Triton: 한 번의 하드웨어 패스로 합침, HBM에서 한 번 읽고 레지스터에서 처리
낮은 동시성·얇은 배치에서 특히 유리

주의할 점은 “Triton이 항상 빠르다”가 아니라는 겁니다. 하드웨어·양자화·토큰 수·동시성에 따라 다르니, AWS 수치는 Hopper 저동시성 FP8 조건의 프로파일링 결과로 읽어야 합니다. 적용은 LMI v28 컨테이너의 라우팅 정책 변경으로 됩니다.

③ JIT 재컴파일 제거: 매번 다시 짓지 않기 (TTFT 9%)

세 번째는 회전 위치 임베딩+FP8 양자화 융합 커널이 토큰 수 바뀔 때마다 재컴파일되던 문제입니다. Triton은 기본적으로 정수 인자를 특수화해서, 길이가 바뀌면 다시 짓습니다. 멀티 GPU에서는 한 대가 짓는 동안 나머지가 기다립니다.

처방: 가변 길이 파라미터에 do_not_specialize 지정
효과: 재컴파일 제거, H200 8-way에서 TTFT 9% 개선
반영: vLLM 0.22.0 이후 (PR #42849)

코드 몇 줄 수준의 손질로 첫 토큰이 빨라졌다는 게 포인트입니다.

그래서 우리 팀은 무엇을 하면 되나

모델을 직접 서빙한다면 순서가 있습니다.

① vLLM 버전 확인 (0.22+ 인지, 0.24+ 인지)
② FP8 MoE라면 백엔드 라우팅 비교 (Triton vs CUTLASS, 내 트래픽으로)
③ 처리량·TTFT를 함께 측정 (평균이 아니라 p95·분포)
④ LMI 컨테이너면 v28 이상으로 올려 라우팅 정책 적용

그리고 AIPerf 글의 교훈을 붙이세요. 합성 균일 부하만 통과한 서버가 실제 트래픽에서 무너집니다. 동시성을 올리는 sweep에서 p95가 꺾이는 지점이 진짜 sweet spot입니다.

MoE active 파라미터 글과도 이어집니다. 토큰당 계산 경로(active)가 작아도 서빙 효율은 라우팅·메모리 대역폭·병렬 방식이 결정합니다. 커널 경쟁이 바로 그 층의 싸움입니다.

CodeBridge Mini Lab: 오늘 버전 번호부터 확인하기

[ ] vLLM / LMI 컨테이너 버전이 최적화 포함 버전인가
[ ] MoE 백엔드가 무엇으로 라우팅되는가
[ ] 처리량·TTFT를 내 트래픽으로 쟀는가 (벤더 수치 아님)
[ ] 낮은 동시성 디코드 조건이 우리와 맞는가

가장 싼 실험은 두 번째입니다. 백엔드만 바꿔 같은 트래픽으로 돌려보는 것, 코드 수정 없이 됩니다.

결론: 모델 성능의 절반은 엔진 싸움이다

한 문장으로 정리합니다.

프론티어 경쟁은 모델 반, 추론 엔진 반이다.

WGMMA 맞추기 2~4%, 백엔드 고르기 10%, 재컴파일 없애기 9%. 어느 것도 모델을 바꾸지 않았습니다. MoE를 운영한다면 이번 주에 버전과 라우팅부터 보세요. 거기에 10%가 있을 수 있습니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

토큰 비용·지연 시간·처리량을 함께 보며 아키텍처를 고르는 연습이 이 글의 측정 이야기와 바로 이어집니다. 검색과 생성을 잇는 설계부터 손에 익혀보세요.