LLM 라우팅은 세션을 바꾸면 손해일까

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

LLM gateway의 Intelligent Router는 쉬운 요청을 저렴한 모델로, 어려운 요청을 frontier 모델로 보내는 구조지만 multi-turn 대화와 agent에서는 비용 절감이 쉽게 약해질 수 있습니다. 세션 중 모델이나 provider를 바꾸면 안정적인 prefix의 Prompt Caching이 끊길 수 있고, 요청 난이도는 실행 전 예측하기 어려우며, 최신 메시지만 보면 문맥을 잃고 전체 대화를 보면 지연과 비용이 늘어납니다. OpenAI-compatible API도 tool selection, schema adherence, reasoning length, refusal behavior가 다른 모델을 완전히 interchangeable하게 만들지 못하므로, 게시자는 세션 시작 시 한 번 선택한 모델을 고정하고 독립적인 subtask에만 별도 라우팅하는 방식을 선호합니다. 라우팅의 성과는 token 단가가 아니라 cache miss, retry, correction cost를 포함한 successful outcome당 비용과 upstream, routing reason, cache-read tokens, TTFT, 최종 비용으로 판단해야 합니다.

실용적 조언

session 시작 시 capabilities, context size, latency, data policy, budget을 기준으로 provider와 model을 한 번 선택하고 해당 session에 고정합니다.
대화 turn마다 모델을 바꾸기보다 독립적인 subtask를 별도로 라우팅하고, 이전 요청을 안전하게 replay할 수 있을 때만 fallback을 사용합니다.
selected upstream, routing reason, cache-read tokens, retry count, time to first token, final cost를 기록해 token 단가가 아닌 successful outcome당 비용으로 라우팅을 평가합니다.

섹션별 상세

LLM gateway는 보통 쉬운 prompt를 저렴한 모델로, 어려운 prompt를 frontier 모델로 보내는 Intelligent Router를 추가하지만, multi-turn 대화와 agent에서는 단순한 모델별 token price 비교가 실제 비용을 반영하지 못합니다. Agent 요청에는 system instructions, tool definitions, conversation history, repository context처럼 큰 stable prefix가 반복해서 들어가며, 다음 turn을 다른 모델이나 provider로 보내면 일반적으로 cold-cache 요청으로 취급해야 합니다. 따라서 model B의 가격에서 cache savings가 사라지는 효과에 router overhead, retries, extra tokens, correction cost를 함께 더해야 routing의 실질적인 경제성을 계산할 수 있습니다.

요청 난이도는 실행 전에 정확히 판별하기 어렵습니다. 예를 들어 repository에서 tests를 개선하라는 동일한 요청도 agent가 발견하는 코드 상태와 작업 범위에 따라 단순한 작업이 되거나 복잡한 작업이 될 수 있으며, 최신 message만 보고 라우팅하면 필요한 문맥을 놓치고 전체 conversation을 읽으면 비용과 latency가 증가합니다. 이 구조에서는 라우터의 분류 정확도만으로 충분하지 않고, 실제 실행 과정에서 드러나는 작업 난이도와 추가 수정 횟수까지 결과 비용에 반영해야 합니다.

OpenAI-compatible API는 요청 format을 정규화하지만 모델을 서로 interchangeable하게 만들지는 못합니다. 모델마다 tool selection, schema adherence, reasoning length, refusal behavior, previous assistant messages의 해석이 다르기 때문에 conversation turn마다 provider를 임의로 바꾸면 행동 양식과 결과 형식이 흔들릴 수 있습니다. 게시자는 session 시작 시 capabilities, context size, latency, data policy, budget을 기준으로 한 번 선택한 provider와 model을 고정하고, 독립적인 subtask에만 별도 라우팅하며 replay가 안전한 경우에만 fallback을 사용하자는 기본값을 선호합니다.

게이트웨이가 routing의 효과를 검증하려면 selected upstream, routing reason, cache-read tokens, retry count, time to first token, final cost를 외부에 노출해야 합니다. 이런 관측값이 없으면 라우팅이 token price를 낮췄는지, 아니면 cache miss와 retries로 절약분을 상쇄했는지 구분하기 어렵습니다. 게시자가 제안하는 핵심 지표는 cost per token이 아니라 작업을 성공적으로 끝내는 데 든 cost per successful outcome이며, 본문에는 Prompt Caching 관련 OpenAI, Anthropic, Gemini 문서 링크가 함께 제시되어 있습니다.

용어 해설

프롬프트 캐싱(Prompt Caching): — 반복 요청에서 변하지 않는 시스템 지침, 도구 정의, 대화 기록 같은 입력 prefix를 저장해 재계산을 줄이는 기법입니다. 다른 모델이나 provider로 전환하면 캐시를 다시 만들 가능성이 커져 토큰 비용과 지연 절감 효과가 사라질 수 있습니다.
지능형 라우터(Intelligent Router): — 입력의 난이도나 요청 특성을 판별해 저렴한 모델과 frontier 모델 중 하나를 선택하는 게이트웨이 기능입니다. 모델 선택 비용, 추가 지연, 재시도와 결과 수정 비용까지 포함해야 실제 절약 여부를 판단할 수 있습니다.
컨텍스트 캐싱(Context Caching): — 긴 문서나 대화처럼 여러 요청에서 반복되는 컨텍스트를 캐시해 후속 추론에서 입력 처리량을 줄이는 방식입니다. 세션 중 provider나 모델이 바뀌면 기존 캐시를 활용하지 못해 요청이 cold-cache 상태로 처리될 수 있습니다.
스키마 준수(Schema Adherence): — 모델이 도구 호출이나 구조화된 출력에서 요구된 필드와 형식을 정확히 따르는 정도입니다. OpenAI-compatible API가 요청 형식을 통일해도 모델별 도구 선택과 스키마 준수 차이는 그대로 남아 모델을 임의로 교체하기 어렵게 만듭니다.
성공 결과당 비용(Cost per Successful Outcome): — 토큰 단가가 아니라 작업이 실제로 성공적으로 끝날 때까지 발생한 전체 비용을 측정하는 지표입니다. 라우팅으로 생긴 cache miss, retry, 추가 토큰, agent의 correction cost를 합산해야 운영상의 경제성을 평가할 수 있습니다.