Gemini 4 Argon의 출력 100만 토큰, 이 모드에서만 되고 12월엔 가격도 두 배

출력 100만 토큰짜리 요청 한 건을 보내면 청구서에는 얼마가 찍힐까요? 출력 단가가 100만 토큰당 $10이니 $10 남짓이라고 답하기 쉽지만, 같은 요청이 약 $11이 될 수도, 약 $26이 될 수도 있고, 12월 1일 이후라면 $52를 넘길 수도 있습니다. 차이를 만드는 것은 서버가 64K씩 이어 쓰는 도약마다 앞 내용이 입력으로 다시 청구되는 구조와, 그 반복 입력이 캐시에 얼마나 맞느냐입니다. 이 글은 Google이 문서에서 든 네 번 도약의 예를 그대로 늘려서, 출력 길이별 청구서를 계산하고 어디서부터 입력 비용이 출력 비용을 넘는지, 장 단위로 쪼개면 얼마나 싸지는지, 중간에 끊기면 얼마가 나오는지를 숫자로 보입니다. 단가와 한도는 2026-10-27 UTC에 개발자 문서의 가격 페이지(10월 22일 갱신)와 모델·긴 출력 가이드에서 다시 확인한 값입니다.

청구서를 뽑기 전에 정해 둘 전제

Gemini 4 Argon(gemini-4-argon)은 10월 13일 일반 공개된 안정 버전이고 유료 등급에서만 API를 쓸 수 있습니다. 컨텍스트 창 1,048,576 토큰은 입력·생각·출력이 함께 쓰며, 기본 출력 한도는 65,536 토큰입니다. 그 이상을 쓰려면 Interactions API에서 백그라운드 실행(background: true)과 저장(store: true)을 켜고 max_output_tokens를 65,536보다 크게 지정해야 합니다. 그러면 서버가 한 번에 최대 64K 토큰, 즉 도약(hop) 하나씩 이어 씁니다. 아래 계산은 이 모드를 전제로 합니다.

단가, 지금

표준 등급, 100만 토큰당 입력 $2 · 출력(생각 포함) $10 · 캐시 입력 $0.10

단가, 12월 1일부터

세 항목 모두 두 배: $4 · $20 · $0.20

도약 크기

생각과 출력을 합쳐 최대 65,536 토큰

프롬프트

1,000 토큰. 문서의 네 번 도약 예와 같은 값

출력 상한

1,048,576 − 입력. 프롬프트가 1,000이면 1,047,576 토큰, 도약 16번

캐시 적중

첫 도약의 프롬프트는 정가, 이후 도약의 입력은 전부 캐시 단가

캐시 미적중

모든 도약의 입력을 정가로 계산

캐시 적중과 미적중은 실제 청구서가 놓일 두 경계입니다. 문서는 반복되는 도약 입력에 암시적 캐싱이 95%를 깎아 준다고 적었고, 실제로 얼마나 맞는지는 응답의 usage.total_cached_tokens에 찍힙니다. 이 글의 모든 달러 값은 위 전제로 편집부가 계산한 값입니다.

한 도약이 입력으로 다시 읽는 것

계산의 뼈대는 하나입니다. 도약 i번째의 입력은 프롬프트에 앞선 모든 도약의 출력을 더한 값이고, 청구서는 이 입력들을 전부 더합니다. 문서가 든 예는 프롬프트 1,000 토큰에 생각과 출력이 20만 토큰인 요청입니다. 네 번의 도약에서 입력이 1,000, 66,536, 132,072, 197,608 토큰이고 합계가 397,216 토큰입니다.

도약마다 무엇이 들어가고 무엇이 나오는지 그림으로 먼저 봅니다. 노란 점선이 프롬프트가 매번 다시 실리는 길이고, 도약 사이의 실선이 앞 도약의 출력이 다음 입력으로 쌓이는 길입니다.

그림 1. 네 번 도약: 입력은 1,000에서 197,608까지 늘고 새로 쓰는 양은 매번 65,536(마지막만 3,392)

