코딩 에이전트 멀티 모델 라우팅의 비용 효율성 분석

멀티 모델 라우팅이 코딩 에이전트에 미치는 영향

멀티 모델 라우팅은 각 요청을 처리할 수 있는 가장 저렴한 모델로 전달합니다. 채팅 트래픽에서는 이 방식이 효과적입니다. 하지만 코딩 에이전트에서는 비용 절감보다 비용 증가를 초래하는 경우가 많습니다. 에이전트의 비용은 모델별로 캐시되는 프롬프트 접두사(prompt prefix)가 대부분을 차지하는데, 모델을 전환하면 해당 캐시가 무효화되기 때문입니다.

이 글에서 제안하는 규칙은 다음과 같습니다. 가용성을 위해서는 공급자 간에 라우팅하고, 비용을 위해서는 작업 경계에서만 티어 간 라우팅을 수행하며, 에이전트 작업 시에는 세션당 하나의 모델을 고정하십시오. 아래 내용은 이에 대한 근거입니다.

네 가지 용어를 정의합니다. 라우터(router)는 요청별로 모델을 선택합니다. 게이트웨이(gateway)는 요청이 통과하는 프록시이며, 라우팅 기능을 포함할 수도 있고 아닐 수도 있습니다. 프롬프트 캐시(prompt cache)는 공급자가 프롬프트의 처리된 접두사를 저장하는 것으로, 이후 동일한 접두사를 반복하는 요청은 입력 비용의 일부만 청구됩니다. KV 캐시(KV cache, key value cache)는 직접 운영하는 서버 내부에서 동일한 개념을 구현한 것입니다.

채팅 트래픽은 잘 라우팅되는데 에이전트 트래픽은 그렇지 않은 이유

채팅 요청은 한 번의 턴으로 이루어집니다. 요청이 도착하면 분류되고, 모델로 전달된 뒤 응답이 반환됩니다. 다음 요청으로 이어지는 상태 정보는 없습니다. 라우터는 이 질문을 작은 모델로 보내고 다음 질문을 큰 모델로 보낼 수 있으며, 각 요청은 서로의 존재를 알지 못합니다. 이것이 거의 모든 라우팅 벤치마크가 측정하는 작업 부하이며, 우수한 라우터는 이를 매우 잘 처리합니다.

에이전트 턴은 단일 요청이 아닙니다. "실패하는 테스트를 수정하라"와 같은 하나의 지시는 20개에서 60개의 API 호출로 이어집니다. 각 호출은 전체 대화 내용을 다시 전송합니다. 여기에는 시스템 프롬프트, 모든 도구 정의, 에이전트가 읽은 모든 파일, 에이전트가 확인한 모든 명령 출력 결과가 포함됩니다. 컨텍스트는 계속 커지기만 합니다. 30번째 호출에 이르면 반복되는 접두사(prefix)만 수만 토큰에 달하게 되며, 각 호출에서 실제로 새로 추가되는 내용은 수백 토큰에 불과합니다.

이러한 형태는 "비용이 많이 든다"는 단어의 의미를 바꿉니다. 채팅에서 비용은 대략 모델의 가격에 요청 횟수를 곱한 값입니다. 에이전트 루프에서 비용은 매 호출마다 다시 청구되는 접두사 비용입니다. 이 글의 나머지 내용은 바로 이 사실에서 비롯됩니다.

프롬프트 캐시는 모델별로 적용되며 에이전트는 그 안에 상주합니다

Anthropic은 캐시 읽기 비용을 기본 입력 가격의 0.1배로, 5분간 유지되는 캐시 쓰기 비용을 1.25배로 책정합니다. 이는 2026년 8월 기준으로 공개된 정가입니다.

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

두 번째 시리즈를 첫 번째 시리즈와 비교할 때는 열 방향이 아닌 행 방향으로 읽어야 합니다. Opus 5에서의 캐시 읽기 비용은 백만 토큰당 0.50 달러입니다. 목록에서 가장 저렴한 모델인 Haiku 4.5의 캐시되지 않은 입력 비용은 1.00 달러입니다. 따라서 가장 비싼 모델에서 활성화된 프리픽스를 다시 읽는 비용이 가장 저렴한 모델에서 동일한 프리픽스를 처음 읽는 비용보다 입력 토큰당 더 저렴합니다.

이 단일 비교만으로도 대부분의 라우팅 계획은 무의미해집니다. 작업을 하위 계층으로 이동시키는 라우터는 정가를 기준으로 비교합니다. 하지만 세션 중간의 에이전트는 이미 사용 중인 모델에 대해 정가를 지불하지 않습니다. 에이전트는 이미 저렴한 모델의 캐시되지 않은 요금보다 낮은 캐시 읽기 가격을 지불하고 있기 때문입니다.

