어떤 질문엔 값싼 모델로, 어떤 질문엔 비싼 모델로 – LLM 라우터를 공정하게 비교하는 통합 플랫폼

arXiv:2608.068672026-08-06

LLMRouter: Unified Infrastructure for Developing, Evaluating, and Deploying LLM Routers

질문마다 어떤 LLM에 보낼지 결정하는 'LLM 라우터'들은 각자 다른 방식으로 만들어져 서로 비교하기 어려웠다. 이 논문은 라우팅을 하나의 공통 틀(문맥 인코더, 모델 인코더, 점수 함수, 결정 규칙, 학습 신호)로 정리하고, 이를 바탕으로 벤치마크 xRouteBench와 오픈소스 인프라 LLMRouter를 만들었다. 16개 이상의 라우터를 같은 조건에서 실험한 결과, 학습된 라우터가 가장 강력한 단일 모델보다 14.6% 더 나은 성능을 보였다.

METAL MEDIA 해설 도표

LLMRouter 통합 구조: 질문에서 응답까지

증거 상태측정 결과가 보고됨

라우팅 상태 입력질문(q), 사용자 맥락(u), 지금까지의 대화 이력(h)이 합쳐져 라우터가 보는 상태가 된다.
5가지 구성요소로 라우터 정의문맥 인코더, 모델 인코더, 점수 함수, 결정 규칙, 학습 신호라는 다섯 부품의 조합으로 어떤 라우터든 표현한다.
자동 데이터 파이프라인질문 수집 → 18개 후보 모델에 모두 질의해 응답·토큰수 수집 → 과제별 지표와 가격으로 채점, 이렇게 만들어진 질문-모델 행렬이 학습·평가 자료가 된다.
xRouteBench 5개 트랙 평가일반 LLM 과제, 기억, 시각, 시계열, 개인화 트랙에서 같은 후보 풀·지표로 16개 이상의 라우터를 성능과 비용 두 축으로 비교한다.
실배포 검증Slack을 통한 실제 사용자 선호 수집과 5가지 멀티에이전트 협업 구조 실험으로 벤치마크 결과가 실사용 환경에서도 유지되는지 살핀다.

METAL MEDIA이 원문을 바탕으로 재구성한 해설 도표이며, 논문 저자의 원문 figure가 아닙니다.

무엇을 했나

여러 LLM 라우터들이 서로 다른 설계와 코드로 만들어져 공정한 비교가 어려웠던 문제를, 라우팅을 순차적 의사결정 과정으로 통합해 다섯 가지 구성요소(문맥 인코더, 모델 인코더, 점수 함수, 결정 규칙, 학습 신호)로 정리했다.
이 통합 틀을 바탕으로 후보 모델들을 벤치마크에 자동으로 돌려 정답 여부와 비용을 함께 기록하는 파이프라인을 만들고, 이를 이용해 일반 LLM 과제, 기억(memory), 시각, 시계열, 개인화 라우팅을 아우르는 벤치마크 xRouteBench(4,767개 문항)를 구축했다.
16개 이상의 대표적 라우터를 하나의 인터페이스로 구현한 오픈소스 인프라 LLMRouter를 공개했으며, Slack 등 메신저 배포와 코드 없이 조립 가능한 ComfyUI 시각 인터페이스도 지원한다.
18개 후보 LLM(7B~671B, 두 API 제공사)과 5개 트랙에서 실험한 결과, 학습된 라우터가 가장 강력한 고정 모델보다 평균 14.6% 더 나은 성능을 보였고, 비용 제약이 커질수록 가벼운 라우터가 더 경쟁력을 가졌으며, 사용자 맥락을 반영한 개인화 라우팅이 꾸준히 성능을 높였다.
실제 Slack 사용자 234건의 선호 데이터와 5가지 멀티에이전트 협업 구조에도 라우터를 적용해, 오프라인 벤치마크 순위가 실제 사용자 반응과 항상 일치하지는 않음을 확인했다.

Figure 1: Overview of LLM routing. Routing is driven by three needs (left), namely cost efficiency, capability matching, and user preference. Our unified formulation (right) casts all of them as one decision process: a context encoder Eq represents the routing state of query, persona, and interaction history, a model encoder Em represents each candidate, and the router dispatches the query or its sub-queries to selected models and aggregates their responses into the answer. The single-turn, multi-turn, and personalized families differ only in which part of the state they observe.

