모델 라우팅은 처음에는 단순해 보인다. 쉬운 요청은 저렴한 모델로 보내고, 어려운 요청은 강한 모델로 보내면 된다. 코드에는 Claude, 멀티모달에는 Gemini 같은 식의 규칙도 만들 수 있다. 하지만 IBM Research가 Hugging Face 블로그에서 공유한 경험은 이 접근이 운영 환경에서 빠르게 한계에 부딪힌다는 점을 보여준다.
가장 눈에 띄는 사례는 비용이다. AppWorld Test Challenge의 417개 태스크를 같은 CodeAct agent로 실행했을 때, Claude Sonnet 4.6은 총 $79, 태스크당 $0.19가 들었다. GPT-4.1은 총 $155, 태스크당 $0.37이었다. 토큰 가격표만 보면 GPT-4.1이 더 싸야 한다. 입력과 출력 단가가 낮고, Sonnet은 같은 일을 끝내는 데 더 많은 reasoning step을 쓰기 때문이다.
결과를 뒤집은 변수는 캐싱이었다. 에이전트 워크로드는 여러 단계에서 큰 컨텍스트를 반복해서 읽는 경우가 많다. 이때 cache hit가 높으면 실제 입력 비용이 크게 낮아진다. Sonnet은 cache-read pricing의 이점을 크게 받아, 높은 기본 단가와 긴 실행 경로의 불리함을 상쇄했다. 가격표만 보는 라우터는 여기서 잘못된 결정을 내릴 수 있다.
난이도 추정도 충분하지 않다. “계약서 요약” 같은 요청은 겉으로는 단순하지만 retrieval, compliance check, tool use, refinement를 거치며 복잡해질 수 있다. 반대로 어려워 보이는 기술 프롬프트도 작은 특화 모델이 빠르게 처리할 수 있다. 실행 전에는 실제 난이도가 잘 보이지 않는다는 뜻이다.
지연시간 역시 모델 크기만으로 설명되지 않는다. 라우터 자체의 호출 비용, endpoint 부하, cache warm 상태, serving hardware가 모두 사용자가 체감하는 시간을 바꾼다. 태스크마다 한 번 라우팅하면 단순하지만, step마다 라우팅하면 적응력은 올라가는 대신 decision point와 운영 복잡도가 늘어난다.
IBM Research의 결론은 라우팅을 classification 문제가 아니라 optimization 문제로 보자는 것이다. 어떤 모델이 이 태스크에 맞는지를 맞히는 대신, cost·quality·latency 사이의 운영 지점을 찾는다. 예시 configuration에서는 Opus 단독 실행 대비 정확도는 4%p 낮아졌지만, 비용은 21%, latency는 9% 줄였다. 라우터 자체도 task당 약 6ms와 2kB memory 수준으로 가볍게 유지했다.
이 글이 중요한 이유는 model router를 플러그인처럼 가볍게 붙일 기능이 아니라 agent runtime의 일부로 보게 만들기 때문이다. 실제 운영에서 중요한 질문은 “어느 모델이 제일 좋은가”가 아니다. 이 workload, 이 cache behavior, 이 infrastructure, 이 compliance constraint 아래에서 어느 조합이 가장 현실적인가다.