Счёт за API почти никогда не растёт одним прыжком. Он растёт понемногу: один скрипт в цикле, повторный прогон тестов, лишний вызов внутри обработчика. К концу месяца получается сумма, которой никто не ждал. Лимиты расходов на API решают это заранее: вы сами задаёте потолок, дальше система не даёт его превысить.
Ниже разберём, какие лимиты бывают, где их ставить и что проверить до того, как продукт ушёл в работу.
Почему расходы растут незаметно
Стоимость запроса зависит от числа токенов: сколько вы отправили и сколько модель вернула. Пока задача запускается руками, расход предсказуем. Как только появляется автоматизация, картина меняется.
- Цикл без ограничения по итерациям. Ошибка в условии — и агент делает десять тысяч вызовов вместо десяти.
- Повторы при сбое. Логика «попробовать ещё раз» без верхней границы превращается в бесконечный поток запросов.
- Разбухший контекст. Если в каждый запрос уходит вся история переписки, цена одного вызова растёт с каждым сообщением.
- Забытые тестовые ключи. Черновой контур остался рабочим, а ключ к нему общий с продакшеном.
Общая черта у всех случаев одна: никто не поставил границу. Расходы не выходят из-под контроля сами, им просто не мешают.
Что можно ограничить: три уровня
Лимитов несколько, и они работают вместе.
- На один запрос. Максимум токенов в ответе и таймаут. Защита от одного длинного вызова, который съедает больше, чем планировалось.
- На ключ. Суточный и месячный потолок расходов. Такой лимит живёт на стороне шлюза, а не в коде, и его нельзя обойти, меняя приложение.
- На сценарий. Отдельный ключ под каждый продукт или клиента. Тогда видно, какой сценарий тянет бюджет, и его можно отключить, не задев остальные.
Три уровня закрывают разные риски. Лимит на запрос ловит техническую ошибку, лимит на ключ — ошибку в логике продукта, раздельные ключи — вопрос учёта.
Лимиты в коде: что задать сразу
Часть ограничений пишется на вашей стороне. Они не заменяют лимиты шлюза, но помогают не отправлять лишние запросы.
response = client.chat.completions.create(
model="deepseek-chat",
messages=messages,
max_tokens=800,
timeout=30,
)
# повтор не бесконечный, а с потолком
for attempt in range(3):
try:
...
break
except RateLimitError:
time.sleep(2 ** attempt)
Здесь важны три числа: у ответа есть верхняя граница по токенам, у запроса — по времени, у повторов — по количеству. Без них любой сбой превращается в расходы.
Держите в голове, что max_tokens не ограничивает расход на вход. Если в промпт уходит разрастающаяся история, дешевле обрезать её, чем поднимать потолок ответа.
Лимиты на стороне шлюза
Код можно переписать, обойти или забыть обновить. Лимит на стороне шлюза работает независимо от приложения: пока ключ не превысил потолок, запросы идут, после — блокируются.
Обычно настраивают два порога: суточный и месячный. Суточный ловит аномалию в тот же день, месячный не даёт выйти за бюджет. Оба задавайте с запасом к ожидаемому расходу, а не впритык: слишком жёсткий порог остановит работу в самый неподходящий момент.
Отдельно проверьте поведение при достижении лимита. Одно дело, когда шлюз возвращает ошибку, другое — когда молча отбрасывает запрос. Второе опаснее: продукт сломается без явного сигнала.
Оповещения и раздельные ключи
Лимит срабатывает в худший момент, поэтому кроме него нужен сигнал заранее.
- Порог оповещения. Задайте его ниже лимита, например на семидесяти процентах. Тогда есть время разобраться, пока работа не остановилась.
- Отдельные ключи под окружения. Тестовый, рабочий и ключ конкретного клиента — разные. Так вы видите источник расхода и гасите его точечно.
- Журнал запросов. Достаточно хранить время, модель, число токенов и сценарий. Этого хватает, чтобы найти виновника, не читая переписку.
Порядок простой: сначала разделить ключи, потом поставить лимиты, потом включить оповещения. В обратном порядке легко ограничить не тот контур.
Что проверить перед запуском
- У каждого ключа задан суточный и месячный потолок.
- У запросов есть max_tokens и таймаут.
- Повторы ограничены по количеству, а не «пока не получится».
- История переписки обрезается, а не растёт бесконечно.
- Оповещение приходит до достижения лимита, а не после.
- Тестовый и рабочий контуры разведены разными ключами.
Список не формальность. Каждый пункт появился из сбоя, который на старте случался у команд.
Что можно применить прямо сейчас
Проверка не требует договора и предоплаты, часть шагов делается без подключения к моделям.
- Посчитайте ожидаемый расход: среднее число токенов на запрос умножить на число запросов в день.
- Умножьте на запас и поставьте этот потолок как лимит на ключ.
- Прогоните свои сценарии на небольшой выборке и сравните расчёт с фактом.
Такой расчёт на своих данных говорит больше любой чужой цифры из обзора.
Как это устроено в Китай-API
Мы делаем Китай-API — российский шлюз к китайским моделям DeepSeek, Qwen, GLM, Kimi. Лимиты расходов здесь часть базовой настройки: потолки на ключ, оповещения и раздельные ключи под окружения, а вокруг — оплата в рублях и документы для бухгалтерии. Один ключ работает с несколькими моделями, менять провайдера не нужно.
Платформа готовится, запуск — скоро. Заявку на ранний доступ можно оставить в Telegram-боте: напишем, когда откроем доступ первым. Как устроен шлюз, коротко на главной странице.
Про бюджет и токены читайте в статье «Сколько стоят токены DeepSeek», про подключение кода — в разборе «OpenAI SDK и китайские модели», про документы — в статье «Оплата API юрлицом».