Table 1: Instantiation of the unified routing formulation for the three router families. For each family, the table specifies the routing state s, the context and model encoders Eq and Em, the routing action defined by the scoring function g and decision rule d, and the learning signal ℒ used to optimize response quality and inference cost.
Family	State s	Encoders Eq,Em	Routing action (scoring g, decision d)	Learning signal ℒ (surrogate of Eq. 1)
Single-turn	(q)	Eq(q),Em(m)	a=arg⁡maxm∈ℳ⁡g⁡(Eq(q),Em(m))	fit g to per-candidate reward perf⁡(ym∣q)−λcm
Multi-turn	(q,ht)	Eq(q,ht),Em(m)	at∼d⁡({g⁡(Eq(q,ht),Em(m))}m)	maximize episode return 𝔼τ[perf⁡(y∣q)−λc(τ)]
Personalized	(q,u,ht)	Eq(q,u,ht),Em(m)	a=arg⁡maxm∈ℳ⁡g⁡(Eq(q,u,ht),Em(m))	fit g to comparisons m+≻um− observing perfu

Figure 2: Task composition of xRouteBench. The benchmark covers generic LLM tasks, memory, vision, time-series, and personalized routing, with percentages indicating the proportion of test queries contributed by each dataset.

Table 2: Results on xRouteBench under the performance-first setting (α,β)=(1.0,0.0). Scores are reported across the Generic LLM Tasks, memory, vision, and time-series tracks, together with their average. Following the original implementations where applicable, all multi-turn routers use Qwen2.5-3B-Instruct as the base model. Top two results are highlighted in bold and underline.
Router	Generic LLM Tasks	Memory	Vision	TimeSeries	Avg
LoCoMo	LongMemEval	Geometry3K	MathVista	Video
Rule-based baselines
Smallest-LLM	57.55	25.44	36.77	27.87	35.00	33.33	49.61	37.94
Largest-LLM	70.29	26.59	35.57	37.70	33.00	22.22	45.67	38.72
Single-turn routers
kNNRouter	71.37	25.24	38.74	31.15	41.00	29.63	51.97	41.30
SVMRouter	74.21	27.64	38.68	42.62	47.00	29.63	55.91	45.10
MLPRouter	68.12	26.78	32.27	27.87	34.00	29.63	56.69	39.34
MFRouter	67.23	24.49	34.91	40.98	29.00	22.22	51.97	38.69
EloRouter	64.15	25.70	37.27	45.90	50.00	25.93	63.78	44.68
Hybrid LLM	64.68	25.89	36.56	32.79	37.00	33.33	51.18	40.20
RouterDC	80.56	24.93	36.77	16.39	24.00	25.93	45.67	36.32
GraphRouter	80.54	25.94	33.93	42.62	50.00	22.22	62.99	45.46
CausalLM	66.90	25.40	37.60	24.60	34.00	33.33	45.70	38.22
Multi-turn routers
Router-R1	35.64	24.60	17.28	14.75	18.00	22.22	23.62	22.30
kNN-MultiRound	13.99	24.70	18.32	16.39	30.00	25.93	33.07	23.20
LLM-MultiRound	12.98	24.60	17.44	14.29	31.03	25.93	30.33	22.37

Figure 3: Architecture of LLMRouter. The system consists of six modules that support routing data construction, router implementation and training, inference, evaluation, and deployment.

Table 3: Performance comparison on the personalized track. Top two results are highlighted in bold and underline.
Router	Acc.	Router	Acc.
GMTRouter	68.78	RouterDC	56.44
PersonalizedRouter	67.86	MFRouter	54.39
EloRouter	66.40	MLPRouter	52.93
GraphRouter	65.23	kNNRouter	51.76
SVMRouter	65.08	CausalLM	46.78
Largest-LLM	58.05	Router-R1	45.46
Hybrid LLM	57.91	Smallest-LLM	42.53

Figure 5: Router rankings across the Generic LLM Tasks, memory, vision, and time-series tracks as the cost weight β increases. Each cell gives a router’s rank under the weighted performance–cost objective, with smaller rank values indicating better performance.

Table 4: Router performance on held-out real-user sessions collected through the Slack deployment. Accuracy measures how often each router’s model selection agrees with the users’ pairwise preferences.
Router	Acc.	Router	Acc.
PersonalizedRouter	83.05	RouterDC	65.25
EloRouter	82.20	kNNRouter	60.17
MLPRouter	78.81	kNN-MultiRound	60.17
SVMRouter	77.12	Smallest-LLM	55.08
Hybrid LLM	73.73	MFRouter	51.69
GMTRouter	70.70	Largest-LLM	41.53
GraphRouter	67.17	CausalLM	27.97