마지막 도약은 입력이 197,608이어도 새로 쓰는 것은 3,392 토큰뿐입니다. 입력이 가장 크고 출력이 가장 작은 도약인 셈이라, 요금 면에서 가장 비효율적인 구간이 맨 끝에 놓입니다. 이 구조에서 일반식이 나옵니다. 도약 수를 k, 프롬프트를 P, 도약 크기를 H(65,536)라 하면 입력 합계는 k×P + H×k×(k−1)÷2입니다. P가 1,000이고 k가 4이면 4,000 + 65,536×6으로 397,216이 되어 문서의 값과 정확히 일치합니다.

입력 합계가 출력보다 빨리 자라는 곡선

출력은 도약 수에 비례해서 늘지만 입력 합계는 도약 수의 제곱에 가깝게 늘어납니다. 도약이 두 배가 되면 입력 합계는 네 배 안팎이 됩니다. 아래 그림에서 파란 직선이 실제 컨텍스트이고, 주황 곡선이 청구서에 올라가는 입력 합계입니다.

그림 2. 도약 16번에서 청구되는 입력은 788만 토큰, 실제 컨텍스트는 105만 토큰(편집부 계산)

두 선은 도약 세 번 근처(출력 약 20만 토큰)까지는 거의 붙어 있다가 그 뒤로 벌어집니다. 네 번 도약에서 입력 합계가 컨텍스트의 1.5배, 여덟 번에서 3.5배, 열여섯 번에서 7.5배입니다. 문서가 total_input_tokens로 컨텍스트 압축 시점을 정하지 말라고 하는 까닭도 여기 있습니다. 이 값은 컨텍스트의 크기가 아니라 청구의 크기에 가깝습니다.

입력 단가가 출력의 5분의 1이라는 점이 이 곡선을 한동안 가려 줍니다. 캐시가 전혀 맞지 않는 최악의 경우에도 출력 비용이 입력 비용을 앞서다가, 11번째 도약(출력 약 72만 토큰)에서 처음으로 재입력의 누적 비용이 $7.23으로 출력의 $7.21을 넘습니다. 그 뒤로는 도약을 더할수록 청구서의 큰 쪽이 입력이 됩니다.

길이 다섯 가지로 뽑은 청구서

같은 식을 출력 길이 다섯 가지에 넣었습니다. 65,536은 기본 한도 안이라 긴 출력이 필요 없는 길이이고, 262,144는 문서가 어려운 추론에서 시작하라고 권한 값입니다. 입력 합계는 도약 수가 정하고 단가는 곱하기만 하므로 표의 토큰 수는 12월 1일 이후에도 그대로이고, 달러만 두 배가 됩니다.

생각+출력 토큰	도약	입력 합계 토큰	출력 비용	입력 비용(전부 정가)	입력 비용(반복분 캐시)
65,536	1	1,000	$0.66	$0.002	$0.002
131,072	2	67,536	$1.31	$0.14	$0.01
262,144	4	397,216	$2.62	$0.79	$0.04
524,288	8	1,843,008	$5.24	$3.69	$0.19
1,047,576	16	7,880,320	$10.48	$15.76	$0.79

표의 두 입력 열을 출력 열과 더해 지금과 12월 1일의 청구서로 만든 것이 아래 그림입니다. 막대 네 개가 한 요청의 서로 다른 청구서입니다. 위의 둘이 지금 단가, 아래의 둘이 12월 1일 단가이고, 각 쌍에서 짧은 쪽이 캐시 적중, 긴 쪽이 미적중입니다.

그림 3. 길이가 길수록 적중·미적중의 간격이 벌어진다(편집부 계산, 표준 등급)

한 도약으로 끝나는 첫 줄은 적중이든 미적중이든 청구서가 같습니다. 입력이 프롬프트 한 번뿐이기 때문입니다. 간격은 도약이 늘수록 벌어져서 262K에서 $0.76, 524K에서 $3.50, 1M급에서 $14.97(지금 단가)입니다. 12월 1일이 되면 이 간격도 두 배가 되어 1M급의 간격은 약 $30입니다. 외부 평가 기관 Artificial Analysis는 Argon이 한 작업에 쓰는 출력 토큰을 평균 약 62K로 집계했는데, 이는 도약 하나(65,536)에 들어가는 크기라 이 표의 첫 줄에 해당합니다. 그 지수의 작업들은 평균적으로 긴 출력 모드의 비용 구조 바깥에 있습니다.

