프롬프트만 정렬해도 MoE 추론이 12~17% 빨라진다

Hugging Face 블로그의 이 글은 MoE(Mixture-of-Experts) 모델의 배치 추론에서 요청 순서를 바꾸는 것만으로 속도를 높일 수 있다고 보여 준다. 배치 안의 어느 요청이든 라우팅한 전문가의 가중치는 모두 읽어야 하므로, 코드·수학·언어처럼 서로 다른 도메인이 섞이면 읽는 전문가가 늘어난다. 비슷한 요청을 모아 함께 디코딩하면 이 낭비가 줄어든다.

"Just sorting the prompts before calling llm.generate, so that similar requests end up decoding together, made unmodified vLLM +12–17% faster."Hugging Face Blog

왜 중요한가

추론 최적화는 보통 커널이나 모델 구조를 건드려야 한다고 여겨진다. 이 방법은 호출 전에 프롬프트를 정렬하고 생성 후 원래 순서로 복원하기만 하면 된다. 정렬 기준은 prefill 단계의 라우터 활성 패턴(fingerprint)이나 0.6B 임베딩 모델과 k-means 클러스터링이다. 보고된 수치로 Qwen3-30B-A3B는 도메인 라벨 기준 배치 16~128에서 12~17%, 임베딩 클러스터링은 5% 안팎의 처리량 향상을 얻었고, gpt-oss-120b는 각각 7~12%와 2~4%였다.

실무 적용

효과는 조건부다. 밀집(dense) 모델, prefill 비중이 큰 작업, 매우 큰 배치에서는 이득이 줄고, 대기열 지연이 생기므로 지연에 민감한 온라인 서빙에도 맞지 않는다. 반면 대량 문서 분류, 요약, 평가 파이프라인 같은 오프라인 배치 작업이라면 도입 비용이 거의 없다. 이론상 절감 가능한 메모리 읽기량의 약 절반만 실현된다는 점도 기대치를 잡을 때 참고할 만하다.

교차 참고

• Hugging Face: SlideOn & mSlideOn — 기존 임베딩을 역색인과 호환되는 희소 검색기로 바꿔 효율을 높이는 LightOn의 모델(174M, 339M).
• Hugging Face: Tokenmaxxing BERT: 50x faster tokenization — 모델이 아닌 주변 파이프라인에서 속도를 찾는 또 다른 사례.

Wemeet의 관점

Wemeet은 AI 기능의 비용을 모델 선택만의 문제로 보지 않는다. 호출 방식과 데이터 흐름을 바꾸는 작은 최적화가 청구서에 더 크게 반영될 때가 많다. 야간 배치로 콘텐츠를 생성하거나 분류하는 기능을 설계한다면, 요청을 성격별로 묶어 처리하는 큐 구조를 처음부터 넣어 두는 것이 합리적이다.