대형 모델 API 토큰 및 요금: 추정, 읽기, 예산 및 계산 예시

토큰이란 무엇이며 어떻게 요금이 계산되나요

토큰은 모델이 텍스트를 처리하는 최소 단위로, 글자나 단어도 아니며 그 사이의 '조각'입니다. 수도 계량기의 눈금처럼 생각하세요: 사용할수록 눈금이 빠르게 움직입니다. 요금은 두 부분으로 나뉩니다:

출력 단가는 입력의 4배이므로, 모델에게 '불필요한 말 줄이기'가 컨텍스트 줄이기보다 종종 더 경제적입니다. 하지만 대화 시나리오에서는 이력 누적 때문에 입력이 팽창하므로 양쪽 모두 관리해야 합니다. 결제 방식은 구독이 아닌 선불 잔액이며, 잔액은 만료되지 않습니다. 신규 계정에는 $0.50 무료 체험 크레딧이 제공되며 7일 동안 유효합니다.

혼동하기 쉬운 점을 덧붙이자면: 출력 토큰은 설정한 max_tokens가 아니라 모델이 실제로 생성한 수입니다. max_tokens는 단지 상한선일 뿐이며, 모델이 200자 만에 답변을 마치면 해당 토큰 수만큼만 요금이 부과됩니다. 하지만 예산 예측 시에는 최악의 경우를 대비해 상한선을 기준으로 계산해야 하며, 그렇지 않으면 긴 출력으로 인해 예상치 못한 비용이 발생할 수 있습니다.

사전 추정: 중국어와 영어는 어떻게 대략 추정하나요

요청을 보내기 전에는 추정만 가능합니다.아래는 근사치이며 콘텐츠에 따라 변동될 수 있습니다:

추정의 올바른 용도는 '규모 판단'입니다: 이 글은 토큰이 약 1만 개인지 10만 개인지, 100,000 컨텍스트 창을 넘는지, 한 번 호출에 몇 센트 정도 들는지 파악하는 것입니다. 정확히 알고 싶다면 usage를 읽으세요. 좋은 습관은 각 비즈니스 시나리오에서 수십 번 샘플링하여 usage 평균값을 구하고, 이를 경험값 대신 사용하는 것입니다.

추정과 실측을 결합한 예를 들어보겠습니다. 중국어 고객 피드백 2000자 정도를 처리해야 한다고 가정해 봅시다. 글자당 1.3 토큰으로 대략 추정하면, 단일 요청은 약 2600 토큰이며 프롬프트 200 토큰을 더해 입력은 약 2800 토큰이 됩니다. 먼저 30개를 테스트해 usage 평균을 읽어보고, 실측 평균이 2500이라면 계수를 약 1.15로 수정합니다. 이후 전체 배치의 예산은 수정된 계수로 계산하면 오차가 훨씬 줄어듭니다. 이 실측 숫자는 방법론 시연을 위한 가정이며, 실제 데이터는 고유한 값을 가질 것입니다.

usage 읽기: 진정한 '전기 계량기'

성공적인 응답에는 항상 usage가 포함되어 있으며, 여기에는 prompt_tokens, completion_tokens, total_tokens 세 가지 항목이 포함됩니다. 스트리밍 응답에는 추가 매개변수가 필요 없으며, 마지막에 usage 데이터 블록이 자동으로 추가됩니다. 아래 코드에서는 두 가지 읽는 방법을 모두 보여주고, 읽은 값을 달러로 환산합니다:

复制import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apidamoxing.com/v1", api_key=os.environ["API_KEY"])
PRICE_IN, PRICE_OUT = 0.25, 1.00     # 美元 / 百万 token

def cost(u):
    return (u.prompt_tokens * PRICE_IN + u.completion_tokens * PRICE_OUT) / 1_000_000

# 非流式：usage 在响应对象上
r = client.chat.completions.create(
    model="uncensored", max_tokens=200,
    messages=[{"role": "user", "content": "用三句话解释什么是通货膨胀。"}],
)
print(r.usage.prompt_tokens, r.usage.completion_tokens, f"${cost(r.usage):.6f}")

# 流式：最后一个数据块带 usage，其余块的 usage 为空
usage_last = None
stream = client.chat.completions.create(
    model="uncensored", max_tokens=200, stream=True,
    messages=[{"role": "user", "content": "再用三句话解释什么是通货紧缩。"}],
)
for chunk in stream:
    if chunk.usage:
        usage_last = chunk.usage
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
print()
if usage_last:
    print(usage_last.prompt_tokens, usage_last.completion_tokens, f"${cost(usage_last):.6f}")

스트리밍 시 주의할 점: usage는 마지막 블록에만 있으며 이전 블록에서는 비어 있으므로, if chunk.usage로 판단하면 됩니다. 각 읽은 값을 로그나 데이터베이스에 기록하면, 월말 정산, 이상 탐지, 사용자별 비용 계산에 이 기록이 모두 활용됩니다.

또 다른 좋은 습관은 각 비즈니스 기능에 태그를 달아 요금 계산 시 함께 기록하는 것입니다. 예를 들어 '요약', '고객 서비스', '번역' 등을 각각 기록하면 월말 정산 시 어떤 기능이 가장 많은 비용이 들는지 파악할 수 있습니다. 이를 통해 프롬프트 최적화, 히스토리 단축 또는 max_tokens 감축이 필요한지 판단할 수 있습니다. 태그가 없으면 총합만 알 수 있어 최적화가 어렵습니다.

