Расчёт стоимости токенов в API больших моделей: оценка, чтение, бюджет и примеры

Что такое токены и как считается стоимость

Токен — это минимальная единица измерения текста, обрабатываемая моделью. Это не символ и не слово, а «фрагмент» между ними. Можно представить его как деление на водосчётчике: чем больше используете, тем быстрее крутятся счётчики. Тарификация делится на две части:

Обратите внимание: цена выходных токенов в 4 раза выше входных, поэтому заставить модель «говорить меньше» часто выгоднее, чем вам «отправлять меньше контекста». Однако в диалоговых сценариях входные данные раздуваются из-за накопления истории, поэтому контролировать нужно оба направления. Оплата производится с предоплаченного баланса, а не по подписке. Баланс не сгорает. Для новых аккаунтов доступен пробный баланс $0,50, действительный в течение 7 дней.

Ещё один момент, который часто путают: выходные токены — это фактическое количество сгенерированных моделью токенов, а не установленное вами значение max_tokens. max_tokens — это лишь верхний предел. Если модель ответит коротким текстом, оплата будет только за фактические токены. Однако при прогнозировании бюджета лучше рассчитывать по верхнему пределу, чтобы избежать неприятных сюрпризов от случайных длинных ответов.

Предварительная оценка: как грубо оценить китайские и английские токены

До отправки запроса можно только оценить. Ниже приведены приблизительные значения, которые могут варьироваться в зависимости от контента:

Правильное использование оценки — определение «порядка величин»: составляет ли статья 10 000 или 100 000 токенов, не превысит ли она контекстное окно в 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: Чат-бот техподдержки

Условия: 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 хватит примерно на 1 250 таких вызовов.

Пример 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. Вариант с обрезкой: первые три шага — 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. Пополняйте баланс только на сумму, которую планируете использовать, и добавляйте средства по мере расходования; предоплаченный баланс — это жёсткий лимит по умолчанию.

Цены и правила баланса определяются на странице цен, а детали API описаны в разделе параметры.

В итоге составьте чек-лист: до — оцените порядок величин, установите max_tokens, проверьте длину истории; во время — при потоковой передаче обращайте внимание на usage последнего блока; после — ведите учёт, группируйте по функциям и сравнивайте с бюджетом. После этих трёх шагов всё будет понятно.