Figure 6: Performance–cost trade-offs of routers averaged across the xRouteBench tracks. Each point represents an operating setting with a different cost weight β, where higher performance and lower per-query inference cost are preferred.

Table 5: Router performance on the Generic LLM Tasks test split when each node in a multi-agent system is routed independently. Results are reported across five coordination topologies, with the final column showing the average performance.
Router	Star	Tree	Graph	Chain	Plan-Exec-Sum	Avg
Largest-LLM	69.00	67.00	77.20	69.00	75.20	71.48
kNNRouter	74.80	78.60	78.60	76.60	71.80	76.08
SVMRouter	76.20	75.60	80.00	74.40	75.20	76.28
MLPRouter	75.40	76.60	76.80	78.00	71.40	75.64
MFRouter	75.40	74.20	81.00	78.60	73.20	76.48
EloRouter	73.80	72.40	78.60	76.60	75.20	75.32
GraphRouter	68.20	70.80	66.20	72.00	69.00	69.24
RouterDC	77.60	79.60	74.20	72.00	76.20	75.92

Figure 7: Representative multi-agent system architectures and coordination topologies: (a) star-based centralized coordination, (b) hierarchical tree-based delegation, (c) graph-based peer interaction, (d) sequential chain collaboration, and (e) planner–executor–summarizer workflow.

Table 6: The eight test sets of xRouteBench. Sizes are the number of test queries; metrics are exact match (EM), multiple-choice accuracy (MC), token-level F1, execution-based code pass rate, math answer matching, and a persona-conditioned LLM judge.
Category	Test set	Content	#Test	Metric
Generic LLM Tasks	Generic mix	13 subtasks	3,729	EM/MC/F1/GSM8K/MATH/code
Memory	LoCoMo	long-conversation QA	314	F1
LongMemEval	long-term memory QA	101	F1
TimeSeries	TimeSeries	7 reasoning skills	127	MC
Vision	Geometry3K	geometry math (image)	61	EM
MathVista	visual math reasoning	100	EM/MC
Charades-Ego	egocentric video	27	EM
Personalized	Chatbot Arena / MT-Bench	preference prompts	308	LLM judge
Total			4,767

Figure 8: One example from each dataset in the Visual Reasoning track, shown with the description that Gemma-3-27B-IT produces for its image. Geometry3K (a) provides a geometry diagram, and MathVista (b) provides a scientific figure. Each description is appended to the problem text to form the query the router sees.

Table 7: Composition of the Generic LLM Tasks track. The table lists the 13 subtasks, their target skills, and the number of test queries, totaling 3,729 examples.
Subtask	Skill	#Test
MBPP	code generation	500
MATH	mathematical reasoning	500
GSM8K	mathematical reasoning	500
MMLU-Pro	knowledge QA	500
OpenBookQA	knowledge QA	500
ARC-Challenge	knowledge QA	500
MMLU	knowledge QA	500
CommonsenseQA	commonsense QA	50
BoolQ	commonsense QA	50
SQuAD	reading comprehension	50
HellaSwag	commonsense QA	50
HumanEval	code generation	16
AIME (2020–2024)	competition math	13

Figure 11: Slack interface for collecting pairwise user preferences. Two anonymized model responses are shown as Answer A and Answer B in randomized order, and users select A, B, or a tie for each interaction turn.

Table 8: Built-in routers in LLMRouter, grouped by routing family. For each method, the table summarizes the information available to the routing decision (State) and the rule used to select or aggregate candidate models (Selection).
Router	State	Selection
Rule-based baselines
Smallest-LLM	candidate parameter counts	always selects the smallest candidate
Largest-LLM	candidate parameter counts	always selects the largest candidate
Single-turn routers
kNNRouter	query embedding and nearby logged queries	votes over the models preferred by nearest neighbors
SVMRouter	query embedding	kernel classifier predicts a candidate
MLPRouter	query embedding	MLP classifier predicts a candidate
MFRouter	query and model latent factors	ranks candidates by their interaction score
EloRouter	logged pairwise model outcomes	always selects the highest-rated candidate
RouterDC	query and candidate representations	contrastive query–model matching score
Hybrid LLM	query embedding and a small/large model pair	predicts whether the small model is sufficient
AutoMix	small-model draft and verification signal	accepts the draft or escalates to the large model
GraphRouter	query–model interaction graph	predicts performance on query–model edges
CausalLM Router	textual query and candidate list	generates the selected model name
Multi-turn routers
Router-R1	query and accumulated search results	iteratively searches specialists or terminates and aggregates
kNN-MultiRound	sub-queries and their embeddings	routes each sub-query with kNN and aggregates the answers
LLM-MultiRound	textual query, decomposition, and candidate list	an LLM chooses routes for sub-queries and aggregates
Personalized routers
GMTRouter	user, session, query, model, and response interactions	predicts user-conditioned model preference
PersonalizedRouter	user features, task description, query, and model	predicts preference for a user–query pair

