예산·사용량·업무·품질·보안 조건을 입력하면, 조건에 맞는 LLM 라우팅 전략 · 예상 비용 · 구현 방식을 추천하는 오픈소스 의사결정 도구.
"Routing is not just choosing a model. It is designing how quality, cost and risk are allocated."
▶ 라이브 데모: https://yoon630.github.io/RouteFit/
RouteFit은 실시간 모델 라우터를 새로 만드는 도구가 아닙니다. 실제 프롬프트를 라우팅하는 RouteLLM이나, 여러 LLM API를 연결·재시도·로드밸런싱하는 AI Gateway(LiteLLM)과 경쟁하지 않습니다.
RouteFit이 답하는 질문은 하나 위 계층입니다.
"RouteLLM · LiteLLM · Bedrock Router · Azure Router · 직접 구현 중, 이 조건에는 무엇이 맞는가?"
기업의 AI 운영 조건을 입력하면 RouteFit은 다음을 추천합니다.
- 적합한 라우팅 방법론
- 모델 후보 조합과 예상 트래픽 비율
- 공식 가격 기반 예상 월 운영비 (보수·기준·공격 시나리오)
- 필요한 데이터와 평가 방식
- 구현 아키텍처와 PoC 계획
그리고 하나의 "정답"이 아니라 비용·품질 지도(Pareto Frontier) 로 보여주고, 왜 이 전략이 선택됐고 무엇이 왜 탈락했는지를 모두 설명합니다.
| 기능 | 설명 |
|---|---|
| 조건 입력 → 전략 추천 | 간편 모드 7개 입력 또는 전문가 모드 상세 입력 |
| 공식 가격 기반 비용 시뮬레이션 | 단일 / 라우팅 / 캐스케이드 / 하이브리드 비용 비교 |
| Cost–Quality Frontier | 정답 하나가 아니라 전략들의 비용 vs 품질 지도 |
| 설명 가능한 추천 (Decision Trace) | 채택뿐 아니라 탈락한 전략과 그 사유까지 공개 |
| 라우팅 흐름 시각화 | 공통 그래프 데이터를 커스텀 SVG로 그리고, 동일 그래프를 mermaid로도 출력 |
| Data Readiness 진단 | 보유 데이터 수준에 따라 실현 가능한 방식만 추천 |
| 구현 산출물 다운로드 | routing-plan.json · litellm-config.yaml · PoC 계획 · 데이터셋 템플릿 |
| 무백엔드 · 프라이버시 | 입력값이 브라우저 밖으로 나가지 않음. 서버·비용 0 |
RouteFit은 라우팅·캐스케이딩·추론 최적화의 개입 시점을 구분해 3단계로 전략을 결정합니다.
flowchart TD
A[기업 운영 조건 입력] --> B[Hard Constraint Filter]
B --> C{명백히 복잡한 요청인가?}
C -->|Yes| D[고성능 모델]
C -->|No 또는 불확실| E[경량 모델]
E --> F{품질 기준 충족?}
F -->|Yes| G[최종 응답]
F -->|No| D
D --> G
1단계 · 제약조건 필터링 — 데이터 반출 정책, 클라우드 환경, 컨텍스트 길이, 멀티모달·Tool calling 지원, 리전·규제, 최대 허용 응답시간을 충족하지 못하는 모델·방식을 후보에서 제외.
2단계 · 사전 라우팅 (생성 前) — 업무 유형·복잡도·예상 품질·비용을 기준으로 경량/고성능 모델을 선택. RouteLLM 및 AWS·Microsoft·Google 관리형 라우팅 개념 참고.
3단계 · 사후 품질 검증 (생성 後) — 경량 모델의 답변이 기준 미달이면 고성능 모델로 에스컬레이션. FrugalGPT의 LLM Cascade와 Quality Gate 개념 참고.
때로는 라우터를 추가하지 않는 것이 최선입니다. 트래픽이 적고 모델 비용도 낮으면 라우터의 호출 비용·지연·운영 복잡도가 이득보다 큽니다. RouteFit은 이 경우 "라우팅 도입 보류" 를 정식 추천안으로 제시합니다.
핵심은 "월 전체 요청량을 토큰으로 환산한 뒤, 각 요청이 거치는 모델 경로에 따라 모델별 비용을 더하는 것" 입니다. 전체 로직은 docs/methodology.md 참고.
월 요청 수 = 월 활성 사용자 × 1인당 일평균 요청 × 월 사용일수
월 입력 토큰 = 월 요청 수 × 요청당 평균 입력 토큰
월 출력 토큰 = 월 요청 수 × 요청당 평균 출력 토큰
월 비용 = (월 입력 토큰 / 1e6 × 입력단가) + (월 출력 토큰 / 1e6 × 출력단가)
단순 할인율을 일괄 적용하지 않고, 실제 가격 구조를 그대로 반영합니다.
- 라우팅 (총 호출 100%): 요청이 처음부터 한 모델로 → 비율대로 토큰 분배 + 라우터 자체 비용
- 캐스케이드 (총 호출 > 100%): 전체 경량 처리 + 에스컬레이션분만 고성능 재호출 → 실패 요청은 두 모델 비용 중복
- 캐시: 입력 토큰을 적중률로 분리. Anthropic처럼 cache write ≠ cache read 는 별도 계산
- Batch: Batch 가능 업무 비율에만 할인 적용 (전체 일괄 금지)
- 컨텍스트 구간: 예) Gemini Pro는 입력 > 200K 토큰 시 단가 상승
- 기간 조건: 예) 출시 기념가 → 표준가 전환 시점을 반영해 월별 비용이 자동으로 달라짐
결과는 ① 순수 모델 비용 · ② 라우팅·평가 오버헤드 · ③ 선택적 도구·인프라 비용 3층으로 분리해 보여줍니다.
사용자 수만으로는 비용을 계산할 수 없습니다. 같은 1만 명도 하루 1회 짧은 요약과 하루 20회 긴 문서 분석은 비용이 완전히 다릅니다.
간편 모드 (7개) — 월 예산 · 예상 사용자 수 · 1인당 일평균 요청 · 운영 방식 선호(관리형[AWS/Google/Azure] · 직접 구축 · 무관) · 주요 업무(8개 프리셋 + 기타) · 품질 우선순위 · 데이터 반출. 업무를 고르면 평균 토큰·캐시율·batch율·품질 성공률 프리셋이 자동 적용되고, 우측에서 파생값(월 요청 수·토큰·baseline 비용)이 실시간으로 계산됩니다.
전문가 모드 — 요청당 토큰 · 업무별 비율 · P95 지연 · 컨텍스트 · 멀티모달/tool calling · 캐시 적중률 · Batch 비율 · 보안·리전 · 자체 GPU 보유 · 평가 데이터 보유 여부 · 허용 품질저하 범위 등으로 프리셋을 덮어씁니다.
운영 방식 선호는 "신호"일 뿐, 제약이 이깁니다. 예를 들어 관리형 + AWS를 선호했더라도 데이터 반출이 불가하면 Bedrock은 탈락하고, RouteFit은 그 이유와 함께 로컬 Semantic Router + 자체 모델을 권장합니다.
RouteFit의 결과 화면은 왜 뽑혔고 무엇이 왜 탈락했는지를 전부 노출합니다.
- 왜 이 전략인가 — 입력 하나하나가 결론으로 이어진 사슬. 각 근거에 출처 태그(입력 필드 / 방법론 규칙 / 제약식 / 비용 공식).
- Decision Trace — 검토된 모든 후보의 상태(채택 / 차선 / 탈락 / 기준선)와 사유. 탈락 사유를 숨기지 않습니다.
- 신뢰도 근거 — 가격(공식 기반) · 사용량(입력 기반) · 품질(평가 데이터 유무) 축별로 분해해 종합 신뢰도를 산출하고, 무엇을 하면 신뢰도가 올라가는지 안내.
전략 결정과 설명 생성 로직의 전체 규칙은 docs/strategy-mapping.md에 있습니다.
가격은 하나의 숫자가 아니라 조건이 붙은 가격 규칙으로 관리합니다 (모드 · 캐시 · 컨텍스트 구간 · 채널 · 기간 · 리전). 스키마와 동기화 구조는 docs/pricing-catalog.md 참고.
- 채널 분리 — 같은 모델도 Anthropic Direct / AWS Bedrock / Vertex 등 구매 채널에 따라 가격이 다릅니다.
- Last-known-good — 공식 페이지 파싱이 실패해도 직전 검증 스냅샷을 계속 사용.
- 정직한 표기 — "최신 가격"이라 쓰지 않고 마지막 확인 시점을 명시합니다. (현재 카탈로그는 공식 가격 출처를 바탕으로 수동 검증한 스냅샷 —
catalog/pricing.seed.json, 2026-07-13 기준) - 이 스냅샷을 앱에 번들해 백엔드 없이 클라이언트에서 비용을 계산합니다. 자동 동기화 파이프라인(빌드타임)은
docs/pricing-catalog.md에 설계돼 있으며 아직 미구현입니다.
RouteFit의 라우팅 추천 로직은 특정 클라우드 서비스의 알고리즘을 복제한 것이 아닙니다. LLM 라우팅·캐스케이딩 연구 논문과, AWS·Microsoft·Google이 공개한 관리형 라우팅 서비스의 설계 원리를 종합해 만든 독립적인 의사결정 프레임워크입니다.
본 프로젝트는 LLM 라우팅을 다음과 같이 정의합니다.
모든 요청에 하나의 모델을 사용하는 대신, 요청의 특성·품질 요구 수준·비용 예산·지연시간·운영 환경을 고려해 가장 적절한 모델과 처리 경로를 선택하는 운영 전략.
RouteFit은 모델 라우팅을 단순한 모델 선택 기능으로 보지 않고, 비용·품질·응답속도·보안·운영 복잡성을 어떻게 배분할 것인지 결정하는 시스템 정책으로 해석합니다.
RouteLLM: Learning to Route LLMs with Preference Data 는 요청이 들어왔을 때 강한 모델과 저렴한 모델 중 무엇을 쓸지 사전에 결정하는 학습형 라우팅을 제안합니다. 사람의 선호 데이터와 증강 데이터로 라우터를 학습해 요청별 비용–품질 균형을 최적화합니다.
RouteFit에 반영된 원리:
- 모든 요청에 가장 강한 모델을 쓸 필요는 없다.
- 요청마다 적합한 모델이 다를 수 있다.
- 라우팅은 가격만이 아니라 예상 응답 품질을 함께 고려해야 한다.
- 학습형 라우터에는 모델별 답변과 선호 데이터가 필요하다.
- 기업이 보유한 평가 데이터 수준에 따라 적용 가능한 방법이 달라진다.
→ 사용자가 선호/평가 데이터셋을 보유하면 규칙 기반보다 RouteLLM 계열 학습형 라우터를 우선 검토하도록 추천합니다.
FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance 의 LLM Cascade는 저렴한 모델을 먼저 호출하고, 답변 신뢰도가 부족할 때만 더 강한 모델을 순차 호출합니다. 생성 결과를 평가하는 scoring function과 다음 호출을 결정하는 router로 구성됩니다.
RouteFit에 반영된 원리:
- 경량 모델이 충분한 요청은 경량 단계에서 종료한다.
- 품질 미달 시 고성능 모델로 에스컬레이션한다.
- 캐스케이드에는 Quality Gate가 필요하다.
- 에스컬레이션된 요청은 두 모델을 모두 호출하므로 중복 비용·지연이 발생한다.
- 캐스케이드 성능은 도메인 평가 데이터와 신뢰도 기준에 크게 의존한다.
flowchart LR
A[사용자 요청] --> B[경량 모델]
B --> C{품질 기준 충족?}
C -->|Yes| D[최종 응답]
C -->|No| E[고성능 모델]
E --> D
하나의 서버리스 엔드포인트로 동일한 모델 패밀리 안의 복수 모델 사이에서 요청을 라우팅합니다. 요청별 예상 응답 품질을 예측해 품질–비용 균형으로 모델을 선택하며, 공식 문서는 동일 패밀리 제약과 영어 프롬프트 최적화를 명시합니다.
RouteFit에 반영된 원리:
- 기존 클라우드 환경과 공급자 선호는 중요한 제약조건이다.
- 관리형 라우터는 빠르게 도입되지만 지원 모델 범위가 제한될 수 있다.
- 같은 패밀리 안에서 경량·고성능을 구분하는 전략도 유효하다.
- AWS 중심 환경이면 직접 구현과 Bedrock 관리형을 함께 비교해야 한다.
- 단일 엔드포인트·관리 편의성·클라우드 종속성도 추천 점수에 반영한다.
→ RouteFit은 AWS 사용만으로 Bedrock을 추천하지 않습니다. 지원 모델·언어·리전·반출 정책·패밀리 제약을 확인한 뒤 관리형과 직접 구현을 비교합니다.
하나의 배포 엔드포인트 뒤에서 요청 복잡도와 최적화 방향에 따라 모델을 선택하는 관리형 라우터로, 라우팅 정책을 Cost · Balanced · Quality 로 구분합니다. (현재 OpenAI·Anthropic·DeepSeek·Meta·xAI 등 다수 벤더 모델을 단일 배포로 통합 지원)
RouteFit에 반영된 원리:
- 하나의 절대적 최적 조합은 존재하지 않는다.
- 기업마다 비용·품질·지연 선호가 다르다.
- 같은 후보군이라도 최적화 목적에 따라 트래픽 분포가 달라져야 한다.
- 사용자는 라우팅 후보 모델 범위를 제한할 수 있어야 한다.
- 추천은 하나의 모델명이 아니라 예상 모델별 트래픽 비율과 함께 제공돼야 한다.
→ RouteFit은 세 가지 최적화 프로필을 제공합니다.
| 최적화 모드 | 주요 목표 | 기본 라우팅 성향 |
|---|---|---|
| Cost | 월 운영비 최소화 | 경량 모델 비율 확대 |
| Balanced | 비용과 품질의 균형 | 요청 복잡도에 따라 분배 |
| Quality | 응답 품질 우선 | 고성능 모델 비율 확대 |
설정한 품질·비용 균형에 따라 각 프롬프트에 적합한 응답 경로를 선택하는 관리형 최적화 기능입니다. (2026년 4월 Vertex AI가 Gemini Enterprise Agent Platform 으로 통합되면서 Model Optimizer도 이 플랫폼 하위 기능으로 제공됩니다.)
RouteFit에 반영된 원리:
- 모델 선택 기준은 난이도뿐 아니라 사용자의 최적화 목표를 포함해야 한다.
- 같은 요청이라도 비용 우선/품질 우선 정책에서 다른 모델이 선택될 수 있다.
- 모델뿐 아니라 도구·추론 옵션도 비용·품질에 영향을 준다.
- 라우팅 추천은 고정된 답이 아니라 사용자 정책에 따라 변하는 시뮬레이션 결과여야 한다.
Google의 Global Endpoint는 여러 리전의 가용 용량을 고려하는 capacity-aware routing으로, 요청 난이도로 모델을 고르는 Model Optimizer와는 다른 종류입니다. RouteFit은 두 층위를 구분합니다.
| 구분 | 핵심 질문 | 예시 |
|---|---|---|
| Model Routing | 어떤 모델이 이 요청을 처리해야 하는가? | 경량/고성능 선택 |
| Infrastructure Routing | 어느 리전·엔드포인트가 처리해야 하는가? | 가용 용량·장애·지연 기반 분배 |
이 구분으로 모델 비용 최적화와 서비스 안정성 최적화를 혼동하지 않도록 설계했습니다.
표준 캐스케이드가 작은 모델 결과를 확인한 뒤 큰 모델을 순차 호출한다면, Speculative Cascades는 speculative decoding과 cascade의 deferral rule을 결합해 토큰 생성 과정에서 작은/큰 모델의 협업을 최적화합니다.
RouteFit은 개입 시점으로 세 가지를 구분합니다.
- Request-level routing: 요청마다 사용할 모델 선택
- Response-level cascade: 생성된 답변 평가 후 상위 모델로 에스컬레이션
- Token-level optimization: 하나의 답변 생성 과정에서 모델들이 협업
Speculative Cascades는 주로 모델을 직접 서빙하는 환경과 관련되므로, RouteFit에서는 자체 GPU로 대·소 모델을 함께 운영하는 사용자에게 고급 추론 최적화 옵션으로 안내합니다.
RouteFit은 보유 데이터 수준에 따라 추천 가능한 방식을 다르게 판단합니다.
| 데이터 준비도 | 추천 가능한 방식 |
|---|---|
| 평가 데이터 없음 | 규칙 기반 라우팅 |
| 업무별 질문 예시 보유 | 임베딩 기반 Semantic Routing |
| 모델별 답변 보유 | 모델 성능 비교 및 Threshold 설정 |
| 사람의 선호 데이터 보유 | RouteLLM 계열 학습형 라우터 |
| 신뢰도·실패 라벨 보유 | Cascade Quality Gate 최적화 |
| 실제 운영 로그 보유 | 트래픽 비율·에스컬레이션 정책 고도화 |
- Deterministic Core — 비용 계산·모델 필터링·기본 전략 추천은 재현 가능한 규칙 엔진으로 수행.
- Cost–Quality Trade-off — 가장 저렴한 모델이 아니라, 최소 품질 기준을 충족하면서 비용을 줄이는 조합을 탐색.
- Data-aware Recommendation — 보유 평가 데이터 수준을 고려해 실제 구현 가능한 방식만 추천.
- Provider-aware Recommendation — 기존 클라우드·공급자 선호를 고려하되 특정 공급자를 자동 우선하지 않음.
- Explainable Recommendation — 선택 이유, 제외된 대안, 예상 모델별 처리 비율, 필요한 검증 데이터를 함께 제공.
- Progressive Adoption — 규칙 기반 → Semantic Routing → Cascade → Learned Router 순으로 고도화할 수 있도록 설계.
- 프론트엔드: React 18 + Vite + Tailwind CSS
- 백엔드: 없음 — 순수 클라이언트. 입력값이 브라우저 밖으로 나가지 않습니다.
- 가격 계산: 공식 가격 기반 수동 검증 스냅샷(
catalog/pricing.seed.json)을 번들 → 클라이언트에서 계산 - 가격 동기화: 빌드타임 Node 어댑터 파이프라인은 설계만 됨 (미구현,
docs/pricing-catalog.md) - 배포: GitHub Pages / Vercel 정적 호스팅 (무료)
- 디자인: 라이트 모드, 밝은 하늘색 강조 (
#38BDF8)
MVP (Architecture Advisor) — 실제 프롬프트를 라우팅하지 않음. 조건 입력 → 비용 계산 → 전략 후보 생성 → 월 비용 시뮬레이션 → 아키텍처 추천 → 필요한 데이터·PoC 안내.
V2 — 샘플 질문 CSV 업로드 → 질문 유형·복잡도 분포 분석 → 후보 모델별 평가 실행 → 실제 라우팅 비율 추정 → 권장 threshold 탐색. (모델 API 호출·과금이 필요하므로 이 단계에서만 서버리스 함수를 선택적으로 도입)
✅ MVP 구현 완료 · 배포됨 — 라이브 데모. 랜딩 → 조건 입력 → 추천 결과까지 동작합니다.
git clone https://github.com/yoon630/RouteFit.git
cd RouteFit
npm install
npm run dev설계 문서(SSOT)는 docs/에 있습니다.
assumptions.md · methodology.md · pricing-catalog.md · ux-spec.md · strategy-mapping.md
논문에서 보고된 비용 절감률은 특정 데이터셋·모델·가격·평가 조건에서 측정된 실험 결과이며, 모든 기업 환경에서 동일한 효과를 보장하지 않습니다.
AWS·Microsoft·Google의 지원 모델·리전·가격·기능은 변경될 수 있습니다. 본 문서의 서비스 설명은 2026-07-13 기준이며, RouteFit의 결과는 사용자가 입력한 조건에 기반한 시뮬레이션이자 입력 가정 하의 권장안입니다. 실제 도입 전에는 기업의 도메인 평가 데이터셋을 이용한 PoC가 필요합니다.
Research Papers
- RouteLLM: Learning to Route LLMs with Preference Data — Isaac Ong et al., 2024.
- FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance — Lingjiao Chen, Matei Zaharia, James Zou, 2023.
- Hybrid LLM: Cost-Efficient and Quality-Aware Query Routing — Microsoft Research.
- Speculative Cascades: A Hybrid Approach for Smarter, Faster LLM Inference — Google Research.
Official Service References
- Multi-LLM routing strategies for generative AI applications on AWS — Amazon Web Services.
- Model router for Microsoft Foundry — Microsoft Learn.
- Vertex AI Model Optimizer & Global Endpoint (Gemini Enterprise Agent Platform) — Google Cloud.
Tooling
- pydantic/genai-prices — LLM 가격 데이터 패키지 (가격 규칙 구조 설계 시 참고, 런타임 의존성 아님).
Design (UX/UI)
- 토스 앱빌더 UX 가이드 — 클린 라이트 UI 톤·컴포넌트 감각 참고 (강조색은 타사 브랜드색을 피해 하늘색으로 재구성).
MIT