긴 컨텍스트 요금제: 최대 6.7배, gateway에는 표시되지 않는다

prompt가 길어지면 gateway의 모델 페이지에 표시된 가격과 실제 청구 가격이 달라진다. 대형 multi-provider aggregator 하나를 통해 구간별 요금이 있는 모델 9개에 요청을 보냈다. 문서에 나온 모든 길이 기준의 전후를 각각 측정했다. 5개 모델은 첫 번째 기준을 넘자 페이지 가격의 정확히 2배가 청구됐다. Alibaba 모델 3개는 최상위 구간에서 각각 3배, 3배, 6.7배까지 올랐다. Azure를 통해 제공된 모델 하나는 기준 전후 모두 표시된 endpoint 요금의 1.25배가 청구된 뒤 다시 2배로 올랐다. 이 내용은 페이지 어디에도 없다. 작동 방식은 vendor 문서에 명시돼 있다. Google, OpenAI, xAI, Alibaba, ByteDance, MiniMax는 input token이 32K, 128K, 200k, 256K, 272K 또는 512k 기준을 넘으면 output을 포함한 요청 전체의 요금을 다시 계산한다. 이 글에서는 실제 청구 내역, 그 배경이 되는 구간별 요금표, 요청을 기준 아래로 유지하는 설정을 차례로 살펴본다.

TL;DR

• 가격 하나만 표시하는 aggregator를 통해 구간별 요금이 있는 모델 9개를 측정한 결과, vendor 기준을 넘으면 1.8배에서 6.7배가 청구됐다. Azure를 통한 GPT-5.6 Luna는 표시가의 1.25배가 청구됐다.
• qwen3.7-flash는 32K와 256K에서 input 100만 token당 $0.03, $0.10, $0.20를 청구했다. qwen3-coder-plus는 vendor가 6배를 명시한 구간에서도 3배에서 멈췄다.
• input이 32K에서 512k token 사이의 기준을 넘으면 vendor는 output을 포함한 요청 전체의 요금을 다시 계산한다.
• output이 아니라 input을 제한해야 한다. Claude Code /autocompact, Codex model_context_window, API compaction trigger를 사용하면 된다.

Gateway는 페이지에 표시한 가격대로 청구하는가?

prompt가 길어지면 그렇지 않다. 차이가 얼마나 되는지 확인하려면 intermediary마다 두 가지가 필요하다. gateway가 공개한 pricing metadata와 기준 전후 요청에 실제로 보고한 비용이다.

한 대형 multi-provider aggregator는 catalog에 pricing.overrides 배열을 공개한다. 여기에는 기본 가격과 min_prompt_tokens: 200000 같은 조건부 규칙, 조건이 적용될 때의 높은 요금이 들어 있다. DeepSeek와 Tencent 모델에는 비혼잡 시간대 가격을 위한 utc_start / utc_end 구간도 있다. 2026-09-01에 가져온 catalog에서는 60개 항목에 override가 있었다. Gemini Pro 모델, Grok 4.x, qwen3.7-plus, qwen3.7-flash, qwen3-coder-plus, Seed 2.0 모델, 272,000 기준이 있는 GPT-5.6 전체 제품군이 포함됐다. 모델 페이지에는 기본 가격만 표시되고, 구간 정보는 metadata에만 있다. 이 metadata도 vendor의 전체 구간표와 같지는 않다. qwen3-coder-plus에는 32,000과 128,000 규칙이 있지만 vendor의 네 번째 구간인 256K 규칙은 없다.

이에 따라 usage accounting을 활성화하고 해당 aggregator를 통해 문서에 나온 모든 기준의 전후로 요청을 보냈다. aggregator는 response 안에 실제 청구 금액을 반환한다. serving endpoint도 기록했다. aggregator의 모델 id 하나가 가격이 서로 다른 여러 upstream host를 가리킬 수 있으며, aggregator는 이를 endpoint라고 부른다. 각 지점에서 2회씩, 2026-09-02와 2026-09-03에 실행했다.

