
usage_metadata로 계산한 Gemini API 요금, 정말 맞을까? 【검증】
요약
Gemini API의 `usage_metadata`를 이용한 비용 계산 시, 사고 토큰(thought token)이 `candidates_token_count`에 포함되지 않고 별도로 카운트된다는 사실을 검증했습니다. 정확한 출력 비용을 계산하기 위해서는 `candidates_token_count`와 `thoughts_token_count`를 합산하여 계산해야 합니다.
핵심 포인트
- Gemini API의 사고 토큰(thought token)은 출력 토큰(candidates)에 포함되지 않고 별도로 집계됨
- 정확한 출력 비용 계산식: (candidates_token_count + thoughts_token_count) × 출력 단가
- 사고 토큰은 출력 토큰과 동일한 단가로 과금됨
- gemini-1.5-pro 모델 등은 200k 토큰을 기준으로 입력 및 출력 단가가 변동되는 메커니즘이 있음
여러분은 Gemini API의 비용을 직접 계산해 본 적이 있는가.
나는 업무에서 Gemini API를 사용하기 시작하면서, 응답(response)의 usage_metadata에서 토큰 수(token count)를 추출하여 비용을 계산하고 있었다.
사용하기 시작한 지 2주. 요금을 확인해 보니, 스스로 토큰 수로부터 산출한 로그상의 비용과 실제 비용이 크게 괴리되어 있었다...
이번에는 이 수수께끼에 다가가 보려 한다.
Gemini API에서는 response 안에 사용된 토큰 수가 포함되어 있다.
이 토큰 수가 API 이용 금액을 좌우하는 모양이다...
※Gemini API 이용 요금: Gemini API 요금
meta = response.usage_metadata
meta.prompt_token_count # 입력 토큰 (input token)
meta.candidates_token_count # 출력 토큰 (output token)
...
Gemini API의 요금을 보고 있다 보니, 미묘한 표현이 하나 있었다.
출력 요금 (사고 토큰 (thought token) 포함)
나는 처음에 이것을 보았을 때,
candidates_token_count(출력 토큰)에 thoughts_token_count(사고 토큰)가 포함되는구나!
라고 생각했다. 그렇게 생각하고 말았다. 즉 계산식으로는 다음과 같다.
prompt_token_count × 입력 단가 + candidates_token_count × 출력 단가
사고 토큰은 candidates에 포함되어 있다고 생각했기에 제외하고 있었다.
실제 상황은 후술한다.
검증용 코드는 다음과 같다. 모델은 최신인 gemini-3.1-pro-preview로 검증했다.
※이 코드는 사고 토큰을 고려하지 않은 당시의 버전이다. 올바른 계산 코드는 후술한다.
import json
import os
from datetime import datetime, timezone
...
시도한 프롬프트(prompt)와 그 응답(response)
(프롬프트)
일본의 수도는 어디인가요? 한 마디로 대답해 주세요.
(응답)
...
print 내용은 다음과 같다.
==================================================
[usage_metadata]
prompt_token_count : 14
...
14 + 3 + 77 = 94가 되어 있다. 즉 candidates와 thoughts는 별도 카운트.
(속마음: "문서에는 'Gemini API에서는 candidates에 포함된다'라고 적혀 있었는데...")
사고 토큰은 출력 토큰과 동일한 단가로 과금된다. 따라서 올바른 출력 비용 계산식은 다음과 같다 ↓
출력 비용 = (candidates_token_count + thoughts_token_count) × 출력 단가
내가 하고 있던 계산은 사고 토큰 분량이 빠져 있었다...
사고 비용이 요금에 포함된다고 가정하면, 총 이용 금액은 앞선 예시의 경우
총 이용 금액 = (prompt_token_count/1000000 * 2 ) + ((candidates_token_count + thoughts_token_count)/1000000 * 12)
= 0.000988(달러)
2026/5 환율은 1달러당 159.03엔.
따라서
0.000988 * 159.03 = 0.157(엔)
올림하여 0.16엔이 되며, 이것으로 계산은 맞는 것 같다!
gemini-3.1-pro-preview에는 200k 토큰을 기점으로 단가가 변하는 메커니즘이 있다.
| ≤200k 토큰 | >200k 토큰 |
|---|---|
| 입력 | $2.00/1M 토큰 |
| 출력 | $12.00/1M 토큰 |
여기서 주의가 필요한 점은, 이 임계값(threshold)은 월간 누적이 아니라 1 리퀘스트(request)당 판정이라는 점이다.
다만, 나는 200k 토큰을 초과하는 리퀘스트를 실제로 시도해 보지는 않았다.
조사한 바로는 "초과한 분량만이 아니라 리퀘스트 전체에 높은 단가가 적용된다"라는 정보도 있지만, 공식 문서에는 명시되어 있지 않다. 게다가 의문도 남아 있다.
- 200k를 초과했을 때 「초과한 분량만큼만」 높은 단가가 적용되는지, 아니면 「전체에」 높은 단가가 적용되는지
- 출력 토큰 수(output token count)도 독립적으로 200k를 기준으로 판정되는지, 아니면 입력 토큰 수(input token count)만으로 양쪽 티어(tier)가 결정되는지
개인 수준에서 검증하기에는 비용이 너무 많이 들기 때문에, 이 부분은 깨끗하게 포기한다 (미안하다).
지금까지의 내용을 바탕으로 올바른 계산식을 정리하면 다음과 같다.
PRICE = {
"input": {"standard": 2.00, "large": 4.00}, # $/1M 토큰
"output": {"standard": 12.00, "large": 18.00},
...
포인트는 두 가지다.
candidates_token_count + thoughts_token_count
를 출력 토큰(output token)으로 계산한다.
- 200k 임계값(threshold) 판정은
prompt_token_count
(입력 토큰 수)로 수행하며, 이를 초과했다면 리퀘스트(request) 전체에 높은 단가를 적용한다.
이번 검증을 통해 알게 된 점을 정리하면 다음과 같다.
candidates_token_count
에는 사고 토큰(thought token)이 포함되지 않는다. thoughts_token_count는 별도로 카운트된다.
- 사고 토큰은 출력 토큰과 동일한 단가로 과금된다.
- 내가 했던 계산에서는 사고 토큰 분량이 통째로 빠져 있었다...
문서에 「출력 요금(사고 토큰 포함)」이라고 적혀 있던 것을 「candidates에 포함된다」라고 잘못 읽었다. 실제로 호출해 보기 전까지는 깨닫지 못했다.
200k 토큰을 초과하는 리퀘스트의 동작에 대해서는, 돈이 너무 많이 들어서 직접 검증할 수 없었다... 누군가 대신 시도해 주길 바란다...
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기