LLM 라우팅 개발부터 배포까지 통합 인프라

왜 중요한가

여러 LLM이 서로 다른 능력과 가격을 가지면서 모든 질의에 가장 좋은 단일 모델을 고르기 어려워졌습니다. LLMRouter는 라우터마다 달랐던 인터페이스와 supervision, 평가 절차를 하나의 sequential decision process와 공통 pipeline으로 묶어 공정한 비교를 가능하게 합니다. 연구 결과 learned router는 가장 강한 fixed-model baseline보다 상대적으로 14.6% 개선됐고, 비용 제약이 커지면 라우터 순위도 달라졌습니다.

핵심 기여

LLM 라우팅의 공통 형식

라우터를 context encoder, model encoder, scoring function, decision rule, learning signal이라는 다섯 구성 요소로 분해합니다. 질의·사용자·대화 이력을 상태로 보고 후보 모델 호출과 종료를 행동으로 표현해 single-turn, multi-turn, personalized 방법을 같은 sequential decision process에 배치합니다.

자동 supervision과 평가 pipeline

Query Curation, Response Collection, Metric Scoring and Pricing의 세 단계를 자동화합니다. 후보 pool의 모든 모델이 모든 질의에 답한 결과를 task metric과 token 비용으로 기록해 query–model matrix를 만들고, 같은 질의·후보·지표로 라우터를 비교합니다.

xRouteBench benchmark

Generic LLM Tasks, memory, vision, time-series, personalized의 다섯 track과 총 4,767개 instance를 하나의 cost-aware protocol으로 묶습니다. 이미지·비디오·시계열 입력을 공통 textual query로 변환하고, 장기 대화와 사용자별 선호까지 포함해 기존 single-turn 중심 benchmark의 범위를 확장합니다.

모듈형 오픈소스 인프라

LLMRouter는 세 라우터 family에 걸친 16개 이상의 대표 라우터를 MetaRouter 인터페이스 뒤에 통합합니다. 사용자는 route_single 또는 route_batch와 loss_func를 구현하고 YAML 설정을 추가해 새 라우터를 등록할 수 있으며, 같은 라우터를 offline 평가와 OpenAI-compatible server 배포에 재사용합니다.

핵심 아이디어 이해하기

여러 LLM 중 하나를 고르는 문제는 단순한 모델 순위표가 아닙니다. 질의마다 필요한 능력과 허용 비용이 다르므로, 가장 큰 모델을 항상 호출하면 비용은 커지지만 그 모델이 모든 질의에 정답을 주지는 않습니다. 따라서 라우터는 질의와 후보 모델의 특성을 비교해 각 입력에 맞는 모델을 선택해야 합니다.

LLMRouter는 이 선택을 한 번의 분류 문제뿐 아니라 순차적 의사결정으로 표현합니다. 현재 상태에는 질의 q, 선택적 사용자 컨텍스트 u, 지금까지의 상호작용 이력 hₜ가 들어가며, 라우터는 후보 모델 m을 호출하거나 종료 행동 ⊥를 선택합니다. 모델을 호출하면 응답 yₜ가 이력에 추가되고, 여러 응답을 모은 뒤 최종 답변 y를 만들기 때문에 multi-turn 라우팅도 같은 구조에서 처리됩니다.

라우터의 목적은 응답 품질과 호출 비용을 함께 최적화하는 것입니다. 논문의 식은 $\pi^{\star}=\arg\max_{\pi}\mathbb{E}_{q,\tau\sim\pi}[\mathrm{perf}(y\mid q)-\lambda\cdot c(\tau)]$ 로, perf(y|q)는 질의에 대한 task-specific 품질, c(τ)는 trajectory 전체의 monetary 또는 token cost, λ≥0은 비용의 중요도를 뜻합니다. λ=0이면 비용을 무시하고 품질만 선택하며, λ가 커질수록 저렴한 모델을 활용하는 경로가 더 높은 목적값을 얻습니다.

방법론