프롬프트가 더 길면 상한이 줄어듭니다. 프롬프트가 5만 토큰이면 출력 상한은 998,576 토큰, 도약 16번이고, 같은 계산으로 청구서는 캐시 적중 때 약 $10.95, 미적중 때 약 $27.31입니다. 프롬프트가 길어도 도약 수는 그대로라 총액이 크게 달라지지 않습니다.

100만 토큰급 한 건을 층별로 쌓아 보기

16번 도약의 청구서가 어떤 층으로 쌓이는지 봅니다. 맨 아래가 출력과 생각 토큰의 $10.48이고, 그 위에 캐시가 전부 맞았을 때의 재입력이 $0.79 얹혀 약 $11.27이 됩니다. 캐시가 전혀 맞지 않으면 재입력 비용이 $15.76이라 약 $14.97이 더 붙어 $26.24가 되고, 12월 1일에는 이 전체가 두 배가 됩니다.

그림 4. 16번 도약의 청구서가 $10.5에서 $52.5까지 쌓이는 순서(편집부 계산)

가장 큰 층은 12월 1일의 두 배입니다. 그다음이 캐시가 맞느냐 아니냐이고, 이 두 층은 요청을 어떻게 짜느냐와 상관없이 정해집니다. 출력 층은 맨 아래에 있지만 가장 단단합니다. 모델이 쓴 토큰은 생각이든 눈에 보이는 답이든 같은 단가이고, 생각만 하고 비어 있는 도약도 청구됩니다. 줄이고 싶다면 max_output_tokens를 깎는 대신 thinking_level을 내리라는 것이 문서의 권고입니다. 한도는 생각과 출력을 합친 값이라 한도만 깎으면 생각이 한도를 먼저 채워 빈 답이 돌아올 수 있습니다.

캐시 적중률이 35%를 넘어야 하는 이유

적중률이 청구서를 가르는 크기를 숫자로 찍어 보면 이렇습니다. 16번 도약에서 반복되는 입력 7,879,320 토큰 중 캐시에서 읽히는 몫을 f라 하면, 입력 비용은 정가분(1−f)×$2에 캐시분 f×$0.10을 곱해 더한 값입니다. 적중률 0%면 총 $26.24, 50%면 $18.75, 90%면 $12.76, 100%면 $11.27입니다.

재입력 비용이 출력 비용 $10.48과 같아지는 지점은 f가 약 35%일 때입니다. 적중률이 이보다 낮으면 청구서에서 입력이 출력보다 큰 층이 됩니다. 출력만 보고 예산을 잡았다면 그 예산은 적중률 35% 이상일 때만 지켜집니다.

적중이 일어나는 조건은 캐싱 문서에 정해져 있습니다.

• 최소 길이. 암시적 캐시는 프롬프트가 4,096 토큰 이상일 때 적용됩니다. 도약 1의 1,000 토큰짜리 프롬프트는 캐시 대상이 아니고, 도약 2부터는 입력이 66,536 토큰이라 대상이 됩니다.
• 멀티턴. 대화가 이어지는 호출은 새 요청이 2,050 토큰 이상 더해질 때 앞 전체가 캐시됩니다.
• 명시적 캐시 없음. 이 모델은 명시적 캐시(cachedContents)를 지원하지 않습니다. 적중을 내가 보장할 수단이 없고 암시적 캐시가 맞기를 바라는 수밖에 없습니다.
• 유휴 시간. GenerateContent API의 긴 출력 가이드는 15~20분 동안 쓰지 않은 캐시가 만료된다고 적었습니다. 도약 사이가 그보다 벌어지면 적중률이 떨어집니다.

