모델 라우팅 (Model Routing)

모델 라우팅(Model Routing)은 요청의 내용과 필요한 기능, 품질·비용·지연 조건을 보고 처리할 AI 모델을 선택하는 방식입니다. 여러 모델을 함께 운영할 때 모든 요청을 같은 모델로 보내지 않고, 미리 정한 규칙이나 학습된 선택기에 따라 요청을 나눕니다.

요청에 맞는 모델을 고른다

짧은 문장의 분류와 여러 파일에 걸친 코드 수정은 필요한 능력과 허용할 시간이 다를 수 있습니다. 분류에 충분한 모델이 복잡한 수정에서도 같은 품질을 낸다는 보장은 없습니다. 반대로 간단한 요청까지 매번 비용이 큰 모델에 보내면 필요 이상의 비용이 들 수 있습니다. 라우터는 사용 가능한 후보 중 어떤 모델을 호출할지 결정하는 부분입니다. 모델이 답변을 만들기 전의 선택이 전체 서비스의 품질과 비용에 영향을 줍니다.

가령 고객 문의를 다루는 서비스에서 언어 분류는 경량 모델에 맡기고, 여러 정책 문서를 함께 읽어야 하는 질문은 더 높은 성능을 보인 모델에 맡길 수 있습니다. 이미지가 들어오면 이미지 입력을 지원하는 모델만 후보로 남길 수도 있습니다. 이는 가능한 설계의 예시이며, 짧은 질문이면 언제나 쉽다는 뜻은 아닙니다. 짧은 문장에도 복잡한 조건이 숨을 수 있으므로 입력 길이 하나만으로 난이도를 확정하면 중요한 요청을 잘못 보낼 수 있습니다.

단순한 라우터는 작업 종류, 입력 형식, 길이 같은 규칙으로 모델을 고릅니다. 학습된 라우터는 이전 요청과 모델 응답에 대한 평가를 바탕으로 어느 모델이 유리할지 예측할 수 있습니다. RouteLLM 연구는 사람의 응답 선호 데이터를 이용해 성능과 비용이 다른 두 모델 중 하나를 선택하는 라우터를 학습합니다. 이처럼 라우팅 자체도 별도의 예측 문제이며, 선택기도 어느 모델이 더 나은 답을 낼지 잘못 예측할 수 있습니다.

제품마다 후보 모델과 선택 기준의 범위도 다릅니다. Amazon Bedrock의 지능형 프롬프트 라우팅 안내는 요청에 대한 응답 품질을 예측하고 설정된 품질 차이 기준에 따라 모델을 선택하는 방식을 설명합니다. 이 사례를 모든 회사의 모든 모델을 자유롭게 섞는 보편적인 기능으로 이해해서는 안 됩니다. 실제 후보는 서비스가 지원하는 모델 조합과 지역, 설정 조건 안에서 정해집니다.

MoE·부하 분산·폴백과 구분한다

MoE에도 라우터가 있지만 선택하는 대상이 다릅니다. MoE의 라우터는 한 모델 내부에서 토큰을 처리할 전문가 신경망을 고릅니다. 여기서 말하는 모델 라우팅은 애플리케이션이 요청을 보낼 모델을 선택하는 층에 있습니다. 서비스가 먼저 MoE 모델을 선택하고, 선택된 모델 안에서 다시 전문가를 고르는 과정이 이어질 수도 있습니다. 이름이 비슷해도 선택 단위와 실행 위치가 다릅니다.

부하 분산은 여러 서버나 배포 인스턴스에 요청을 나눠 혼잡을 줄이는 데 초점을 둡니다. 같은 모델을 여러 곳에 배포하고 덜 바쁜 곳으로 보내는 경우가 대표적입니다. LiteLLM의 라우터 문서는 사용량, 지연, 비용 등을 기준으로 배포 대상을 고르는 방식을 다룹니다. 하나의 라우터 제품에 모델 선택과 부하 분산이 모두 들어갈 수 있으므로, 이름보다 실제로 무엇을 기준으로 어느 대상을 고르는지 살펴야 합니다.

폴백은 기본 경로를 사용할 수 없거나 정해진 조건을 충족하지 못할 때 다른 경로를 택하는 동작입니다. 서버 오류나 시간 초과 뒤에 다른 모델을 호출하는 설계가 여기에 해당합니다. 제품에 따라 품질 기준을 만족하지 못했을 때 선택할 기준 모델을 폴백이라고 부르기도 합니다. 요청 내용을 보고 처음부터 모델을 고르는 결정과 실패 뒤의 대체 경로는 구분하되, 함께 설계할 수 있습니다. 어느 단계에서 변경됐는지 기록해야 원인을 추적하기 쉽습니다.

절감액과 함께 선택 오류를 본다

라우터 설정에서 중요한 것은 실제 요청의 구성입니다. RouteLLM 공식 저장소의 보정 안내는 유입되는 질문 표본을 기준으로 선택 임계값을 조정하라고 권합니다. 공개 예제에 적힌 값을 복사한다고 자신의 서비스에서도 같은 모델 사용 비율이나 품질이 나오는 것은 아닙니다. 질문의 언어, 전문 분야, 길이와 요구하는 답변 형식이 달라지면 선택 결과도 달라질 수 있습니다.

평가는 전체 평균만으로 끝내지 않는 편이 좋습니다. 단순 질문의 비용이 줄었더라도 어려운 요청을 지나치게 경량 모델로 보내면 필요한 품질을 놓칠 수 있습니다. 반대로 모든 요청을 성능이 높은 모델로 보내면 라우팅을 둔 목적이 약해질 수 있습니다. 실제 질문을 유형별로 나눠 정답률이나 작업 성공률, 비용, 응답 시간을 함께 비교하면 어느 요청에서 선택 기준을 조절해야 할지 알 수 있습니다. 연구의 절감 비율은 해당 평가 조건의 결과로 읽어야 합니다.

모델 선택 과정에도 시간과 비용이 들어갈 수 있습니다. 분류 모델이나 임베딩을 한 번 더 호출한다면 그 비용을 최종 모델 호출 비용에 더해야 합니다. 잘못 선택한 뒤 다시 요청하는 비율도 함께 봅니다. 저렴한 모델을 많이 호출했다는 지표만으로 전체 비용이 줄었다고 판단하면, 선택 단계와 재시도에서 발생한 비용을 놓칠 수 있습니다. 작업 하나가 성공할 때까지 든 비용이 더 유용한 판단 기준일 수 있습니다.

기능과 데이터 조건은 비용보다 먼저 후보를 좁히는 기준이 될 수 있습니다. 필요한 도구 호출이나 구조화된 출력을 지원하지 않는 모델, 입력 길이를 감당하지 못하는 모델은 요청을 제대로 처리하기 어렵습니다. 자료를 보낼 수 있는 서비스나 지역이 정해져 있다면 그 범위도 후보에 반영해야 합니다. 선택된 모델과 라우팅 기준, 실패 후 바뀐 경로를 에이전트 관측성 기록에 남기면 품질 저하가 모델 자체의 문제인지 선택 오류인지 나누어 살펴볼 수 있습니다.