Model Routing
다중 모델 시스템에서 정확도, 비용, 지연 시간, 리소스 사용량의 균형을 맞추기 위해 모델 라우팅이 각 요청에 적합한 AI 모델을 선택하는 방법을 알아보세요.
모델 라우팅은 들어오는 각 요청을 처리할 AI 모델을 선택하는 프로세스입니다. 모든 입력을 단일 모델로 전송하는 대신, 라우팅 레이어는 요청된 작업, 입력 유형, 복잡성, 지연 시간 목표, 비용 한도, 하드웨어 가용성 또는 신뢰도 요구 사항 등의 신호를 평가합니다. 그런 다음 가장 적합한 후보에게 요청을 전달합니다. 이 맥락에서 “라우터”는 물리적 네트워크 라우터가 아니라 추론 결정 컴포넌트입니다. 라우팅은 다중 모델 머신 러닝 시스템이 예측 품질, 리소스 사용량, 추론 지연 시간의 균형을 맞추도록 돕습니다.
모델 라우팅의 작동 방식#
라우팅 시스템은 일반적으로 배포된 모델 풀, 결정 로직, 공통 애플리케이션 인터페이스를 포함합니다. 애플리케이션이 하나의 요청을 제출하면 라우터가 적격한 모델을 선택하고, 모델 서빙 레이어는 해당 모델의 출력을 반환합니다.
라우팅 결정은 다음과 같은 방식일 수 있습니다:
- 규칙 기반: 마스크를 요청하는 이미지를 세분화 모델로 라우팅하는 것과 같이 명시적인 메타데이터를 사용하여 모델을 선택합니다.
- 점수 기반: 각 후보의 예상 품질, 비용 또는 응답 시간을 추정하고 가장 높은 점수를 받은 옵션을 선택합니다.
- 학습 기반: 경량 분류기나 라우팅 모델을 사용하여 어떤 후보가 입력에 가장 잘 부합하는지 추론합니다.
- 캐스케이드: 빠른 모델을 먼저 실행한 다음, 불확실하거나 위험도가 높은 결과를 더 성능이 뛰어난 모델로 에스컬레이션합니다.
예를 들어 Amazon Bedrock intelligent prompt routing은 언어 모델 중에서 선택하기 전에 응답 품질을 예측하는 반면, Microsoft’s model-routing strategy guidance는 비용, 품질 및 균형 잡힌 라우팅을 설명합니다. 유사한 원리가 컴퓨터 비전에도 적용됩니다. 작업, 카메라 위치, 이미지 해상도 또는 필요한 예측 세부 정보에 따라 요청을 라우팅할 수 있습니다.
관련 개념 및 주요 차이점#
모델 라우팅은 다른 다중 모델 기술과 긴밀하게 연결되어 있지만, 두 용어가 서로 호환되는 것은 아닙니다.
- AI 게이트웨이: AI 게이트웨이는 인증, 할당량, 로깅 및 트래픽 관리를 위한 더 넓은 제어 레이어를 제공합니다. 모델 선택은 게이트웨이 기능 중 하나일 수 있습니다. Kubernetes Gateway API Inference Extension 또한 모델 인식 라우팅을 엔드포인트 선택 및 부하 분산과 구분합니다.
- 모델 앙상블: 앙상블은 일반적으로 여러 모델을 실행하고 그 예측을 결합합니다. 반면 라우터는 보통 하나의 모델을 선택하여 연산량을 줄입니다. NVIDIA Triton ensemble models은 대신 여러 모델을 통과하는 고정된 데이터 플로우를 정의합니다.
- 전문가 혼합: MoE 아키텍처는 내부 표현을 단일 신경망 내부의 컴포넌트로 라우팅합니다. 모델 라우팅은 개별적으로 배포 가능한 모델 또는 엔드포인트 중에서 선택합니다.
- 에이전트 라우팅: 에이전트 라우터는 특화된 에이전트, 워크플로 또는 도구를 선택합니다. 모델 라우팅은 추론 단계를 수행하는 기본 모델을 선택합니다. 에이전틱 시스템에서는 두 형태의 라우팅이 모두 존재할 수 있습니다.
부하 분산은 또 다른 중요한 차이점입니다. 부하 분산은 가용성이나 처리량을 향상시키기 위해 동일한 서비스의 복제본 간에 요청을 분산합니다. 모델 라우팅은 서로 다른 기능, 비용 또는 출력을 가진 모델 중에서 선택합니다.
실제 적용 사례#
시각적 검사: 제조 시스템은 일상적인 부품 카운팅을 위해 객체 감지를 사용할 수 있지만, 정확한 경계를 위해 의심스러운 표면 결함을 인스턴스 세분화로 라우팅할 수 있습니다. Ultralytics YOLO26은 객체 감지와 인스턴스 세분화를 모두 지원하므로 일관된 API 내에서 작업 기반 라우팅이 가능합니다. 이를 통해 바운딩 박스로 충분할 때 세분화 비용을 지불하지 않아도 됩니다.
AI 어시스턴트: 지원 어시스턴트는 간단한 분류 및 조회 요청을 작고 빠른 언어 모델로 전송할 수 있는 반면, 복잡한 추론이나 도구 사용을 위해서는 더 강력한 모델을 할당합니다. Google Cloud’s agentic architecture guidance는 이 패턴을 품질, 지연 시간, 비용의 균형을 맞추는 방법으로 설명합니다. 고정된 캐스케이드와 달리 동적 라우팅은 초기 답변을 생성하기 전에 더 강력한 모델을 선택할 수 있습니다.
라우터 구현 및 평가#
이 최소한의 Ultralytics 예시는 애플리케이션이 요청한 출력에 따라 이미지를 감지 또는 세분화로 라우팅합니다:
from ultralytics import YOLO
models = {
"detect": YOLO("yolo26n.pt"),
"segment": YOLO("yolo26n-seg.pt"),
}
requested_task = "segment"
source = "https://ultralytics.com/images/bus.jpg"
model = models.get(requested_task)
if model is None:
raise ValueError(f"Unsupported task: {requested_task}")
results = model(source)
result = results[0]
result.save(filename=f"{requested_task}_result.jpg")이 규칙은 의도적으로 단순합니다. 객체 마스크가 필요한 요청은 세분화로 이동하고, 박스만 필요한 요청은 감지를 사용할 수 있습니다. 프로덕션 라우터는 측정된 정확도, 큐 깊이, 장치 유형, 개인 정보 보호 제약 조건 또는 서비스 상태도 고려할 수 있습니다.
모델 평균에만 의존하지 말고 대표적인 트래픽을 기준으로 라우팅을 평가하세요. 선택된 각 모델에 대해 라우트 분포, 엔드투엔드 지연 시간, 비용, 실패 및 작업 수준 품질을 추적하세요. OpenTelemetry observability guidance는 추적, 메트릭, 로그가 분산 서비스 전체에서 개별 요청을 어떻게 추적할 수 있는지 설명합니다. Ultralytics Platform deployment monitoring도 유사하게 엔드포인트 지연 시간, 오류, 상태 및 요청 활동 검사를 지원합니다.
잘못된 라우팅은 비용을 증가시키고, 지연 시간 목표를 놓치며, 어려운 입력을 부적절한 모델로 보낼 수 있습니다. 따라서 팀은 대체 동작을 정의하고, 민감한 워크로드에 대해 적격 모델을 제한하며, 선택된 라우트를 로깅하고, 정책을 주기적으로 재테스트해야 합니다. 이러한 제어는 라우팅 결정을 NIST AI Risk Management Framework의 광범위한 관행과 일치시킵니다.
