The State of Model Routing — NVIDIA, Cognition, OpenRouter
📺 원본 영상: The State of Model Routing — NVIDIA, Cognition, OpenRouter
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-08-07
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 패널의 핵심 주제는 AI 시스템이 단일 모델 중심 구조에서 벗어나 여러 모델을 상황에 맞게 조합하는 “모델 라우팅(Model Routing)”의 시대로 이동하고 있다는 점이다. NVIDIA, Cognition, OpenRouter의 패널들은 비용, 성능, 캐시, 로컬 추론, 에이전트 협업이라는 서로 다른 관점에서 모델 라우팅이 왜 중요한 문제로 떠올랐는지를 설명한다.
논의의 초점은 단순히 “비싼 모델 대신 싼 모델을 쓰자”는 비용 절감에 머물지 않는다. 오히려 패널들은 더 똑똑한 모델이 계획과 감독을 맡고, 더 저렴하거나 특정 영역에 강한 모델이 실행을 담당하는 구조가 전체 시스템의 품질과 경제성을 동시에 개선할 수 있다고 본다. 이 관점에서 모델 라우팅은 API 선택 기능이 아니라, 앞으로 에이전트 시스템과 모델 학습 과정 자체에 깊게 통합될 가능성이 큰 인프라 레이어로 해석된다.
단일 모델의 시대가 저물고 있다
패널의 출발점은 “우리는 멀티모델 세계에 있다”는 전제였다. NVIDIA 측 진행자는 프로덕션 환경에서 AI를 배포하는 팀, 특히 로컬 환경까지 고려하는 팀일수록 하나의 모델만으로 모든 요구를 충족하기 어렵다는 사실을 이미 체감하고 있다고 설명한다. 이 때문에 NVIDIA가 Nemotron 모델을 공개하면서 데이터셋, 가중치, 레시피까지 함께 제공한 것도, 결국 기업과 개발자가 자신들의 워크로드에 맞게 모델을 커스터마이즈할 필요가 커질 것이라는 판단에 기반한다.
Cognition의 Walden은 이 문제를 고객의 ROI(Return on Investment) 관점에서 풀어낸다. 기업 고객들은 어떤 작업에 가장 비싼 frontier model을 써야 하고, 어떤 작업은 더 저렴한 모델에 맡겨도 되는지 알고 싶어 한다. 이는 단순한 비용 최적화 문제가 아니라, 엔지니어의 실제 업무 흐름 속에서 모델 비용과 생산성 사이의 균형을 어떻게 잡을 것인가의 문제다.
NVIDIA의 Carter 역시 비슷한 문제의식을 제시한다. frontier model의 성능은 매력적이지만, 사용량이 많아질수록 비용은 개인 개발자, 스타트업, 소규모 기업에게 부담이 된다. 따라서 모델 라우팅은 “최고 성능 모델을 덜 쓰는 방법”이 아니라, 원하는 결과를 유지하면서도 지불 가능한 경제 구조를 만드는 기술로 자리 잡고 있다.
모델 라우팅의 본질은 “작업의 분해”에 있다
Cognition이 공개한 Devin Fusion 사례는 이 논의를 구체화한다. Walden은 Cognition이 frontier급 지능 수준을 유지하면서 비용을 약 40% 줄였다고 설명하면서도, 더 작은 모델 하나가 갑자기 frontier model을 전면적으로 능가한다는 뜻은 아니라고 선을 긋는다.
핵심은 delegation, 즉 위임이다. 더 강한 모델이 전체 계획과 어려운 의사결정을 맡고, 구현이나 탐색 같은 하위 작업은 더 저렴한 모델에게 넘기는 방식이다. 흥미로운 점은 저렴한 모델을 쓰기 때문에 오히려 더 많은 토큰과 더 많은 병렬 탐색을 사용할 수 있다는 것이다. 예컨대 코드베이스 탐색에서 frontier model 하나가 제한된 경로로 살펴보는 대신, 여러 개의 작은 에이전트가 병렬로 파일을 읽고 구조를 파악하면 더 포괄적인 조사가 가능해진다.
05:00 - Cognition의 Devin Fusion이 frontier model의 계획 능력과 작은 모델의 병렬 실행을 결합해 비용과 탐색 범위를 개선하는 구조
이 관점에서 모델 라우팅은 단순한 분류기가 아니다. “이 질문은 쉬우니 작은 모델, 이 질문은 어려우니 큰 모델”처럼 최초 입력만 보고 결정하는 방식은 agentic task에서 쉽게 무너진다. 실제 개발 업무는 “코드베이스를 설명해 달라”는 질문에서 시작해, 기능 구현, 테스트, 디버깅, 예외 상황 처리로 계속 변형되기 때문이다. 따라서 라우터는 작업의 시작점만이 아니라, 작업이 진행되는 동안 복잡도가 어떻게 변하는지를 관찰해야 한다.
모델마다 능력의 지형은 울퉁불퉁하다
NVIDIA의 Tanay는 모델의 능력을 하나의 순위로 이해하는 태도에 경고를 보낸다. 어떤 모델이 코딩 벤치마크에서 더 높은 점수를 받았다고 해서, 데이터 시각화, 모델 빌딩, scikit-learn, matplotlib, 디버깅, 문서 분석 등 모든 하위 작업에서 일관되게 우월하다고 볼 수는 없다. 모델은 학습 데이터, post-training, teacher model, distillation 과정에 따라 특정 영역에서는 강하고 다른 영역에서는 약한 “jagged capabilities”를 가진다.
08:34 - NVIDIA 패널리스트가 모델별 jagged capabilities와 보완적 모델 조합을 통해 정확도 개선이 가능하다고 설명하는 구간
이 설명은 모델 라우팅의 경제적 의미를 더 넓힌다. 라우팅의 목적은 가장 싼 모델을 찾는 것이 아니라, 각 모델의 강점과 약점을 세밀하게 이해한 뒤 특정 하위 작업에 적절히 배치하는 것이다. Tanay는 과학적 발견처럼 여러 하위 도메인이 얽힌 one-shot 문제를 예로 들며, 서로 다른 모델이 다른 teacher와 subtasks로 튜닝되었다면 그 겹치는 강점을 조합하는 것만으로도 일종의 arbitrage가 생길 수 있다고 설명한다.
패널에서는 특정 벤치마크에서 이러한 기법을 사용하면 최대 10% 수준의 정확도 개선이 가능하다는 언급도 나온다. 다만 이 수치는 모델 풀과 작업 유형에 따라 달라진다고 덧붙였기 때문에, 일반적인 보장값이라기보다는 멀티모델 조합이 성능 개선 여지를 갖는다는 사례로 이해하는 편이 정확하다.
작은 모델은 항상 싸지 않다
OpenRouter의 Alex는 모델 라우팅에서 가장 중요한 구분 중 하나로 in-distribution과 out-of-distribution을 제시한다. 사람 이름인지 조직 이름인지 분류하는 것처럼 대부분 모델의 학습 분포 안에 있는 작업은 작은 모델에게 맡기는 것이 합리적이다. 이런 작업을 대형 모델에 보내는 것은 비용 대비 효율이 떨어진다.
그러나 작업이 모델의 분포 밖에 있으면 이야기가 달라진다. 작은 모델은 토큰당 가격이 낮더라도, 문제를 해결하지 못하고 도구 호출을 반복하거나 루프에 빠지면서 전체 비용을 끌어올릴 수 있다. Alex는 Terminal Bench에서 Opus와 Haiku를 비교하는 예를 들며, STT 기준으로 Opus가 Haiku보다 훨씬 높은 성능을 내면서도 성공 작업당 비용은 더 낮을 수 있다고 설명한다. 이 대목은 “저렴한 모델은 언제나 비용을 줄인다”는 직관이 agentic workload에서는 성립하지 않을 수 있음을 보여준다.
따라서 라우팅의 핵심 판단은 모델 가격표만 보는 것이 아니라, 성공적으로 끝난 작업당 비용을 추정하는 데 있다. 특정 모델이 실패와 재시도를 반복한다면, 토큰 단가는 낮아도 실제 비용은 높아진다. 반대로 비싼 모델이 적은 토큰과 적은 도구 호출로 빠르게 결론에 도달한다면, 전체 시스템 관점에서는 더 경제적인 선택이 될 수 있다.
컨텍스트 공유와 압축은 라우팅의 숨은 비용이다
여러 모델을 함께 쓰면 자연스럽게 context sharing 문제가 생긴다. 한 모델이 파일을 읽고 분석했는데, 다른 모델도 같은 정보를 알아야 한다면 동일한 컨텍스트를 반복 전송하게 되고, 이는 곧 중복 토큰 비용으로 이어진다. Walden은 멀티모델 시스템이 오히려 더 비싸지는 대표적 이유가 바로 이 중복 컨텍스트라고 지적한다.
11:36 - 여러 모델이 같은 컨텍스트를 중복 처리할 때 발생하는 비용 문제와 context compaction 전략
Cognition의 접근은 대부분의 컨텍스트를 기본적으로 하나의 모델에만 보내고, 메인 모델에는 필요한 수준의 고수준 상태만 전달하는 것이다. 작은 모델이 어떤 파일을 읽었는지, 어떤 방향으로 생각하고 있는지, 어떤 결론을 임시로 얻었는지를 압축해 전달하고, 필요한 경우 큰 모델이 원본 파일을 다시 참조한다. 이 구조는 long-running agent에서 이미 중요한 문제였던 context compaction을 모델 라우팅에 적용한 형태라고 볼 수 있다.
다만 compaction은 본질적으로 손실 압축이다. Tanay는 AST(Abstract Syntax Tree)나 코드베이스의 구조적 표현처럼, 원본 정보를 완전히 잃지 않으면서 모델이 다시 확장할 수 있는 중간 표현이 중요해질 수 있다고 말한다. Walden 역시 인간의 기억이 매우 손실적이지만, 파일시스템 같은 비손실 외부 저장소를 활용하기 때문에 복잡한 작업을 수행할 수 있다는 비유를 든다. 좋은 agent harness는 모든 정보를 즉시 컨텍스트 안에 넣는 시스템이 아니라, 필요한 정보를 다시 찾을 수 있는 경로를 보존하는 시스템이어야 한다는 뜻이다.
KV Cache는 모델 라우팅의 경제학을 바꾼다
이 패널에서 반복적으로 등장하는 또 하나의 핵심 키워드는 KV Cache다. 모델이 긴 컨텍스트를 처리할 때 이미 계산된 prefix 상태를 재사용할 수 있다면, 같은 컨텍스트를 다시 읽는 비용은 크게 줄어든다. Cognition은 Devin Fusion에서 subagent라는 표현보다 sidekick이라는 구조를 강조하는데, 이는 계속 살아 있는 하나의 보조 에이전트가 자체 running context를 유지함으로써 이전 컨텍스트를 매번 다시 주입하지 않아도 되기 때문이다.
18:55 - Cognition이 subagent 대신 sidekick 구조를 사용해 running context와 KV Cache 이점을 유지한다고 설명하는 구간
Walden은 cache token이 10배 저렴해질 수 있다는 식으로 설명하며, sidekick 구조가 단순한 병렬 subagent 구조보다 비용상 유리할 수 있다고 말한다. 작은 모델을 여러 개 띄우는 것만으로는 충분하지 않고, 각 모델이 어떤 컨텍스트를 얼마나 오래 유지하며, 언제 메인 모델과 상태를 교환하는지가 전체 비용을 좌우한다는 의미다.
OpenRouter의 Alex는 marketplace 사업자 관점에서 KV Cache 최적화의 제약을 설명한다. OpenRouter는 대부분 모델을 직접 운영하지 않기 때문에 각 모델의 내부 KV Cache를 직접 제어할 수는 없지만, cache hit가 발생하면 그 절감분을 사용자에게 전달하고, 캐시가 남아 있는 동안 가능한 한 활용하는 방식으로 최적화한다. 앞으로는 “캐시가 아직 남아 있지만 모델을 바꿀 만큼 이득이 큰가” 같은 판단을 고객이 조정할 수 있는 형태도 가능하다고 언급한다.
25:54 - OpenRouter가 cache hit를 사용자에게 전달하고 모델 전환과 캐시 유지 사이의 trade-off를 다루는 방식
로컬 추론과 클라우드 모델 사이의 경계
Carter는 모델 라우팅의 또 다른 중요한 축으로 local versus cloud를 제시한다. 지금까지 논의가 주로 큰 모델과 작은 모델 사이의 비용 및 성능 균형에 집중했다면, 실제 배포 환경에서는 민감정보와 로컬 컴퓨트 자원 활용도 중요한 판단 기준이 된다. 예컨대 프롬프트에 개인정보나 민감한 코드가 포함되어 있다면, 먼저 로컬 모델로 이를 탐지하거나 익명화한 뒤 클라우드 frontier model에 넘기는 구조가 가능하다.
또한 로컬 하드웨어를 이미 구매한 조직이라면 클라우드 토큰 비용과 로컬 전력 비용 사이의 경제성이 달라진다. Carter는 DGX Spark 같은 장비를 예로 들며, 로컬 장비가 100% 활용되지 않는다면 heartbeat, 단순 처리, privacy-sensitive preprocessing 같은 작업을 로컬 모델로 돌리는 것이 합리적일 수 있다고 설명한다. 이 경우 모델 라우팅은 API 비용 절감 도구가 아니라, 로컬 하드웨어와 클라우드 모델을 함께 쓰는 hybrid AI infrastructure의 제어 계층이 된다.
Tanay는 self-hosted model의 경우 context length가 길어질수록 throughput이 느려지는 비용 구조도 고려해야 한다고 덧붙인다. API provider는 다양한 고객의 워크로드를 평균화해 가격을 책정하지만, self-hosting 환경에서는 자신의 워크로드에 맞춰 cache duration, memory allocation, compaction 전략을 직접 최적화할 수 있다. 따라서 라우팅의 최적해는 클라우드 API 사용자인지, 자체 GPU를 운영하는 조직인지에 따라 달라진다.
32:16 - 긴 context window가 항상 지능을 보장하지 않으며 compaction이 intelligence와 비용 문제에 미치는 영향을 논의하는 구간
모델을 라우팅에 맞게 훈련하는 단계로 간다
현재의 라우팅은 이미 존재하는 모델들을 조합하는 방식에 가깝다. 그러나 패널들은 장기적으로 모델 자체가 orchestration system과 함께 설계될 것이라고 본다. Walden은 한 모델을 end-to-end task에 대해 강화학습(RL, Reinforcement Learning)하는 문헌은 많지만, 다른 모델과 협업을 잘하도록 훈련하는 문제는 아직 초기 단계라고 말한다.
Cognition은 두 가지 방향을 모두 실험하고 있다고 설명한다. 하나는 모델이 orchestrator가 되어 어떤 일을 다른 모델에 위임할지 결정하도록 학습시키는 것이고, 다른 하나는 모델이 executor 또는 sidekick이 되어 다른 모델의 지시를 잘 수행하도록 학습시키는 것이다. 이 관점에서는 모델 라우팅이 외부 wrapper의 문제가 아니라, 모델의 행동 양식 자체에 포함되는 능력이 된다.
NVIDIA의 Tanay도 Nemotron과 같은 foundation model을 특정 harness에 맞춰 post-training한다면, 그 harness가 라우팅을 많이 포함할 경우 모델 훈련 과정에도 라우팅 친화적 행동이 반영될 수 있다고 설명한다. 또한 STT상 “Flexron”으로 인식된 NVIDIA 기술에 대해서는, 큰 모델을 더 작은 footprint로 distill하고 작업 복잡도에 따라 decoding을 맡는 모델을 바꾸는 구조라고 설명한다. 정확한 기술명은 원본 영상 확인이 필요하지만, 발언의 요지는 flexible model size와 flexible weight activation이 라우팅의 미래와 맞물린다는 데 있다.
프롬프트는 모델 간에 자동으로 이식되지 않는다
패널 후반부에서는 모델마다 prompt portability가 다르다는 문제가 제기된다. 서로 다른 모델 아키텍처와 post-training 방식을 가진 모델들은 같은 프롬프트에 다르게 반응하며, 특히 agentic system에서는 작은 문구 차이가 도구 호출, 회복 전략, 실패 루프에 큰 영향을 미칠 수 있다. Alex는 Devin 같은 agent company의 가치가 다양한 산업에서 발견한 doom loop와 그 회복 방식의 축적에 있다고 설명한다.
Cognition은 실제 사용자 행동을 라우팅 시스템 개선 신호로 활용하려는 방향도 언급한다. 사용자가 특정 작업 중 모델을 upgrade하거나 downgrade했다면, 혹은 시스템이 처음 보낸 모델이 잘못되어 교체했다면, 그것은 라우터가 배워야 할 중요한 production signal이 된다. Walden은 데이터셋에 맞춘 튜닝도 가능하지만, 실제 제품에서는 사람들이 어떤 프롬프트를 보내고 어떤 모델로 라우팅되었을 때 성공했는지를 계속 관찰하는 것이 더 중요하다고 본다.
기계적인 prompt tuning framework에 대해서는 다소 회의적인 의견도 나온다. Walden은 gradient descent식 prompt tuning보다, 똑똑한 모델에게 잘못된 결정의 맥락과 결과를 보여주고 왜 실패했는지 분석하게 한 뒤, agent가 프롬프트를 수정하고 regression test를 다시 돌리는 방식에 더 신뢰를 둔다고 설명한다. 이는 모델 라우팅이 단순한 runtime routing을 넘어, production feedback loop와 자동 연구 시스템으로 확장될 수 있음을 시사한다.
라우터는 제품인가, 아니면 배관인가
마지막 논의는 라우터의 위치에 관한 질문으로 모인다. 앞으로 라우터는 독립 제품으로 남을까, 아니면 모델과 harness 안에 자연스럽게 녹아드는 infrastructure plumbing이 될까. 패널들의 답은 한쪽으로 완전히 기울지 않는다. Cognition은 이미 모델이 좋은 collaborator가 되도록 훈련하고 있으며, 새로운 frontier model들도 자연스럽게 위임과 협업에 능숙해지고 있다고 본다.
반면 Tanay는 비결정적 모델 위에 구축되는 애플리케이션은 낮은 신뢰 환경에서 작동하기 때문에, 어떤 형태로든 controller나 arbitration layer가 필요하다고 말한다. 모델 입장에서도 다른 모든 모델의 행동을 완전히 알 수 없기 때문에, orchestration level에서 중앙화된 판단과 제어가 유지될 가능성이 높다는 것이다. 그는 웹 초창기 traffic-based routing이 시간이 지나며 중앙화된 routing control로 발전한 사례를 비유로 든다.
45:57 - 라우팅 제어가 모델 내부 능력과 orchestration layer 중 어디에 위치할지에 대한 장기 전망을 논의하는 구간
Alex는 반대 가능성도 함께 제시한다. 미래에는 하나의 거대한 모델이 대부분의 작업에서 가장 효율적이어서 굳이 작은 모델에 위임할 필요가 줄어들 수도 있다. 그러나 cache, limited memory, in-distribution easy task의 대량 존재를 고려하면, 모델 간 협업의 필요성은 쉽게 사라지지 않을 가능성이 크다. 특히 OpenRouter의 공개 데이터에서 분류 작업 같은 쉬운 작업에도 비싼 Opus가 많이 쓰이고 있다는 언급은, 아직 시장에 라우팅으로 개선할 여지가 크다는 사실을 보여준다.
마무리 / 핵심 정리
이 패널이 보여주는 모델 라우팅의 현재는 아직 정답이 확정되지 않은 연구와 제품화의 중간 지대다. 과거의 라우팅이 “입력 프롬프트를 보고 가장 알맞은 모델 하나를 고르는 일”에 가까웠다면, 앞으로의 라우팅은 작업을 단계별로 분해하고, 각 모델의 강점과 약점을 이해하며, 캐시와 컨텍스트 비용까지 반영하는 동적 orchestration에 가까워진다.
가장 중요한 takeaway는 작은 모델과 큰 모델의 관계를 대체 관계로 보지 말아야 한다는 점이다. 작은 모델은 in-distribution task와 병렬 탐색에서 강력한 경제성을 제공하지만, out-of-distribution task에서는 오히려 실패 루프와 토큰 낭비를 만들 수 있다. 반대로 frontier model은 비싸지만 계획, 감독, 오류 감지, 도구 사용 효율성에서 전체 시스템 비용을 낮출 수 있다.
결국 모델 라우팅의 미래는 모델, harness, cache, local hardware, production feedback이 함께 설계되는 방향으로 움직일 가능성이 높다. 라우터가 독립 제품으로 남든, 모델 내부 능력으로 흡수되든, 멀티모델 시스템을 효과적으로 운용하는 능력은 AI agent 시대의 핵심 엔지니어링 역량이 될 것이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | The State of Model Routing — NVIDIA, Cognition, OpenRouter |
| 채널 | AI Engineer |
| 영상 길이 | 약 48분 |
| 리포트 작성 | 2026-08-07 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.