캐시는 프롬프트 프리픽스의 해시값을 키로 사용하며 모델별로 관리됩니다. 다른 모델에 대한 요청은 해당 모델이 한 번도 본 적 없는 저장소를 대상으로 해시를 수행하므로, 일치하는 항목을 찾지 못해 전체 비용을 지불하게 됩니다. 캐시는 또한 도구, 시스템, 메시지 순으로 구성된 계층 구조를 가집니다. 특정 수준에서 변경이 발생하면 해당 수준과 그 이후의 모든 데이터가 무효화됩니다. 즉, 도구 정의를 하나만 수정해도 그 뒤에 있는 시스템 프롬프트 캐시가 폐기됩니다. 런타임에 도구를 등록하는 에이전트는 라우터를 거치지 않고도 이러한 문제에 직면하게 됩니다.

단일 세션 전환의 실제 비용

에이전트가 파일을 몇 개 읽은 후의 일반적인 크기인 40,000 토큰의 안정적인 프리픽스를 가진 세션을 가정해 봅니다. 아래는 위 정가표를 바탕으로 계산한 단일 턴의 프리픽스 비용입니다.

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

캐시가 유지된 상태에서 Opus 5를 계속 사용하는 경우 해당 턴의 프리픽스 비용은 0.020 달러입니다. Sonnet 5로 라우팅을 변경한 후 첫 번째 턴은 0.100 달러가 소요됩니다. Sonnet은 해당 프리픽스에 대한 항목을 가지고 있지 않아 새로 작성해야 하기 때문입니다. 다시 Opus 5로 돌아올 때는 0.250 달러가 소요됩니다. 세션이 이동한 동안 기존 항목이 만료되었기 때문입니다.

즉, 왕복 과정에서 두 번의 캐시 읽기를 피하기 위해 두 번의 캐시 쓰기 비용을 지불하는 셈입니다. 반면, 이 전환을 통해 Opus 대신 Sonnet의 출력 가격으로 한 턴의 출력을 얻었습니다. 세부 정보 블록에서 전체 과정을 계산하면, 절감액은 센트의 소수점 단위인 반면 캐시 페널티는 수십 센트에 달합니다. 페널티가 절감액보다 한 자릿수 이상 크며, 프리픽스 길이가 길어질수록 절감액과 달리 페널티는 계속 증가합니다.

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

공급자마다 도구 호출 형식이 다릅니다

에이전트는 도구 호출 루프이므로, 일반적인 채팅과는 달리 도구 호출 형식이 매우 중요합니다. Anthropic의 Messages API는 tool_use 콘텐츠 블록을 반환하며, 응답으로 tool_result 블록을 요구합니다. OpenAI 호환 API는 tool_calls 배열을 반환하는데, 여기서 function.arguments은 중첩된 객체가 아닌 JSON 인코딩된 문자열입니다. 게이트웨이가 이 두 형식 사이를 변환하며, 일반적인 호출의 경우 변환 과정은 깔끔하게 처리됩니다.

문제는 경계 상황에서 발생합니다. 모델이 한 번의 응답으로 여러 호출을 생성하는 병렬 도구 호출은 표현 방식이 서로 다르며, 모든 곳에서 동일하게 지원되지 않습니다. 엄격한 스키마 강제는 공급자별 기능이므로, 한 엔드포인트에서 스키마 유효 인자를 보장하던 모델이라도 다른 곳에서는 유효하지 않은 인자를 생성할 가능성이 큽니다. 에이전트는 이를 구문 분석 오류가 포함된 도구 결과로 인식하며, 이를 수정하기 위해 추가적인 턴을 소비합니다. 이러한 수정 턴은 전체 프리픽스 가격으로 청구되므로, 형식 불일치는 대화 기록뿐만 아니라 청구서에도 나타납니다.

자체 호스팅 엔드포인트는 이를 명시적으로 설정해야 합니다. vLLM의 OpenAI 호환 서버는 --enable-auto-tool-choice와 함께 모델 제품군(hermes, mistral, llama3_json 등)에 맞는 --tool-call-parser, 그리고 도구 역할 메시지를 처리하는 채팅 템플릿이 필요합니다. vLLM 문서는 이 경로의 한계를 명확히 밝히고 있습니다. tool_choice="auto"를 사용하고 엄격한 스키마 제약이 없는 경우, vLLM은 원시 텍스트에서 도구 호출을 추출하므로 인자가 때때로 잘못된 형식이거나 함수의 매개변수 스키마를 위반할 수 있습니다. 모델에 맞지 않는 파서를 선택하는 것은 설정 오류이며, 이는 에이전트가 도구를 호출하지 못하는 결과로 나타납니다. 트래픽을 라우팅하기 전에 모델을 직접 서빙할 때의 Ollama와 vLLM의 차이를 이해하는 것이 중요한 이유입니다. 두 도구는 서로 다른 조건으로 도구 호출을 노출하기 때문입니다.

