TokenRouter: 토큰 단위 LLM 라우팅을 위한 효율적 서빙 시스템
들어가며
현재 운영되는 LLM 라우터는 대체로 세션이나 요청 단위로 모델을 선택합니다. 입력의 난이도나 목적을 판단한 뒤 전체 생성을 하나의 모델에 맡기는 방식입니다. 구현과 운영이 비교적 단순하지만, 생성 과정에서 토큰마다 달라지는 요구 사항을 반영하기에는 한계가 있습니다.
토큰 단위 라우팅은 이 결정을 생성 단계까지 세분화합니다. 현재 상태에 따라 각 토큰을 서로 다른 모델로 보낼 수 있기 때문에 품질, 비용, 지연 시간 사이의 균형을 더 정밀하게 조정할 여지가 있습니다. 하지만 기존 추론 시스템은 단일 LLM과 동기화된 디코딩 단계를 중심으로 설계된 경우가 많습니다. 여러 모델로 작업이 나뉘면 모델마다 처리 속도가 달라지고, 실행 단계가 서로 어긋날 수 있습니다. 또한 각 모델에 전달되는 요청이 분산되면서 효율적인 배치를 구성하기까지 기다리는 시간도 늘어날 수 있습니다.
TokenRouter의 접근법
TokenRouter는 새로운 라우팅 알고리즘을 제안하기보다, 토큰 단위 라우팅을 실제로 실행하기 위한 서빙 구조에 초점을 맞춥니다. 핵심 원칙은 “요청 중심 프로그래밍, 모델 중심 실행”입니다. 개발자는 하나의 요청을 기준으로 라우팅 로직을 작성하고, 런타임은 LLM마다 별도의 서브서버를 실행한 뒤 요청을 비동기적으로 분배합니다.
이 구조는 라우팅 로직과 모델별 실행을 분리합니다. 개발자가 각 모델의 내부 실행 상태와 스케줄링을 일일이 제어할 필요가 줄어들며, 각 서브서버는 자신에게 들어온 부하와 모델 속도에 맞춰 작업을 진행할 수 있습니다. 모든 모델을 하나의 동기화된 실행 루프에 맞추지 않아도 된다는 점이 중요한 특징입니다.
각 서브서버에는 지연 배칭 스케줄러도 적용됩니다. 요청이 도착하는 즉시 처리하는 대신, 조금 더 기다려 큰 배치를 만들었을 때의 처리량 이득과 추가 대기 시간을 비교합니다. TokenRouter는 시스템 처리량을 나타내는 수학적 모델을 바탕으로 스케줄러의 주요 하이퍼파라미터를 도출해 경험에만 의존한 조정을 줄이려 합니다.
핵심 내용
- 요청 단위가 아닌 토큰 단위 모델 라우팅을 지원합니다.
- LLM별 독립 서브서버를 사용합니다.
- 모델 서버 사이의 작업을 비동기적으로 분배합니다.
- 동적 분배로 발생하는 작은 배치 문제를 지연 배칭으로 완화합니다.
- 처리량 모델을 사용해 스케줄러 설정을 정합니다.
- 여러 라우팅 알고리즘, 워크로드, 모델 조합에서 평가했습니다.
- 기존 시스템 대비 2.01~64.15배 높은 디코딩 처리량을 보고했습니다.
의미와 한계
TokenRouter가 보여주는 핵심은 토큰 단위 라우팅이 알고리즘만의 문제가 아니라는 점입니다. 라우팅 전략이 품질이나 비용 측면의 이론적 이점을 제공하더라도, 동기화와 스케줄링 오버헤드가 크면 실제 서비스에서 효과를 내기 어렵습니다. 요청 수준의 프로그래밍과 모델 수준의 실행을 분리하는 방식은 서로 다른 능력과 처리 속도를 가진 모델을 조합하기 위한 비교적 명확한 시스템 추상화를 제공합니다.
다만 제공된 자료만으로는 전체 하드웨어 구성, 각 비교 대상의 구현 세부 사항, 실험별 절대 처리량을 확인할 수 없습니다. 따라서 보고된 배수 향상이 모든 운영 환경에서 동일하게 재현된다고 단정할 수는 없습니다. 모델 조합, 트래픽 패턴, 라우팅 분포에 따라 결과가 달라질 수 있습니다. 그럼에도 TokenRouter는 “요청마다 하나의 모델을 고르는” 구조에서 “토큰마다 모델을 선택하는” 구조로 이동할 때 필요한 추론 서빙의 방향을 제시합니다.
댓글
로그인 상태 확인 중…
댓글 불러오는 중…