vLLM Semantic Router Fusion 프리미티브는 프로그래머블 멀티‑모델 서빙을 가능하게 합니다

vLLM Semantic Router Fusion 프리미티브는 프로그래머블 멀티‑모델 서빙을 가능하게 합니다

TL;DR

vLLM은 Semantic Router용 Fusion primitive를 출시하여, 프로덕션 시스템이 이질적인 모델들의 조정된 패널을 실행하고, 출력물을 평가하며, 라우터 내부에서 정책, 구성 및 추적을 유지하면서 단일 응답을 합성할 수 있게 합니다. 이는 모델 혼합을 임시 실험이 아닌 일급 프로그래머블 서빙 패턴으로 만듭니다.

단일 모델 이상의 필요성

전통적인 서빙은 어떤 단일 모델이 요청을 처리해야 하는가? 라는 질문만을 다루었습니다. 현대 AI 애플리케이션은 이제 빠르고 저렴한 모델, 사내 프라이빗 모델, 전문 추론 모델, 외부 제공자 API 등 포트폴리오가 필요합니다. 운영자는 요청을 단일 모델로 만족시킬 수 있는 경우와 비용·지연·프라이버시·안전 정책을 고려해 조정된 멀티‑모델 워크플로를 트리거해야 하는 경우를 판단해야 합니다.

Fusion을 라우터 프리미티브로

Fusion은 라우팅 알고리즘으로 도입되었으며, 전역 엔드포인트가 아닙니다. 라우터의 signal‑decision 레이어에 의해 활성화되며 다음과 같은 명확한 파이프라인을 따릅니다:

  1. Signal 추출 – 요청에 도메인, 복잡도, 안전성 등 메타데이터를 주석합니다.
  2. Decision making – 라우터는 해당 신호에 따라 일반 라우트 또는 Fusion 라우트를 선택합니다.
  3. Fusion entrymodel: "vllm-sr/fusion"을 사용하면 Fusion‑가능한 결정만 매칭됩니다.
  4. Panel 실행analysis models 집합이 독립적인 후보 답변을 동시에 생성합니다.
  5. Judgingjudge model이 합의, 모순, 빈틈, 고유 인사이트 등을 평가합니다.
  6. Synthesis – 판정 모델(또는 별도 synthesis model)이 단일 사용자 응답을 생성하고, 필요 시 OpenAI‑호환 tool_calls를 반환합니다.
  7. Tracing – 라우터는 실행된 모델, 실패, 토큰 사용량, 구조화된 분석 등을 기록해 디버깅 및 비용 정산에 활용합니다.

이 설계는 각 단계가 명시적이고 관찰 가능하도록 하여, 운영자가 결정별 패널 구성, 오류 처리(on_error: skip vs. fail), 동시성 제한, 런타임 노브 등을 자유롭게 설정할 수 있게 합니다.

엔트리 경로와 정책 제어

엔트리 경로 동작
model: "vllm-sr/auto" 전체 signal/decision 로직을 실행합니다; 선택된 결정의 algorithm.typefusion인 경우에만 Fusion이 실행됩니다.
model: "vllm-sr/fusion" Signal은 여전히 추출되지만 Fusion‑가능한 결정만 고려됩니다; 매칭되는 것이 없으면 명확한 오류가 반환됩니다.
Request plugin {"id": "fusion", ...} 패널, 판정 모델 및 런타임 노브를 단일 요청에 대해 오버라이드하여, 매칭되는 결정이 없더라도 범위가 제한된 Fusion 실행을 구성합니다.

이 분리는 운영자가 Fusion을 모든 요청에 대한 기본이 아닌 선택적·비용‑제어 기능으로 유지할 수 있게 합니다.

OpenRouter에서의 증거

OpenRouter의 최근 Fusion 출시(DRACO 벤치마크)에서는 다양한 모델 패널이 가장 강력한 단일 모델을 능가한다는 결과를 보여주었습니다. 보고된 점수는 다음과 같습니다:

구성 DRACO 점수
Fusion: Fable 5 + GPT‑5.5, Opus 4.8이 합성 69.0%
Fusion: Opus 4.8 + GPT‑5.5 + Gemini 3.1 Pro, Opus 4.8이 합성 68.3%
Solo Claude Fable 5 65.3%
Solo DeepSeek V4 Pro 60.3%

예산‑패널 행은 저렴한 모델들의 조합이 단일 저가 모델이 잃는 품질을 회복할 수 있음을 보여줍니다—바로 라우터가 관리해야 할 트레이드오프입니다.

상세 Fusion 워크플로

  1. 정책 해결 – 결정‑레벨 Fusion 설정을 요청‑레벨 오버라이드와 병합합니다.
  2. 라우터 보호 – Fusion 슬러그는 패널이나 판정 모델로 사용할 수 없으며, 재귀적인 Fusion 호출을 방지합니다.
  3. 패널 실행 – 모든 analysis 모델이 max_concurrent를 준수하며 동시에 호출됩니다.
  4. 실패 처리on_error: skip은 남은 모델로 계속 진행하고, on_error: fail은 즉시 중단합니다.
  5. 판정 분석 – 판정 모델은 합의, 모순, 부분 커버리지, 고유 인사이트, 블라인드 스팟을 설명하는 구조화된 JSON을 반환합니다.
  6. 합성 또는 tool‑call – 최종 단계에서 일반 답변이나 OpenAI‑호환 tool_calls 응답을 생성합니다.
  7. 추적 반환 – 응답 페이로드에 전체 Fusion 추적, 중간 패널 출력, 실패 기록, 토큰 사용량 집계 등을 포함할 수 있습니다.

