The State of Model Routing — NVIDIA, Cognition, OpenRouter

URL: https://www.youtube.com/watch?v=QHBjufYK8TA 날짜: 2026-08-06 채널: aiDotEngineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

이 영상은 생성 AI가 "멀티모델(multimodel) 세계"로 진입한 상황에서, 어떤 모델이 어떤 작업을 담당해야 하고, 그 선택과 전환을 누가, 어떤 기준으로, 어떤 인프라 위에서 orchestration(오케스트레이션)할 것인지를 다룬다.

• ==모델 라우팅은 단순히 "저렴한 모델로 바꿔 쓰는 비용 최적화"가 아니라, 작업의 복잡도 단계(in-domain/out-of-domain), 에이전트의 세션/서브태스크 흐름, KV 캐시, 컨텍스트 공유, 로컬-클라우드 하이브리드 등을 종합적으로 설계하는 문제==다.
• Cognition, NVIDIA, OpenRouter 세 패널리스트는 각각 제품(Devin Fusion), 모델/인프라(Neotron, Flex Run, Dynamo), 마켓플레이스/라우터(OpenRouter) 관점에서 이 문제를 풀고 있으며, 공통된 메시지는 "모델과 하네스(harness)가 공동으로 진화하고, 결국 라우팅은 AI 시스템의 기본 인프라가 될 것"이라는 점이다.

---

1. 멀티모델 시대와 모델 라우팅의 등장

1.1. 프로덕션 AI는 이미 멀티모델

1. 라우팅이 핵심이 된 이유

   1. 에지·로컬 배포의 확산: NVIDIA는 Neotron 모델을 데이터셋, 가중치, 레시피 전체를 공개한다. 이는 사용자가 모델을 직접 커스터마이즈하고 로컬에서 실행하는 "멀티모델" 시대를 전제로 한다.
   2. 단일 모델의 한계: 한 모델이 모든 작업에서 최고일 수 없다. 특히 에이전트형 작업(agentic task)에서는 질문이 단순 설명에서 코드 구현, 디버깅, 테스트, 장기 실행으로 단계적으로 변화한다.

2. 라우팅의 목표

   1. 비용·성능 트레이드오프: Carter는 "프론티어 모델이 비싸질수록 원하는 출력을 얻으면서 비용을 줄이는 방법"이 개발자의 최우선 관심사라고 언급했다.
   2. 능력 기반 할당: Dane는 모델의 정확도·효율·비용을 밀접하게 평가하고, 모델별 강점/약점을 "친밀하게(intimately)" 이해하는 것이 라우터 설계의 핵심이라고 말했다.

1.2. 모델 능력의 울퉁불퉁한 분포

1. Jagged capabilities(울퉁불퉁한 능력)

   1. 코딩도 하나의 영역이 아님: Dane는 "코딩이라는 하나의 영역 안에도 데이터 시각화(scikit-learn, matplotlib), 모델 빌딩 등 수많은 하위 영역이 있으며, 각 모델의 훈련 코퍼스에 따라 강점이 다르다"고 설명했다.
   2. 벤치마크와 실전의 괴리: 벤치마크에서 모델 A가 모델 B보다 높다고 해서 특정 하위 작업에서도 항상 우위인 것은 아니다.

2. 라우팅의 본질

   1. 아비트라지 활용: 서로 다른 모델의 겹치지 않는 강점을 이해하면 이를 "arbitrage"처럼 활용할 수 있다.
   2. 수치: Dane는 LMR Bench 등에서 이런 기법을 쓰면 모델 풀과 작업에 따라 최대 10% 정확도 향상을 얻을 수 있다고 언급했다.

---

2. Cognition: Devin Fusion과 스마트-서브모델 구조

2.1. Devin Fusion의 핵심 설계

1. 프론티어 모델은 오케스트레이터로, 저렴한 모델은 구현으로

   1. 역할 분리: Walden은 "Fable 수준의 모델이 계획(planning)과 어려운 판단(hard decision-making)을 맡고, 구현(implementation)은 오픈소스나 미니 모델 같은 저렴한 모델에 위임한다"고 설명했다.
   2. 결과: 이 방식으로 Cognition은 Fable 수준 지능을 40% 낮은 비용으로 제공할 수 있다고 밝혔다.