LLMRouter는 상태를 표현하는 context encoder E_q와 후보 모델을 표현하는 model encoder E_m을 먼저 적용합니다. E_q는 질의 embedding, 과거 모델 성능, 사용자·세션 정보, 대화 이력 또는 자연어 prompt를 입력으로 사용할 수 있고, E_m은 모델 크기·가격, 과거 응답 프로필, learned embedding 또는 모델 설명을 표현합니다. 두 표현의 호환도를 scoring function g가 계산하고 decision rule d가 argmax, threshold, cascade, sampling 또는 종료 행동으로 변환합니다.

학습 신호는 후보별 정답 점수, 모델 간 선호 비교, contrastive objective, trajectory-level reinforcement learning reward 등으로 구성됩니다. 데이터 engine은 benchmark 질의를 통일된 schema로 정규화하고 train/test로 나눈 뒤, 설정된 18개 후보 모델에 모든 질의를 보내 응답과 token 수를 수집합니다. 이후 exact 또는 close matching, multiple-choice accuracy, token-level F1, 수학 답 검증, code execution 같은 task metric과 token 가격을 결합해 각 질의와 모델의 성능·비용 행렬을 생성합니다.

평가는 test 질의를 라우터가 고른 후보에만 보내고, 동일한 질의·후보 pool·metric을 사용해 품질과 비용을 비교합니다. 가중 보상은 $\alpha\cdot\mathrm{perf}-\beta\cdot\mathrm{cost}$ 이며, α와 β는 품질과 비용의 상대적 비중을 뜻하고 논문은 (1.0, 0.0)부터 (0.2, 0.8)까지 다섯 설정을 사용합니다. 예를 들어 (1.0, 0.0)은 품질만 평가하고 (0.2, 0.8)은 비용을 더 강하게 반영하므로, 같은 라우터도 운영점에 따라 순위가 달라집니다.

xRouteBench는 4,767개 instance를 Generic LLM Tasks, memory, vision, time-series, personalized track으로 나눕니다. Memory는 수백 턴의 대화에서 최대 다섯 개 memory item을 검색하고 token-level F1로 채점하며, vision은 Geometry3K·MathVista·Charades-Ego, time-series는 TSRBench, personalized는 Chatbot Arena와 MT-Bench의 persona prompt를 사용합니다. 비텍스트 자산은 변환 script를 통해 textual query와 선택적 원본 포인터로 바꾸고, 새 task는 변환 script와 metric을 등록하는 방식으로 pipeline에 추가합니다.

주요 결과

성능만 중시한 설정에서 한 라우터가 모든 task를 지배하지 않았습니다. Generic LLM Tasks에서는 RouterDC가 가장 높았고 LoCoMo에서는 SVMRouter가 가장 높았지만, 전체 평균에서는 GraphRouter가 앞섰습니다. 이는 평균 성능이 특정 task의 독주보다 여러 시나리오에서의 일관성에 좌우된다는 뜻입니다.

Multi-turn 라우팅은 single-turn보다 일관된 이득을 만들지 못했습니다. 여러 차례의 질의 분해와 응답 집계가 일부 문제에서는 도움이 되지만, 다른 문제에서는 중복 정보와 추가 호출 비용을 만들며 Qwen2.5-3B-Instruct의 분해·집계 능력에도 영향을 받았습니다. 따라서 sufficiency estimation, early stopping, decomposition과 aggregation 개선이 필요한 결과로 이어졌습니다.

Personalized routing에서는 사용자 컨텍스트를 쓰는 방식이 성능 차이를 만들었습니다. persona-conditioned judge 기준 GMTRouter는 68.78, PersonalizedRouter는 67.86, 가장 높은 user-agnostic router인 EloRouter는 66.40을 기록해 GMTRouter가 PersonalizedRouter보다 0.92포인트 높았습니다. 실제 Slack 사용자 15명의 40개 session과 234개 pairwise record로 검증했을 때는 PersonalizedRouter가 83.05로 가장 높았고 GMTRouter는 70.70으로 6위가 되어, 시뮬레이션 선호와 실제 사용자 선호가 다를 수 있음을 확인했습니다.

