Micro-Agent: Beat Frontier Models with Collaboration Inside Model API

TL;DR Highlight

vLLM 팀이 단일 모델 API 호출 뒤에서 여러 모델이 협업하는 'Micro-Agent' 개념을 공개했습니다. 별도의 에이전트 코드 없이 라우터 레이어에서 모델 조합을 실행해 GPT-4급 결과를 더 저렴하게 낼 수 있다는 아이디어입니다.

Who Should Read

LLM 기반 서비스를 운영 중인데 frontier 모델 비용이 부담스럽거나, 여러 모델을 조합하는 에이전트 파이프라인을 직접 구축하기 어려운 백엔드/ML 엔지니어.

Core Mechanics

vLLM Semantic Router는 '라우터(router)'를 단순한 모델 선택기 이상으로 확장합니다. 요청을 받으면 적절한 레시피를 골라 여러 모델에 팬아웃(fan-out)하고 결과를 합성해서 일반 OpenAI 호환 응답 하나로 돌려줍니다.
사용자 입장에서는 `{ 'model': 'vllm-sr/auto' }` 한 줄만 바꾸면 됩니다. 내부에서 무슨 모델 몇 개가 돌든 API 표면은 그대로여서 기존 코드 변경이 최소화됩니다.
핵심 실행 단위는 'Looper'입니다. Looper는 예산(budget), 위상 구조(topology), 추적(trace), 실패 정책(failure policy)을 관리하는 소형 런타임으로, 단순히 '모델을 더 많이 쓰자'는 개념과는 다릅니다.
Looper 패턴은 현재 5가지입니다. ① Confidence(저렴한 모델 먼저 시도 후 자신감 낮으면 escalate), ② Ratings(동시에 여러 모델 실행 후 가중 집계), ③ ReMoM(넓게 샘플링 후 합성), ④ Fusion(독립 응답들을 판사(judge) 모델에게 넘겨 최종 답 도출), ⑤ Workflows(정적/동적 역할 분담 워크플로).
Confidence 루프의 핵심은 '어려운 요청에만 비싼 모델을 쓴다'는 점입니다. 토큰 수준 log probability, logprob margin, 자기검증(self-verification), AutoMix 스타일 entailment verifier 등으로 신뢰도를 측정하고 임계값을 넘으면 바로 반환합니다.
이 아이디어의 배경에는 Sakana AI의 Fugu 모델이 있습니다. Fugu는 '모델 API 뒤에 팀을 두는' 방식으로 상업적 주목을 받았는데, vLLM은 이걸 특정 상업 엔드포인트에 묶지 않고 오픈 서빙 레이어의 기본 기능(primitive)으로 만들겠다는 방향입니다.
라우터가 처리하는 역할은 크게 4가지입니다. ① 비용 절감(쉬운 요청은 오픈소스 모델로), ② 안전 정책 실행(민감 도메인은 더 엄격한 모델로), ③ 클라우드-엣지 협력(프라이버시 필요한 건 로컬, 어려운 건 클라우드), ④ 모델 능력 자체를 향상.

Evidence

'frontier model'이라는 단어가 체크포인트(특정 모델 가중치)와 시스템 경계(서비스 표면) 두 가지 의미로 혼용되기 시작했다는 지적이 있었습니다. 한 댓글러는 이런 불투명한 래핑이 모델 동작을 추론하기 어렵게 만들고, Opus나 Claude 5.5에서 이걸로 갈아타는 건 단순 모델 교체보다 훨씬 큰 변화라고 우려했습니다.
OpenRouter도 비슷한 'Fusion Router'를 최근 출시했고, Fable 같은 서비스도 내부적으로 가드레일 실패 시 다른 모델로 라우팅하고 있다는 댓글이 있었습니다. 상용 모델 제공사들이 이미 UI 뒤에서 이런 걸 하고 있을 수 있다는 맥락입니다.
Sakana Fugu를 실제 테스트 구독했다가 이틀 만에 취소했다는 경험담이 있었습니다. 기대와 달리 실용성이 부족했다는 암시로 읽히며, 벤치마크 성능과 실사용 경험 간의 괴리를 시사합니다.
벤치마크 선택에 대한 의혹도 제기됐습니다. VSR Hybrid가 Humanity's Last Exam에서만 비교되고 LiveCodeBench, GPQA-Diamond에서는 비교가 없는 점을 지적하며, 결과가 좋지 않아서 빠진 게 아니냐는 의문이 달렸습니다.
'다음 세대 frontier 모델이 단일 프롬프트로 이 모든 걸 커버해버리면 이 복잡성이 무의미해진다'는 반론도 있었습니다. 반면 다른 댓글러는 이게 오히려 LLM이 범용 상품(commodity)화되고 있다는 신호이며, 핵심은 항상 '하네스(harness, 모델을 감싸는 실행 환경)'에 있었다고 맞받아쳤습니다.