중간 작업 중 폴백 발생 시 오류 없이 동작이 변경됨

폴백 라우팅은 실수로 활성화되기 가장 쉬운 기능입니다. 게이트웨이는 첫 번째 모델이 속도 제한이나 5xx 오류를 반환할 때 다른 모델로 재시도하도록 설정되며, 이후 실패한 모델을 몇 초 동안 쿨다운 상태로 전환합니다. 채팅 트래픽에서는 이 방식이 정확히 의도대로 작동합니다. 하지만 긴 에이전트 작업 내부에서는 작업의 후반부가 사용자가 선택하지 않은 모델에서 실행된다는 것을 의미합니다.

이를 보고하는 항목은 없습니다. 작업은 실패하지 않으며, 에이전트는 경고를 보내지 않고, 종료 상태는 성공으로 표시됩니다. 결과적으로 작업의 계획은 한 모델이 작성하고 편집은 다른 모델이 수행하게 되어, 작업 도중 어조와 습관이 바뀌는 현상이 발생합니다. 유일하게 신뢰할 수 있는 신호는 게이트웨이의 요청 로그나 응답 메타데이터에 있는 model 필드입니다. 따라서 폴백을 사용하는 경우라면 요청마다 해당 필드를 기록하고, 결과가 예상과 다를 때 이를 확인해야 합니다. 어떤 모델이 결과를 생성했는지 모른 채 동작을 디버깅하는 것은 폴백으로 절약한 시간보다 더 많은 시간을 낭비하게 만듭니다.

동일한 함정이 컨텍스트 압축에서도 발생합니다. 많은 에이전트가 긴 기록을 요약하기 위해 작은 모델을 호출합니다. 만약 해당 호출이 다른 모델이나 다른 시스템 프롬프트를 사용한다면, 자체 캐시 항목을 작성하게 되어 메인 세션의 캐시를 갱신하지 못합니다. 결과적으로 다음 전체 턴에서는 캐시를 활용하지 못하고 콜드 프리픽스(cold prefix) 비용을 지불하게 됩니다. 압축을 통해 토큰은 절약했지만 캐시는 손실된 것입니다.

라우팅 오버헤드는 실재하지만, 지연 시간이 결정적인 문제는 아닙니다

라우터는 요청마다 추가적인 작업을 수행하며, 그 비용이 어느 정도인지 정확히 파악할 필요가 있습니다. DigitalOcean의 보고에 따르면, 자사의 Arch-Router 모델은 자체 평가 기준 93.17%의 라우팅 정확도로 라우팅 의도를 해결하는 데 약 51 밀리초가 소요됩니다. 이는 DigitalOcean의 측정과 벤치마크 결과이며, 보편적인 수치는 아닙니다. 이 수치를 액면 그대로 받아들인다면 결론은 안심할 만합니다. 40번의 에이전트 호출에 걸쳐 51 밀리초가 추가되는 것은 수 분간 실행되는 작업에 약 2초를 더하는 수준이기 때문입니다.

여기서 라우팅을 비싸게 만드는 주범은 2초의 지연 시간이 아닙니다. 진짜 문제가 되는 오버헤드는 전체 모델 호출을 통해 분류를 수행하는 라우터입니다. 이는 모든 요청마다 두 번째 추론을 수행하는 것이며, 다른 요청과 마찬가지로 비용이 청구되고 대기열에 추가되기 때문입니다. 이 두 경우의 기저에는 앞서 언급한 캐시 연산이 존재하며, 이는 오버헤드가 아닙니다. 오히려 라우팅이 최적화하려 했던 대상의 비용입니다.

직접 운영하는 서버에서도 동일한 규칙이 적용되지만, 대응할 수 있는 여지는 더 적습니다. 프롬프트 캐시의 로컬 대응 개념은 GPU 메모리에 상주하는 KV 캐시의 프리픽스 캐싱(prefix caching)입니다. 하나의 GPU에서 두 개의 모델을 호스팅하면 메모리가 분할되므로, 각 모델은 더 작은 KV 캐시를 유지하게 되어 프리픽스를 더 빨리 제거(evict)하게 됩니다. 따라서 두 로컬 모델 사이에서 라우팅을 수행하면 두 모델의 캐시 적중률이 동시에 낮아질 수 있습니다. 이 작업을 위해 하드웨어 규모를 산정한다면, 라우터보다는 코딩 에이전트가 VPS에서 실제로 필요로 하는 메모리와 CPU를 기준으로 삼는 것이 더 유용합니다.

