Provider Drift: 기본 라우팅이 LLM 비용을 3.9배 증가시키는 방식 — 측정 결과

프롬프트 캐싱 (Prompt Caching)을 활성화했고, 히트 카운터 (hit counter)가 가끔씩 올라가지만, 청구 금액은 거의 변하지 않았습니다. 프롬프트 구조를 탓하기 전에, 대시보드가 숨기고 있는 무언가를 살펴보십시오. 즉, 각 요청을 실제로 처리한 업스트림 (upstream)이 무엇인지 확인해야 합니다.

멀티 프로바이더 게이트웨이 (Multi-provider gateways)는 단일 모델을 여러 업스트림 프로바이더 (upstream providers)에 분산시키고 요청마다 하나를 선택합니다. 프롬프트 캐시 (Prompt caches)는 프로바이더 단위(종종 프로바이더 내부의 노드 단위)로 작동합니다. 따라서 두 번째 동일한 요청이 첫 번째 요청과 다른 업스트림에 도달하면, 프롬프트가 단 1바이트도 바뀌지 않았음에도 불구하고 캐시 미스 (cache miss)가 발생합니다. 이것이 바로 **Provider Drift (프로바이더 드리프트)**이며, 토큰당 과금 (pay-per-token) 모델에서는 비용을 조용히 배가시킵니다.

이를 유발하는 두 가지 조건

이것은 사용자가 선택한 설정 오류가 아닙니다. 기본 설정 그대로 사용했을 때 발생하는 현상입니다:

1. 기본 자동 라우팅 (Default auto routing). 업스트림을 고정하지 않고 모델로 요청을 보내므로, 게이트웨이가 호출마다 하나를 선택합니다.
2. **기본 프로바이더 정렬 = "default (balanced)" (Default provider sort = "default (balanced)").
   게이트웨이는 하나에 고정되는 대신 적절한 업스트림들 사이에서 부하 분산 (load-balances)을 수행합니다.

두 가지 모두 공장 출하 시 기본값입니다. 드리프트 (drift)를 발생시키기 위해 무엇을 건드릴 필요는 없습니다. 드리프트를 피하기 위해서만 설정을 건드려야 합니다.

20개의 동일한 요청 결과

우리는 위에서 언급한 기본 설정을 사용하여, 인기 있는 하나의 멀티 프로바이더 게이트웨이에 약 8K 토큰의 동일한 접두사 (prefix)를 20회 연속으로 보냈습니다. 매번 업스트림이 보고하는 자체 프로바이더 및 캐시 필드를 요청했습니다. DeepSeek 제품군의 디스크 캐시 모델 (disk-cached model)의 경우 결과는 다음과 같습니다:

• 9개의 서로 다른 업스트림이 20번의 호출을 처리했습니다: N***a, S***w, M***h, D***a, A***L, P***l, S***e, V***e, A***d.
• 캐시 히트율 (Cache hit rate): 4/20 (20%). 이미 귀하의 접두사를 캐싱하고 있는 업스트림에 우연히 도달한 호출에서만 히트가 발생했습니다.

동일한 워크로드에 대해 단일 백엔드 (single-backend) 게이트웨이(하나의 모델, 하나의 업스트림, 부하 분산 없음)를 대상으로 동일한 20번의 호출을 실행하면 히트율은 **19/20 (95%)**입니다. 모델도 같고, 프롬프트도 같고, 호출 횟수도 같습니다. 유일한 변수는 라우팅이 드리프트 (drifts)되는지 여부뿐입니다.

대조를 위해, 동일한 멀티 프로바이더 게이트웨이 (multi-provider gateway)에서 GPT급 모델을 20번의 호출 동안 단 하나의 업스트림 (A***e)으로 라우팅했을 때는 20번 중 19번의 히트 (hit)를 기록했습니다. 드리프트 (Drift)는 균일하게 발생하지 않습니다. 게이트웨이가 모델을 분산시키는 대상 모델을 골라 공격하며, 이번 실행에서는 DeepSeek 계열 모델이 그 대상이었습니다.

결론 A: 예상했던 비용 vs 실제 지불한 비용

드리프트가 발생한 모델의 호출당 비용은 캐시 결과에 따라 명확하게 나뉩니다:

호출 유형	호출당 중앙값 비용
캐시 히트 (cache hit)	~$0.00015
캐시 미스 (cache miss)	~$0.00062

이 모델에서 미스 (miss)는 히트 (hit)보다 약 4배의 비용이 듭니다 (원시 입력 토큰 (raw input tokens) 기준으로는 발표된 격차가 이보다 더 커서 대략 50배에 달합니다). 이제 20번의 호출 전체를 합산해 보겠습니다:

시나리오	히트율 (hit rate)	20번의 동일 호출 비용
예상 (캐시 도달 가능)	95%	$0.0026
실제 (기본 드리프트)	20%	$0.0102

동일한 모델, 동일한 프롬프트, 동일한 20번의 요청입니다. 프로바이더 드리프트 (Provider drift)로 인해 이번 실행 비용이 약 3.9배 더 많이 발생했습니다. 캐싱은 내내

거의 모든 요청이 새로운 업스트림 (upstream)으로 처리되기 때문에, 콜드 프리필 (cold-prefill) 지연 시간 (latency)을 유지하게 되며 응답한 프로바이더 (provider)의 변동성을 그대로 물려받게 됩니다. GPT 모델은 도달 가능한 캐시 (cache) 덕분에 TTFT (Time To First Token)가 36% 개선되었지만, 드리프트 (drift)가 발생한 모델은 개선 효과가 전혀 없었을 뿐만 아니라 가장 빠른 호출과 가장 느린 호출 사이의 편차가 4.5배에 달했습니다.