2. 왜 구현 모델이 더 깊게 탐색할 수 있는가

   1. 토큰 예산의 재배분: 프론티어 모델 1토큰 비용이면 구현 모델은 훨씬 많은 토큰을 생성할 수 있다.
   2. 서브 에이전트 확장: 예를 들어 코드베이스 탐색 시 3개의 서브 에이전트를 띄워 더 포괄적으로 탐색할 수 있으며, 이는 단일 프론티어 모델이 탐색하는 것보다 더 깊고 광범위할 수 있다.

2.2. 단순 작업유형 라우팅의 취약성

1. Naive task-type routing의 문제

   1. 에이전트 작업의 단계적 변화: 실제 개발자의 요청은 "코드베이스 설명 → 기능 구현 → 디버깅/테스트"처럼 시간이 지나며 복잡도와 유형이 변한다.
   2. 갇힘 현상: 단순히 초기 작업 유형으로 작은 모델을 선택하면, 이후 작업이 어려워졌을 때 그 모델에 갇혀 성능이 떨어진다.

2. 프론티어 모델의 상시 감시

   1. 상위 에이전트의 모니터링: Devin Fusion은 항상 프론티어 지능을 "상위 모델"로 남겨두고, 하위 모델이 범위를 벗어나면 전환하거나 도움을 요청하도록 설계했다.
   2. 안정성 보장: Walden은 "항상 프론티어 지능이 존재하는 것이 시스템의 취약성을 크게 줄인다"고 강조했다.

2.3. 컨텍스트 공유와 압축

1. 완전한 흔적 전달의 비용

   1. 중복 토큰 비용: 여러 모델이 동일한 파일을 각각 읽으면 비용이 3배로 불어날 수 있다.
   2. 기본 원칙: 대부분의 컨텍스트는 구현 모델에만 제공하고, 상위 모델에는 필요한 최소한의 압축된 정보(예: 읽은 파일 목록, 하이레벨 사고)만 전달한다.

2. Context compaction

   1. 손실 압축과 fallback의 결합: Dane는 "컨텍스트 압축은 lossy하지만, 파일 시스템 같은 non-lossy 저장을 fallback으로 삼으면 필요할 때 전체를 다시 찾을 수 있다"고 설명했다.
   2. 핵심 목표: 하네스가 모든 정보를 즉시 갖추지 않아도, 필요할 때 찾을 수 있도록 설계하는 것이 좋은 컨텍스트 엔지니어링이다.

2.4. 모델 협업을 위한 학습

1. 협업 능력의 강화학습

   1. 두 가지 역할 시도: Cognition은 "오케스트레이터 역할을 맡은 모델"과 "다른 모델 지시를 실행하는 사이드킥(sidekick) 역할의 모델"을 각각 RL로 학습시키며 실험 중이다.
   2. 목표: 단순히 기성 모델을 조합하는 것을 넘어, 모델과 오케스트레이션 시스템을 공동 설계(co-design)하는 것이다.

2. KV 캐시 기반 사이드킥

   1. 사이드킥의 지속적 컨텍스트: Walden은 "하위 에이전트를 매번 새로 띄우는 대신, 지속적으로 실행되는 사이드킥을 KV 캐시에 유지하면 캐시 토큰이 10배 저렴하다"고 설명했다.
   2. 모델 교체의 유연성: 상위/하위 모델의 역할을 자유롭게 바꿀 수 있어 다양한 협업 구조를 시험할 수 있다.

---

3. OpenRouter: 라우터 마켓플레이스와 운영 현실

3.1. OpenRouter의 역사와 변곡점

1. 자동 라우터의 2년 역사

   1. 초기 낮은 수용: Alex는 OpenRouter의 auto router가 2년 전부터 있었지만, 사용자들은 특정 모델을 직접 쓰기 원해 채택이 낮았다고 말했다.
   2. 에이전트 워크로드의 등장: 2026년 1월경 "openclaw"(영상 자막 표기; 실제 에이전트 클라이언트 또는 서비스명으로 추정) 같은 앱이 등장하면서, 10분마다 하트비트(heartbeat)를 보내는 등 동일한 클라이언트 안에서 두 완전히 다른 지능 수요가 발생해 라우팅 수요가 폭증했다.

