다들 LLM 라우터 만들 때, 우리는 라우터를 폐기했다

TL;DR Highlight

요청별 모델 라우터를 4개월 운영해 보니 비용 절감보다 손해가 컸다

Who Should Read

비용 절감을 위해 요청별로 LLM 모델을 나눠 호출하는 라우터 도입을 고민하는 백엔드·에이전트 개발자

Core Mechanics

Manifest는 라우터를 접었다
- 3월에 출시하고 6월에 폐기를 결정했으며 9월 1일에 완전히 종료한다.
- 요청을 simple, standard, complex, reasoning 4단계로 분류해 비용을 줄이려는 라우터였다.
- 클라우드 사용자 7000명이 4개월 쓴 결과는 엇갈렸고 GitHub 이슈·토론이 많았다.
프롬프트만으로는 난이도를 모른다
- 프롬프트는 작업 전체가 아니라 시작 신호일 뿐이다.
- 난이도를 가르는 맥락은 툴 호출·웹 검색을 거치며 나중에 드러난다.
- 같은 '테스트 평가하고 개선해줘'도 HTML5 개인 사이트와 Linux kernel repo는 난이도가 전혀 다르다.
비용은 캐시가 라우팅보다 잘 줄인다
- 캐시 읽기(cache read)는 캐시 안 된 입력보다 75~90% 저렴하다.
- 시스템 프롬프트와 대화 기록은 프롬프트 앞쪽이라 prefix cache(앞부분 일치 시 재사용)가 잘 먹는다.
- 캐시를 고려한 라우터는 처음 고른 모델에 고정(stickiness)하게 되어 결국 라우팅을 안 하는 셈이 된다.
세션 중 모델이 바뀌면 일관성이 깨진다
- 작업 도중 모델을 갈아타면 전체 결과물 품질이 떨어진다고 본다.
- Manifest 엔지니어는 각자 의도에 맞춰 모델과 effort 파라미터를 직접 고른다.
- 라우터는 사람이 도구를 숙달하는 것도 방해한다고 주장한다.

Community Reactions

난이도는 시작할 때 알 수 없다는 경험
- 작년에 라우팅을 조사한 댓글러도 비슷한 결론이었다는 의견이다.
- 에이전트가 검색으로 답을 찾을 수 있는지에 따라 난이도가 달라지므로 질문만으로는 알 수 없다고 했다.
역할을 고정한 서브에이전트는 잘 된다는 경험
- 오케스트레이터가 맥락을 만들어 서브에이전트 역할별로 모델을 고정하면 효과적이었다는 경험이다.
- 탐색·사서 역할에 Minimax M3를 쓰니 싸고 빠르며 $10 플랜이 한 달 간다고 했다.
풀을 작게 두면 캐시 문제가 풀린다는 경험
- 모델 풀을 작게 하고 역할이 뚜렷한 모델만 두라는 의견이다.
- GPT 5.4와 DeepSeek 사이를 라우팅하며 캐시 적중률 99% 이상을 꾸준히 얻었다는 경험이다.
컨텍스트를 아는 라우터는 효과가 있다는 반론
- 워크로드를 이해하는 라우터로는 좋은 결과를 얻었다는 의견이다.
- 난이도 버킷 분류만 하는 라우터는 안 되지만, 챗봇 프롬프트를 법률·의료·코드 같은 카테고리로 나누는 건 잘 된다는 경험도 있다.

How to Apply

지금 쓰는 프롬프트 캐시 적중률 확인하기
- 오늘 API 응답의 usage 필드에서 cached input 토큰 비율을 로그로 뽑아라.
- 시스템 프롬프트와 대화 기록을 프롬프트 앞쪽에 고정해 prefix 일치를 유지하라.
라우터 대신 역할별 모델 고정하기
- 에이전트 단계(탐색, 요약, 코딩)마다 사용할 모델과 effort를 설정 파일에 명시하라.
- 요청 내용으로 분류하지 말고 호출 위치 기준으로 정하라.
라우터 도입 전 절감액 계산하기
- 캐시 할인(75~90%)을 적용한 현재 비용과 라우팅 예상 비용을 비교하라.
- eval, 프롬프트, 모니터링을 모델마다 따로 유지할 인건비를 함께 넣어라.

Try It

복사해서 바로 해보기

# Claude나 ChatGPT에 그대로 붙여넣기. 원문 주장을 우리 서비스에 적용해 보는 점검용 프롬프트

우리 서비스의 LLM 호출 구조는 아래와 같다.
{{호출 지점별 설명: 어떤 단계에서 어떤 모델을 쓰는지, 시스템 프롬프트 길이, 대화 길이}}

다음 관점에서 점검해 줘.
1. 캐시 읽기가 입력 대비 75~90% 저렴하다는 전제로, prefix cache를 더 잘 쓰려면 프롬프트 구조를 어떻게 바꿔야 하나?
2. 요청 내용으로 모델을 나누는 라우터를 넣는 것과, 호출 단계(역할)별로 모델을 고정하는 것을 비교해 줘. 비용, 일관성, eval·모니터링 유지 부담 기준으로.
3. 프롬프트만으로 난이도를 알 수 없는 요청 사례가 우리 서비스에 있는지 찾아 줘.

이어서 해 볼 것: 단계별 모델 고정안을 표로 만들어 달라고 요청하기.

Terminology

LLM 라우터요청마다 어떤 모델이 답할지 자동으로 골라 주는 교통정리 담당이다. 간단한 건 싼 모델, 어려운 건 비싼 모델로 보내는 게 목적이다.

prefix cache프롬프트 앞부분이 같으면 이미 계산한 결과를 재사용하는 기능이다. 같은 서두를 매번 다시 읽지 않고 책갈피에서 이어 읽는 것과 비슷하다.

stickiness처음 고른 모델을 계속 쓰게 붙잡아 두는 성질이다. 캐시를 살리려면 모델을 못 바꾸니 라우터의 존재 이유가 약해진다.

effort 파라미터모델이 얼마나 깊이 생각할지 조절하는 설정이다. 같은 모델이라도 값에 따라 속도와 품질이 달라진다.