Lodestar: 온라인 학습으로 LLM 추론 요청을 라우팅하는 방법 (arXiv:2606.00946)

왜 LLM 추론 라우팅이 어려운가

여러 GPU 인스턴스로 구성된 LLM 서빙 클러스터에서 "이 요청을 어느 인스턴스로 보낼 것인가"는 간단해 보이지만 실제로는 풀기 어려운 문제다.

첫째, 실행 시간이 입력에 크게 의존한다. 동일한 요청이라도 컨텍스트 길이나 생성 토큰 수에 따라 지연이 몇 배씩 달라진다. 둘째, 배칭과 KV 캐시 재사용이 요청 간 결합을 만든다. 한 인스턴스에 요청이 몰리면 배칭 효율은 오르지만 큐 대기 시간도 함께 오른다. KV 캐시 히트 여부에 따라 같은 인스턴스로 묶어야 빠를 수도 있고, 분산해야 빠를 수도 있다. 셋째, 이종(heterogeneous) 클러스터에서는 GPU마다 처리 속도가 다르다. A100과 H100이 섞인 클러스터라면 같은 모델도 인스턴스마다 TTFT가 다르게 나온다.

기존 휴리스틱(최소 큐 길이, 최소 부하, 프리픽스-캐시 우선 등)은 이 세 가지를 동시에 고려하지 못한다. Lodestar(arXiv:2606.00946, 2026년 5월)는 온라인 학습으로 이 문제를 풀었다.

Lodestar 아키텍처

온라인 보상 예측기

Lodestar의 핵심은 보상 예측기(reward predictor)다. 매 요청마다 각 인스턴스에 보낼 때 기대되는 보상(예: TTFT 역수)을 예측하고, 가장 높은 점수를 받은 인스턴스로 요청을 보낸다.

예측기의 입력은 두 가지다.

1. 클러스터 상태: 각 인스턴스의 현재 KV 캐시 사용률, 큐에 쌓인 요청 수, GPU 활용률, 처리 중인 요청 수
2. 요청 특성: 컨텍스트 길이, 프리픽스 캐시 히트 여부, 예상 생성 길이

예측기는 실제 TTFT 피드백을 받아 온라인으로 갱신된다. 별도의 오프라인 훈련 단계 없이, 서빙 시작 후 실제 트래픽을 처리하면서 약 5분 안에 효율적인 라우팅 전략을 학습한다.

이 접근법의 장점은 클러스터 구성이 바뀌거나 워크로드 패턴이 달라져도 스스로 적응한다는 점이다. 새 인스턴스가 추가되거나 GPU 모델이 교체되면 잠시 탐색 페이즈를 거친 뒤 새 환경에서 최적 라우팅을 다시 학습한다.

성능 결과

UIUC·ByteDance·에든버러대 연구팀이 다양한 클러스터 구성에서 상태-최신 휴리스틱(프리픽스-캐시 우선 + 부하 인식 라우팅)과 비교한 결과다.

이종 클러스터에서 개선이 특히 큰 이유는, GPU마다 처리 속도가 다를 때 휴리스틱은 인스턴스를 동등하게 대우하지만 Lodestar는 각 인스턴스의 실제 처리 능력을 학습하기 때문이다.

기존 라우터와의 차이

Lodestar는 vLLM과의 통합을 목표로 설계되어, 기존 서빙 스택을 크게 수정하지 않고 라우터 레이어만 교체하는 방식으로 배포할 수 있다.

운영자 관점

Lodestar가 실제로 도입 가치가 있는 상황은 두 가지다. 첫째, GPU 모델이 섞인 클러스터를 운영할 때 — 이종 클러스터에서 최대 4.38×의 TTFT 개선이 측정되었다. 둘째, 워크로드 패턴이 시간대별로 크게 달라질 때 — 온라인 학습 특성상 트래픽 변화에 자동으로 따라간다.

동종 클러스터에서 안정적인 워크로드를 처리한다면 기존 프리픽스-캐시 우선 라우팅과의 차이가 상대적으로 작을 수 있다. 단, 프로덕션 환경에서 클러스터 구성이 자주 바뀌거나 새 인스턴스가 추가되는 경우라면 재튜닝 없이 자동 적응하는 Lodestar의 특성이 운영 부담을 낮출 수 있다.

References

• https://arxiv.org/abs/2606.00946
• https://arxiv.org/html/2606.00946v1
• https://arxiv.org/pdf/2606.00946