「이 요청을 어떤 모델로 보내야 할까」. LLM 라우팅(Routing)에 관한 논의는 줄곧 이 질문을 중심으로 진행되어 왔다. 저렴한 모델로 충분할 것인가, 아니면 더 비싼 모델로 에스컬레이션(Escalation)할 것인가. 요점은 1개의 요청당 1개의 모델을 선택한다는 전제였다.

vLLM 프로젝트가 6월 16일에 공개한 Fusion은 그 전제를 깨뜨리려 하고 있다. 하나를 선택하는 것이 아니라, 여러 모델에 동일한 요청을 동시에 답변하게 하고, 별도의 모델이 그것들을 대조하여 하나의 답변으로 묶어낸다. 발상 자체는 연구계에서 말하는 Mixture-of-Agents에 가깝지만, 이를 추론 서버의 「라우터(Router)」 기능으로서 설정 파일 몇 줄만으로 실무 운영에 올릴 수 있는 형태로 만든 것이 이번의 핵심이다.

Fusion의 전제로서, 토대가 되고 있는 vLLM Semantic Router(이하 SR)를 짚고 넘어가고 싶다. 이것은 OpenAI 호환 API 앞에 두는 「똑똑한 라우터」로, 요청의 내용을 보고 어떤 모델로 흘려보낼지를 결정한다. README의 말을 빌리자면, 클라우드에서 에지(Edge)까지의 여러 모델(mixture-of-models)을 묶는 System Level Intelligent Router다.

6월 5일 v0.3 Themis에서 라우팅의 개념이 정리되었다. 요청으로부터 언어·의도·안전성·문맥 길이와 같은 「시그널(Signal)」을 추출하고, 이를 support_fast와 같이 다루기 쉬운 개념으로 정규화한 뒤, 정책(Policy)으로 조건을 판정하여 최종적으로 알고리즘이 모델을 선택한다. 시그널 → 투영 → 판정 → 알고리즘 → 모델로 이어지는 일직선 구조다. 구현은 Go가 약 절반을 차지하며 Python, Rust, TypeScript가 뒤를 잇는 다국어 구성으로 되어 있다.

여기서 중요한 점은, Fusion이 이 「알고리즘(Algorithm)」의 일종으로서 삽입되어 있다는 점이다. 즉, 기존 라우팅 기반에 대한 추가 기능이지 별개의 새로운 시스템이 아니다.

Fusion의 처리는 4단계로 나뉜다.

• 패널 실행(Panel Execution): 여러 분석 모델이 동일한 요청을 병렬로 처리한다.
• 심판(Judge): 전용 judge 모델이 패널의 출력을 읽고, 합의점·모순·누락을 분석한다.
• 합성(Synthesis): 최종 답변을 생성한다. 에이전트 용도라면 도구 호출(Tool Calling)도 여기서 일어난다.
• 트레이스(Trace): 어떤 모델이 참여했는지, 어디서 실패했는지, 토큰을 얼마나 사용했는지를 통째로 기록한다.

설정은 알고리즘의 정의로서 다음과 같이 작성한다.

algorithm:
  type: fusion
  fusion:
    ...

analysis_models가 패널이며, model이 심판 겸 합성 역할이다. on_error: skip 설정을 통해 패널 중 하나가 다운되어도 나머지를 통해 계속 진행할 수 있는, 운영상 유용한 설정이 처음부터 포함되어 있다. 호출 측은 요청의 model 필드를 전환하는 것만으로 동작을 선택할 수 있다.

{ "model": "vllm-sr/auto" } // 라우터가 시그널을 보고 Fusion 적용을 판단
{ "model": "vllm-sr/fusion" } // 명시적으로 Fusion만 사용

게다가 요청 단위로 plugins에 Fusion 설정을 삽입하여 패널 구성을 그 자리에서 덮어쓸 수도 있다. 서버 측의 기본 설정과 특정 요청에 대해서만 구성을 강화하는 식의 구분 사용이 가능하다.

효과로서 포스트에서 언급한 내용은, OpenRouter의 DRACO 벤치마크에서 Fusion 구성이 69.0%를 기록했으며, 단일 모델 중 최강이었던 Claude Fable 5가 65.3%였다는 수치다. 이는 포스트가 인용한 값이며, 필자가 직접 재현한 것은 아니다. 그렇다 하더라도 여러 모델이 합의하게 함으로써 단일 모델이 놓치는 부분을 잡아낼 수 있다는 방향성 자체는 타당해 보인다.

냉정하게 살펴봐야 할 것은 비용이다. 3개 모델의 패널에 심판이 1회. 단순하게 생각하면 1개 요청당 토큰 소비는 단일 모델의 약 4배 정도로 불어난다. 레이턴시(Latency) 또한 병렬 실행이라 하더라도 「가장 느린 패널 멤버 + 심판의 생성 시간」이 하한선이 된다. 즉, Fusion은 모든 요청에 상시 적용하는 것이 아니다. vllm-sr/auto로 시그널을 확인하고, 어려운 문의가 왔을 때만 패널을 여는 선택적인 사용 방식이 현실적일 것이다. SR이 이를 알고리즘의 일종으로 통합하여 auto 라우팅과 공존시킨 설계는 이 점에서 이치에 맞다.

실무적으로 또 하나 효과적인 것은 4단계의 트레이스(trace)다. 어떤 모델이 무엇을 말했고, 심판이 어떻게 판단했는지가 남는다. 합의의 내용이 블랙박스라면 장애 분석도 품질 개선도 어렵기 때문에, Themis의 '재생(replay)' 가능한 라우팅과 결합되면 나중에 '왜 이런 답변이 나왔는가'를 추적할 수 있다는 점은 매우 크다.

도입을 위한 설치 스크립트가 준비되어 있다.

curl -fsSL https://vllm-semantic-router.com/install.sh | bash

기동, 대화, 평가는

vllm-sr serve

/ vllm-sr chat

/ vllm-sr eval

과 같은 CLI로 실행한다. v0.3 이후의 설정은 version: v0.3을 가진 단일 포맷으로 통일되었으므로, 먼저 Themis의 설정 구조를 읽은 뒤 알고리즘에 fusion을 추가하는 방식이 접근하기 쉽다.

단일 모델의 비용 최적화에 국한되었던 LLM 라우팅이, '중요한 문의는 합의를 거치게 한다'라는 품질 측면의 레버(lever)를 얻었다. 하나의 모델을 완전히 선택한다는 전제를 버린 이 한 수가 실제 운영 환경의 라우팅 설계를 어떻게 바꿀지는 지켜볼 만하다.