결정 규칙

• 가용성을 위해 공급자 간 라우팅을 수행합니다. 요청 실패가 대안인 상황에서는 어떤 비용이든 지불할 가치가 있습니다. 에이전트의 루프가 계속 작동하도록 대체 모델을 동일한 도구 호출 형식을 가진 모델로 고정하고, 각 호출을 처리한 모델을 로그에 기록합니다.
• 작업 경계에서만 비용을 위해 계층 간 라우팅을 수행합니다. 이름 변경에는 Haiku를, 리팩토링에는 Opus를 선택하는 것은 세션 시작 전 한 번 내리는 좋은 결정입니다. 세션의 30번째 턴에서 이런 결정을 내리는 것은 좋지 않습니다.
• 에이전트 작업 시 세션당 하나의 모델로 고정합니다. 세션의 가치는 캐시가 유지되는 상태에 있습니다. 모델을 전환하는 것은 캐시를 비우는 것과 같으므로, 그에 준하는 주의를 기울여야 합니다.
• 서브 에이전트는 자유롭게 라우팅합니다. 새로운 작은 컨텍스트로 시작하는 서브 에이전트는 잃을 캐시가 없으므로, 작업에 적합한 모델이라면 무엇이든 실행할 수 있습니다. 에이전트 내부에서 라우팅 비용이 거의 발생하지 않는 유일한 지점입니다.

이를 구축하는 방법은 게이트웨이가 담당합니다. 모델 별칭과 명시적 대체 목록을 사용합니다. 최소한의 LiteLLM 프록시 설정은 다음과 같습니다.

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

에이전트가 agent-primary을 가리키도록 설정하면 해당 모델에 도달할 수 없는 상황이 발생하기 전까지는 하나의 모델만 사용합니다. 두 항목 모두 동일한 공급자에 있으므로 대체 모델이 작동할 때 도구 호출 형식이 변경되지 않습니다. 이때 계층 변경이 발생하지만, 요청 실패보다는 나은 선택이므로 감수할 가치가 있습니다. 이것이 비용 라우팅이 포함되지 않은 가용성 라우팅이며, 대부분의 코딩 에이전트가 원하는 조합입니다. 키와 예산을 포함한 전체 구축 과정은 자체 VPS에서 LiteLLM 게이트웨이 직접 운영하기에서 다루고 있으므로, 이 게시물에서는 반복하지 않습니다.

잘 선택한 모델 하나가 라우터보다 나은 경우

라우팅은 요청 난이도의 편차를 해결하기 위한 방법입니다. 코딩 에이전트의 경우, 모든 호출에서 비용이 많이 드는 부분은 요청 내용과 관계없이 동일한 접두사(prefix)이므로 실제로는 생각보다 편차가 크지 않습니다. 접두사가 전체 토큰의 대부분을 차지하게 되면, 저가형 모델과 고가형 모델의 차이는 출력 가격의 차이로 좁혀지며, 출력 토큰은 에이전트 전체 토큰에서 차지하는 비중이 작습니다.

따라서 가장 정직한 기본 설정은 모델 하나를 신중하게 선택하고, 캐싱을 활성화한 뒤 diff를 읽기 위해 작업을 멈추는 간격을 충분히 커버할 수 있을 만큼 긴 TTL(time to live)을 설정하는 것입니다. Anthropic은 기본 입력 비용의 2배로 1시간 동안 캐시를 유지하는 기능을 제공하는데, 이는 두 번만 읽어도 비용을 회수할 수 있어 어떤 라우터보다 더 효과적인 수단이 되는 경우가 많습니다. Opus, Sonnet, Haiku의 직접 비교를 통해 의도적으로 모델 등급을 선택하십시오. 만약 여전히 비용이 문제라면, 세션 도중 모델을 전환하기보다는 VPS에서 AI 에이전트 비용 제어하기에서 설명하는 것처럼 예산 설정과 컨텍스트 크기 축소를 통해 비용을 절감하십시오.