비용 가중치가 커지면 라우터 순위가 크게 바뀌었습니다. RouterDC는 Generic LLM Tasks에서 품질만 볼 때 선두였지만 가장 비용 민감한 설정에서는 11개 중 10위로 내려갔고, Vision에서는 품질 우선 설정에서 약했던 MLPRouter가 β≥0.4에서 가장 좋은 선택이 됐습니다. Multi-agent system에서 노드별로 모델을 선택한 경우에는 학습 기반 라우터 7개 중 6개가 Largest-LLM보다 높았고, MFRouter가 평균 76.48로 Largest-LLM의 71.48을 앞섰습니다.

기술 상세

LLMRouter의 핵심 상태는 $s_t=(q,u,h_t)$ 이며 q는 입력 질의, u는 사용자 식별자와 과거 상호작용을 포함할 수 있는 컨텍스트, h_t는 현재까지 누적된 응답 이력입니다. 행동은 $a_t\in\mathcal{M}\cup\{\bot\}$ 로, a_t=m이면 후보 pool $\mathcal{M}=\{m_1,\ldots,m_K\}$ 중 하나를 호출하고 응답 y_t를 얻어 $h_{t+1}=h_t\oplus y_t$ 로 이력을 갱신하며, a_t=⊥이면 episode를 끝내고 응답을 집계합니다. 한 번의 모델 호출 뒤 종료하는 경우가 single-turn routing이고, 여러 호출을 이어가면 multi-turn routing입니다.

목적 함수는 응답 품질과 trajectory 비용의 차이를 최대화합니다. perf(y|q)는 accuracy, F1 또는 LLM judge score처럼 task에 맞는 품질 점수이고, c(τ)는 trajectory τ에 포함된 모든 모델 호출의 monetary 또는 token cost이며, λ는 비용 penalty입니다. 따라서 λ가 0이면 greedy argmax가 품질 기준에서 적합하지만, λ가 양수이면 점수만 가장 높은 모델이 아니라 품질 증가분이 추가 비용을 정당화하는지 판단해야 합니다.

Context encoder는 embedding-based와 text-based 방식으로 나뉩니다. kNN-style router는 off-the-shelf sentence embedding을 사용하고, discriminative router는 frozen embedding 위에 lightweight encoder를 학습하며, personalized router는 사용자·세션 노드를 포함한 heterogeneous interaction graph를 활용합니다. 반대로 cascade는 draft response와 verification confidence를 질의에 붙이고, fine-tuned LM router는 전체 상태를 prompt로 verbalize해 forward pass 안에서 표현과 scoring을 함께 계산합니다.

Model encoder와 scoring function의 결합 방식도 다양합니다. 후보를 모델 크기·능력 설명·가격으로 표현할 수 있고, 과거에 해결한 질의 집합·scalar rating·matrix factorization latent factor 또는 jointly learned embedding으로 나타낼 수도 있습니다. 이후 scoring은 embedding similarity, bilinear product, classification head, query–model graph의 message passing, fine-tuned LM의 next-token logits 중 하나로 계산되며, decision rule은 greedy 선택·quality-gap threshold·accept-or-escalate cascade·exploration sampling으로 이를 행동으로 바꿉니다.

구현상 새 라우터는 MetaRouter를 상속해 route_single 또는 route_batch를 작성하고, Trainer는 BaseTrainer를 상속해 pointwise loss, pairwise loss 또는 trajectory reward를 loss_func에 넣습니다. Data Engine과 Route Engine, Evaluation, Deployment는 구현한 라우터와 무관하게 같은 흐름을 사용하므로 candidate pool과 objective weight를 YAML에서 바꿀 수 있습니다. 평가 단계에서는 multi-turn과 agentic 호출의 decomposition·aggregation 비용도 trajectory에 포함하고 λ 또는 α, β를 sweep해 performance–cost frontier를 계산합니다.

실무 활용

LLMRouter는 여러 LLM endpoint를 질의별로 선택하는 개발·평가·배포 흐름에 사용할 수 있습니다. 후보 모델의 응답 품질과 token 가격을 동일한 데이터 행렬에 기록한 뒤, 품질 우선 또는 비용 민감한 objective로 라우터를 학습하고 평가합니다. GitHub 저장소에는 새 라우터와 Trainer를 같은 인터페이스로 구현하는 코드가 공개되어 있습니다.