How to Apply

여러 난이도가 섞인 사용자 요청을 처리하는 서비스라면, Confidence 루프를 적용해서 간단한 요청은 로컬 or 오픈소스 모델로, 자신감이 낮은 어려운 요청만 GPT-4o/Claude 같은 frontier 모델로 escalate하면 비용을 크게 줄일 수 있습니다.
에이전트 파이프라인을 직접 구현하기 부담스러운 팀이라면, vLLM Semantic Router를 OpenAI-compatible API 앞단에 두고 `model: 'vllm-sr/auto'`만 지정하는 방식으로 멀티모델 협업을 기존 코드 변경 없이 실험해볼 수 있습니다.
정확도가 중요한 도메인(의료, 법률, 코드 리뷰 등)에서 단일 모델 응답이 불안하다면, Fusion 또는 ReMoM 패턴으로 여러 모델의 독립 응답을 judge 모델에게 통합시켜 더 신뢰성 높은 최종 답을 얻는 구조를 고려할 수 있습니다.
이기종 GPU 클러스터(사내 A100 + 클라우드 H100 혼합 등)를 운영 중이라면, 라우터로 프라이버시 민감 요청은 온프레미스 모델로, 연산 집약 요청은 클라우드로 분리하는 정책을 코드 변경 없이 라우터 설정으로 관리할 수 있습니다.

Code Example

snippet

// vLLM Semantic Router 사용 예시 - 기존 OpenAI 호환 코드에서 model 이름만 변경
const response = await openai.chat.completions.create({
  model: "vllm-sr/auto",  // 기존: "gpt-4o" 또는 특정 모델명
  messages: [
    { role: "user", content: "복잡한 수학 문제 풀어줘..." }
  ]
});
// 내부적으로 라우터가:
// 1. 요청 난이도 분석
// 2. 적절한 looper 패턴 선택 (Confidence / ReMoM / Fusion 등)
// 3. 필요시 여러 모델에 fan-out
// 4. 결과 합성 후 단일 응답 반환
// 사용자 코드는 변경 없음

Terminology

Looper라우터 안에서 동작하는 소형 실행 런타임. 예산, 병렬 구조, 실패 처리 규칙을 가지고 여러 모델을 조율하는 반복 실행 엔진입니다.

fan-out하나의 요청을 여러 모델에 동시에 보내는 것. 식당에서 주문을 여러 주방에 동시에 넣는 것과 비슷합니다.

logproblog probability의 줄임말. 모델이 각 토큰을 얼마나 확신하고 선택했는지를 나타내는 수치로, 높을수록 모델이 자신 있게 답했다는 의미입니다.

entailment verifier모델의 답변이 논리적으로 질문을 제대로 커버하는지 검증하는 보조 모델. 답이 맞는지를 다른 시각에서 한 번 더 확인하는 검수자 역할입니다.

ReMoMRepeated Mixture-of-Models의 약자. 여러 모델에서 넓게 샘플링한 뒤 합성 라운드를 거쳐 최종 답을 만드는 패턴입니다.

OpenAI-compatible APIOpenAI의 API 형식(/v1/chat/completions 등)을 그대로 따르는 인터페이스. 이를 따르면 OpenAI SDK나 기존 코드를 변경 없이 다른 서버로 교체할 수 있습니다.