Gemini API billing устроен так, что расход растёт молча: запросы уходят из кода, а счёт обнаруживается позже. Поэтому рабочий порядок начинается с контроля, оплата идёт вторым шагом: выбрать модель оплаты, назначить ограничения на проект, настроить сигналы и до запуска провести небольшую тестовую нагрузку. Конкретные тарифы и суммы здесь опущены, они меняются, и актуальные значения смотрят в консоли и справке на день расчёта.
Деньги и лимиты
Биллинг отвечает на вопрос «сколько мы потратили», а квоты на вопрос «сколько запросов можно отправить». Это разные механизмы, и для проекта нужны оба: один держит бюджет, другой защищает от перегрузки.
Два понятия часто смешивают. Квоты и ограничения частоты задают потолок скорости: сколько запросов и данных сервис принимает за период. Биллинг определяет, кто и как платит, и какие у проекта предельные расходы. Про квоты мы писали отдельно в статье Gemini API limits: квоты и контроль нагрузки, а здесь речь о деньгах.
Практическая сторона такова: пока проект маленький, оба вопроса решаются на глаз. Когда сервисом пользуются десятки сотрудников или клиенты, расход перестаёт быть очевидным, а перегрузка превращается в сбой. Договорённости о бюджете и лимитах дешевле принять до запуска, чем после первого неожиданного счёта.
| Вопрос | Что отвечает | Где смотреть |
|---|---|---|
| Сколько потрачено | Учёт расхода по проекту | Раздел использования в консоли и страница оплаты |
| Сколько можно потратить | Ограничения расходов на проекте или уровне аккаунта | Настройки проекта и оплаты |
| Как быстро можно отправлять запросы | Квоты и лимиты частоты | Раздел лимитов |
| Кто оплачивает | Платёжный аккаунт и способ оплаты | Страница оплаты |
Общий порядок подключения интерфейса к рабочему процессу описан в материале Gemini API для компании: как подключить.
Модели оплаты
Справка Google описывает уровни доступа в зависимости от платёжной истории, от бесплатного уровня до уровней с повышенными ограничениями, и две схемы оплаты. Условия и названия обновляются, поэтому сверяйте их с актуальной страницей перед решением.
- Предоплата: вы заранее вносите средства, расход списывается с баланса; при нулевом балансе ключи проекта прекращают работать, что защищает от неожиданных счетов, но грозит остановкой сервиса.
- Постоплата: счета выставляются по итогам периода или при достижении порога, это стандартная модель облачных услуг, удобная для регулярной нагрузки.
- Автопополнение при предоплате убирает риск остановки, но требует контроля, чтобы расход оставался под наблюдением; по справке, для него можно задать ежемесячный предел списаний.
- Срок действия и условия возврата предоплаченных средств читайте в справке: у кредитов есть срок, и остаток нужно планировать.
- Бесплатный уровень подходит для проб и имеет собственные условия обработки данных, которые нужно прочитать до загрузки рабочих материалов.
Отдельно обратите внимание на то, как каждая схема ведёт себя при исчерпании средств. При предоплате сервис останавливается, и пользователи видят ошибку, при постоплате расход продолжается до установленного ограничения. Поэтому для обеих схем нужен план: кто получает сигнал, что говорит приложение пользователям и как быстро решается вопрос с пополнением или ограничением.
Выбор между схемами определяется предсказуемостью нагрузки. Для пилота с небольшим бюджетом удобна предоплата: потолок задан суммой на балансе. Для работающего сервиса с постоянной нагрузкой удобнее постоплата с ограничениями и оповещениями. В обоих случаях решение и ответственный записываются в регламент.
Тестовая нагрузка
Перед рабочим запуском проверьте кроме качества ответов ещё и расход. Тестовая нагрузка показывает, сколько стоит типичный запрос в вашем проекте и как быстро растёт счёт при реальных сценариях.
Состав набора для теста определяет качество прогноза. Если в боевой работе будут длинные документы, включите их в тест, иначе оценка окажется оптимистичной: длинный ввод стоит заметно больше короткого. Повторите тест на разных режимах и моделях, которые планируете использовать, и сравните расход.
- Создайте отдельный проект для теста, изолированный от рабочего, и подключите к нему оплату с минимальным ограничением.
- Подготовьте репрезентативный набор запросов: короткие, длинные, с файлами, с картинками, если они планируются.
- Запустите набор небольшой партией и запишите время, объём ввода и вывода, итоговое списание.
- Подождите: разбивка расходов обновляется с задержкой, по справке до суток, поэтому смотрите итог на следующий день.
- Посчитайте стоимость типичного запроса и умножьте на ожидаемую нагрузку в день и в месяц.
- Добавьте запас на ошибки, повторы и всплески и сравните с бюджетом.
- Запишите вывод в документ: допущенная нагрузка, ожидаемый расход, порог для сигнала.
Тест выполняйте на безобидных данных, без персональной информации и коммерческих секретов. Условия обработки данных на бесплатном и платном уровнях различаются, поэтому до загрузки реальных материалов прочитайте их и согласуйте с юристом.
Какую нагрузку на Gemini API вы ожидаете в первый месяц работы?
Сигналы и ограничения
Контроль строится на двух слоях: ограничения, которые останавливают расход, и сигналы, которые предупреждают заранее. Справка описывает ограничения расходов двух видов: на уровне проекта, где функция помечена экспериментальной, и на уровне платёжного аккаунта по уровню доступа. Вступают они в силу с небольшой задержкой.
Каждый рабочий проект имеет ограничение расходов и сигнал о приближении к нему, получателем сигнала назначен конкретный человек. Ключи доступа выданы приложениям по отдельности и отзываются при подозрении на утечку.
Настройка сигналов работает, только когда есть получатель и процедура. Письмо, упавшее в общий ящик без адресата, пользы приносит мало. Укажите конкретного человека и его заместителя, договоритесь, что делать при срабатывании: отключить ключ, снизить нагрузку, поднять ограничение. Раз в квартал проверяйте, что сигналы доходят.
- Сигнал по порогам: предупреждение при заметной доле бюджета и при его исчерпании.
- Ежедневный взгляд на расход в первые недели, затем еженедельный.
- Отдельные ключи и проекты для разных сервисов, чтобы видеть, кто тратит.
- Защита ключей: хранить в секретах, вдали от кода, ограничивать по приложению; общие правила описаны в статье Безопасность ИИ-агентов: права, секреты и проверка.
- Защита от зацикливания: в коде ограничивается число повторов и длина диалога, иначе ошибка превращается в быстрый расход.
- План на случай остановки: что видят пользователи, когда расход исчерпан.
Помните о задержке учёта: показания обновляются с запозданием, и между всплеском и сигналом проходит время. Поэтому ограничения в коде надёжнее наблюдения за панелью.
Оплата и учёт
Оплата сервисов Google из России упирается в практическое ограничение: прямая оплата российскими банковскими картами недоступна. Вопросы способа оплаты решаются на стороне компании с финансовой службой и юристом, обходные схемы исключены. Подробнее об использовании сервиса компаниями в России читайте в материале Gemini в России: как использовать в компании.
- Назначьте владельца платёжного аккаунта и резервного ответственного.
- Ведите реестр проектов: название, назначение, владелец, ограничения, дата проверки.
- Раз в месяц сверяйте расход с бюджетом и записывайте причины отклонений.
- При смене схемы оплаты или уровня обновляйте регламент и оповещения.
- Для конфиденциальных данных рассматривайте локальный запуск открытых моделей на своём сервере.
Если нужно спроектировать учёт и контроль расхода ИИ-сервисов в вашей компании, этим занимается наша команда в консалтинге по внедрению ИИ: бюджеты, права, сигналы и тест нагрузки на ваших сценариях.