5분 만에 자신의 설정 감사하기

이 수치들이나 다른 누구의 수치도 맹신하지 마세요. 동일한 긴 접두사 (prefix)를 여러 번 보내고 두 가지 필드를 관찰하십시오. 도메인을 하드코딩하지 말고, 환경 변수 (env vars)를 사용하여 자신의 게이트웨이 (gateway)를 가리키도록 설정하세요.

import os, uuid
from openai import OpenAI

...

동일한 모델에 대해 하나 이상의 업스트림이 존재한다는 것은 드리프트가 발생하고 있음을 의미합니다. 프롬프트 안정성 (prompt stability)에 비해 현저히 낮은 히트율 (hit rate)은 비용 부담이 발생하고 있다는 신호입니다. 더 완전한 방법은 Does Your LLM Gateway Lie About Cache?에서 확인할 수 있습니다.

살펴봐야 할 사항

드리프트의 해결책은 구조적입니다. 각 호출을 귀하의 접두사를 한 번도 본 적 없는 새로운 업스트림으로 로드 밸런싱 (load-balancing)하는 대신, 특정 모델을 일관된 백엔드 (backend)로 라우팅하여 다음 요청 시 따뜻한 캐시 (warm cache)에 실제로 도달할 수 있도록 해야 합니다. 게이트웨이를 평가할 때는 동일한 접두사를 20번 보내고 업스트림의 개수를 세어보세요. 하나가 당신이 원하는 결과이며, 아홉 개는 세금(tax)입니다.

공정하게 주의를 드리자면, 프롬프트 캐싱 (prompt caching)은 어디에서나 최선(best-effort)을 다하는 방식이며, 디스크 캐시된 모델의 경우 단일 백엔드를 사용하더라도 긴 유휴 시간 (idle gaps)이 지나면 히트율이 여전히 낮아질 수 있습니다. 드리프트를 제거한다고 해서 무한한 캐시가 주어지는 것은 아닙니다. 다만, 당신이 동의한 적도 없고 볼 수도 없는, 미스 (miss)의 가장 크고 낭비적인 원인을 제거해 줄 뿐입니다.

마치며

"프롬프트 캐싱 지원"과 "캐시에 도달 가능함"은 서로 다른 주장입니다. 하나의 모델을 순환하는 여러 업스트림에 흩뿌리는 게이트웨이는 캐시 지원을 사실대로 보고하면서도, 20%의 히트율, 약 4배의 청구 금액, 그리고 4.5배나 요동치는 첫 번째 토큰 지연 시간 (first-token latency)을 제공할 수 있습니다. 주시해야 할 숫자는 캐싱이 광고되고 있는지 여부가 아닙니다. 측정된 히트율과 동일한 요청이 얼마나 많은 업스트림을 건드리는지입니다. 프로브 (probe)를 실행하고 데이터가 결론을 내리게 하십시오.

더 광범위한 감사 방법은 Does Your LLM Gateway Lie About Cache?를 참조하십시오. 캐시가 존재하는 근본적인 이유에 대해서는 How KV Cache & TTL Work를 참조하십시오.

FAQ

이것이 제 측의 설정 오류인가요?
아니요. 이는 공장 기본 설정(factory defaults)에서 발생합니다. 즉, 제공자 정렬(provider sort)이 "default (balanced)"로 남겨진 상태의 자동 라우팅(auto routing)에서 발생합니다. 드리프트(drift)를 방지하려면 반대로 하는 것이 아니라, 업스트림(upstream)을 능동적으로 고정(pinning)해야 합니다.

하나의 업스트림을 고정하면 해결되나요?
제공자 간의 드리프트(cross-provider drift)는 제거되지만, 단일 업스트림이라도 접두사 어피니티(prefix affinity) 없이 여러 복제본(replicas)을 실행하는 경우가 많으므로 히트(hit)가 여전히 왔다 갔다 할 수 있습니다. 가정하기보다는 고정 후에 측정하십시오.

왜 GPT급 모델은 드리프트가 발생하지 않았나요?
이번 실행에서는 게이트웨이가 우연히 해당 모델을 단일 업스트림으로 라우팅했습니다. 드리프트는 모델별로 발생하며, 게이트웨이가 얼마나 많은 적격 업스트림 간에 부하를 분산하는지에 따라 달라집니다. 즉, 균일하게 발생하지 않습니다.

비용 차이가 정말 약 4배인가요?
우리가 측정한 호출당 총액 기준으로는 미스(miss)가 히트(hit)보다 약 4배 높았습니다. 이 모델 클래스의 원시 입력 토큰(input-token) 가격 기준으로는 발표된 히트 대 미스 격차가 50배에 더 가깝습니다. 어느 쪽이든, 예상되는 히트를 미스로 바꾸는 것이 비용이 많이 드는 부분입니다.

어떤 단일 지표를 모니터링해야 하나요?
시간 경과에 따른 모델별 캐시 히트율(Cache hit rate)과 함께 모델별 고유 업스트림(distinct upstreams) 수를 모니터링하십시오. 히트율이 떨어지거나 업스트림 수가 증가한다면, 실질적인 토큰 비용이 상승한 것입니다.