요청이 독립적이고 짧거나, 하위 에이전트가 새로운 컨텍스트로 시작하는 경우에는 라우팅을 사용하십시오. 하나의 긴 세션에서 하나의 작업을 수행할 때는 모델을 고정하십시오. 대부분의 코딩 에이전트 작업은 후자에 해당하며, 이것이 바로 채팅 제품에서 비용을 절감해 주던 라우터가 여기서는 오히려 비용을 증가시키는 이유입니다. 아직 에이전트를 결정하지 못했다면, Claude Code와 Cursor, Codex, Copilot 비교를 통해 각 도구가 모델 선택을 어떻게 처리하는지 확인하십시오. 일부 도구는 이 결정을 사용자를 대신해 자동으로 수행합니다.

FAQ

세션 도중 모델을 전환하면 프롬프트 캐시가 정말로 사라집니까?

네, 사라집니다. 프롬프트 캐시는 프롬프트 접두사의 해시값을 기준으로 모델별로 저장됩니다. 따라서 다른 모델로 요청을 보내면 해당 접두사를 본 적이 없는 저장소에서 해시를 찾게 됩니다. 결과적으로 캐시를 찾지 못해 전체 입력 비용을 지불하게 되며, 캐싱이 활성화되어 있다면 추가로 캐시 쓰기 비용까지 발생합니다. 다시 원래 모델로 돌아와도 캐시 항목을 복구할 수 없는데, 이는 보통 기본값인 5분의 유효 기간이 이미 지났기 때문입니다. 응답 usage 객체의 cache_read_input_tokens 및 cache_creation_input_tokens 필드를 확인하십시오. 긴 세션에서 캐시된 토큰을 0개 읽는 턴이 발생한다면 이것이 바로 그 증상입니다.

에이전트 작업 시 더 저렴한 모델로 라우팅하는 것이 항상 비용 효율적입니까?

잃어버릴 캐시가 없을 때만 그렇습니다. Anthropic의 캐시 읽기 비용은 기본 입력 비용의 0.1배이므로, Opus 5의 캐시 읽기 비용은 Haiku 4.5의 캐시되지 않은 입력 비용보다 낮습니다. 세션에 이미 큰 캐시 접두사가 있다면, 현재 사용 중인 모델이 입력 비용 측면에서 이미 저렴한 선택지입니다. 라우팅은 컨텍스트가 작고 신선할 때, 즉 작업 시작 시점이나 필요한 컨텍스트만 전달받는 하위 에이전트에서 비용 절감 효과가 있습니다.

작업 도중 에이전트의 동작이 왜 달라졌습니까?

게이트웨이 폴백(fallback)이 작동했는지 확인하십시오. 기본 모델에서 속도 제한이나 5xx 오류가 발생하면 게이트웨이는 대기 모델로 재시도하고 기본 모델을 몇 초간 쿨다운 상태로 전환합니다. 이 과정에서 나머지 작업은 다른 곳에서 수행됩니다. 이 경우 오류나 경고가 발생하지 않으며 작업은 성공한 것으로 보고됩니다. 게이트웨이 요청 로그나 응답 메타데이터의 model 필드가 유일한 신뢰할 수 있는 기록이므로, 폴백을 사용한다면 요청별로 이 필드를 기록하십시오.

도구 호출(tool call)은 모든 제공자에서 동일하게 작동합니까?

그렇지 않습니다. Anthropic의 Messages API는 tool_use 및 tool_result 콘텐츠 블록을 사용하는 반면, OpenAI 호환 API는 function.arguments이 JSON 인코딩 문자열인 tool_calls 배열을 사용합니다. 게이트웨이가 일반적인 사례는 잘 변환하지만, 병렬 도구 호출이나 엄격한 스키마 강제 적용 방식은 제공자마다 다릅니다. 자체 호스팅하는 vLLM에서는 --enable-auto-tool-choice와 모델 제품군에 맞는 --tool-call-parser를 설정해야 합니다. vLLM 문서에 따르면 엄격한 스키마 제약이 없으면 서버가 원시 텍스트에서 도구 호출을 추출하므로 인자가 가끔 잘못된 형식으로 생성될 수 있습니다.

코딩 세션의 캐시 TTL은 어느 정도로 설정해야 합니까?

지속적인 작업에는 기본값인 5분 유효 기간을 사용하고, 사람이 턴 사이의 diff를 검토하는 경우에는 1시간 옵션을 사용하십시오. Anthropic은 5분 쓰기 비용을 기본 입력의 1.25배, 1시간 쓰기 비용을 2배로 책정하며, 읽기 비용은 0.1배입니다. 5분 쓰기 비용은 한 번의 읽기로 회수되고, 1시간 쓰기 비용은 두 번의 읽기로 회수됩니다. 따라서 다시 돌아와 작업을 이어갈 것으로 예상되는 세션이라면, 콜드 접두사 비용을 지불하는 것보다 더 긴 유효 기간을 설정하는 것이 보통 더 저렴합니다.