실제 적중률은 응답이 돌려주는 사용량에서 계산합니다. 앞 절의 표처럼 반복 입력의 총량을 식으로 구한 뒤 total_cached_tokens를 나누면 됩니다. 이 계산은 마지막 절의 코드에 넣어 두었습니다.

장 단위로 쪼갰을 때의 손익분기

긴 출력이 비싼 이유가 입력 재전송이라면 쪼개서 요청하는 방법을 생각할 수 있습니다. 문서는 모델이 단어 수나 토큰 수 목표를 따르지 않는다고 적었으니, 분량을 통제하기에도 나누는 쪽이 다루기 쉽습니다. 아래는 편집부의 가정입니다. 65,536 토큰짜리 요청 16번을 따로 보내고, 요청마다 프롬프트 1,000 토큰에 앞 장까지의 개요와 요약 5,000 토큰을 붙인다고 둡니다. 입력은 모두 합해 96,000 토큰이고 정가로 $0.19, 출력은 같은 $10.48이라 총 약 $10.67입니다.

이 값은 긴 출력의 캐시 적중 $11.27보다 약 $0.60 싸고 미적중 $26.24보다는 약 $15.6 쌉니다. 요청마다 넘기는 앞 장 내용이 N 토큰일 때의 손익분기도 계산할 수 있습니다. N이 약 2만 4천 토큰이면 정가로 넘기는 입력 때문에 총액이 캐시가 완벽히 맞은 긴 출력과 같아지고, 약 49만 토큰이면 캐시가 전혀 안 맞는 긴 출력과 같아집니다. 요약이나 개요 정도만 넘기는 작업이라면 쪼개는 쪽이 어느 경우에도 비슷하거나 쌉니다.

비용만 놓고 한 계산이라는 점은 짚어야 합니다. 증명이나 긴 코드처럼 앞 내용을 통째로 이어받아야 하는 작업은 요약만으로 이어 쓰면 일관성이 깨질 수 있고, 그 작업에 긴 출력이 있는 것입니다. 쪼갤 수 있는지는 비용이 아니라 작업의 성격이 정합니다.

도중에 끊기거나 생각만 한 구간의 요금

청구는 끝까지 가야만 생기지 않습니다. 긴 출력 가이드는 모든 도약에 요금이 붙고, 생각만 한 도약도 포함된다고 적었습니다. 여기에 실패와 취소 규칙이 더해집니다.

GenerateContent API는 규칙이 다릅니다. 클라이언트가 직접 이어 쓰는 이 경로에서 실패한 비스트리밍 도약은 무료이고, 스트림이 32K 전에 끊기면 무료이지만 그 이후에 끊기면 마지막 체크포인트까지 청구됩니다. 이 경로의 한도는 스트리밍과 SDK가 64K, 비스트리밍 REST가 32K이고 요청 하나가 최대 20분입니다.

12월 1일 이후의 단가표와 평범한 호출의 하루치 청구서

단가는 등급마다 다르고, 12월 1일에 모든 등급이 두 배가 됩니다. 아래가 가격 페이지의 유료 등급 표입니다(100만 토큰당 달러).

등급	입력	출력(생각 포함)	캐시 입력
표준	$2 → $4	$10 → $20	$0.10 → $0.20
배치	$1 → $2	$5 → $10	$0.05 → $0.10
Flex	$1 → $2	$5 → $10	$0.05 → $0.10
우선(Priority)	$3.60 → $7.20	$18 → $36	$0.18 → $0.36
Contributor(초대 전용 미리보기)	$1 → $2	$5 → $10	$0.05 → $0.10

표에서 두 가지가 눈에 띕니다. 먼저 12월 이후의 배치·Flex 단가가 지금의 표준 단가와 같습니다. 기다려도 되는 작업을 이 등급으로 돌리면 인상분을 상쇄할 수 있습니다. 다음으로 이 모델에는 긴 출력만을 위한 별도 단가도, 컨텍스트 길이 구간별 단가도 없습니다. 위 계산이 전부 같은 단가표에서 나오는 까닭이고, 긴 출력이 비싸 보이는 것은 단가 때문이 아니라 토큰 수 때문입니다. Contributor 등급은 데이터가 제품 개선에 쓰이고 단가가 표준의 절반이며, 표준 등급의 데이터는 쓰이지 않습니다. 검색·지도 근거는 월 5,000건까지 무료이고 그 뒤 1,000건당 $14이며 12월에도 그대로입니다.

