모델 라우터는 "어떤 모델을 먼저 사용할지 결정하는 데 도움을 주는" 스케줄링 계층으로 이해할 수 있습니다. 질문에 직접 답변하지는 않지만, 요청이 시스템에 들어온 후 작업 유형, 예산, 속도 요구사항, 컨텍스트 길이, 도구 요구사항 등을 바탕으로 더 적합한 모델이나 제공자에게 요청을 분배합니다. 최근 이 개념은 다중 모델이 객관식 문제에서 운영 문제로 바뀌면서 점점 더 인기를 얻고 있습니다. 많은 제품들이 한 모델만으로 세상을 지배할 수 없게 되었기 때문입니다.
초기에는 많은 팀이 매우 직관적이었습니다: 가장 강력한 모델을 선택해 모든 상황에서 사용하는 것. 문제는 곧 드러났다. 가장 비싼 모델인 폐기물의 단순한 작업; 긴 컨텍스트 작업은 짧은 윈도우 모델을 제공하며 크래시가 발생할 수 있습니다; 지연이 적은 실시간 장면은 느린 모델이고 경험이 좋지 않습니다. 그 결과, 점점 더 많은 팀이 모델 앞에 라우터를 추가하여 시스템이 먼저 분류하고 누가 응답할지 결정할 수 있게 되었습니다.
좋은 모델 라우터는 보통 여러 종류의 신호를 결합합니다. 예를 들어, 질문은 그것이 코드인지, 수학인지, 긴 문서인지, 음성 실시간 작업인지, 현재 어떤 공급자가 더 저렴하거나 더 안정적인지, 모델이 현재 한계를 트리거했는지, 그리고 컨텍스트가 임계값을 초과했는지 여부입니다. 사실 이는 품질, 비용, 지연 시간 사이에서 더 나은 해결책을 찾는 실시간 트레이드오프입니다.
이것이 모델 게이트웨이와 다른 점 중 하나입니다. 게이트웨이는 통합 인증, 기록, 청구 및 호환 인터페이스를 담당하는 인프라 입구입니다. 라우터가 더 많은 의사결정을 내리며 '이번에는 누가 가겠는가'에 대한 책임이 있습니다. 물론 실제 시스템에서는 두 단어가 종종 함께 등장하기 때문에 모두가 함께 이야기합니다.
왜 요금은 점점 표준에 가까워졌을까요? 모델 생태계가 너무 빠르기 때문입니다. 새로운 모델들이 끊임없이 나오고, 가격은 끊임없이 변하며, 역량의 경계도 함께 변하고 있습니다. 만약 제품이 여전히 데드 오더 모델을 작성한다면, 반복 속도가 느려집니다; 라우팅 계층이 독립적으로 되면, 팀은 모델을 더 유연하게 변경하고, A/B를 수행하며, 비용을 통제하고 수익을 관리할 수 있습니다. 기업용 애플리케이션에서는 단순히 가장 강력한 모델을 쫓는 것보다 이것이 더 현실적입니다.
하지만 라우터가 단순히 추가하는 게 아닙니다. 평가 기준, 예비 논리, 모니터링, 그리고 과거 데이터 지원이 필요합니다. 너무 치명적인 라우팅 규칙은 시스템을 점점 더 복잡하게 만듭니다; 라우팅을 다른 모델에 맡기면 추가 비용과 지연이 발생할 수 있습니다. 더 문제인 점은 경로가 잘못되면 사용자들은 보통 "오늘 이 제품이 어떻게 멍청해졌지"라고만 생각하고, 분류 전략에 문제가 있다는 사실을 거의 인지하지 못한다는 것입니다.
따라서 모델 라우터의 인기는 업계의 초점이 "모델이 존재하는지"에서 "다중 모델 기능을 어떻게 조직할지"로 옮겨갔음을 보여줍니다. 앞으로 많은 AI 제품들이 보조원처럼 보이지만, 그 이면에는 실제로는 일정 관리 시스템에 더 가깝게 작용할 것입니다. 사용자들은 답만 볼 뿐이며, 실제로 결정을 내리는 것은 종종 라우팅 계층입니다.