invoice와 같은 날 캡처한 실제 페이지에는 대표 가격 하나와 endpoint별 표만 있었고, 두 페이지 모두 길이 구간은 표시하지 않았다. 모든 청구 금액은 token 단위까지 metadata와 일치했다. 9개 모델 모두 vendor의 첫 기준에서 vendor가 정한 배수만큼 올랐다. Alibaba 모델 3개의 invoice에는 페이지에 없는 구간별 인상이 적용됐다. qwen3.7-flash는 32K에서 $0.03에서 $0.10으로, 256K에서 다시 $0.20로 올랐다. $0.03만 표시된 페이지 가격의 6.7배다. GPT-5.6 Luna도 기준에서 가격이 올랐으며, 별도의 차이도 있었다. Azure가 제공한 모든 실행은 기준 전후와 관계없이 표시된 Azure endpoint 가격보다 1.25배 높게 청구됐다. $0.22 대신 $0.275, $0.40과 $0.44 대신 $0.50과 $0.55였다. 이 surcharge는 페이지에도 endpoint metadata에도 없다.

aggregator의 요금 구간이 vendor보다 일찍 끝날 수도 있다. qwen3-coder-plus는 32K에서 1.8배, 128K에서 3배로 올랐지만 276k tokens까지 100만 개당 $1.95로 유지됐다. Alibaba의 공식 가격표에서는 이 구간에서 input $6, output $60으로 오른다. 각각 기본 가격의 6배와 12배다. aggregator metadata에는 256K 규칙이 없어서 실제 청구액도 변하지 않았다. aggregator가 차액을 부담하는지, 다른 계약으로 구매하는지는 외부에서 확인할 수 없다. 확인 가능한 사실은 invoice가 metadata를 따르며, metadata와 페이지는 서로 다른 문서라는 점이다.

투명성의 문제는 metadata와 invoice 사이가 아니라 페이지와 나머지 둘 사이에 있다. 페이지의 대표 가격은 아래 표에 나온 endpoint 중 가장 저렴한 요금일 뿐, 실제 요청을 처리할 endpoint의 요금이 아니다. 어느 가격에도 길이 조건은 포함되지 않는다. 가격 하나만 있는 model card로는 구간별 요금, 다음 요청을 처리할 endpoint, 현재 계정에서 해당 가격의 endpoint를 사용할 수 있는지 알 수 없다.

확인 방법은 간단하다. 사용하는 모델의 machine-readable pricing을 endpoint 단위로 읽고 길이 조건이 있는지 확인한다. 그다음 usage accounting을 켜고 기준 전후로 요청을 하나씩 보내 보고된 비용을 비교한다. 페이지에 표시하지 않은 vendor 규칙을 그대로 넘기는 gateway라면 해당 기준에서 청구액이 오른다. vendor 가격이 오르는 지점에서도 gateway 청구액이 그대로라면 가격이 다른 host에서 모델을 제공하거나 차액을 부담하는 것이다. 이 중 안정적으로 유지될 수 있는 경우는 전자뿐이다.

기준은 어디에 있고, 구간별 요금은 어떻게 적용되는가?

6개 vendor가 길이 기준을 공개한다. 규칙이 명시된 모든 모델은 기준을 넘으면 output을 포함한 요청의 모든 token에 높은 요금을 적용한다. 대부분의 첫 기준에서는 2배지만, 상위 구간으로 갈수록 더 오른다. qwen3.7-plus는 유일한 기준에서 3배다. qwen3.7-flash는 세 번째 구간에서 input이 6.7배다. qwen3-coder-plus의 네 번째 구간은 input 6배, output 12배다. 가격은 token 100만 개 기준이며, 2026-09-01에 vendor pricing page에서 가져왔다.

billing code에 그대로 반영해야 할 경계 조건이 두 가지 있다. Google의 두 페이지는 1 token 차이로 설명이 다르다. Vertex 각주는 “200K 이상”이라고 하지만 Gemini API pricing table은 “prompts > 200k tokens”라고 한다. Alibaba는 K를 정확히 정의한다. 128K는 128,000 tokens, 256K는 256,000이며 2의 거듭제곱 기준이 아니다.

구간은 input 길이만으로 결정되며 output을 포함한 요청 전체 token에 적용된다. 따라서 기준을 넘기는 마지막 token의 한계비용에는 그 앞에 있는 모든 token의 할증분이 포함된다. Gemini 2.5 Pro에서 199,999-token prompt의 input 요금은 $0.25다. 200,001 tokens가 되면 $0.50이며, 4,000-token 답변은 $0.04에서 $0.06으로 오른다. token 하나가 늘면서 비용은 $0.27 증가한다.

