모델 라우팅 (Model Routing): 모든 작업에 하나의 모델만 사용하는 것을 멈추세요

200단어 분량의 이메일을 요약하기 위해 70B 파라미터 모델을 실행하는 것은 낭비입니다. 프로덕션 코드를 리뷰하기 위해 3B 모델을 실행하는 것은 무모합니다. 대부분의 시스템은 그 중간 어디쯤에 위치하며, 바로 이 지점에서 모델 라우팅 (Model Routing)이 등장합니다.

모델 라우팅은 작업의 복잡도와 모델의 역량을 일치시킵니다. 트레이드오프 (Tradeoffs)는 분명히 존재하지만, 그만큼의 비용 절감 효과도 있습니다.

라우팅 문제 (The routing problem)

사람들은 보통 하나의 모델로 시작하여 그것을 계속 사용합니다. 비용이나 지연 시간 (Latency), 혹은 두 가지 모두가 눈에 띄기 전까지는 말이죠. 대안은 라우터 (Router)를 구축하는 것입니다. 즉, 어떤 모델이 어떤 요청을 처리할지 결정하는 무언가를 만드는 것입니다.

실제로는 네 가지 전략이 유효합니다:

역량 기반 (Capability-based) — 모델이 할 수 있는 능력에 따라 라우팅
비용 인식 (Cost-aware) — 지불할 용의가 있는 비용에 따라 라우팅
지연 시간 인식 (Latency-aware) — 필요한 속도에 따라 라우팅
하이브리드 (Hybrid) — 이들을 결합

각 방식은 서로 다른 요소를 최적화합니다. 하나를 선택하는 것은 대개 무엇이 가장 큰 손실을 주는가에 대한 결정입니다.

역량 기반 라우팅 (Capability-based routing)

가장 단순한 접근 방식입니다. 작업을 분류하고, 해당 작업을 처리할 수 있는 모델로 보냅니다.

작업	모델 크기	예시
분류 (Classification), 태깅 (Tagging)	1-3B	Qwen2.5-1.5B, Gemma-2-2B
...

작업에 더 큰 모델이 필요하지 않다면, 사용하지 마세요. 1.5B 모델은 감성 분류 (Sentiment classification)를 충분히 잘 수행합니다. 다만 일관성 있는 에세이를 쓰지는 못할 뿐입니다.

구현은 간단합니다:

ROUTING_RULES = {
    "classify": {"model": "qwen2.5-1.5b", "max_tokens": 100},
    "summarize": {"model": "qwen2.5-7b", "max_tokens": 500},
...

함정은 분류 (Classification) 자체에 있습니다. 작업 유형을 잘못 분류하면 잘못된 모델로 라우팅하게 됩니다. 저는 코드 리뷰를 "요약 (Summarization)"으로 분류하여 조용히 품질을 떨어뜨리는 시스템을 본 적이 있습니다.

비용 인식 라우팅 (Cost-aware routing)

로컬 추론 (Local inference)이 여기서 빛을 발합니다. 로컬 모델은 하드웨어 감가상각 이후에는 사실상 무료입니다. RTX 5080은 적당한 API 사용량 기준으로 약 6개월이면 본전을 뽑습니다.

모델	입력 ($/M tokens)	출력 ($/M tokens)	로컬 비용/시간
GPT-4o	$2.50	$10.00	—
...

세션당 수천 개의 요청을 처리하고 있다면, 0.05달러의 전기료가 1,000,000(M) 토큰당 15달러보다 저렴합니다.

예산 기반 라우팅 (Budget-based routing)은 지출이 늘어남에 따라 폴백 (fallback)됩니다:

class CostAwareRouter:
    def __init__(self, budget_per_session: float = 0.10):
        self.budget = budget_per_session
...

폴백이 진행될수록 품질은 저하됩니다. Claude로 시작하여 Qwen-32B로 이동하고, 그다음 Qwen-7B로 넘어갑니다. 긴 세션이 끝날 무렵에는 출력 품질이 눈에 띄게 나빠집니다. 이것이 문제가 될지 여부는 당신이 무엇을 만들고 있느냐에 달려 있습니다.

지연 시간 인식 라우팅 (Latency-aware routing)

대화형 도구는 빠른 첫 토큰 (first tokens)이 필요합니다. 배치 작업 (Batch jobs)은 기다릴 수 있습니다. 그 차이는 보통 모델 크기에서 5배 정도 발생합니다.

사용 사례	첫 토큰	완료	최대 모델 크기
실시간 채팅	< 200ms	< 2s	< 7B
...

사용자에게 토큰을 스트리밍할 때, 사용자가 체감하는 것은 첫 토큰 지연 시간입니다. 시작하는 데 0.5초가 걸리는 32B 모델은 즉각적으로 반응하는 1.5B 모델에 비해 느리게 느껴집니다.

class LatencyAwareRouter:
    def __init__(self):
        self.model_latencies = {
...

지연 시간 수치는 대략적인 것이며, 하드웨어, 양자화 (quantization), 배치 크기 (batch size)에 따라 달라집니다. 자신의 환경에서 직접 측정하세요.

폴백 전략 (Fallback strategies)

모델은 실패할 수 있습니다. API는 속도 제한 (rate-limit)을 겁니다. 타임아웃 (Timeout)도 발생합니다. 효과적인 패턴은 가장 우수한 것부터 가장 신뢰할 수 있는 것 순으로 정렬된 폴백 체인 (fallback chain)입니다:

class FallbackRouter:
    def __init__(self):
        self.fallback_chain = [
...

체인의 마지막 모델은 로컬 모델이어야 합니다. 속도는 더 느릴 수 있지만, 네트워크 문제나 API 키 문제로 인해 실패하지는 않을 것입니다.

라우팅이 도움이 되는 경우

워크로드가 혼합되어 있을 때 라우팅은 의미가 있습니다. 동일한 시스템에서 분류 (classification), 요약 (summarization), 추론 (reasoning)을 수행하고 있다면, 라우터는 비용과 지연 시간을 모두 절약해 줍니다.

수행하는 모든 작업의 복잡도가 동일하다면 모델 라우팅을 사용하는 것은 의미가 없습니다. 그저 해당 작업에 적합한 모델을 사용하면 됩니다. 라우터는 불필요한 복잡성을 추가할 뿐입니다.

초기 프로토타이핑 단계에서도 라우팅을 건너뛰어야 하는 또 다른 이유가 있습니다. 우선 하나의 모델로 작업을 작동시킨 다음, 비용이나 지연 시간 (latency)이 실제로 문제가 될 때 라우팅을 추가하십시오.

트레이드오프 (Tradeoffs)

모든 라우팅 전략은 무언가를 최적화하는 대신 다른 무언가를 희생합니다.

단일 모델 (Single model) — 가장 단순함, 가장 비쌈, 일관된 품질
역량 기반 (Capability-based) — 더 나은 비용, 작업당 더 높은 품질, 중간 정도의 복잡성
비용 인식 (Cost-aware) — 가장 저렴함, 품질이 가변적임, 중간 정도의 복잡성
지연 시간 인식 (Latency-aware) — 가장 빠름, 품질을 희생할 수 있음, 중간 정도의 복잡성
하이브리드 (Hybrid) — 모든 면에서 가장 좋음, 구현이 가장 복잡함

프로덕션 시스템은 대개 하이브리드 방식으로 수렴합니다. 역량 기반 (capability-based) 라우팅으로 시작하여, 청구서가 나오면 비용 인식 (cost awareness)을 추가하고, 사용자들이 느리다고 불평하면 지연 시간 인식 (latency awareness)을 추가하십시오.