vLLM Semantic Router로 설계하는 LLM 서빙 레이어 라우팅
vLLM Semantic Router가 에스컬레이션, 팬아웃, 불일치 판단을 Model API 레이어에서 처리하는 구조와 운영 방식을 다룬다.
2026-08-14 · 최초 발행 2026-08-02
2026년 LLM 애플리케이션에서는 모델 호출 하나보다 그 앞뒤의 판단이 더 복잡해지고 있다. 어떤 모델에 요청을 보낼지, 초기 결과를 더 강한 모델로 넘길지, 여러 후보를 동시에 생성할지, 충돌한 답변을 어떻게 판정할지가 모두 오케스트레이션 코드에 쌓인다.
vLLM Semantic Router는 이 판단을 Model API 레이어에서 직접 처리한다. 단일 백엔드 실행부터 에스컬레이션, 팬아웃, 불일치 판정과 증거 합성까지 서빙 계층 안으로 옮긴 구조다. 폐쇄형 레시피를 기준으로 LiveCodeBench 92.6을 기록한 파이프라인도 이 패턴을 사용했다.
라우팅 판단을 서빙 인프라로 내린 구조
LangChain이나 CrewAI 같은 기존 프레임워크에서는 에이전트와 모델 사이의 라우팅을 파이썬 코드 또는 YAML 워크플로우로 표현한다. 판단이 오케스트레이션 레이어에 집중되면서 레이턴시 오버헤드와 직렬화 비용이 생기고, 애플리케이션이 관리해야 할 상태도 복잡해진다.
Semantic Router의 접근은 라우팅 결정을 서빙 인프라 내부에서 맡는 것이다. 요청이 vLLM 엔드포인트에 들어오면 Router가 의미론적 특성을 분석한 뒤 실행 경로를 고른다.
복잡도가 낮은 요청은 단일 백엔드에서 처리한다. 초기 응답의 신뢰도나 품질이 임계값을 넘지 못하면 더 강력한 모델로 에스컬레이션한다. 높은 신뢰도가 필요한 요청은 여러 모델이나 샘플로 팬아웃하며, 결과가 충돌하면 Judge Model이 최종 답변을 결정한다. 외부 오케스트레이션 레이어에는 이 과정의 최종 결과만 반환된다.
초기 응답을 어디까지 신뢰할 것인가
에스컬레이션은 모델 이름만 교체하는 폴백과 다르다. vLLM Semantic Router는 초기 결과의 logprob 분포, 응답 길이, 내부 일관성 지표를 함께 사용해 상위 모델 호출 여부를 판단한다. 운영자는 임계값을 라우팅 정책에 미리 선언하고, 비용과 품질의 균형을 API 레이어에서 조정한다.
예를 들어 Qwen2.5-7B로 첫 응답을 만든 뒤 신뢰도가 0.7 미만이면 Qwen2.5-72B로 보낸다. 여기에서도 0.85 미만이면 DeepSeek-R2 또는 Claude Opus 수준의 최상위 모델로 에스컬레이션한다. 이 실행 체인은 vLLM 설정 파일에 선언적으로 기록된다.
여러 후보를 만들고 충돌을 판정하는 방식
팬아웃에서는 같은 요청을 여러 모델에 보내거나, 한 모델에서 복수 샘플을 병렬 생성한다. 정확도 추정, 형식 준수, 길이 적절성 등을 평가하는 내부 스코어링 함수가 후보마다 점수를 부여하고 가장 높은 점수의 응답을 선택한다. LiveCodeBench 92.6 달성에는 이 팬아웃과 코드 실행 검증의 결합이 핵심으로 작용했다.
후보들이 서로 모순될 때는 Judge Model이 개입한다. 각 응답의 근거가 타당한지 평가하고, 그 증거를 합성해 최종 답변을 만든다. 판단 과정이 서빙 레이어 내부에 있으므로 외부 프레임워크가 별도의 API 호출 순서나 중간 상태를 관리할 필요가 없다.
LiveCodeBench 92.6을 만든 코드 검증 파이프라인
LiveCodeBench는 생성된 코드를 실제로 실행해 LLM의 코딩 능력을 평가한다. Claude Sonnet 4.5와 GPT-4.1 등을 사용한 폐쇄형 모델 레시피에서도 높은 수준의 결과가 나온 벤치마크이며, vLLM Semantic Router 기반 파이프라인은 92.6을 달성했다.
파이프라인은 같은 문제에 대해 N개의 코드 솔루션을 병렬 생성하는 것으로 시작한다. 각 솔루션은 샌드박스에서 테스트 케이스로 검증한다. 통과율이 가장 높은 코드를 선택하되, 결과가 임계값 미만이면 더 강한 모델로 에스컬레이션해 다시 시도한다. 마지막에는 코드 실행 결과를 증거로 제공하고 Judge Model이 최종 솔루션을 결정한다.
이는 프롬프트만 조정해 얻은 결과가 아니다. vLLM의 연속 배칭(Continuous Batching)과 PagedAttention이 팬아웃 요청의 병렬 처리를 뒷받침하면서 레이턴시와 처리량을 함께 개선한 서빙 인프라 수준의 최적화다.
기존 vLLM 환경에 라우터 연결하기
vLLM Semantic Router는 vLLM v0.6 이후 버전에 통합된 오픈소스 기능이다. 기존 배포에서 사용하려면 서버를 시작할 때 라우팅 정책 파일을 지정한다.
vllm serve Qwen/Qwen2.5-72B-Instruct \
--semantic-router-config ./router_policy.yaml \
--router-fallback-models "deepseek-ai/DeepSeek-V3,Qwen/Qwen2.5-7B-Instruct" \
--router-escalation-threshold 0.75router_policy.yaml에는 에스컬레이션 체인, 팬아웃 후보 수, Judge Model, 비용 예산 제한을 선언한다. 쿠버네티스에서는 모델 백엔드를 각각 별도 Deployment로 운영하고, Router가 내부 서비스 엔드포인트를 호출하는 사이드카 패턴이 권장된다.
LangChain, LlamaIndex, AutoGen을 이미 사용하고 있다면 호출 경계부터 점진적으로 옮길 수 있다. 1단계에서는 LLM 호출 부분만 vLLM Semantic Router 엔드포인트로 교체한다. 2단계에서는 if/else 기반 모델 선택과 재시도 로직을 라우팅 정책 파일로 이전한다. 3단계에서는 오케스트레이션 레이어가 비즈니스 로직과 도구 호출에 집중하도록 구조를 단순화한다.
이렇게 분리하면 애플리케이션 코드의 복잡도는 줄고 비용, 레이턴시, 품질 사이의 운영 판단은 인프라 레이어에 모인다.
비용·품질·레이턴시를 정책으로 다루기
비용을 우선한다면 토큰당 단가가 낮은 소형 모델을 1차 경로에 배치하고, 에스컬레이션 임계값을 보수적으로 정해 대형 모델 호출 빈도를 낮춘다.
품질 기준은 태스크별로 분리해야 한다. 코딩과 창의적 글쓰기는 같은 평가 기준을 쓰기 어려우므로 도메인에 맞는 임계값을 적용한다. 레이턴시 측면에서는 팬아웃 후보 수와 타임아웃을 SLA에 맞추고, 제한을 넘으면 베스트 에포트(best-effort) 응답을 반환하도록 폴백을 둔다.
애플리케이션 라우터와 관리형 라우터의 차이
LangChain LLM Router는 애플리케이션 프로세스 안에서 파이썬 코드로 라우팅한다. 프레임워크 생태계와 연결하기 쉽고 유연하지만, 모델을 선택하는 과정에서 네트워크 왕복(round-trip)이 추가된다. 라우팅 코드가 애플리케이션 곳곳에 흩어질 가능성도 있다. vLLM Semantic Router는 판단을 서빙 인프라에 배치하고 정책을 인프라 설정으로 중앙화한다.
Anthropic Model Router는 Claude API에서 Haiku, Sonnet, Opus 사이의 자동 라우팅을 제공하는 완전 관리형 서비스다. 별도 설정 없이 Anthropic 모델 생태계에 맞춘 최적화를 사용할 수 있는 대신, 오픈소스 모델이나 자체 파인튜닝 모델을 포함한 멀티벤더 라우팅은 지원하지 않는다. 오픈소스인 vLLM Semantic Router는 벤더 독립성을 유지하며 온프레미스와 프라이빗 클라우드에서 운영 제어권을 확보할 수 있다.
| 항목 | vLLM Semantic Router | LangChain LLM Router | Anthropic Model Router |
|---|---|---|---|
| 라우팅 위치 | 서빙 레이어 | 애플리케이션 레이어 | API 서비스 레이어 |
| 벤더 독립성 | 완전 독립 | 완전 독립 | Anthropic 종속 |
| 팬아웃 지원 | 네이티브 | 직접 구현 필요 | 미지원 |
| 에스컬레이션 | 자동 (정책 기반) | 수동 구현 | 자동 (내부 정책) |
| 오픈소스 | O | O | X |
| 온프레미스 | O | O | X |
| 설정 방식 | 선언적 YAML | 파이썬 코드 | API 파라미터 |
| 성능 최적화 | vLLM 네이티브 통합 | 외부 의존 | Anthropic 내부 |
팬아웃 비용을 제어하는 서빙 최적화
같은 모델을 향하는 팬아웃 요청은 vLLM의 연속 배칭으로 묶인다. 단순히 여러 API 호출을 병렬로 보내는 방식보다 GPU 활용률을 높일 수 있다. 동일한 프리픽스를 공유하는 후보 요청은 KV 캐시를 함께 사용해 중복 연산을 줄인다.
판정 단계도 항상 실행하지 않는다. 팬아웃 결과가 일치해 Judge Model이 필요 없는 상황을 조기에 감지하면 해당 호출을 건너뛰어 평균 레이턴시를 줄인다.
실측 데이터에서는 동등한 품질 수준에서 대형 모델만 사용하는 방식과 비교했을 때, 소형 모델 우선 실행과 에스컬레이션을 결합한 vLLM Semantic Router가 평균 추론 비용을 40-60% 절감하는 것으로 보고됐다. 다만 팬아웃 깊이가 커질수록 레이턴시도 증가한다. 운영 전에 레이턴시 SLA와 품질 목표가 만나는 지점을 실험으로 정해야 한다.
이 구조의 가치는 라우팅 로직 자체보다 책임 경계를 바꾸는 데 있다. 애플리케이션은 비즈니스 흐름과 도구 사용을 담당하고, 서빙 인프라는 모델 선택과 품질 판정을 맡는다. 멀티에이전트 시스템에서 모델 선택, 재시도, 후보 비교 코드가 빠르게 불어나고 있다면 검토할 수 있는 분리 방식이다.