qwen3.7-plus에서는 3배로 오른다. 공식 요금 기준으로 255,029-token prompt는 $0.102, 257,332-token prompt는 $0.309다. qwen3-coder-plus는 같은 방식이 4개 구간에 걸쳐 누적된다. 따라서 260k-token prompt는 30k prompt보다 token당 input 요금이 6배, output 요금이 12배다.

이 규칙은 vendor 표뿐 아니라 실제 invoice에서도 확인된다. qwen3.5-plus의 공식 input 요금은 256K를 기준으로 100만 token당 $0.40에서 $0.50로 오른다. gateway invoice에서 기준 미만 10회 실행은 243k tokens였고, 기준 초과 24회는 256k에서 321k tokens였다. 두 그룹의 input token당 청구액 차이는 정확히 1.25배였으며 output 가격은 변하지 않았다. 259k 요청은 마지막 3k tokens에만 1.25배를 지불한 것이 아니라 전체 token에 1.25배를 지불했다.

history가 누적되는 agent에서는 session 도중 조용히 기준을 넘는다. 기준을 처음 넘긴 turn부터 이전 모든 turn을 포함한 전체 context에 할증이 붙는다. 이후에도 context를 줄이기 전까지 모든 turn에 계속 높은 요금이 적용된다.

성능도 같은 기준에서 달라지는가?

아니다. 요금 기준을 성능의 경계로 오해하기 쉽지만 둘은 무관하다. 이를 확인하기 위해 256K 기준이 있는 Qwen 모델 2개를 측정했다. 매 실행마다 임의 code를 붙인 한 줄짜리 사실인 salted needle을 5개 깊이에 삽입했다. thinking을 끈 상태에서 243k, 269k, 320k tokens로 측정했으며, 두 모델 모두 각 길이에서 30회 중 30회 정확히 recall했다. latency는 특정 지점에서 급증하지 않고 길이에 따라 선형으로 증가했다. qwen3.7-plus의 중앙값은 15.2 s, 17.0 s, 20.5 s였다. 전체 log에 드물게 삽입한 K개의 항목을 세는 더 어려운 작업은 길어질수록 성능이 떨어졌다. qwen3.7-plus에서 찾은 비율은 128k의 74%에서 192k의 60%, 243k의 58%, 320k의 45%로 감소했다. 하락은 요금 기준보다 훨씬 전부터 시작되며, 기준 양쪽의 측정값도 같은 기울기 위에 있다.

Anthropic 문서에서는 이 점진적인 현상을 명확히 설명한다. token 수가 늘수록 정확도와 recall이 떨어지며, 이를 “context rot”이라고 한다. 실제로 발생하는 현상이지만 연속적이며, 요금 기준과는 무관하다.

요청을 기준 아래로 유지하려면 어떻게 해야 하는가?

output이 아니라 input을 제한해야 한다. 구간은 요청의 input 길이로 결정되므로 output 상한인 max_tokens는 아무 효과가 없다. client가 보내는 양을 제한하는 설정을 사용해야 하며, 4개 layer에 걸쳐 이런 설정이 제공된다.

layer별로 prompt를 제한하는 설정은 다음과 같다. “구간 미만 유지”는 절대 token 수를 지정할 수 있어 가격 기준 바로 아래로 설정 가능한 항목을 뜻한다. window 대비 비율을 쓰는 설정은 모델의 context window 안에만 유지한다. context window 크기와 요금 기준은 서로 다른 값이다.

이 표에서 두 가지를 알 수 있다. 구간별 요금이 있는 모델을 coding agent에서 사용할 때는 compaction window가 급격한 요금 상승 대신 요약을 실행하게 만드는 설정이다. 1M window의 비율이 아니라 요금 기준 바로 아래의 절대 token 수로 지정해야 한다. 흔히 쓰는 두 가지 “안전” 설정인 Responses truncation: "auto"와 aggregator의 middle-out은 window guard일 뿐이다. 구간별 요금이 있는 Gemini와 GPT-5.6 모델에서는 1M인 모델 window에서 작동하며, 가격이 오르는 200,000 또는 272,000 tokens에서는 작동하지 않는다. 요청 실패는 막아도 요금 기준을 넘는 것은 막지 못한다.