세 가지 예제 (가정 조건 명시)

예제 1: 고객 서비스 Q&A

가정: 요청당 입력 800 토큰(system 및 지식 조각 포함), 출력 200 토큰; 일일 10,000회.

단일 호출 비용: 800 × 0.25 ÷ 1,000,000 = $0.0002, 출력 200 × 1.00 ÷ 1,000,000 = $0.0002, 합계 $0.0004. 하루 $4.00, 30일 $120입니다. 이 속도로 $0.50의 무료 체험 크레딧은 약 1250회의 이러한 호출을 지원합니다.

예제 2: 긴 글 요약

가정: 글당 입력 20,000 토큰, 요약 출력 600 토큰; 총 500편.

단일 비용: 입력 20,000 × 0.25 ÷ 1,000,000 = $0.005, 출력 600 × 1.00 ÷ 1,000,000 = $0.0006, 합계 $0.0056. 500편 총 $2.80. 긴 입력과 짧은 출력 작업은 비용이 매우 적게 든다는 것을 알 수 있습니다.

예제 3: 다중 대화 및 역사 데이터 절단

가정: system 100 토큰; 라운드당 사용자 입력 60 토큰, 응답 150 토큰; 대화 20 라운드.

전체 역사 방안의 입력은: 20 × (100 + 60) + 210 × (0 + 1 + … + 19) = 3,200 + 39,900 = 43,100입니다. 절단 방안은 처음 3 라운드가 각각 160, 370, 580이며, 4 라운드부터 20 라운드까지 라운드당 790으로 합계 14,540입니다. 비용이 약 절반 차이 나며, 라운드가 늘어날수록 차이가 커집니다. 전체 역사 방안의 입력은 라운드 수에 따라 제곱 수준으로 증가하기 때문입니다.

이 세 가지 예제로부터 하나의 경험 공식 도출: 비용은 주로 “요청 횟수 × 라운드당 입력/출력량”에 의해 결정되며, 라운드당 입력량에서 역사 데이터와 첨부 자료가 가장 큰 변수입니다. 고객 서비스에서는 지식 조각 길이를 줄이고, 대화에서는 역사를 절단하며, 요약에서는 청크 단위로 병렬 처리하는 것이 모두 같은 이치입니다: 불필요한 토큰에 대해 불필요한 비용을 지불하지 마십시오. 강조하자면, 이 세 예제의 수치는 위에서 명시한 가정에서 비롯된 것이며, 실제 데이터는 usage를 기준으로 하십시오.

역산 예시: 월 예산이 $30일 때, 20 라운드 대화 제품을 월간 몇 회까지 지원할 수 있는지 확인하십시오. 예제 3의 “최근 3 라운드만 포함” 방안 기준, 회당 약 $0.0066이므로 $30 ÷ 0.0066은 약 4,545회입니다. 동일한 예산으로 전체 역사 방안을 사용하면 회당 $0.0138이므로 약 2,174회만 가능합니다. 이것이 역사를 절단하는 것이 가져오는 실제 차이입니다.

예산 제어: 프로그램에 게이트 설치하기

예측은 예측일 뿐, 게이트가 보험입니다. 아래는 달러 기준 일일 예산 클래스입니다: 요청 전 “최악의 경우”로 예측(출력 max_tokens 최대 사용), 요청 후 실제 usage로 장부 기록.

复制class Budget:
    """按美元计的日预算。超出时拒绝新请求。"""
    def __init__(self, daily_usd):
        self.limit = daily_usd
        self.spent = 0.0

    def check(self, est_prompt_tokens, max_tokens):
        # 最坏情况：输出用满 max_tokens
        worst = (est_prompt_tokens * 0.25 + max_tokens * 1.00) / 1_000_000
        if self.spent + worst > self.limit:
            raise RuntimeError(f"预算不足：已用 ${self.spent:.4f}，本次最坏 ${worst:.4f}，上限 ${self.limit}")

    def record(self, usage):
        self.spent += (usage.prompt_tokens * 0.25 + usage.completion_tokens * 1.00) / 1_000_000

budget = Budget(daily_usd=5.0)
budget.check(est_prompt_tokens=1200, max_tokens=500)   # 请求前
# ……发请求……
# budget.record(response.usage)                        # 请求后

프로그램 내 게이트 외에도 세 가지 구성 수준 방법이 있습니다:

1. max_tokens을 작업에 맞게 설정하고 무조건 상한까지 늘리지 마십시오. 기본값 2048, 최대 32,000;
2. 대화 히스토리 길이 제한은 채팅 봇 구축의 방법을 참조하세요;
3. 계정에서 계획된 사용량만큼만 충전하고, 다 쓰면 보충하십시오. 선불 크레딧 방식은 본질적으로 하드 상한선입니다.

단가 및 잔액 규칙은 가격 페이지를 기준으로 하며, 인터페이스 세부 사항은 매개변수 설명에 있습니다.

마지막으로 확인 목록으로 정리: 사전 단계에서 규모 예측, max_tokens 설정, 역사 길이 확인; 진행 중에는 스트리밍 출력 시 마지막 블록의 usage 확인; 사후에는 장부 기록 및 기능별 분류, 예산 대비 비교. 이 세 단계를 거치면 장부가 명확해집니다.