NVIDIA의 오픈소스 라우팅 라이브러리 Switchyard

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Production AI agent는 분류, 간단한 도구 호출, 진행 확인, 복잡한 추론을 모두 가장 비싼 frontier model로 보내면서 불필요한 비용과 지연을 감수하는 경우가 많습니다. NVIDIA NeMo Switchyard는 agent와 모델 사이에 proxy 겸 library 형태의 라우팅 계층을 두고, 요청 또는 대화 turn마다 실제 처리 모델을 선택합니다. 튜토리얼은 OpenRouter와 openai/gpt-4o 및 openai/gpt-4o-mini를 연결해 무작위 라우팅에서 classifier 기반 deterministic routing, stage_router, escalation_router로 확장하는 과정을 보여줍니다. 예시 로그에서는 쉬운 요청이 weak 모델에서 1,428ms, 복잡한 Redis race-condition 요청이 strong 모델에서 4,475ms에 처리됐으며, 품질과 비용의 균형은 항상 strong·always weak·router 세 구성을 실제 workload에서 비교해야 판단할 수 있습니다.

섹션별 상세

Production AI agent는 단순한 분류와 도구 호출부터 복잡한 추론까지 모든 LLM 요청을 같은 고가 모델로 보내기 때문에 비용과 지연이 커집니다. Switchyard는 애플리케이션과 upstream 모델 사이에 proxy 겸 library 계층으로 들어가 요청 또는 turn마다 실제 처리 대상을 선택합니다. 클라이언트는 openai/gpt-4o 같은 구체적인 모델 대신 ab-test나 smart 같은 route ID를 호출하므로, 모델 선택 로직을 애플리케이션 코드와 분리할 수 있습니다.

가장 단순한 시작점은 strong과 weak 두 모델에 요청을 확률적으로 나누는 random_routing입니다. 예시 설정은 strong_probability를 0.3으로 두어 약 30%를 openai/gpt-4o에, 약 70%를 openai/gpt-4o-mini에 보내며 rng_seed와 fallback_target_on_evict도 지정합니다. 이 방식은 지능적인 난이도 판단은 하지 않지만 A/B 테스트와 proxy 설정 검증에 유용하고, 실제 예시에서는 gradient descent 질문이 weak tier로 전달되어 비용 $0.0001503이 기록됐습니다.

yaml

defaults:
  base_url: https://openrouter.ai/api/v1
  api_key: ${OPENROUTER_API_KEY}
routes:
  ab-test:
    type: random_routing
    strong:
      model: openai/gpt-4o
    weak:
      model: openai/gpt-4o-mini
    strong_probability: 0.3
    rng_seed: 42
    fallback_target_on_evict: weak

strong과 weak 두 모델에 요청을 무작위로 배분하는 기본 Switchyard 라우팅 설정입니다.

Switchyard의 deterministic classifier route는 classifier가 weak 모델의 해결 가능성을 p_solve 값으로 추정한 뒤 설정된 판단 기준에 따라 tier를 고릅니다. 쉬운 15% 계산 요청은 openai/gpt-4o-mini으로, Redis lease race condition의 안전한 재설계처럼 복잡한 요청은 openai/gpt-4o로 전달되는 흐름입니다. 기록된 예시에서 두 요청의 지연 시간은 각각 1,428ms와 4,475ms였으며, 애플리케이션이 모델명을 직접 하드코딩하지 않아도 요청별 선택이 이뤄졌습니다.

bash

switchyard serve \
  -c routes.random.yaml \
  --host 127.0.0.1 \
  --port 4000

지정한 YAML 라우팅 설정으로 Switchyard 서버를 로컬 4000번 포트에서 실행합니다.

요청 난이도뿐 아니라 coding agent의 작업 단계도 라우팅 신호가 될 수 있습니다. stage_router는 최근 turn의 오류, 반복되는 비생산적 행동, 탐색, 생산적인 변경 같은 conversation 및 tool-result 신호를 signal_recent_window 범위에서 살펴보고 추가 능력이 필요한 turn에 strong 모델을 배정합니다. 30턴짜리 agent 세션에서 탐색과 반복 편집까지 계속 강한 모델을 쓰는 낭비를 줄이고, established plan을 적용하는 효율적인 단계에는 weak 모델을 우선 사용할 수 있습니다.