2. OpenRouter의 라우터 제품

   1. Pareto code: 코딩 작업에서 주어진 품질 임계값에 대한 Pareto 최적 모델을 추천한다.
   2. Fusion: 여러 모델을 오케스트레이션해 하나의 결과를 만든다.

3.2. 캐시와 KV 캐시 인식 라우팅

1. 캐시 히트의 경제

   1. OpenRouter의 한계: OpenRouter는 자체 모델을 거의 실행하지 않아 KV 캐시를 볼 수 없으므로, KV 캐시 최적화는 직접 불가능하다.
   2. 캐시 히트 전달: OpenRouter는 캐시 히트가 발생하면 그 혜택을 사용자에게 그대로 전달한다.

2. 캐시 손실 vs 모델 전환의 트레이드오프

   1. 전환 시점: 캐시가 2분 남았는데 더 적합한 모델로 바꾸는 것이 유리할 때가 있다.
   2. 사용자 허용도: Alex는 이런 trade-off에 대한 사용자의 tolerance(허용도)를 조정할 수 있도록 하는 기능을 연구 중이라고 언급했다.

3.3. In-domain / Out-of-domain 감지

1. 도메인 내/외 구분

   1. In-domain: "이름이 사람 이름인지 조직 이름인지 분류"처럼 작고 명확한 작업은 작은 모델에 맡기는 것이 효율적이다.
   2. Out-of-domain: 모델이 훈련 분포 밖의 작업을 만나면 작은 모델이 도구를 무한 호출하거나 루프에 빠져 비용이 오히려 커질 수 있다.

2. Alex의 실증

   1. Terminal Bench: Alex는 "Opus와 Haiku로 Terminal Bench를 실행하면 Haiku는 훨씬 저렴한 토큰 단가임에도 Opus가 3배 더 잘하고 전체 비용은 Haiku의 1/10"이라고 언급했다.
   2. 시사점: 단가만 보고 작은 모델을 고르면 out-of-domain 작업에서 오히려 총비용이 증가할 수 있다.

3.4. Prompt tuning과 프롬프트 이식성

1. 프롬프트 이식성 문제

   1. 모델별 차이: 모델 아키텍처와 훈련 방식이 다르면 동일한 프롬프트가 다른 결과를 낸다.
   2. OpenRouter Fusion: 다양한 모델에 보내지는 프롬프트를 데이터셋과 실제 사용 피드백에 맞춰 튜닝할 계획이다.

2. 프롬프트 튜닝 방법론

   1. Gradient descent 기반 프롬프트 튜닝: Walden은 "Japa(영상 자막 표기) 같은 구식 gradient descent 프롬프트 튜닝보다, 스마트 모델에게 '왜 이 선택을 했고 다른 선택은 왜 안 했는지' 묻고 프롬프트를 직접 업데이트·리그레션 테스트하는 방식을 더 신뢰한다"고 말했다.
   2. 운영 데이터 기반 반복: 실제 사용자가 모델 업그레이드/다운그레이드를 선택하는 신호를 수집해 라우터를 지속적으로 재학습하는 것이 Cognition의 목표다.

---

4. NVIDIA: 모델, 인프라, 로컬-클라우드 하이브리드

4.1. Neotron 모델과 오픈 레시피

1. Neotron의 철학
   1. 전체 공개: NVIDIA는 데이터셋부터 가중치, 레시피까지 모두 공개해 사용자가 모델을 커스터마이즈할 수 있도록 한다.
   2. 커스터마이즈의 중요성: Carter는 "사람들이 모델을 직접 커스터마이즈하는 것이 엄청나게 커질 것"이라고 강조했다.

4.2. Flex Run: 유연한 모델 가중치와 디코딩

