모델 라우팅은 간단하다. 아닐 때까지는

모델 라우팅은 간단한 분류 문제처럼 보인다. 간단한 요청은 저가 모델로, 어려운 작업은 고성능 모델로 보내면 비용을 절감하면서 성능을 유지할 수 있을 것으로 예상된다. 하지만 실제로는 그렇지 않다.

문제 1: 비용은 모델 가격 이상

GPT-4.1이 Claude Sonnet보다 저렴해야 하지만, 실제로는 반대였다. AppWorld Test Challenge에서 417개 작업을 처리했을 때 Sonnet은 총 $79 ($0.19/작업)이었고 GPT-4.1은 $155 ($0.37/작업)였다. 토큰 가격만 보면 GPT-4.1이 우위여야 하지만, 프롬프트 캐싱이 전체 비용을 좌우했다. 에이전트 워크로드는 단계별로 컨텍스트 대부분을 재사용하는데, Sonnet의 낮은 캐시 읽기 가격이 높은 기본 가격과 더 긴 처리 경로를 상쇄했다.

문제 2: 복잡도는 작업 난이도 이상

라우팅 시점에는 실제 작업 난이도를 알 수 없다. '계약 요약'은 간단해 보이지만 검색, 규정 확인, 도구 사용, 반복 개선이 필요할 수 있다. 반대로 기술적 프롬프트는 작은 전문 모델이 효율적으로 처리할 수 있다. 실행하기 전까지는 실제 난이도를 예측할 수 없다.

더불어 프로덕션 환경에서는 비용, 지연시간, 모델 전문성, 신뢰성을 동시에 균형 맞춰야 한다. 엔터프라이즈 배포에서는 규정 준수, 데이터 거주지, 개인정보 보호, 승인된 모델 목록 같은 제약도 추가된다.

문제 3: 지연시간은 모델 속도 이상

더 큰 모델이 더 느리고 작은 모델이 더 빠르다는 직관은 부분적일 뿐이다. 라우팅 자체가 오버헤드를 추가하고, 하드웨어 환경, 캐시 상태, 엔드포인트 부하 같은 인프라 요인이 전체 응답시간을 좌우한다. 매 단계마다 라우팅하면 유연성은 높지만 지연시간과 운영 복잡도가 증가한다.

최적화 문제로의 전환

이러한 교훈을 바탕으로 개발된 라우터는 라우팅을 분류 문제가 아닌 최적화 문제로 접근한다. '어느 모델이 최선인가' 대신 비용, 품질, 지연시간을 동시에 최적화하면서 라우터 자체가 병목이 되지 않도록 가볍게 유지한다 (작업당 약 6ms, 2KB 메모리).

AppWorld Test Challenge 결과는 이 접근법의 우위를 보여준다. 지연시간 최적화 설정(구성 1)은 84% 정확도, $93, 83초로 Opus 단독 실행 대비 21% 비용 절감, 9% 지연시간 단축을 달성했으며 정확도는 4%만 하락했다. 비교 대상인 난이도 기반 라우터(청록색 다이아몬드)는 유사한 정확도 범위에서 더 높은 비용을 보였다.