LLMRouter(arXiv:2608.06867) 정리했습니다. 핵심은 이겁니다. 쿼리마다 어떤 LLM으로 보낼지 정하는 라우팅을 하나의 순차 의사결정 프로세스로 통합하고, 라우터 16종 이상을 같은 후보 풀·같은 프로토콜로 비교하는 오픈소스 인프라입니다.
일리노이 UIUC 중심 연구진이 만들었구요, 라우팅 연구가 각자 다른 코드베이스·다른 후보 풀로 흩어져 있어서 공정 비교가 안 되던 문제를 정면으로 풉니다.
핵심 수치부터 보시면 됩니다.
| 항목 | 값 |
|---|---|
| 후보 모델 풀 | 오픈웨이트 18종 · 7B–671B |
| 구현 라우터 | 16종 이상 · 싱글턴/멀티턴/개인화 3계열 |
| 학습 라우터 vs 최강 고정 모델 | 상대 개선 +14.6% |
| 실사용자 배포 | 15명 · 세션 40개 · 선호쌍 234개 |
| 실사용자 선택 정확도 1위 | PersonalizedRouter 83.05% |
배경: 라우터끼리 비교가 안 되던 문제
모델이 싸고 비싼 것까지 섞여 다양해진 지금, 배포에서는 “어떤 쿼리를 어떤 모델로 보낼지”가 실비용 문제입니다. 그래서 라우터 연구가 많이 나왔는데 비교가 안 됐습니다.
이유는 두 개입니다.
- 각 라우터가 서로 다른 formalism, 별도 코드베이스, 다른 후보 풀, 다른 학습 데이터를 씀. 성능 차이가 라우터 덕인지 실험 스택 덕인지 분리가 안 됩니다
- 라우터 평가는 후보 모델 전부 × 벤치마크 쿼리 전부를 실행하고 채점해야 해서 비쌉니다. 기존 벤치마크는 고정 풀·싱글턴 한정이라 멀티턴·개인화는 표준 평가 자체가 없었습니다
논문은 이 두 병목을 “통합 formulation + 자동 감독 구축 파이프라인”으로 지웁니다.
구조: 라우팅을 순차 의사결정 프로세스로 통합
그림 1. LLM 라우팅 개요: 3가지 니즈와 통합 formulation. 출처: 논문 Figure 1.
정식화는 단순합니다. 라우터는 매 스텝 상태(쿼리 q, 사용자 컨텍스트 u, 히스토리 h)를 보고 후보 모델 하나를 고르거나 종료합니다. 목표식은 성능에서 비용을 뺀 것입니다.
π* = argmax E[ perf(y|q) − λ · c(τ) ]
모든 기존 라우터는 다음 5개 구성요소 선택으로 기술됩니다.
| 구성요소 | 역할 | 예시 |
|---|---|---|
| 컨텍스트 인코더 | 쿼리·히스토리 표현 | 문장 임베딩, 텍스트 프롬프트 |
| 모델 인코더 | 후보 모델 표현 | 메타데이터, Elo 레이팅, 학습 임베딩 |
| 스코어링 함수 | 상태×모델 점수 | MLP, 그래프 스코어러 |
| 결정 규칙 | 액션 선택 | argmax, 캐스케이드, 탐색 |
| 학습 신호 | 구성요소 학습 | 지도학습, RL, 선호 피드백 |
계열 구분도 여기서 나옵니다. 싱글턴은 쿼리만, 멀티턴은 히스토리까지, 개인화는 사용자 컨텍스트까지 상태에 넣는 겁니다. 개인화는 컨텍스트 인코더만 바꾸면 나머지 구성요소를 그대로 상속합니다.
LLMRouter 라이브러리: 새 라우터를 메서드 하나로 추가
그림 2. LLMRouter 시스템 구조. 출처: 논문 Figure 3.
라이브러리의 실용 포인트는 확장 비용입니다. 새 라우터를 추가하려면 라우팅 메서드와 로스 함수만 구현하면 됩니다. 데이터 구축, 학습, 추론, 평가는 공용 파이프라인을 그대로 씁니다. 후보 풀이나 학습 목표를 바꾸는 것도 재구현 없이 설정 변경으로 끝납니다.
내장 라우터는 16종 이상입니다.
- 싱글턴: kkNN, SVM, MLP, Elo, MF, RouterDC, Hybrid LLM, AutoMix, GraphRouter, CausalLM + 최소/최대 모델 고정 규칙
- 멀티턴: Router-R1, kkNN-MultiRound, LLM-MultiRound
- 개인화: GMTRouter, PersonalizedRouter
배포층도 같이 옵니다. 임의 라우터를 OpenAI 호환 서버로 띄울 수 있어서 OpenClaw로 Slack 같은 메신저에 붙여 실배포할 수 있구요, ComfyUI 기반 비주얼 인터페이스로 코드 없이 프로토타이핑도 됩니다.
xRouteBench: 다섯 트랙 벤치마크와 18개 후보
그림 3. xRouteBench 태스크 구성. 출처: 논문 Figure 2.
벤치마크는 5개 트랙으로 구성됩니다. 일반 LLM 과제, 메모리 증강(LoCoMo, LongMemEval), 비전(Geometry3K, MathVista, 비디오), 시계열, 개인화입니다. 8개 테스트셋이 같은 프로토콜 아래 들어갑니다.
후보 풀은 오픈웨이트 18종, 7B부터 671B까지입니다.
- 소형: Mistral-7B, Llama-3-8B, Qwen2.5-7B, Gemma-2-9B, GPT-OSS-20B, RNJ-1-15B
- 중형: Mixtral-8x7B/8x22B, Mistral-Small-24B, Qwen3-Next-80B, Llama-3-70B/3.3-70B, GPT-OSS-120B, Llama-4-Maverick
- 대형: DeepSeek-V3.1(671B), Cogito-v2(671B)
감독 데이터 구축도 자동입니다. 벤치마크 쿼리마다 후보 전부를 돌리고 태스크별 메트릭으로 채점하면서 토큰 단위 비용을 기록합니다. 이 기록이 라우터 학습·평가의 공통 감독이 됩니다.
결과 1: 학습 라우터가 최대 모델 고정을 이긴다
그림 4. 라우터별 성능-비용 트레이드오프. 출처: 논문 Figure 6.
품질만 보는 설정(α,β)=(1.0,0.0)에서 항상 제일 큰 모델을 부르는 Largest-LLM은 평균 38.72입니다. 학습된 싱글턴 라우터는 GraphRouter 45.46, SVMRouter 45.10, EloRouter 44.68입니다.
해석은 논문이 명확히 줍니다. 제일 큰 모델이 틀리는 쿼리를 더 작고 싼 모델들이 맞추는 경우가 많아서, 학습 라우터가 저렴한 모델로 돌려도 성적이 오릅니다. 최대 모델 고정은 비용이 제일 높으면서 성적은 중간이라 학습 라우팅에 지배당합니다. 종합 상대 개선이 +14.6%입니다.
결과 2: 멀티턴 라우팅이 싱글턴을 못 이긴다
같은 표에서 제일 눈에 띄는 구간입니다.
| 라우터 | 평균 |
|---|---|
| Router-R1 | 22.30 |
| kkNN-MultiRound | 23.20 |
| LLM-MultiRound | 22.37 |
| 싱글턴 상위권 | 38~45 |
쿼리를 분해하고 응답을 집계하는 라운드가 비용과 중복 정보만 늘립니다. 분해·집계를 Qwen2.5-3B-Instruct가 맡아서 이 베이스 역량에 성적이 달려 있다는 지적도 있습니다. 논문은 충분성 추정과 조기 종료 설계가 남은 과제라고 정리합니다.
결과 3: 비용 가중치를 올리면 순위가 뒤집힌다
그림 5. 비용 가중치 β 증가에 따른 라우터 순위 변화. 출처: 논문 Figure 5.
평가는 품질-비용 가중 보상 α·perf − β·cost로 하구요, β를 0.0에서 0.8까지 스윕하면 순위가 크게 흔들립니다.
- RouterDC는 품질만 보면 일반 과제 1위(80.56)인데, 비용 민감 설정에서는 11개 중 10위로 떨어집니다
- MLPRouter는 비전 트랙 최하위였다가 β≥0.4부터 그 트랙 1위가 됩니다
그래서 라우터 선택은 예산 체제에 맞춰야 합니다. 어느 한 시점의 리더보드만 보고 결정하면 실제 운영 조건에서 어긋납니다.
결과 4: 개인화는 실사용자 검증까지 봐야 한다
그림 6. 실사용자 세션에서의 라우터 성능. 출처: 논문 Table 4.
개인화 트랙은 두 단계로 확인됩니다.
| 설정 | 1위 | 상위 | 비고 |
|---|---|---|---|
| 페르소나 심판 | GMTRouter 68.78 | PersonalizedRouter 67.86, EloRouter 66.40 | 시뮬레이션 |
| 실사용자(OpenClaw+Slack) | PersonalizedRouter 83.05 | EloRouter 82.20, MLPRouter 78.81 | GMTRouter는 70.70로 6위 |
15명이 40세션 동안 쌍별 비교 234개를 만들었구요, 세션 기준으로 학습/테스트를 나눠 실사용자 선호와의 일치율을 봤습니다. 시뮬 1위가 실전 6위로 떨어진 것에서 알 수 있듯, 개인화 라우터는 실피드백 검증이 필수입니다.
결과 5: 멀티에이전트 시스템의 노드별 라우팅
멀티에이전트 시스템(MAS)은 보통 모든 노드가 같은 베이스 모델을 공유합니다. 논문은 노드 프롬프트(기획/실행/검증)마다 라우터가 모델을 고르는 걸로 바꿔서 다섯 가지 토폴로지(Star, Tree, Graph, Chain, Plan-Exec-Sum)에서 테스트합니다.
학습 라우터 7개 중 6개가 Largest-LLM(71.48)을 상회했구요, MFRouter가 76.48로 최고입니다. 에이전트 파이프라인에서 노드별 모델 배정은 저비용으로 성능을 올릴 수 있는 지점입니다.
실무에서 가져갈 점
- 최대 모델 고정 전략은 비용과 성적이 같이 나쁠 수 있습니다. 라우팅으로 가져올 수 있는 이득이 실측됩니다
- 라우터 도입은 예산 체제별 순위를 보고 고르시면 됩니다. 비용 가중치에 따라 1위가 바뀝니다
- 멀티턴·에이전트형 라우팅이 자동 이득은 아닙니다. 분해·집계를 맡는 모델 역량이 병목입니다
- 개인화 라우터는 실사용자 선호로 검증하세요. 시뮬 순위가 실전에 그대로 안 넘어옵니다
- 멀티에이전트 파이프라인이라면 노드별 모델 배정부터 바꿔볼 만합니다
한계
- 후보 풀이 오픈웨이트 18종 중심입니다. 클로즈드 프론티어 모델과의 비교는 별도 과제로 남습니다
- 개인화 트랙의 심판 비용은 보고 비용에서 제외됩니다
- 멀티턴·RL 라우터는 가중 목적함수를 최적화하지 못해서 단일 설정으로만 실행됩니다
더 실습해보고 싶은 분들께
모델 라우팅·멀티에이전트 자동화는 결국 에이전트 루프 설계 문제와 맞닿아 있습니다. 실습이 필요하시면 아래 두 개를 추천합니다.