기준 미만을 유지할 목적으로 caching에 의존하면 안 된다. Prompt caching은 비용을 줄이지만 Google 모델의 구간 판정에는 영향을 주지 않는다. Google은 cache read에도 같은 길이 구간별 요금을 적용한다. cache된 150k prefix와 새 context 60k를 합치면 210k prompt이며, 하나의 요청으로 청구된다. Provisioned capacity는 이 문제 자체를 피한다. provisioned throughput unit(PTU)은 token 수와 관계없이 시간당 과금되기 때문이다. 기준을 넘길 가치가 있다면 의도적으로 넘겨야 한다. 위 측정 결과에서 모델 성능은 기준에서 나빠지지 않았다. 판단 기준은 추가 context가 요청 전체에 적용되는 2배, 3배, 최상위 구간에서는 6.7배의 비용을 감수할 가치가 있는지뿐이다.

Synthorai의 처리 방식

길이 구간은 요금 조건이므로 gateway도 이를 요금 조건으로 처리한다. 모델의 price card에는 input-token 경계를 key로 하는 구간 목록을 넣을 수 있다. 각 요청은 자체 prompt 길이가 선택한 구간에 따라 모든 token의 요금을 계산한다. vendor의 계산 방식과 같다. 앞서 본 qwen3.5-plus invoice도 이 방식으로 처리됐다. usage record에는 계산된 비용과 함께 prompt token 수와 가격 version을 보관한다. 따라서 bill을 다시 분석해 “이 요청이 기준을 넘었다”는 사실을 확인할 수 있다. 요청에 적용된 구간은 price table뿐 아니라 usage record에서도 확인할 수 있다.

FAQ

긴 컨텍스트의 높은 요금은 기준을 넘은 token에만 적용되는가?

아니다. 규칙을 문서화한 모든 vendor는 요청 전체의 요금을 다시 계산한다. Google은 “모든 token에 long context 요금이 적용되며 input과 output을 모두 포함한다”고 명시한다. OpenAI는 “요청 전체”, xAI는 “요청의 모든 token”, Alibaba는 “요청의 모든 token은 해당 구간의 단가로 청구된다”고 설명한다. prompt가 기준을 단 1 token 넘겨도 그 앞의 모든 token에 할증이 붙는다.

API gateway는 긴 컨텍스트 구간별 요금을 그대로 적용하는가?

이번 측정에서는 그렇다. 대형 aggregator 하나를 통해 측정한 모델 9개는 가격 하나만 표시된 모델 페이지와 달리, vendor 기준을 넘자 vendor의 높은 요금으로 청구됐다. 구간 정보는 페이지가 아니라 gateway의 pricing metadata에 있다. metadata에서 vendor 구간이 빠질 수도 있다. qwen3-coder-plus의 256K 초과 구간이 그 사례다.

max_tokens로 요청을 요금 기준 아래에 유지할 수 있는가?

아니다. max_tokens는 output을 제한하고, 구간은 input 길이로 결정된다. 도움이 되는 설정은 prompt를 제한하는 기능이다. agent의 compaction window 또는 token limit(Claude Code /autocompact, Codex model_context_window), API의 compaction trigger, 요청 전 client-side truncation을 사용해야 한다.

요금 기준에서 모델 품질도 떨어지는가?

이번 측정에서는 그렇지 않았다. 구간별 요금이 있는 Qwen 모델 2개에서 needle recall은 256K 기준의 양쪽 모두 완벽했다. counting task의 성능은 길이에 따라 점진적으로 떨어졌지만 같은 기준에서 급격한 변화는 없었다. 구간별 요금은 비즈니스 규칙이다. 길이에 따른 성능 저하는 실제로 발생하지만 연속적이다.

가격과 적용 방식은 2026-09-01에 가져온 vendor pricing page를 기준으로 했다. agent와 API 설정은 2026-09-02 기준 링크된 문서에서 확인했다. invoice 측정은 thinking을 끄고 salted prompt를 사용해 2026-09-01부터 2026-09-03까지 진행했으며, aggregator의 각 지점에서 2회 실행했다. 가격은 바뀔 수 있다. billing code에 기준을 반영하기 전에 링크된 원문을 확인해야 한다.

관련 글: billing unit 필드 가이드 (이 글에서 자세히 다룬 modifier layer), token usage 구조, prompt caching 설명, cache minimum 실측.

← 블로그로 돌아가기