Preferences Over Benchmarks: Model Routing — Archana Kamath & Tyler Gillam, DigitalOcean

한 줄 핵심

단일 모델을 최고 점수로 고르는 습관은 비용·지연·장애 위험을 키우므로, 작업별 선호와 평가를 반영해 모델을 라우팅하는 방식이 더 현실적이고 효율적이다.

시간별 요약

1. 0:00
   하나의 모델 습관이 무너지는 이유 모든 작업에 하나의 모델을 쓰는 방식은 비용 급증, 작업 적합성 부족, 단일 장애 지점이라는 세 가지 문제를 낳는다. 모델 선택은 벤치마크 순위보다 실제 운영 비용과 리스크를 기준으로 다시 봐야 한다.
2. 2:42
   단 하나의 최적 모델은 없다 분류·라벨링, 코드 완성, 코드 생성, 보안 검토처럼 작업 성격이 다르면 적합한 모델도 달라진다. 정답은 공개 리더보드가 아니라 작업 목표, system prompt와 tools, 허용 비용, 지연 허용치, 최종 사용자 선호의 조합에 의해 결정된다.
3. 4:21
   맞춤 설정하고 평가할 수 있는 라우터 이 라우터는 블랙박스 자동 선택이 아니라, 작업별 선호와 규칙을 자연어와 설정으로 반영해 요청마다 모델을 고른다. 오픈 프록시와 목적 특화 라우팅 모델을 모두 open source로 제공해 vendor lock-in 없이 수정·평가·개선이 가능하다.
4. 6:57
   태스크, 모델 풀, 장애 대비 설정 bug fixing, code generation, test writing처럼 작업을 나누고 각 작업마다 여러 모델을 연결할 수 있다. 예를 들어 manual ranking으로 GLM 5.2를 우선 사용하되 실패 시 GPT 5.2로 failover하거나, fastest 정책으로 최근 30분 기준 가장 빠른 모델을 선택할 수 있다.
5. 7:48
   플레이그라운드에서 직접 비교하기 같은 요청을 Opus와 라우터에 나란히 넣어 보면, 라우터가 작업별로 더 싸고 빠른 모델을 고르는 모습을 바로 확인할 수 있다. 단순 체감만으로는 충분하지 않으며, 실제로는 평가를 통해 성능을 입증해야 한다.
6. 9:29
   평가로 성능을 입증하기 평가 결과에서 라우터와 Opus의 정확도는 거의 비슷했지만, 라우터가 훨씬 적은 토큰과 더 낮은 지연으로 동일한 수준의 결과를 냈다. 즉, 라우팅은 품질을 크게 해치지 않으면서 비용과 속도를 함께 줄이는 방식이다.
7. 10:18
   두 개의 코딩 에이전트와 세션 비용 격차 하나는 모든 요청을 premium 모델 하나로 보내고, 다른 하나는 작업별로 라우팅해 실시간으로 비용과 모델 선택을 관찰한다. 같은 기능 요청 흐름에서도 라우터 쪽은 세션 총비용이 크게 낮아지고, 품질은 비슷하게 유지된다.
8. 13:49
   200ms 미만, 오픈 소스, 코드 변경 없음 라우팅 결정은 요청당 200ms 미만이며, 목적 특화 MoE 모델로 동작한다. 애플리케이션 코드 변경 없이 바로 적용할 수 있고, 전체 라우팅 모델은 Plano을 통해 open source로 공개된다.
9. 14:43
   평가, 캐싱, 개인화 라우팅의 다음 단계는 평가로 정답을 검증하고, 캐싱으로 같은 응답에 중복 비용을 줄이며, 개인화로 팀에 맞는 선택을 학습하는 것이다. 라우팅을 반복할수록 평가 결과가 쌓여 더 나은 선택으로 이어지는 지속 개선 루프가 만들어진다.

실무 인사이트

• 모델 선택 기준을 리더보드 대신 작업 유형·비용·지연·사용자 선호로 재정의하면, 과도한 frontier 모델 사용을 줄이면서도 품질을 유지할 수 있다.
• 라우터 도입의 핵심은 자동화가 아니라 평가 체계다. 자신의 워크로드 기준으로 비교 평가를 만들어야 라우팅 규칙을 안전하게 개선할 수 있다.
• 실무에서는 failover, 최근 성능 기반 선택, 캐싱, 개인화를 함께 넣어야 라우팅이 단순 비용 절감 도구를 넘어 안정적인 운영 계층이 된다.