추적이 명시적이기 때문에 운영자는 라우팅 결정을 디버깅하고, 비용을 모니터링하며, 실제 불일치 패턴을 기반으로 정책을 개선할 수 있습니다.

Fusion은 기본이 아닌 선택적 결정

Fusion은 지연 시간과 토큰 비용을 추가하므로 라우터는 언제 이를 사용할지 판단해야 합니다. vllm-sr/auto를 사용할 경우 라우터는 신호(예: 요청 복잡도, 도메인, 테넌트 정책)를 평가하고 고위험·고가치 쿼리에만 Fusion 결정을 선택합니다. 간단한 프롬프트는 빠른 단일‑모델 라우트를 계속 사용합니다. 명시적인 vllm-sr/fusion 별칭은 추가 관점이 필요할 때 클라이언트가 Fusion을 강제하도록 합니다.

예시 API 호출

라우터가 선택하도록 함

{
  "model": "vllm-sr/auto",
  "messages": [{"role": "user", "content": "What are the strongest arguments for and against carbon taxes?"}]
}

매칭된 결정이 algorithm.type: fusion을 지정하면 Fusion 파이프라인을 따르고, 그렇지 않으면 선택된 단일 모델로 진행됩니다.

Fusion 강제

{
  "model": "vllm-sr/fusion",
  "messages": [{"role": "user", "content": "What are the strongest arguments for and against carbon taxes?"}]
}

Fusion‑가능한 결정만 고려되며, 매칭이 없을 경우 명확한 오류가 반환됩니다.

하나의 호출에 대해 패널 오버라이드

{
  "model": "vllm-sr/fusion",
  "messages": [{"role": "user", "content": "..."}],
  "plugins": [{
    "id": "fusion",
    "model": "google/gemini-3-flash-preview",
    "analysis_models": [
      "google/gemini-3-flash-preview",
      "moonshotai/kimi-k2.6",
      "deepseek/deepseek-v4-pro"
    ]
  }]
}

오버라이드는 해당 요청에만 적용되며 전역 라우팅 설정을 변경하지 않습니다.

에이전트 루프에서 Fusion

Fusion은 OpenAI‑호환 tool calls와 함께 작동합니다. 패널 모델은 대화 기록을 받지만 toolstool_choice를 보지 못합니다. 최종 판정 모델만 tool_calls를 반환할 수 있습니다.

{
  "model": "vllm-sr/fusion",
  "messages": [{"role": "user", "content": "Find the latest benchmark result and explain whether it changes our launch plan."}],
  "tools": [{
    "type": "function",
    "function": {"name": "web_search", "parameters": {"type": "object", "properties": {"query": {"type": "string"}}, "required": ["query"]}}
  }],
  "tool_choice": "auto"
}

패널은 분석을 수행하고, 판정 모델은 직접 답변하거나 tool_calls 페이로드를 반환할지 결정합니다.

구성 레이아웃

전역 런타임 구성은 엔트리 별칭만 등록합니다:

global:
  router:
    auto_model_names:
      - vllm-sr/auto
      - auto
      - MoM

Fusion 슬러그는 looper 통합 아래에 등록됩니다:

global:
  integrations:
    looper:
      fusion:
        model_names:
          - vllm-sr/fusion

결정‑별 라우팅 구성에 실제 Fusion 정책이 들어갑니다:

routing:
  decisions:
    - name: deep-research-fusion
      description: Use model diversity for research prompts with high synthesis risk.
      rules:
        operator: AND
        conditions:
          - type: domain
            name: research
          - type: complexity
            name: needs_reasoning:hard
      algorithm:
        type: fusion
        fusion:
          model: google/gemini-3-flash-preview
          analysis_models:
            - google/gemini-3-flash-preview
            - moonshotai/kimi-k2.6
            - deepseek/deepseek-v4-pro
          max_concurrent: 3
          on_error: skip

이 분리는 전역 상태를 최소화하면서 워크로드‑특정 Fusion 정책을 세밀하게 정의할 수 있게 합니다.

향후 방향

OpenRouter DRACO 결과는 vLLM‑SR 내 Fusion에 대한 체계적인 평가를 촉구합니다:

  • 스모크 테스트를 넘어선 대규모 공개 벤치마크.
  • Fusion, ReMoM, AutoMix, Router‑R1, 단일 모델 베이스라인 간 비교.
  • 예산‑패널 vs. 최첨단 모델 패널 분석.
  • 불일치, 커버리지 빈틈, 판정 행동에 대한 향상된 추적 진단.
  • 지연‑비용 트레이드오프에 대한 정책 연구를 통해 언제 Fusion을 적용할지 결정.

궁극적인 비전은 명확합니다: 최고의 답변은 가장 큰 단일 체크포인트가 아니라, 프로그래머블 라우터에 의해 오케스트레이션되는 모델 시스템에서 점점 더 나오게 될 것입니다. vLLM‑SR의 Fusion 프리미티브는 그 시스템을 관찰 가능하고, 구성 가능하며, 프로덕션‑레디하게 만듭니다.

참고 자료

Sources