Разница в цене входных и выходных токенов — почему так

В официальном прайс-листе вендора на модель — будь то Claude Opus 5.5 ($4/$20), GPT-5.6 Sol ($5/$30) или GLM 5.3 ($1.4/$4.4 за 1M) — цена указана дважды: за миллион входных токенов и отдельно за миллион выходных, и вторая цифра почти всегда выше. Разница не бухгалтерская условность, а прямое следствие того, как модель физически работает. В Zukko у включённых сейчас моделей вход и выход стоят одинаково (например, claude-opus-5-5 — $0.30/$0.30), но понимать асимметрию вендорских тарифов всё равно полезно.

Откуда берётся асимметрия

Когда модель обрабатывает входной текст, она делает это за один проход: весь промпт целиком загружается в память ускорителя и обсчитывается параллельно, токен за токеном, но все сразу. Это называется prefill, и он хорошо распараллеливается — GPU умеют перемножать матрицы для тысяч токенов одновременно почти так же быстро, как для одного.

Генерация ответа устроена иначе. Модель — авторегрессионная: чтобы сгенерировать токен номер 50, ей нужен уже готовый токен номер 49, и так далее по цепочке. Каждый новый токен требует отдельного прохода через все слои сети. Это последовательный процесс, который нельзя ускорить простым распараллеливанием — и именно поэтому генерация ответа медленнее и дороже по вычислениям на токен, чем чтение промпта.

Отсюда и разница в цене: провайдеры моделей закладывают реальную стоимость GPU-времени, а не берут цифры произвольно.

Что это значит на практике

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

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

Vision-запросы тоже считаются как входные токены: изображение, переданное в messages, разбивается на токены наравне с текстом. Это не отдельная строка в счёте, а часть той же входной стоимости — актуально для моделей с приёмом изображений (Claude и GPT); glm-5.3 и glm-5.3-flash изображения не принимают.

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

Мини-пример: чат против агента

Возьмём два разных по форме запроса к одной и той же модели.

Обычный чат-ответ: 40 токенов на входе — короткий вопрос пользователя, и 400 токенов на выходе — развёрнутый ответ с объяснением. Здесь выходных токенов в десять раз больше, и именно более высокий тариф на выход определяет итоговую цену запроса почти целиком.

Шаг агента с чтением файла: 18 000 токенов на входе — содержимое файла, накопленная история, системный промпт с описанием инструментов, и 60 токенов на выходе — вызов функции с параметрами. Соотношение здесь обратное: входных токенов больше в триста раз, и даже более высокая ставка на выход погоды не делает — цену определяет объём входа, а не разница в тарифах.

Проверить это на своих реальных числах можно тем же count_tokens до отправки запроса и заголовком X-Zukko-Cost-Micros после получения ответа — сравнение фактических цифр быстро показывает, какая часть тарифа доминирует именно в вашей нагрузке.

Как узнать точные цифры на сейчас

Каталог меняется, и называть конкретные ставки в тексте — плохая идея, они устареют. Актуальные цифры для каждой модели доступны без ключа:

curl https://api.zukko.pro/v1/models/info

Ответ содержит цену за миллион входных и за миллион выходных токенов отдельно по каждой модели, а также лимиты. Обычный /v1/models даёт список идентификаторов без деталей — для расчётов нужен именно /models/info.

Как прикинуть свою стоимость до отправки

Бесплатный подсчёт токенов работает для любой модели из каталога:

import requests

resp = requests.post(
    "https://api.zukko.pro/v1/messages/count_tokens",
    headers={
        "Authorization": "Bearer fetch_ваш_ключ",
        "anthropic-version": "2023-06-01",
    },
    json={
        "model": "claude-opus-5-5",
        "messages": [{"role": "user", "content": long_context_string}],
    },
)
print(resp.json())

Зная число входных токенов заранее и ставки из /v1/models/info, можно посчитать нижнюю границу стоимости запроса ещё до отправки — не хватает только числа выходных токенов, которое заранее не известно, но обычно на порядок меньше входных в агентских сценариях.

Практический вывод

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