1. Flex Run의 구조

   1. 증류 기반 축소: 큰 모델을 더 작은 풋프린트(footprint)로 distill(증류)한다.
   2. 작업별 디코더 교체: 작업의 복잡도에 따라 어떤 모델이 디코딩을 담당할지 전환한다.
   3. 선택적 가중치 활성화: 모델 아티팩트 내부에서 작업에 맞는 가중치 집합만 활성화해 효율을 높인다.

2. In-distribution 판단의 이점

   1. 레시피 접근: 오픈 모델은 훈련 레시피와 데이터를 알기 때문에 질문이 in-distribution인지 판단하기 쉽다.
   2. 증류 간극(distillation gap): 훈련 시 사용한 다양한 도메인 데이터가 모델 전체에 균일하게 흡수되었는지 분석할 수 있다.

4.3. Dynamo와 Prefix Cache

1. Dynamo의 역할
   1. Prefix cache 최적화: NVIDIA Dynamo는 prefix cache 최적화를 포함해 추론 효율을 높인다.
   2. 자체 호스팅 권장: Carter는 DGX Spark 같은 조직형 환경이 아니더라도 Dynamo를 활용해 prefix cache를 최적화할 것을 권했다.

4.4. 로컬-클라우드 하이브리드 라우팅

1. 프라이버시·비용·활용도

   1. 민감 정보: 프롬프트에 민감 정보가 포함되면 on-device에서 실행하고, 익명화한 일부 정보만 클라우드로 보내 고급 작업을 수행할 수 있다.
   2. DGX Spark 활용: 로컬 GPU가 100% 활용되지 않으면, 하트비트·단순 작업 등을 로컬에서 처리해 전체 클라우드 토큰 비용을 줄인다.

2. 자체 호스팅의 비용 역학

   1. 컨텍스트 길이와 처리량: Dane는 "자체 호스팅 시 컨텍스트가 길어지면 처리량이 떨어지므로, compaction으로 처리량을 회복하는 것이 중요하다"고 말했다.
   2. 맞춤형 최적화: API 제공자는 모든 사용자의 워크로드를 평균내 가격을 책정하지만, 자체 호스팅은 자신의 워크로드(예: 32K 캐시·1K 입출력)에 맞춰 최적화해 훨씬 저렴하게 운영할 수 있다.

---

5. 운영 측면: 캐시, 컨텍스트, 비용, 탐지

5.1. 캐시 지속 시간과 비용

1. 5분 캐시의 현실

   1. 운영적 결정: 캐시가 5분 후 evict되는 것은 제공자의 운영 기준이며, 물리 법칙은 아니다.
   2. 자체 호스팅의 자유: 자체 GPU를 쓰면 비즈니스 로직에 맞게 캐시 지속 시간을 길게 유지할 수 있다.

2. 캐시 미스와 컴팩션

   1. 컴팩션의 역설: Dane는 "컴팩션만으로 비용·처리량 문제를 해결하지 못하는 경우가 많다. 오히려 컴팩션 과정에서 캐시 미스가 발생해 입력 토큰 비용이 10배로 뛸 수 있다"고 경고했다.
   2. 컴팩션의 진짜 목적: 비용보다는 지능을 위해 사용한다. 모델은 광고되는 100만 토큰 창을 실제로 200K 이상 넘기면 성능이 절벽에 떨어진다.

5.2. 환각 탐지 프로브

1. 내부 상태 기반 탐지

   1. Hallucination probes: Dane는 "모델의 내부 상태(activation, linear probe)를 분석해 얼마나 환각에 가까워지는지 측정하는 probe를 활용할 수 있다"고 언급했다.
   2. Perplexity: 내부 퍼플렉시티(perplexity)를 모니터링하면 모델이 얼마나 "길을 잃었는지"를 추정할 수 있다.

2. 라우팅 신호로 활용

   1. 토큰량 대신 상태 기반: 작은 모델이 많은 토큰을 생성한다고 무조건 문제가 아니라, 내부 상태가 불안정할 때 큰 모델로 전환하는 것이 더 정확한 신호다.

5.3. Prompt tuning과 학습

