GLM API — это не продукт с фиксированной абонентской платой, а сервис с оплатой по фактическому расходу. Многие команды, впервые увидев счёт, удивляются: запросов немного, а сумма выше ожидаемой. Причина обычно не в ставке за токен, а в слишком длинном входе, неконтролируемом выходе, промахах кэша или повторной генерации после ошибки.
В статье нет конкретных цен: они зависят от модели, ступени контекста и акций. Ниже — структура тарификации, источники затрат, способы оценки и снижения, а также практический чек-лист. Актуальные цены смотрите на странице цены на модели и на официальной странице тарифов Zhipu.
Примечание: Zhipu, GLM и BigModel — товарные знаки соответствующих правообладателей. Статья носит технический характер и не подразумевает аффилированность, агентские или лицензионные отношения с Zhipu. Правила тарификации и цены могут меняться; перед заказом сверяйтесь с официальной документацией и страницей биллинга.
1. Базовая единица тарификации
Для текстовых моделей базовая единица — токен. В документации Zhipu приводится ориентир: примерно 1 токен на 1,6 китайских иероглифа, но фактическое количество зависит от токенизатора и текста, а окончательным считается значение usage, возвращённое API. То есть оценка подходит для планирования бюджета, но не заменяет счёт.
Не все модели тарифицируются по токенам. Генерация изображений, генерация видео, синтез речи, клонирование голоса, потоковое аудио и видео, разбор баз знаний могут считаться за вызов, минуту, символ или страницу. Для мультимодального продукта сначала определите единицу тарификации, а затем обсуждайте ставку.
2. Почему вход и выход считаются отдельно
Обычный запрос содержит входные и выходные токены; они тарифицируются раздельно, выход, как правило, дороже. Модели с длинным контекстом могут разбивать вход по длине, например с границей 32K, выше которой действует более высокая ступень; некоторые модели также разбивают по длине выход. Поэтому «одна и та же модель» при разных сценариях может иметь разную удельную стоимость.
Затраты определяет не число запросов, а контекст, который несёт каждый запрос. Если в промпт вставить всю базу знаний, всю историю диалога и десятки описаний инструментов, вход быстро разрастётся. Более частая утечка — выход: без ограничения максимальной длины модель «говорит» много, и счёт растёт.
| Статья затрат | База тарификации | Типичный триггер | Способ контроля |
|---|---|---|---|
| Входные токены | Вход, не попавший в кэш | Длинные промпты, история диалога, описания инструментов | Сжимать контекст, делать резюме |
| Выходные токены | Сгенерированный контент | Длинные тексты, генерация кода | Задать максимальную длину выхода |
| Попадание в кэш | Скидочная ставка для совпавшей части | Фиксированный system prompt, префикс базы знаний | Поддерживать стабильность префикса |
| Ступень длинного контекста | Ставка меняется выше порога | Длинные документы, анализ кодовой базы | Дробить, суммировать, загружать по необходимости |
| Повторы и ошибки | Частично сгенерированный ответ может тарифицироваться | Тайм-ауты, обрывы потока, повторная отправка | Идемпотентность, задержка, дедупликация |
| Мультимодальность и инструменты | За вызов, минуту, страницу и т. д. | Генерация изображений, речь, поиск, разбор | Считать отдельно, ограничивать вызовы |
3. Попадания в кэш: экономия на повторяющемся префиксе
Zhipu предоставляет кэширование контекста; в документации в основном описано неявное кэширование: система сама распознаёт повторяющийся контент, вручную отмечать точки кэша не нужно. Оно подходит для схемы «фиксированный system prompt + фиксированная база знаний + меняющийся вопрос».
Чтобы повысить долю попаданий, нужны как минимум три условия. Повторяющийся префикс должен быть достаточно длинным: официальная рекомендация — от 500 токенов. Префикс должен полностью совпадать, и даже лишний пробел может привести к промаху. Кэш создаётся асинхронно, поэтому после первого запроса лучше немного подождать, прежде чем отправлять следующие. Попадания видны в usage.prompt_tokens_details.cached_tokens.
Кэш не универсален. Короткие промпты, каждый раз новый контент и часто обновляемая база знаний редко дают попадания. Тарифицируется ли хранение кэша отдельно и насколько велика скидка — смотрите на официальной странице цен. Рассматривайте кэш как оптимизацию, а не как обязательное допущение в модели затрат.
4. Длинный контекст, Batch и мультимодальность
Длинный контекст полезен, но именно на нём проще всего выйти за бюджет. Работая с договорами, статьями или кодовой базой, задайте три вопроса: действительно ли весь объём нужен сразу? Можно ли сначала выполнить поиск, а затем собрать контекст? Можно ли обработать частями и потом суммировать? Многие задачи решаются схемой «поиск + резюме» гораздо дешевле, чем вставкой всего корпуса.
Для пакетных задач стоит посмотреть на интерфейс Batch. Документация указывает, что поддерживаемые модели обычно получают скидку при использовании Batch; это подходит для офлайн-разметки, массового суммирования и очистки данных, где не нужен ответ в реальном времени. Плата — более высокая задержка и усложнённая оркестрация; такой режим подходит командам с очередями и проверкой результатов.
Мультимодальные возможности считайте отдельно. Генерация изображений тарифицируется за изображение, понимание изображений обычно по токенам; синтез речи — по символам или минутам, разбор базы знаний — по страницам. Если смешать эти расходы с текстовым бюджетом, в конце месяца цифры не сойдутся.
5. Повторы, обрывы потока и скрытые затраты
Неудачный запрос не обязательно бесплатен. Если сервер уже сгенерировал часть контента, а затем произошёл тайм-аут, этот объём может быть тарифицирован; при обрыве потокового соединения уже сгенерированная часть также может попасть в счёт. Поэтому стратегия повторов должна быть сдержанной: повторяйте только при ограничении частоты, ошибках 5xx и сетевых тайм-аутах, используйте экспоненциальную задержку и задавайте максимальное число попыток.
Ещё одна скрытая статья — повторная отправка. Пользователь несколько раз нажимает кнопку, фронтенд автоматически переотправляет запрос после тайм-аута, очередь повторно обрабатывает сообщение — всё это создаёт дополнительные запросы. Идемпотентность по request ID или дедупликация на уровне шлюза эффективнее, чем разбор расхождений постфактум.
Не забывайте и об инженерных затратах: логи, мониторинг, оценка качества, ручная проверка. Плата за вызовы моделей — лишь часть общей стоимости; не стоит экономить на вызовах ценой многократных ручных доработок.
6. Как оценить месячный бюджет
Оценка состоит из четырёх шагов: посчитать месячное число вызовов, оценить средние вход и выход, оценить долю попаданий в кэш, подставить текущие ставки. Если нужно управлять балансом и расходом нескольких моделей в одном месте, можно зарегистрироваться в ZSQH AI Gateway и смотреть всё в одной панели; конкретные цены по-прежнему на странице цены на модели. Код ниже — только каркас расчёта; ставки возьмите с официальной страницы цен.
# Модель бюджета: все ставки — заполнители, замените на актуальные официальные цены
monthly_calls = 300_000
avg_input_tokens = 1_200
avg_output_tokens = 300
cache_hit_rate = 0.35
input_rate = 0.0 # ставка за вход, см. официальную страницу цен
output_rate = 0.0 # ставка за выход
cache_rate = 0.0 # ставка за попадание в кэш
uncached_input = avg_input_tokens * (1 - cache_hit_rate)
cached_input = avg_input_tokens * cache_hit_rate
per_call = (
uncached_input * input_rate
+ cached_input * cache_rate
+ avg_output_tokens * output_rate
)
print(f"Оценка месячных затрат: {monthly_calls * per_call:.2f} юаней")
При оценке оставляйте запас. Реальный вход новой задачи обычно длиннее проектного, а повторы и ошибки добавляют расход. Рекомендуется две недели поработать на малом трафике, заменить допущения реальными данными usage и только затем утверждать бюджет.
7. Чек-лист контроля бюджета
- Задайте отдельный лимит для каждого окружения и сервиса.
- Для всех запросов установите максимальную длину выхода и тайм-аут.
- Фиксируйте порядок system prompt, чтобы повысить долю попаданий в кэш.
- Длинные документы сначала ищите и суммируйте, затем решайте, нужен ли длинный контекст.
- Повторяйте только ошибки, допускающие повтор, с задержкой и лимитом попыток.
- Ежедневно смотрите расход, еженедельно — счёт; при аномальном росте сразу разбирайтесь.
- Офлайн-задачи по возможности отправляйте в Batch, онлайн-задачи — через обычный интерфейс.
8. Частые вопросы (FAQ)
1. Сколько именно стоит GLM API?
Цена зависит от модели, ступени контекста и акций, поэтому фиксированных цифр в статье нет. Смотрите цены на модели или официальную страницу тарифов Zhipu, а ориентируйтесь на счёт в панели управления.
2. Как тарифицируется попадание в кэш?
Попавшая в кэш часть тарифицируется по скидочной ставке, непопавший вход — по стандартной ставке входа. Конкретная скидка и плата за хранение указаны на официальной странице цен; объём попаданий виден в поле usage.
3. Списываются ли деньги за неудачный запрос?
Зависит от стадии отказа. Если часть контента уже сгенерирована, она может быть тарифицирована по фактическому расходу; ошибки параметров и аутентификации обычно не создают расходов на генерацию. Ориентируйтесь на детализацию счёта.
4. Всегда ли длинный контекст дороже?
Как правило, да. Многие модели разбивают вход по длине, и выше порога ставка растёт. Задачи, которые решаются разбиением или поиском, не обязательно тянуть в длинный контекст.
5. Как быстро снизить текущие затраты?
Начните с трёх вещей: ограничьте максимальную длину выхода, сожмите system prompt, повысьте долю попаданий в кэш. Обычно это даёт эффект быстрее и предсказуемее, чем смена модели.