Figure 12: The ComfyUI interface of LLMRouter. The source benchmarks and the candidate pool enter at the left, the data-engine node produces the query–model matrix, and each router node consumes the matrix and reports its evaluation, so the graph traces the routing pipeline from data construction to evaluation. Each router node exposes the hyperparameters of its library configuration as typed widgets.

Table 9: The 18 candidate LLMs, sorted by blended average price. Prices in USD per 1M tokens.
#	Model	Params	Input	Output	Service
1	gemma-2-9b-it	9B	0.10	0.10	NVIDIA
2	llama-3-8b-instruct-lite	8B	0.10	0.10	Together
3	gpt-oss-20b	20B	0.05	0.20	Together
4	rnj-1-instruct	15B	0.15	0.15	Together
5	mistral-7b-instruct-v0.3	7B	0.20	0.20	NVIDIA
6	mistral-small-3-24b-instruct	24B	0.10	0.30	Together
7	qwen2.5-7b-instruct	7B	0.20	0.20	NVIDIA
8	qwen2.5-7b-instruct-turbo	7B	0.30	0.30	Together
9	gpt-oss-120b	120B	0.15	0.60	Together
10	llama-4-maverick	402B	0.27	0.85	Together
11	mixtral-8x7b-instruct-v0.1	46.7B	0.60	0.60	NVIDIA
12	qwen3-next-80b-a3b-instruct	80B	0.15	1.50	Together
13	qwen3-coder-next	200B	0.50	1.20	Together
14	llama-3.3-70b-instruct-turbo	70B	0.88	0.88	Together
15	llama3-70b-instruct	70B	0.90	0.90	NVIDIA
16	deepseek-v3.1	671B	0.60	1.70	Together
17	mixtral-8x22b-instruct-v0.1	140.6B	1.20	1.20	NVIDIA
18	cogito-v2-1-671b	671B	1.25	1.25	Together

Table 10: The five multi-agent topologies, their structures, and the number of LLM calls per query.
Topology	Structure	LLM calls
Star	planner decomposes → 3 actors in parallel → planner consolidates	6
Tree	root planner → 2 sub-planners refine → 2 actors → root consolidates	7
Graph	3 actors answer independently → one full-communication revision round	7
Chain	3 agents relay sequentially, each verifying and improving the previous answer	4
Plan-Exec-Sum	planner emits 3 atomic sub-queries → 3 executors → summarizer merges	6

실제로 확인된 결과

18개 후보 LLM과 xRouteBench 5개 트랙에서 학습된 라우터들이 가장 강력한 고정 모델 기준보다 평균 14.6% 상대적으로 높은 성능을 냈다.
특정 라우터가 모든 과제를 지배하지 않았다. 예를 들어 RouterDC는 일반 LLM 과제에서, SVMRouter는 LoCoMo에서 최고 성능을 보였고, GraphRouter는 평균은 가장 좋았지만 개별 과제에서 항상 1위는 아니었다.
멀티턴(다단계) 라우팅은 단일턴 라우팅보다 일관되게 더 나은 성능을 보이지 않았으며, 이는 사용하는 기반 모델(Qwen2.5-3B-Instruct)의 능력에 성능이 좌우되기 때문으로 나타났다.
개인화 트랙에서 GMTRouter가 페르소나 심사 정확도 68.78로 PersonalizedRouter(67.86)와 사용자 정보 없이 동작하는 최고 라우터 EloRouter(66.40)를 앞섰다.
비용 가중치가 커질수록(Figure 5, 6) 라우터 순위가 크게 뒤바뀌었고, 항상 가장 큰 모델만 쓰는 방식은 비용이 가장 높으면서도 성능은 평범해 학습된 라우터에 뒤처졌다. 실제 Slack 사용자 234건 데이터에서는 PersonalizedRouter가 83.05로 1위였으나, 시뮬레이션에서 1위였던 GMTRouter는 6위로 떨어졌고, 멀티에이전트 5개 협업 구조 실험에서는 MFRouter가 평균 76.48로 항상 가장 큰 모델 사용(71.48)을 앞섰다.

