Gimbal: MoE LLM 서빙에서 DP 스케줄링과 전문가 배치를 동시에 협조시키는 방법
요약
Mixture-of-Experts(MoE) LLM은 추론 비용을 낮추는 유력한 아키텍처지만, 서빙 시스템이 풀어야 할 문제를 두 겹으로 만든다. 첫째, 여러 데이터 병렬(DP) 엔진 사이에 요청이 고르게 분산되지 않는 엔진 불균형. 둘째, 특정 전문가(expert)에 활성화가 집중되는 전문가 핫스팟. 두 문제는 서로 연결되어 있지만, vLLM을 비롯한 기존 서빙 시스템은 이를 각각 독립적으로 처리한다. 프론트엔드는 요청 수만 세고, 백엔드는 집계된 전문가 활성화 빈도만 본다.
Gimbal(arXiv:2606.15177, 2026년 6월)은 이 두 계층의 결정을 하나의 피드백 루프로 묶는 협조 스케줄링 시스템이다. 백엔드의 세밀한 압력 신호(KV 캐시 사용량, 잔여 프리필 작업, 큐 깊이, 전문가 부하)를 프론트엔드 라우팅 결정에 실시간으로 반영하고, 소스 DP 엔진별 전문가 활성화 통계를 전문가 배치에 활용한다. 결과는 vLLM 대비 평균 TTFT -42.9%, TPOT -33.3%, 고부하 처리량 +3.0%다.
문제: MoE 서빙의 두 가지 구조적 도전
MoE 아키텍처 복습
MoE LLM은 각 레이어의 FFN을 N개 전문가 네트워크로 대체하고, 라우터가 토큰마다 K개(K ≪ N)만 활성화한다. 전체 파라미터 수는 밀집 모델보다 많지만 실제 계산량은 K/N배로 줄어든다. Mixtral, DeepSeek, Kimi 등 대규모 오픈 모델 대부분이 이 구조를 채택한다.
문제는 K개 전문가의 선택이 요청 내용에 따라 동적으로 결정된다는 데 있다. 토큰의 도메인, 언어, 작업 유형에 따라 특정 전문가가 집중적으로 선택되는 패턴이 생기고, 이 패턴은 사전에 예측하기 어렵다.
도전 1: DP 엔진 불균형
대규모 MoE 서빙은 모델을 여러 GPU 그룹(DP 엔진)에 복제한다. 요청이 들어오면 프론트엔드 스케줄러가 엔진 중 하나에 배정한다. 기존 방식은 엔진별 큐 길이나 요청 수 같은 거친 지표만 사용한다.
이 거친 지표는 중요한 상태를 놓친다.
- 엔진 A에 요청이 10개 있어도 모두 짧은 요청(prompt 50토큰)이라면 실제 부하는 낮다.
- 엔진 B에 요청이 7개 있어도 모두 긴 요청(prompt 4,000토큰)이라면 KV 캐시가 포화 직전일 수 있다.
결과적으로 "부하가 낮아 보이는" 엔진에 과도한 요청이 쏟아지고, TTFT 꼬리 지연이 폭발한다.
도전 2: 전문가 핫스팟
MoE에서 전문가는 여러 DP 엔진이 공유하거나, 각 엔진이 전문가 집합을 복제하여 보유한다. 어느 방식이든 특정 전문가에 활성화가 집중되면 그 전문가를 담당하는 GPU가 병목이 된다.
기존 전문가 로드밸런싱은 집계된 활성화 수를 보고 전문가를 재배치(migration)한다. 그런데 활성화 패턴은 어느 DP 엔진에서 어떤 유형의 요청이 오느냐에 따라 달라진다. DP 엔진 1이 영어 코딩 요청을 주로 처리하고 엔진 2가 한국어 대화 요청을 처리한다면, 두 엔진이 활성화시키는 전문가 집합이 다르다. 이 소스 의존성을 무시한 전문가 배치는 최적이 아니다.
Gimbal 아키텍처
SJF + aging
SJF + aging
SJF + aging
Gimbal은 세 개의 협조 구성요소로 이루어진다.
- DP 엔진 스케줄러 — 프론트엔드에서 요청을 엔진에 배정
- SJF 큐 순서화 — 각 엔진 내부의 큐 재정렬
- 소스 인식 전문가 배치 — 백엔드의 전문가 물리 배치 조정
계층 1: 세밀한 DP 엔진 스케줄러
네 가지 압력 신호
기존 스케줄러가 "요청 수"만 쓰는 것과 달리, Gimbal은 각 엔진으로부터 네 가지 신호를 실시간으로 수집한다.
| 신호 | 의미 | 포착하는 위험 |
|---|---|---|
| KV 캐시 사용량 | 전체 KV 캐시 중 현재 사용 비율 | 메모리 포화 → OOM 또는 프리엠션 |
| 잔여 프리필 작업 | 아직 처리하지 않은 입력 토큰 수 | 계산 백로그 |
| 큐 압력 | 대기 중인 요청 수 및 예상 대기 시간 | 신규 요청의 지연 예측 |
| 전문가 압력 | 각 전문가의 현재 부하 수준 | 백엔드 핫스팟의 프론트엔드 반영 |
이 네 신호를 종합해 엔진별 압력 점수를 계산하고, 점수가 낮은 엔진에 신규 요청을 배정한다. 전문가 핫스팟이 심한 엔진에는 그 전문가를 많이 활성화할 가능성이 있는 요청을 보내지 않는 것이다.
피드백 루프 설계
압력 신호는 엔진에서 스케줄러로 비동기 폴링 방식으로 전달된다. 동기 방식으로 모든 배정마다 신호를 기다리면 디스패치 자체가 병목이 되므로, Gimbal은 주기적으로 신호를 갱신하고 최신 스냅숏을 기반으로 배정 결정을 내린다.
계층 2: SJF 큐 순서화 with Aging
헤드-오브-라인 블로킹 문제
연속 배치(continuous batching)에서 긴 프리필 요청은 큐의 앞에 자리잡아 뒤에 있는 짧은 요청의 TTFT를 늘린다. 예를 들어 4,000토큰짜리 요청이 배치에 들어가면, 50토큰짜리 요청이 그 뒤에서 기다려야 한다.
SJF(Shortest-Job-First) + Aging
Gimbal은 각 엔진의 내부 큐에서 프리필 길이 예측값(입력 토큰 수)을 기준으로 요청을 재정렬한다. 짧은 요청이 먼저 실행되어 TTFT를 낮춘다.
단순 SJF는 긴 요청을 무한정 뒤로 미룰 수 있다(기아 문제). Gimbal은 aging 메커니즘으로 이를 방지한다. 대기 시간이 길어진 요청의 우선순위를 점진적으로 높여, 결국 실행 기회를 보장한다.
핵심은 출력 길이 예측 없이 입력 토큰 수(이미 알고 있는 값)만으로 구현한다는 점이다. 별도 예측 모델 없이 즉시 적용할 수 있다.
계층 3: 소스 인식 전문가 배치
소스 DP 의존성 통계 수집
Gimbal은 런타임 중 각 DP 엔진이 어떤 전문가를 얼마나 활성화하는지 추적한다. 이 통계를 소스-DP-to-전문가 활성화 행렬로 유지한다. 엔진 1에서 들어오는 요청이 전문가 D와 F를 집중적으로 활성화한다면, 전문가 D와 F는 엔진 1과 통신 비용이 낮은 위치에 배치하는 것이 유리하다.
MINLP 기반 배치 결정
전문가 배치 최적화는 세 목표를 동시에 고려한다.
- 전문가 부하 균형 — 핫스팟 전문가를 여러 GPU로 분산
- 소스 인식 통신 비용 — 어느 엔진에서 어떤 전문가를 자주 부르는지 반영해 GPU 간 통신 최소화
- 마이그레이션 안정성 — 전문가를 너무 자주 이동하면 오버헤드가 발생하므로, 현재 배치에서 크게 벗어나지 않도록 제약
이 세 목표를 수식화하면 혼합 정수 비선형 계획법(MINLP)이 된다. Gimbal은 MINLP를 직접 풀지 않고, MINLP의 최적해를 가이드로 삼은 경량 휴리스틱을 사용해 실시간 적용 가능한 수준으로 계산량을 낮춘다.
성능 결과
벤치마크 조건
논문은 MoE LLM을 DP 엔진 여러 개로 구성한 환경에서, 다섯 가지 서로 다른 요청 분포(다양한 입력 길이, 다양한 도메인 혼합)와 부하 수준을 실험했다. 비교 기준은 vLLM(현재 사실상 표준 서빙 시스템).
주요 수치
| 지표 | Gimbal vs vLLM | 조건 |
|---|---|---|
| 평균 TTFT | -42.9% | 고부하(1.4 RPS 이상) 평균 |
| 평균 TPOT | -33.3% | 고부하 평균 |
| 처리량 | +3.0% | 동일 SLO 조건 |
| TTFT (5개 분포 평균) | -17.76% | 전체 부하 범위 평균 |
| TPOT (5개 분포 평균) | -13.34% | 전체 부하 범위 평균 |
Open question: 어떤 MoE 모델(Mixtral, DeepSeek 등)과 어떤 하드웨어 구성에서 실험했는지 논문 원문(arXiv:2606.15177) 확인 필요.
고부하 조건에서의 효과(TTFT -42.9%)가 전체 평균(-17.76%)보다 큰 이유는, 기존 시스템이 부하가 높을수록 압력 신호의 부재로 더 잘못된 라우팅을 내리기 때문이다.
기존 방식과의 차이
| 항목 | 기존(vLLM 등) | Gimbal |
|---|---|---|
| DP 라우팅 신호 | 요청 수(coarse) | KV 캐시·큐·프리필·전문가 압력(fine-grained) |
| 인트라 엔진 큐 | FCFS(선착순) | SJF + aging |
| 전문가 배치 기준 | 집계 활성화 수 | 소스 DP 의존성 + 통신 비용 + 안정성 |
| 계층 간 피드백 | 없음(독립적) | 실시간 피드백 루프로 연결 |
운영 관점
Gimbal이 특히 효과적인 시나리오
- 혼합 요청 패턴: 짧은 요청(코드 자동완성)과 긴 요청(문서 분석)이 동시에 들어오는 서빙 환경에서 SJF 효과가 두드러진다.
- 도메인 혼합 트래픽: 한국어, 영어, 코딩 등 서로 다른 전문가 활성화 패턴을 만드는 요청이 섞이는 환경에서 소스 인식 배치가 통신 비용을 줄인다.
- 고부하 구간: SLO를 지키기 어려운 피크 트래픽 상황에서 TTFT 개선 효과가 가장 크다.
적용 전 확인 사항
- Gimbal은 프리프린트 단계(2026년 6월)로, 프로덕션 서빙 시스템(vLLM, SGLang)에 공식 통합된 버전은 확인 필요.
- 압력 신호 수집 빈도와 정확도 사이의 트레이드오프는 배포 환경마다 튜닝이 필요하다.
- MINLP 휴리스틱이 전문가 마이그레이션을 얼마나 자주 트리거하는지에 따라 마이그레이션 오버헤드가 발생할 수 있다.
정리
Gimbal은 MoE LLM 서빙의 두 핵심 문제(DP 불균형, 전문가 핫스팟)를 분리된 독립 결정이 아닌 협조된 피드백 루프로 해결한다. 프론트엔드 라우터가 백엔드 전문가 압력 신호를 보고 결정하고, 전문가 배치가 어떤 DP 엔진에서 어떤 전문가를 자주 쓰는지를 반영하는 방식이다. MoE LLM의 보급이 확대될수록, 이런 교차 계층 협조 스케줄링의 중요성은 커진다. vLLM이 단일 엔진에서 연속 배치를 표준화했다면, Gimbal은 다중 엔진 MoE 서빙의 표준 스케줄링 프레임워크가 될 후보다.
References
- Yifan Sun et al., "Coordinated Scheduling for MoE LLM Serving," arXiv:2606.15177, June 2026. https://arxiv.org/abs/2606.15177
- Woosuk Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention," SOSP 2023. https://arxiv.org/abs/2309.06180
- Bingyang Wu et al., "ExpertPlex: A High-Goodput Disaggregated Serving System for MoE LLMs with Adaptive Persistent Kernels," arXiv:2607.18002, July 2026. https://arxiv.org/abs/2607.18002
- Lianmin Zheng et al., "SGLang: Efficient Execution of Structured Language Model Programs," arXiv:2312.07104. https://arxiv.org/abs/2312.07104
- "Dual Routing and Dynamic Scheduling for Efficient On-Device MoE-based LLM Serving (D2MoE)," arXiv:2504.15299, 2026. https://arxiv.org/abs/2504.15299