긴 출력을 쓰지 않는 서비스의 청구서도 같은 방식으로 계산합니다. 아래는 편집부의 가정입니다. 하루 1,000건을 호출하고 건당 입력 2만, 출력(생각 포함) 2천 토큰이며, 앞의 1만 5천 토큰이 매번 같은 프롬프트라 캐시에 맞는다고 둡니다. 캐시가 없으면 하루 입력이 $40, 출력이 $20이라 $60이고 30일에 $1,800입니다. 캐시가 맞으면 입력이 $10(비캐시 500만 토큰)에 $1.5(캐시 1,500만 토큰)를 더한 $11.5로 줄어 하루 $31.5, 30일에 $945입니다. 12월 1일부터는 각각 $3,600과 $1,890이 됩니다. 이 경우에는 캐시가 청구서를 절반으로 줄이는 가장 큰 수단이고, 긴 출력과 달리 출력이 입력보다 작은 층이라 인상분이 고스란히 두 배로 옵니다.

내 요청 로그로 같은 식을 돌리는 계산기

앞의 계산을 코드로 옮기면 내 요청의 평균 입력·출력(생각 포함) 토큰으로 지금과 12월 1일의 청구서를 한 번에 뽑을 수 있습니다. 도약 크기와 단가만 바꾸면 다른 등급에도 쓸 수 있습니다.

import math

H = 65_536  # 도약 하나의 생각+출력 최대 토큰

def bill(prompt, thought_output, p_in=2.0, p_out=10.0, p_cache=0.10):
    """100만 토큰당 달러. 반환: (도약 수, 입력 합계, 출력 비용, 정가 합계, 캐시 적중 합계)"""
    hops = max(1, math.ceil(thought_output / H))
    total_in = hops * prompt + H * hops * (hops - 1) // 2
    repeated = total_in - prompt                      # 첫 도약 이후에 다시 들어가는 입력
    out = thought_output * p_out / 1e6
    miss = out + total_in * p_in / 1e6
    hit = out + (prompt * p_in + repeated * p_cache) / 1e6
    return hops, total_in, out, miss, hit

print(bill(1_000, 262_144))            # (4, 397216, 2.62, 3.42, 2.66)
print(bill(1_000, 1_047_576))          # (16, 7880320, 10.48, 26.24, 11.27)
print(bill(1_000, 1_047_576, 4, 20, 0.20)[3:])   # 12월 1일 단가: (52.47, 22.53)

식에 넣을 값은 응답의 usage에서 얻습니다. Interactions API에서는 total_output_tokens와 total_thought_tokens를 더한 값이 생각+출력이고, 입력은 total_input_tokens가 이미 도약마다 합산된 값입니다. 따라서 total_input_tokens가 위 식의 total_in과 가깝게 나오는지가 계산이 맞는지의 점검이 됩니다. 캐시가 실제로 맞았는지는 total_cached_tokens를 위 식의 repeated로 나눈 값이 적중률이고, 이 값이 35%를 밑돌면 입력이 출력보다 큰 청구서가 나옵니다. GenerateContent API에서 쓰는 경우에는 prompt_token_count가 도약을 합산한 값이므로 initial_prompt_token_count를 프롬프트 값으로 씁니다. 모델이 열려 있는 프로젝트인지는 모델 목록을 읽는 요청으로 확인할 수 있습니다(읽기 전용, 키는 환경 변수).

curl -s -H "x-goog-api-key: $GEMINI_API_KEY" "https://generativelanguage.googleapis.com/v1beta/models" | grep -i argon

무료 키로 호출하면 할당량 0으로 429 오류가 난다고 외부 매체가 확인했으니, 결제가 연결된 유료 프로젝트인지부터 보면 됩니다.