들어온 요청의 난이도나 종류를 보고 그 요청에 맞는 LLM을 골라 보내는 구조다. 쉬운 요청은 작고 싼 모델로, 어려운 요청은 큰 모델로 나눠 비용은 줄이면서 어려운 요청의 품질은 지키고 싶을 때 쓴다.
| 방식 | 비용 | 품질 |
|---|---|---|
| 모두 큰 모델 | 높음 | 높음 |
| 모두 작은 모델 | 낮음 | 어려운 요청에서 떨어짐 |
| 라우팅 | 낮게 유지 | 요청에 맞춤 |
요청을 어디로 보낼지 정하는 방법은 크게 네 가지다. 처음에는 규칙으로 시작하고, 규칙으로 잘 나뉘지 않는 요청이 늘어나면 분류 모델을 붙이는 순서가 무난하다.
| 방법 | 판단 방식 | 어울리는 경우 |
|---|---|---|
| 규칙 기반 | 길이·키워드·작업 종류로 나눔 | 요청 유형이 뚜렷할 때 |
| 분류 모델 | 작은 모델이 난이도를 판단 | 요청이 다양할 때 |
| LLM 판단 | 작은 LLM에게 난이도를 물어봄 | 기준을 말로 정하기 쉬울 때 |
| 단계적 시도 | 작은 모델 먼저, 부족하면 큰 모델로 | 답을 자동으로 검사할 수 있을 때 |
가장 쉬운 출발점은 LiteLLM 같은 프록시다. 여러 모델을 하나의 주소 뒤에 등록하고 "짧은 질문은 경량 모델, 긴 문서나 코딩은 상위 모델"처럼 규칙을 걸어 둔다. 그러면 앱 코드는 그대로 두고 요청이 가는 곳만 바뀐다. RouteLLM처럼 강한 모델과 약한 모델 중 어디로 보낼지 판단하는 오픈소스 라우터도 있다. Martian 같은 상용 서비스나 Microsoft Foundry의 모델 라우터처럼 클라우드가 라우팅을 대신 해 주는 방식도 있다.
구성하는 순서는 이렇다. 먼저 실제 요청 기록을 모아 유형별로 나눈다. 유형마다 작은 모델로도 충분한지 직접 비교해 보고, 그 결과로 나누는 기준을 정한다. 마지막으로 작은 모델이 실패하면 큰 모델로 넘기는 경로를 만들어 둔다.
라우터가 어려운 요청을 작은 모델로 보내면 품질이 떨어진다. 반대로 쉬운 요청을 큰 모델로 보내면 비용을 아끼는 효과가 사라진다. 라우터가 판단하는 데에도 시간과 비용이 든다. 그래서 요청량이 적거나 요청 난이도가 대부분 비슷하다면 모델 하나만 쓰는 편이 단순하다.
모델마다 프롬프트에 반응하는 방식과 출력 형식이 달라서, 같은 프롬프트도 모델에 따라 다르게 동작할 수 있다. 어떤 요청이 어느 모델로 갔는지 기록해 두어야 문제가 생겼을 때 원인을 찾을 수 있다.
| 기법 | 무엇을 보고 보내나 | 목적 |
|---|---|---|
| 라우팅 | 요청 내용과 난이도 | 비용과 품질의 균형 |
| 폴백 | 앞 모델의 오류나 실패 | 장애 대응 |
| 로드밸런싱 | 서버 부하와 사용 한도 | 처리량 분산 |
실제 서비스에서는 세 가지를 함께 쓰는 경우가 많다. 라우팅으로 모델을 고르고, 그 모델에 문제가 생기면 폴백으로 다른 모델에 넘긴다.
요청이 많고 쉬운 것과 어려운 것이 섞여 있는 곳에서 효과가 크다. 대부분을 차지하는 쉬운 요청을 작은 모델로 돌리고, 어려운 일부만 큰 모델로 올리는 방식이 기본이다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 고객 상담 챗봇 | 인사·단순 문의는 경량 모델이, 복잡한 문의나 긴 대화는 상위 모델이 답하게 나눔 |
| 코딩 에이전트 | 파일 검색·결과 요약 같은 단순 단계는 작은 모델로, 설계·디버깅만 큰 모델로 |
| 사내 LLM 게이트웨이 | 프록시 뒤에 여러 모델을 등록하고, 각 팀 앱은 주소 하나만 불러 규칙에 따라 모델이 정해짐 |