1. Cognition의 실험적 접근
   1. RL로 협업 학습: Cognition은 모델들이 서로 협업하는 방식을 강화학습으로 직접 학습시키며, "오케스트레이터"와 "사이드킥" 두 역할을 모두 실험 중이다.
   2. 프롬프트는 관측 가능한 자산: Walden은 "프롬프트는 스타트업 빌딩 과정의 일부이며, trace를 관찰하고 여러 사람과 에이전트가 협업해 쉽게 수정할 수 있다"고 말했다.

---

6. 결론 및 시사점

1. 라우팅은 제품이 아닌 인프라가 될 것

   1. Alex는 "모델과 하네스가 함께 진화할 것이며, 완벽하게 중앙 집중화된 라우터/컨트롤러가 필요하다"고 본다.
   2. Carter는 "뛰어난 하네스와 뛰어난 모델은 서로 없는 상태에서 존재할 수 없으며, 시스템 전체를 설계해야 한다"고 강조했다.

2. 공동 설계(co-design)의 시대

   1. 모델-하네스 공진화: 모델이 라우팅을 고려해 post-training되고, 하네스가 모델의 강점을 활용하도록 설계되어야 한다.
   2. 협업 지능: 미래 모델은 스스로 다른 모델에게 위임하고, 협업을 강화학습으로 학습할 수 있을 것이다.

3. 실무 적용 포인트

   1. 작은 모델은 in-domain·짧은 작업에, 큰 모델은 out-of-domain·계획·감시에 사용하라.
   2. 단순 작업 유형 라우팅은 에이전트 작업에서 취약하므로, 세션/서브태스크 단계를 추적하라.
   3. 컨텍스트를 무조건 전달하지 말고, 압축된 요약과 non-lossy fallback(파일 시스템 등)을 결합하라.
   4. 캐시 지속 시간과 KV 캐시를 비용 모델에 포함하고, 자체 호스팅과 클라우드의 경제를 비교하라.
   5. 로컬 GPU(DGX Spark)의 활용도를 높이기 위해 다중 에이전트 협업형 워크로드를 설계하라.

---

주요 발언 모음

"We firmly believe that we're in a multimodel world. Anyone who is deploying AI in production and who is doing so locally is seeing that multimodel world." — Carter, NVIDIA "We're reducing the cost of Fable level intelligence by 40%." — Walden, Cognition "Smarter models actually get better and better at delegating work." — Walden, Cognition "A model is just a combination of the data and its understanding of the data, both its compute and the quality of its RL." — Alex, OpenRouter "If you run Terminal Bench on Opus and Haiku, Opus will do about three times better at one-tenth the cost of Haiku." — Alex, OpenRouter "I would never recommend using these models past 200k tokens, under 100k if you can. The intelligence just kind of falls off a cliff at some point." — Walden, Cognition "Routing will evolve as the task evolves. It's more useful to see things in terms of subtasks and sessions than individual problems." — Dane, NVIDIA "There's not going to be a really great harness in absence of a really great model and vice versa." — Carter, NVIDIA

---

핵심 데이터 & 수치

• 40% 비용 절감: Cognition Devin Fusion이 Fable 수준 지능을 40% 더 낮은 비용으로 제공.
• 10% 정확도 향상: LMR Bench 등에서 모델 풀과 작업에 따라 라우팅 기법으로 최대 10% 정확도 향상 (Dane).
• 캐시 토큰 10배 저렴: KV 캐시에 유지된 사이드킥의 캐시 토큰은 일반 토큰보다 10배 저렴 (Walden).
• Terminal Bench: Opus가 Haiku보다 3배 더 잘 수행하면서 전체 비용은 Haiku의 1/10 (Alex).
• 컨텍스트 절벽: 200K 토큰 이상, 특히 100K 이상에서는 모델 지능이 급격히 감소 (Walden).
• 5분 캐시 evict: 대부분의 API 제공자가 5분 주기로 캐시를 evict하는 운영 기준 (Alex, Walden).
• 2024년 초 비용: 100K 토큰을 반복 전송해도 캐시 토큰 할인이 없어 풀가격을 지불하던 시절이 있었음 (Walden).