어디에 쓸 수 있나

여러 LLM을 동시에 운영하는 서비스에서 질문 특성과 예산에 맞춰 모델을 선택하는 라우팅 시스템 설계 및 튜닝
새로운 라우팅 알고리즘을 개발할 때, 설정 파일 변경만으로 기존 데이터 파이프라인·평가 도구를 재사용해 실험 시간을 줄이는 용도
장시간 대화형 서비스, 이미지/영상 질의, 시계열 데이터 질의 등 다양한 입력 유형에 걸쳐 라우팅 성능을 비교 평가하는 용도
사용자별 선호나 페르소나를 반영한 개인화 챗봇/어시스턴트 설계
멀티에이전트 시스템에서 각 에이전트(계획자, 실행자, 요약자 등) 노드별로 다른 모델을 선택하는 구조 설계

한계와 남은 검증

멀티턴 라우터는 모두 Qwen2.5-3B-Instruct를 분해·집계용 기반 모델로 사용했기 때문에, 이 결과가 다른 기반 모델에도 일반화되는지는 확인되지 않았다.
개인화 라우터의 시뮬레이션(페르소나 심사) 순위와 실제 Slack 사용자 234건 선호 데이터의 순위가 일치하지 않아(GMTRouter가 6위로 하락), 오프라인 벤치마크 결과가 실사용 환경에 그대로 전이된다고 볼 수 없다.
후보 모델 풀은 18개 오픈웨이트 모델(7B~671B, Together API·NVIDIA NIM 제공)로 제한되어 있어, 폐쇄형 상용 모델이나 다른 가격 구조에서의 결과는 검증되지 않았다.
실제 사용자 실험은 15명, 40세션, 234건의 소규모 데이터에 기반하고 있어 통계적 대표성에 한계가 있다.
GraphPlanner 기반 Plan-Exec-Sum 토폴로지는 원래의 플래너를 재학습하지 않고 그대로 사용했다는 점 등, 일부 실험 설계상 단순화가 있었다.

왜 중요한가

AI 서비스에 여러 모델을 섞어 쓰는 것이 흔해지면서, 어떤 질문을 어떤 모델에 보낼지 결정하는 라우팅 기술이 비용과 품질을 동시에 좌우하는 핵심 요소가 되고 있다. 이 연구는 제각각이던 라우터 연구들을 같은 잣대로 비교할 수 있는 공통 틀과 도구를 제공해, 실무자가 자신의 서비스에 맞는 라우터를 고르거나 새로 만들 때 참고할 기준을 준다.

이 논문의 용어

LLM 라우팅 · 들어온 질문마다 여러 후보 LLM 중 어느 모델에게 처리를 맡길지 결정하는 것
컨텍스트 인코더 / 모델 인코더 · 질문·대화 상황을 벡터나 텍스트로 표현하는 부분(컨텍스트 인코더)과 각 후보 모델의 특징을 표현하는 부분(모델 인코더)
결정 규칙(decision rule) · 점수화된 후보들 중 실제로 어느 모델에 보낼지, 언제 멈출지를 정하는 규칙
xRouteBench · 이 연구가 만든, 일반 QA·기억·시각·시계열·개인화 과제를 아우르는 라우팅 평가용 벤치마크
성능-비용 트레이드오프 · 답변 품질을 높이려면 비용(토큰·요금)이 늘어나는 관계로, 둘 사이의 균형점을 조절하는 것

저자 · Tao Feng

arXiv에서 원문 보기

METAL MEDIA 최신 기사

그림 출처: Tao Feng et al., arXiv:2608.06867, CC BY 4.0

어떤 질문엔 값싼 모델로, 어떤 질문엔 비싼 모델로 – LLM 라우터를 공정하게 비교하는 통합 플랫폼

LLMRouter 통합 구조: 질문에서 응답까지

무엇을 했나

실제로 확인된 결과

어디에 쓸 수 있나

한계와 남은 검증

왜 중요한가

이 논문의 용어

최신 논문

METAL MEDIA 최신 기사