AI 에이전트를 개발할 때 단 하나의 모델만 고집할 필요는 없습니다. 작업 종류나 진행 단계에 따라 모델마다 강점, 단점, 비용 효율성이 완전히 다르기 때문입니다. 실제로 에이전틱 AI 작업은 단순 분류로 시작해 고난도 추론을 거친 뒤, 루틴한 후속 작업으로 이어지는 경우가 많습니다. 이때 모든 요청을 최고 성능의 대형 모델에 몰아주면 비용과 응답 지연이 급증하고, 반대로 저단가 소형 모델만 쓰면 복잡한 연산에서 품질이 떨어지는 계륵에 빠집니다.
모델 라우팅은 특화 모델과 최고 성능의 프론티어(Frontier) 모델을 최적으로 조합하여 이 딜레마를 해결합니다. NVIDIA NeMo Switchyard는 이러한 복잡한 구조를 에이전트 워크로드에 손쉽게 이식해 줍니다. 개발자는 특정 공급업체나 개별 모델에 맞춰 코드를 매번 새로 짜지 않고도 여러 모델에 작업을 효율적으로 배분할 수 있습니다.
실행 단계에서 라우터는 들어오는 요청과 문맥을 실시간으로 분석한 뒤, 해당 작업의 조건과 정책에 가장 부합하는 모델로 일을 넘겨줍니다. 이처럼 여러 모델을 하나처럼 묶어 쓰는 ‘모델 시스템(System of Models)’ 방식은 단일 거대 모델만 사용할 때보다 비용은 대폭 낮추면서도 종합적인 정확도는 오히려 끌어올립니다.
NeMo Switchyard는 다채로운 라우팅 전략을 즉시 적용할 수 있는 라이브러리를 제공합니다. 본 글에서는 NeMo Switchyard가 선사하는 모델 시스템 접근 방식을 살펴보고, 실제 프로덕션 환경에 최적화된 효율적이고 제어 가능한 에이전트를 구축하는 방법을 알아봅니다.
모델 라우터의 의사결정 방식
Terminal-Bench Hard 벤치마크로 측정된 컴퓨터 사용(computer-use) 작업을 수행하는 모델 시스템을 생각해 보겠습니다(그림 1). 이 예시에서 DeepSeek V4는 전체적으로 가장 높은 정확도를 보이지만, 모든 작업 그룹에서 최선의 모델은 아닙니다. 예를 들어 Kimi K2.6은 ML 및 RL 작업 그룹에 더 적합하고, Qwen3.5 397B A17B는 수학과 과학 분야에서 선호됩니다. 나머지 6개 작업 그룹에는 DeepSeek V4를 사용해야 합니다. 이 접근 방식은 개별 작업 수준이나 단일 작업 해결의 각 단계에도 적용할 수 있습니다.
그림 2에서 볼 수 있듯이 비용과 완료 시간은 의사결정을 더욱 복잡하게 만듭니다. 각 모델은 모델 실행 또는 접근과 관련된 고유한 비용과, 토큰뿐 아니라 툴 호출과도 연관된 고유한 상세도(verbosity) 프로파일을 가집니다.
라우터를 구축하려면 다양한 소스의 신호를 고려해야 합니다. 각 라우팅 알고리즘은 이러한 신호를 어디서 도출할지 결정하는 데 도움을 줍니다.
효과적인 라우팅 결정은 크게 세 가지 영역의 신호에 의존합니다.
- 모델 역량: 어떤 모델이 작업을 올바르게 해결할 수 있는지.
- 모델 비용 프로파일: 각 모델과 관련된 지연 시간 및 비용.
- 인프라: 안정적이고 원활한 핸드오프를 가능하게 하는 시스템 수준 신호.
역량 및 비용 신호를 파악하는 방법은 다음과 같습니다.
- 요청 자체를 살펴봅니다. 라우터는 분류를 활용해 주제나 예상 난이도에 따라 요청을 매칭할 수 있습니다. 예를 들어 분류기는 쿼리의 주제를 파악하고 모델 풀의 모델과 매칭한 후 적절히 라우팅할 수 있습니다. 임베딩 모델이나 특징 추출기(feature crafter)를 사용해 쿼리에서 특징을 추출할 수 있습니다.
- 모델 상태를 살펴봅니다. 라우터는 모델의 로그프로브(logprob), 캐스케이드, 에이전틱 추적, 모델의 잔류 스트림(residual stream), 어텐션 행렬 등을 검토할 수 있습니다.
- 시스템을 살펴봅니다. 가격, 지연 시간, 부하, 오류를 포함한 에이전트 특정 신호 등이 옵션입니다. 이러한 신호는 모델 라우터를 평가하거나 실시간 라우팅 신호로 활용할 수 있습니다.
중요한 점은, 라우터가 어떤 신호를 사용할지뿐만 아니라 언제, 어디서 평가할지도 고려해야 한다는 것입니다. 예를 들어 멀티 턴 에이전트 작업에서 라우터는 전체 요청을 특정 모델로 라우팅하거나 각 단계에서 라우팅할 수 있습니다. 전체 시스템이 하나의 풀을 공유할 수도 있고, 서브 에이전트가 작업에 특화된 모델 풀을 사용할 수도 있습니다.
이러한 질문에 대한 답은 활용 사례, 배포 복잡성, 오류 허용 범위, 지연 시간, 처리량 제약 등 여러 요소에 따라 달라집니다. 또한 시스템에는 에이전트/사용자에게 원활하고 투명한 핸드오프를 위한 인프라가 필요합니다.
NeMo Switchyard는 여러 라우터를 지원하는 지능형 오케스트레이션 레이어로 이러한 문제를 해결합니다. 개발자는 자체 라우팅 알고리즘이나 커스터마이징 데이터를 NeMo Switchyard에 추가할 수도 있습니다.
NeMo Switchyard의 라우팅 구현 방식
라우팅 알고리즘은 서로 다른 강점을 가진 모델 간 라우팅 결정을 안내하는 신호를 생성합니다. 또한 시스템에는 라우터의 결정을 수행하고, 요청을 선택한 모델로 전송하며, 응답을 애플리케이션으로 반환하는 인프라가 필요합니다.
이는 NeMo Switchyard의 기반이 되는 공급업체 독립적(provider-agnostic) SDK인 NeMo switchyard-libsy에서 시작됩니다. 이 SDK는 요청을 표현하고, 시스템에서 사용 가능한 모델을 정의하며, 선택된 모델에 대한 호출을 관리합니다. 각 모델 타깃은 시맨틱 이름을 가지며, 그 뒤의 클라이언트가 해당 이름을 공급업체 엔드포인트와 모델 ID에 매핑합니다. 이러한 분리 구조 덕분에 라우팅 로직이 특정 공급업체에 종속되지 않습니다.
NeMo Switchyard는 정책이 필요할 때 에이전트 세션 전반에 걸쳐 라우팅 상태를 유지할 수 있습니다. 또한 툴 결과나 친화성(affinity) 결정과 같은 이전 턴의 정보를 보존하고, 이후 라우팅 결정에 해당 컨텍스트를 제공할 수 있습니다. 이러한 이력이 필요하지 않은 경우 라우팅을 스테이트리스로 유지할 수도 있습니다.
이러한 분리는 모델 배포가 변경되기 때문에 중요합니다. 팀이 모델을 업데이트하거나, 다른 엔드포인트로 이동하거나, 다른 공급업체를 사용하더라도 라우팅 통합을 변경할 필요가 없습니다. NeMo Switchyard는 타깃 클라이언트를 통해 모델 호출을 수행하거나, 호출을 호스트 애플리케이션으로 반환할 수 있습니다. 이를 통해 에이전트 런타임, 추론 플랫폼, 게이트웨이가 동일한 라우팅 계약을 유지하면서 요청 처리 방식을 제어할 수 있습니다.
NeMo Switchyard 서버는 LLM 게이트웨이를 시뮬레이션하여 일반적인 API를 통해 라우팅을 제공하는 참조 구현입니다. OpenAI, Anthropic, Responses API 요청을 수락하고, 이를 NeMo Switchyard 내부 요청 형식으로 변환하며, 예상되는 응답 형식으로 반환합니다. 또한 선택된 모델, 결정 근거, 토큰 사용량, 지연 시간, 호출 결과를 기록하여 팀이 실행 중인 라우팅을 검토할 수 있게 합니다.
NeMo Switchyard의 라우팅 알고리즘
인프라가 갖춰지면 다음 단계는 이를 활용해 의사결정을 내리는 라우팅 방식을 살펴보는 것입니다. NeMo Switchyard는 튜닝 불필요(tuning-free) 라우터와 조정 가능(tunable) 라우터를 모두 제공합니다.
튜닝 불필요 라우터
NeMo Switchyard에는 워크로드별 데이터 학습 없이 의사결정을 내리는 여러 튜닝 불필요 라우터가 포함되어 있습니다. LLM 분류기, 스테이지 라우터, 에스컬레이션 라우터가 이에 해당합니다.
LLM 분류기
LLM 분류기는 LLM을 판별자(judge)로 활용해 후보 LLM을 선택하고, 이후 턴 전반에 걸쳐 해당 모델과의 세션 친화성을 유지합니다. 이를 통해 에이전트가 작업을 해결하는 과정에서 실질적인 변화 없이 반복적으로 작업을 재분류하는 것을 방지합니다.
이 방식은 헤드리스(headless) 시스템과 도메인 특화 시스템에 적합합니다. 팀은 코딩, 수학, 의료 관련 작업을 선택된 모델 타깃으로 라우팅하고, NeMo Switchyard가 라우팅과 상태 관리를 담당하게 할 수 있습니다.
스테이지 라우터
코딩 에이전트는 여러 단계를 거칩니다. 초기에는 코드베이스를 탐색하고 오류를 복구하며, 이후에는 보다 기계적인 구현 단계로 전환됩니다. 이러한 단계에는 서로 다른 수준의 모델 역량이 필요하며, 스테이지 라우터는 이를 라우팅 결정에 활용합니다.
스테이지 라우터는 매 턴마다 최근 툴 활동을 분석하여 에이전트에게 필요한 모델 역량 수준을 결정합니다. 심각한 오류, 반복적인 비생산적 작업, 또는 장기간의 탐색은 해당 턴을 고성능 모델 쪽으로 기울이고, 특히 테스트를 통과한 후 지속적인 작성 및 편집은 효율적인 모델을 선호합니다. 신호가 불명확한 경우 라우터는 LLM 판별자에게 의뢰한 후 구성된 기본값으로 폴백할 수 있습니다.
에스컬레이션 라우터
에스컬레이션 라우팅은 각 대화를 비용이 낮은 모델로 시작합니다. LLM 판별자가 매 턴마다 작업 진행 상황을 모니터링하고, 지속적인 어려움이 감지되면 세션을 더 강력한 모델로 이동시킵니다.
이 방식은 소형 모델이 루틴 작업은 처리할 수 있지만 반복적인 오류, 루프, 또는 표류 후에는 지원이 필요할 수 있는 멀티 턴 에이전트 워크로드를 위해 설계되었으며, LLM 분류기 라우팅 방식을 정적에서 적응형으로 확장합니다.
조정 가능 라우터
조정 가능 라우터는 고정된 휴리스틱 대신 실제 워크로드 데이터에서 학습한 신호를 사용하여 이 라우팅 기반을 발전시킵니다. 요청 텍스트를 기반으로 가장 적합한 모델을 결정하는 대신, 조정 가능 라우터는 각 후보 모델이 요청에 올바르게 답할 가능성을 예측하는 방법을 학습할 수 있습니다.
프리필 라우터
학습 중 프리필(prefill) 라우터는 LLM의 잔류 스트림(residual stream)을 추출하여 쿼리의 복잡도를 추정합니다. 공유 트렁크(shared-trunk) MLP는 잔류 스트림의 신호를 사용하고, 이를 라우팅 풀의 각 LLM에 대한 정확도 레이블에 매핑합니다.
추론 시 프리필 상태는 라우터의 입력으로 작용하며, 공유 트렁크는 각 LLM이 작업을 성공적으로 완료하거나 쿼리에 답할 가능성을 예측합니다.
그런 다음 라우터는 예측 정확도와 비용, 지연 시간, 또는 기타 배포 제약을 혼합하는 정책을 적용할 수 있습니다. 각 후보 모델은 점수를 받고, 해당 워크로드에서 가장 좋은 트레이드오프를 가진 모델로 요청이 라우팅됩니다. 그림 5는 라우팅이 단순히 가장 강력한 모델을 선택하는 것이 아님을 보여줍니다. 요구되는 품질 수준을 적절한 비용으로 충족할 가능성이 가장 높은 모델을 선택하는 것입니다.
NeMo Switchyard로 에이전트 효율성 향상
NVIDIA는 에이전트, 모델, 엔터프라이즈 애플리케이션 생태계 전반의 파트너들과 협력하여 별도 설정 없이 기존 개발자 워크플로에 NeMo Switchyard 모델 라우팅을 통합하고 있습니다. 이러한 협업에는 다음이 포함됩니다.
- 에이전트 워크플로우: Cognition과의 코딩 에이전트 워크플로, Nous Research와의 간편하게 구성 가능한 Hermes Agent 모델 라우팅, Ramp와의 금융 소프트웨어 엔지니어링 워크플로, LangChain과의 모델 라우팅 평가.
- 애플리케이션 및 인프라 통합: LiteLLM과의 플러그인 형태 LLM 애플리케이션 스택; Kong과의 AI 게이트웨이, 거버넌스, API 트래픽 관리; Classmethod와의 Claude 모델 라우팅; Boomi Agent Garden과의 엔터프라이즈 자동화 및 연결성.
- 산업별 AI 에이전트: ChipStack AI Super Agent에서 Cadence와의 공식 검증(formal verification) 워크플로 및 Siemens와의 EDA(전자 설계 자동화) 에이전트 워크플로.
LangChain은 내부 딥 에이전트 평가 스위트를 사용해 NeMo Switchyard를 벤치마크했습니다. 이 스위트는 정책 제약이 있는 고객 지원 대화, 온콜 장애 조사, 메시징·이슈 추적·이메일에 걸친 멀티 스텝 워크플로 자동화와 같은 프로덕션 워크로드를 반영한 145개의 멀티 턴 에이전틱 작업을 포함합니다. 툴 사용, 멀티 스텝 검색, 파일 시스템 작업, 장문 컨텍스트 요약을 평가하며, 시나리오는 τ²-bench airline, Berkeley Function Calling Leaderboard, FRAMES, Nexus에서 가져왔습니다. 에스컬레이션 라우터로 NVIDIA Nemotron 3.5 Lightning과 Claude Opus 4.8 사이에서 요청을 라우팅한 5회 실행에서, 프론티어 전용 기준 대비 74% 비용 절감을 달성했으며, 전체 호출의 7%만 프론티어 모델로 전송하면서 약 6포인트의 정확도 트레이드오프를 기록했습니다.
Cognition은 NeMo Switchyard 스테이지 라우팅 방법론을 Devin Desktop에 구현하고 실제 테스트를 위해 NVIDIA 내부 사용자에게 배포했습니다. 프로덕션 수준 코딩 작업을 위한 Cognition의 벤치마크인 FrontierCode Main에서, 구현은 Opus 5와 Kimi K2.7 사이에서 라우팅했습니다. 평균 비용 3.11달러로 50.6%의 정확도를 달성하며, Opus 5 정확도 대비 약 2.8포인트 차이를 유지하면서 평균 비용을 약 28% 절감했습니다. 벤치마크와 내부 배포 결과를 종합하면, 모델 중립적이고 적응형 에이전트의 실용적인 사례 연구가 됩니다. 각 모델의 상호 보완적 강점이 작업의 진행에 따라 동적으로 활용될 수 있음을 보여줍니다.
개발자는 친숙한 에이전트 툴, 프레임워크, 게이트웨이에 NeMo Switchyard를 통합하는 파트너 연동으로 시작하거나, NeMo Switchyard GitHub 지침을 사용해 자체 에이전트와 LLM 게이트웨이에 커스텀 라우팅을 구축할 수 있습니다.
오케스트레이션의 시대
모델 라우팅은 특화 모델과 프론티어 모델의 시스템이 협력하여 각 부분의 합을 뛰어넘는 결과를 달성할 수 있게 합니다. 그러나 유용하고 프로덕션에 즉시 투입 가능한 라우팅 시스템을 구축하는 것은 여전히 매우 어려운 엔지니어링 과제입니다.
NeMo Switchyard는 완전한 오픈 소스로 이미 사용 중인 기술과 통합됩니다. 특정 활용 사례에 맞는 라우팅 알고리즘을 생성, 테스트, 기여할 수 있는 GitHub에서 NeMo Switchyard를 시작해 보십시오.
AI 시스템이 점점 더 많은 모델을 결합하면서, 라우팅은 효율성, 품질, 비용의 균형을 맞추면서 각 작업에 적합한 모델을 선택하는 데 필수적인 요소가 되었습니다.
NVIDIA 뉴스 구독 및 LinkedIn, X, Discord, YouTube에서 NVIDIA AI를 팔로우하여 NVIDIA AI의 최신 소식을 받아보십시오. 시작에 필요한 리소스는 개발자 페이지를 방문하세요. Hugging Face에서 오픈 Nemotron 모델 및 데이터셋을, build.nvidia.com에서 블루프린트를 살펴보세요. Nemotron 라이브스트림, 튜토리얼, NVIDIA 포럼 및 Discord 개발자 커뮤니티에도 참여해 보세요.
