모델 라우팅은 간단할 때까지는 그렇다.

하지만 그렇지 않습니다. 대부분의 라우팅 시스템은 모델 선택이 분류(classification) 문제라고 가정합니다. 저희가 에이전트 시스템에 라우팅 기능을 구축하는 과정에서, 모델 선택처럼 보이는 것이 금방 시스템 최적화(systems optimization) 문제가 됩니다. 세 가지 차원이 이 문제를 놀라울 정도로 어렵게 만들었습니다.

저희는 GPT-4.1이 Claude Sonnet 4.6보다 저렴할 것으로 예상했습니다. 하지만 그렇지 않았습니다.

동일한 CodeAct 에이전트를 사용하여 AppWorld Test Challenge의 417개 작업에 걸쳐, Sonnet은 총 $79($0.19/작업)을 비용으로 지출한 반면 GPT-4.1은 $155($0.37/작업)로, 거의 두 배에 달했습니다. 이론적으로만 보면 이는 말이 되지 않습니다. GPT-4.1의 토큰 가격이 입력과 출력 모두에서 더 낮고, Sonnet은 동일한 작업을 완료하는 데 추론 단계(reasoning steps)가 약 세 배나 더 필요합니다. 스티커 가격만으로 판단하면 GPT-4.1이 쉽게 승리해야 합니다.

그 이유는 무엇일까요? 캐싱(Caching)입니다. 이는 대부분의 라우팅 논의에서 완전히 무시되는 부분입니다. 에이전트 워크로드는 단계별로 대규모 컨텍스트 덩어리를 재사용하는 경향이 있습니다. 캐시 적중률(cache hit rates)이 높을 때, 유효 입력 비용은 극적으로 떨어집니다. Sonnet의 낮은 캐시 읽기 가격은 이 패턴으로부터 불균형적인 이점을 얻었으며, 이는 더 높은 기본 가격과 긴 추적 궤적(longer trajectories)을 상쇄하기에 충분했습니다.

핵심 시사점: 실제 비용은 모델, 워크로드, 그리고 서비스 인프라 간의 상호작용에 달려 있습니다. 단순히 가격표만 보는 라우터는 잘못된 숫자를 기준으로 최적화하고 있는 것입니다.

일반적인 라우팅 전략 중 하나는 작업이 얼마나 어려운지 추정하여 더 어려운 작업을 더 강력한 모델로 보내는 것입니다. 직관적으로 들리지만, 두 가지 방식으로 무너집니다.

첫째, 난이도는 종종 라우팅 시점에는 보이지 않습니다.

둘째, 아무리 난이도를 완벽하게 추정할 수 있다 하더라도, 그것은 여러 신호 중 하나일 뿐입니다. 실제 서비스 환경(production)에서 라우터는 비용, 지연 시간(latency), 모델 특화성, 그리고 신뢰성을 동시에 균형 있게 맞춰야 합니다. 기업용 배포(Enterprise deployments)의 경우 여기에 더 많은 요소가 추가됩니다: 규정 준수 요구사항(compliance requirements), 데이터 상주 규칙(data residency rules), 개인 정보 보호 제약 사항(privacy constraints), 승인된 모델 목록 등입니다. 이상적으로는 하나의 모델로 처리되어야 할 작업이 거버넌스 문제 때문에 다른 곳으로 가야 할 수도 있으며, 이때 라우터가 이를 우아하게 처리해야 합니다.

라우터는 단 하나의 문제를 해결하는 것이 아닙니다. 그것은 비용, 품질(quality), 지연 시간, 규정 준수, 신뢰성을 한 번에 끊임없이 저글링합니다.

지연 시간을 단순히 모델 크기 측면에서만 생각하기 쉽습니다. 모델이 클수록 느리고, 작을수록 빠르다고 생각하기 쉽죠. 하지만 사용자가 실제로 경험하는 것은 그보다 훨씬 많은 것에 달려 있습니다.

라우팅 자체도 오버헤드를 발생시킵니다. 인프라 요소들—모델이 어떤 하드웨어에서 실행되는지, 캐시가 따뜻한 상태(cache is warm)인지, 엔드포인트가 얼마나 바쁜지—종종 종단 간 응답 시간(end-to-end response times)을 지배합니다. 이론적으로 더 빠른 모델이라도 서비스 조건이 적절하지 않으면 느린 경험을 제공할 수 있습니다.

그리고 라우팅의 세분성(granularity)도 문제입니다. 작업당 한 번만 라우팅하는 것은 최소한의 오버헤드만 추가합니다. 하지만 실행 중간에 조정할 수 있는 유연성을 더 많이 제공하는 '모든 단계에서' 라우팅을 하는 것은, 모든 추가적인 결정 지점마다 지연 시간과 운영 복잡성(operational complexity)을 초래합니다.

서비스 시스템을 무시하는 라우터는 잘못된 현실에 대해 최적화하고 있는 것입니다.

이러한 교훈들이 저희가 라우터를 구축하는 방식에 영향을 주었습니다. 핵심적인 변화는 다음과 같습니다: 우리는 라우팅을 분류 문제(classification problem)로 취급하는 것을 멈추고, 최적화 문제(optimization problem)로 취급하기 시작했습니다.

아래 그림은 CodeAct 에이전트를 사용한 AppWorld 테스트 챌린지 결과를 보여줍니다. 각 파란색 사각형은 저희 라우터의 다른 구성으로, 비용-정확도 프론티어(cost-accuracy frontier)를 추적합니다. 중요한 것은 어느 한 지점이 아니라, 라우터가 비용, 지연 시간 또는 정확도 중 무엇을 우선시하느냐에 따라 선택할 수 있는 작동점(operating points)의 범위를 제공한다는 점입니다. 구성 1(지연 시간 최적화)은 Opus 단독 실행 대비 비용을 21% 줄이고 지연 시간을 9% 줄인 $93 및 83초의 정확도 84%에 도달하며, 정확도는 단 4% 하락합니다. 구성 2는 비용을 더욱 낮춥니다.

표준적인 난이도 기반 라우터(청록색 다이아몬드)가 유사한 정확도 범위에 위치하지만 더 높은 비용으로 떨어진다는 점에 주목하십시오. 이는 최적화 기반 접근 방식처럼 전체 트레이드오프 공간을 탐색하지 못합니다. 또한, 최적화 자체가 가볍기 때문에(작업당 대략 6ms 및 2kB 메모리), 라우터가 이전에 경고했던 병목 지점이 되지 않습니다.

저희가 이 작업에서 얻은 교훈은 라우팅이 실제로 모델을 선택하는 것에 관한 것이 아니라는 것입니다. 시스템을 최적화하는 것에 관한 것입니다. 모델은 하나의 변수일 뿐입니다. 중요한 변수이지만, 캐싱 동작(caching behavior), 인프라 상태(infrastructure state), 규정 준수 제약 조건(compliance constraints) 및 워크로드 패턴(workload patterns) 중 하나에 불과합니다.

라우팅이 잘 작동하는 경우는 주어진 작업에 대해