LLM 모델 라우팅, 쉬운 요청은 싼 모델로 보내는 원리와 도구
LLM 모델 라우팅은 요청마다 값싼 모델과 비싼 모델 중 하나를 골라 보내 비용을 줄이는 기법이다. LMSYS의 RouteLLM, LiteLLM, OpenRouter를 예로 캐스케이드·직접 분류·앙상블 방식과 도입 시 주의점을 정리했다.
LLM 모델 라우팅은 하나의 요청을 여러 언어 모델 중 어디로 보낼지 자동으로 정하는 기법이다. 쉬운 질문은 값싼 소형 모델로, 어려운 질문만 비싼 대형 모델로 흘려보내 품질을 크게 떨어뜨리지 않으면서 API 비용을 줄이는 것이 핵심이다. LMSYS(챗봇 아레나를 운영하는 연구 조직)는 라우팅 프레임워크 RouteLLM 발표 블로그에서, 행렬 분해 방식 라우터가 GPT-4 성능의 약 95%를 GPT-4 호출 26%만으로 달성했다고 밝혔다. 이 글은 2026년 7월 기준으로 오픈소스 라우팅 도구와 대표적인 라우팅 방식을 개발자 눈높이에서 정리한 것이며, 특정 매니지드 서비스의 세부 요금표는 다루지 않는다.
모델 라우팅이 정확히 무엇인가
모델 라우팅은 들어온 요청 하나를 어느 모델이 답하게 할지 코드가 대신 정하는 계층이다. OpenRouter는 공식 문서에서 라우팅을 두 판단으로 나눈다고 설명한다. 어떤 모델이 답할지 정하는 모델 라우팅과, 그 모델을 어느 공급자가 서빙할지 정하는 공급자 라우팅이다. 여기에 부하 분산과 페일오버(failover, 한 대상이 죽으면 자동으로 대체 대상으로 넘기는 것)까지 얹으면 라우터가 맡는 일이 정리된다.
개발자가 이 계층을 직접 두는 이유는 비용이다. 요약, 분류, 짧은 추출 같은 요청은 소형 모델로도 충분한데 이걸 전부 최상위 모델로 보내면 토큰당 단가가 높은 청구서만 쌓인다. 앞서 든 RouteLLM 수치가 이 지점을 보여 준다. 쉬운 요청을 값싼 모델로 걸러 내면 전체 비용은 내려가고 체감 품질은 크게 흔들리지 않는다.
라우팅은 어떻게 동작하나
동작 방식은 크게 세 가지로 나뉜다.
- 캐스케이드(cascade): 싼 모델을 먼저 부르고 답의 확신도가 낮을 때만 비싼 모델로 올려 보낸다. 단계형이라 쉬운 요청 대부분은 첫 단계에서 끝난다.
- 직접 분류(direct): 요청 내용을 작은 분류기가 보고 어느 모델로 보낼지 한 번에 정한다.
- 앙상블(ensemble): 여러 모델을 동시에 불러 결과를 고르거나 합친다. 품질은 높지만 호출이 여러 번이라 비용이 가장 크다.
가장 단순한 형태는 조건 하나로 갈림길을 만드는 것이다. 아래는 직접 분류를 개념만 남긴 의사코드다.
def route(query):
# 쉬운 요청이면 소형 모델, 아니면 대형 모델
if is_simple(query):
return call_model("small-model", query)
return call_model("large-model", query)실무에서는 is_simple 자리를 무엇으로 채우느냐가 라우팅의 전부다. 글자 수나 키워드 같은 규칙으로 채우면 규칙 기반 라우팅이고, 따로 학습한 분류기를 넣으면 학습 기반 라우팅이다. LMSYS는 RouteLLM에서 챗봇 아레나의 사람 선호 데이터로 이 분류기를 학습시켰다고 밝혔다. 라우팅 대상 자체를 어떻게 나눌지 막막하다면 LLM 에이전트를 세 축으로 구분한 글이 모델과 역할을 정리하는 데 도움이 된다.
대표 오픈소스 도구 비교
밑바닥부터 직접 구현하기 전에 이미 검증된 도구를 먼저 보는 편이 시행착오를 줄인다. 2026년 7월 기준으로 자주 쓰이는 세 가지를 정리했다.
| 도구 | 형태 | 특징 |
|---|---|---|
| RouteLLM | 오픈소스 프레임워크 | 강한 모델과 약한 모델 사이를 분류, 학습된 라우터 동봉 |
| LiteLLM | 셀프호스팅 프록시·SDK | 100개 이상 공급자를 OpenAI 형식으로 통합, 폴백·로드밸런싱 |
| OpenRouter | 매니지드 게이트웨이 | 70개 이상 공급자에 걸친 모델·공급자 라우팅 |
LiteLLM 공식 문서에 따르면 LiteLLM은 100개 이상의 공급자를 OpenAI 형식 하나로 감싸는 프록시이자 SDK이고, 재시도·쿨다운·폴백을 설정 파일로 관리한다. 폴백은 아래처럼 앞 모델에서 뒤 모델로 지정한다.
fallbacks = [{"gpt-3.5-turbo": ["gpt-4"]}]이 설정은 앞 모델이 재시도 후에도 실패하면 뒤 모델로 넘긴다. 반대로 OpenRouter는 서버를 직접 운영하지 않고 게이트웨이를 빌려 쓰는 쪽이다. OpenRouter는 요청마다 70개 이상 공급자를 두고 모델과 공급자를 각각 고르며, 최근 30초 안에 장애가 있었던 공급자는 우선순위에서 내리고 나머지는 폴백으로 남긴다고 설명한다. 두 도구의 문서는 각각 LiteLLM 문서와 OpenRouter, RouteLLM 코드는 GitHub 저장소에서 확인할 수 있다.
왜 단순한 라우팅은 운영에서 무너지나
IBM 리서치는 2026년 7월 허깅페이스 블로그 글 「Model Routing Is Simple. Until It Isn’t.」에서, 모델 라우팅을 ‘어느 모델이 맞는지 고르는 분류 문제’로만 다루면 운영에서 무너진다고 지적한다. 공시 단가표만 보고 갈림길을 짜면 세 가지가 어긋난다는 것이다.
- 비용은 토큰 단가가 아니다: IBM 리서치는 AppWorld 벤치마크 417개 과제를 CodeAct 에이전트로 돌린 실측에서 Claude Sonnet이 총 79달러(과제당 0.19달러)였던 반면, 토큰 단가가 더 싼 GPT-4.1은 총 155달러(과제당 0.37달러)로 약 두 배가 나왔다고 밝힌다. 원인은 캐시된 토큰을 다시 읽는 값(cache-read) 단가 차이다 — 단가표만 보면 순위가 뒤집히는 지점이다.
- 복잡도는 겉으로 안 보인다: ‘이 계약서를 요약해 줘’ 같은 요청이 실제로는 문서 검색과 규정 확인, 도구 호출, 여러 번의 다듬기를 부른다. 라우팅하는 순간에는 그 난이도가 드러나지 않는다.
- 지연은 모델 속도가 아니다: 하드웨어와 캐시가 데워졌는지, 엔드포인트 부하가 실제 응답 시간을 가른다. 게다가 실행 단계마다 라우터를 한 번씩 태우면 그 오버헤드가 쌓인다.
그래서 IBM 리서치는 라우팅을 분류가 아니라 비용·품질·지연을 한꺼번에 맞추는 최적화 문제로 다시 정의한다. 과제당 약 6밀리초·2킬로바이트만 쓰는 가벼운 알고리즘으로 여러 ‘작동점’을 내놓는 방식이다. 같은 AppWorld 실험에서 한 구성은 정확도 84%·총비용 93달러·83초를 기록했는데, 이는 최상위 모델(Opus)만 쓸 때와 견줘 비용을 약 21%, 지연을 약 9% 줄이는 대신 정확도를 약 4%포인트 내준 결과다. 자세한 수치와 방법은 IBM 리서치의 원문 글에 정리돼 있다.
도입할 때 확인할 것
라우팅은 공짜 점심이 아니다. 붙이기 전에 세 가지를 먼저 따져 봐야 한다.
- 라우터의 지연과 이중 호출: 캐스케이드는 싼 모델이 확신을 못 주면 결국 비싼 모델까지 두 번 부른다. 이때는 지연도 비용도 오히려 늘어난다. 실제 트래픽으로 승급 비율을 재지 않으면 절감 효과가 착시로 끝난다.
- 분류 정확도: 어려운 요청을 싼 모델로 잘못 보내면 품질이 떨어지고, 쉬운 요청을 비싼 모델로 보내면 돈이 샌다. 분류기가 어느 쪽으로 틀리는지와 그 대가를 함께 봐야 한다.
- 운영 부담: LiteLLM처럼 프록시를 직접 운영하면 쿨다운과 사용량 추적에 Redis 같은 상태 저장소가 필요하다. 게이트웨이를 쓰면 이 부담은 줄지만 외부 서비스 의존이 생긴다.
결국 라우팅은 프로토타입을 지나 운영으로 넘어가는 팀에서 제값을 한다. 요청량이 늘고 청구서가 눈에 들어오기 시작하는 시점이다. 개발팀이 AI 도입에서 자주 멈추는 지점을 함께 보면 라우팅을 언제 붙일지 감을 잡기 쉽다.