escalation_router는 요청을 시작하기 전에 난이도를 예측하지 않고 weak 모델이 먼저 작업하게 한 뒤 실제 문제 신호가 지속될 때 strong 모델로 올립니다. judge가 최근 turn과 메시지 창을 평가하고 confirmations가 2로 설정된 경우처럼 일정한 확인 횟수를 충족하면 escalation이 발생하는 구조입니다. task difficulty가 세션 중 변할 수 있는 장기 agent 작업에서는 사전 분류보다 실제 처리 결과에 근거해 모델 능력을 추가하는 방식이 적합합니다.

yaml

defaults:
  base_url: https://openrouter.ai/api/v1
  api_key: ${OPENROUTER_API_KEY}
routes:
  smart:
    type: deterministic
    classifier:
      model: openai/gpt-4o-mini
    strong:
      model: openai/gpt-4o
    weak:
      model: openai/gpt-4o-mini
    profile: general
    session_affinity: true
    fallback_target_on_evict: weak

classifier가 요청을 평가해 weak 모델 또는 strong 모델로 보내는 결정론적 라우팅 설정입니다.

라우팅의 가치는 선택 정확도 자체보다 강한 모델의 품질을 얼마나 보존하면서 비용과 지연을 얼마나 줄였는지로 판단해야 합니다. Switchyard는 /metrics와 /v1/stats에서 요청, 오류, 지연 시간, 토큰, 라우팅 동작을 수집하며, always strong과 always weak를 각각 품질 상한과 저비용 기준선으로 삼아 router 결과와 비교할 수 있습니다. 기사에 제시된 예시인 strong-only 20달러·성공률 92%, weak-only 5달러·성공률 71%, router 9달러·성공률 89%는 라우팅이 실제 workload에서 비용을 낮추면서 품질 대부분을 유지했는지 판단하는 비교 방식입니다.

용어 해설

모델 라우팅(Model Routing): — 하나의 AI 애플리케이션이 모든 요청을 동일한 모델로 보내지 않고, 요청의 난이도나 작업 단계에 따라 여러 모델 중 적절한 대상을 선택하는 방식입니다. 비용과 지연 시간을 줄이면서 강한 모델의 품질을 최대한 유지하는 것이 핵심입니다.
프록시(Proxy): — 클라이언트와 실제 모델 서버 사이에 위치해 요청을 전달하고 응답을 중계하는 구성 요소입니다. Switchyard에서는 애플리케이션이 실제 upstream 모델을 직접 알지 않아도 라우팅 계층이 대상 모델을 선택하도록 만드는 역할을 합니다.
분류기 기반 라우팅(Classifier Routing): — 별도의 classifier가 각 요청을 약한 모델이 처리할 수 있는지 추정한 뒤, 설정된 기준에 따라 저비용 모델이나 강한 모델로 보내는 방식입니다. 요청 난이도를 사전에 판단한다는 점에서 실행 결과를 보고 올리는 escalation routing과 구분됩니다.
에스컬레이션 라우팅(Escalation Routing): — 먼저 저비용 모델에 요청을 보낸 뒤, 반복 실패나 지속적인 문제 같은 신호가 나타날 때 강한 모델로 작업을 넘기는 방식입니다. 요청을 처음부터 분류하는 대신 실제 처리 과정의 결과를 이용하므로 장시간 이어지는 agent 세션에 적합합니다.
Prometheus 메트릭(Prometheus Metrics): — 서버 요청 수, 오류, 지연 시간, 토큰 사용량, 라우팅 동작 등을 수치로 수집하는 관측 데이터입니다. Switchyard는 /metrics 엔드포인트를 통해 이런 정보를 제공해 라우팅이 품질과 비용을 실제로 개선했는지 비교할 수 있게 합니다.

기술

NVIDIA NeMo Switchyard
OpenRouter
uv
Rust
Cargo
Prometheus
openai/gpt-4o
openai/gpt-4o-mini

활용 사례

Production AI agent의 요청별 모델 선택
Coding agent의 turn별 모델 배정
저비용 모델 우선 처리와 조건부 escalation
LLM 비용·품질·지연 시간 비교 실험

NVIDIA의 오픈소스 라우팅 라이브러리 Switchyard

TL;DR

섹션별 상세

용어 해설

기술

활용 사례

관련 토론

댓글

관련 기사

모델 라우팅을 통한 LLM 비용 최적화와 성능 개선 전략

AI 모델 라우팅의 기술적 과제와 최적화 전략

LLM 라우팅은 세션을 바꾸면 손해일까

에이전트 시스템의 LLM 모델 선택

LLM 라우팅 개발부터 배포까지 통합 인프라