18개 후보 LLM 중 질의별로 적절한 모델을 선택하는 cost-aware API routing
Slack과 Discord 같은 messaging platform에 OpenClaw 연동 server로 라우터 배포
ComfyUI 기반 visual interface에서 코드 없이 라우팅 prototype 구성
Multi-agent system의 planning, execution, verification 노드마다 다른 LLM 선택
새 benchmark와 candidate pool을 설정 파일, prompt template, metric 등록으로 평가

코드 공개 여부: 공개

코드 저장소 보기

키워드

LLM Routing(대규모 언어 모델 선택)Context Encoder(라우팅 상태 인코더)Model Encoder(후보 모델 인코더)Scoring Function(후보 적합도 함수)Sequential Decision Process(순차적 의사결정)xRouteBench(라우팅 benchmark)Personalized Routing(사용자 조건부 라우팅)

용어 해설

LLM 라우팅(LLM Routing): — 질의마다 여러 LLM 후보 중 적절한 모델을 선택하는 방법입니다. 라우터는 질의·사용자·대화 이력을 인코딩하고 후보 모델별 점수를 계산한 뒤, 응답 품질과 추론 비용을 함께 고려해 dispatch 대상을 결정합니다. 모델별 능력과 가격 차이를 활용해 고정 모델보다 효율적인 배치를 목표로 합니다.
순차적 의사결정 과정(Sequential Decision Process): — 라우팅을 현재 상태를 관찰하고 모델 호출 또는 종료 행동을 반복하는 과정으로 표현하는 형식입니다. 상태에는 질의, 선택적 사용자 정보, 지금까지의 응답 이력이 포함되며, 각 호출은 다음 상태를 만듭니다. 최종 목표는 응답 품질을 높이면서 전체 호출 비용을 낮추는 정책을 학습하는 것입니다.
컨텍스트 인코더(Context Encoder): — 라우팅 상태를 모델 선택에 사용할 표현으로 변환하는 구성 요소입니다. 질의만 벡터로 바꾸거나 사용자 정보와 대화 이력까지 결합할 수 있으며, 자연어 상태를 그대로 prompt에 넣는 방식도 포함됩니다. 어떤 상태 부분을 읽는지가 single-turn, multi-turn, personalized 라우팅을 구분합니다.
모델 인코더(Model Encoder): — 후보 LLM 각각을 라우터가 비교할 수 있는 표현으로 변환하는 구성 요소입니다. 모델 크기·가격 같은 정적 메타데이터, 과거 성능 프로필, 학습된 embedding, prompt에 삽입하는 모델 이름과 설명을 사용할 수 있습니다. 컨텍스트 표현과의 호환도를 계산하면 후보별 routing score가 만들어집니다.
성능·비용 상충 관계(Performance–Cost Trade-off): — LLM 라우팅에서 응답 품질과 추론 비용을 하나의 선택 기준으로 함께 다루는 관계입니다. 품질 성능은 accuracy, F1, LLM judge 점수 등으로 측정하고 비용은 호출별 token 수와 가격으로 계산합니다. 비용 가중치가 커지면 값비싼 대형 모델보다 저렴한 후보를 선택하는 정책이 유리해집니다.

LLM 라우팅 개발부터 배포까지 통합 인프라

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

실무 활용

키워드

용어 해설

관련 토론

댓글

관련 기사

LLM 라우팅의 절감 효과는 공급자별로 달랐다

모델 라우팅을 통한 LLM 비용 최적화와 성능 개선 전략

AI 모델 라우팅의 기술적 과제와 최적화 전략

에이전트 웹 검색, 엔진보다 예산과 모델 선택이 중요

LLM 에이전트 모델 교체 평가의 재생 간극

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

실무 활용

키워드

관련 토론

댓글

관련 기사

LLM 라우팅의 절감 효과는 공급자별로 달랐다

모델 라우팅을 통한 LLM 비용 최적화와 성능 개선 전략

AI 모델 라우팅의 기술적 과제와 최적화 전략

에이전트 웹 검색, 엔진보다 예산과 모델 선택이 중요

LLM 에이전트 모델 교체 평가의 재생 간극