Gemini API: сравнение тарифов Flex и Priority — как сэкономить 50% на фоновых задачах

Гонка за тротилом. Почему ваш AI-агент жрёт деньги как не в себя

Вы запустили продакшен. Ваш AI-агент на Gemini API работает. Каждый месяц приходит счет от Google Cloud — цифры растут как на дрожжах. Вы смотрите на графики: тысячи запросов, десятки миллионов токенов. И вопрос: куда уходят все эти деньги? Может, пора резать функциональность?

Стоп. Не режьте. Скорее всего, вы просто платите за приоритет там, где он не нужен. Google не афиширует это громко, но с 2025 года в Gemini API работают два разных двигателя под одним капотом: Priority и Flex. Разница в цене — до 50%. Разница в скорости — иногда в 10 раз. Проблема в том, что 80% разработчиков по умолчанию используют Priority для всего, включая задачи, которые могли бы спокойно ждать.

Flex vs Priority: не выбор тарифа, а выбор архитектуры

Забудьте про "дешевый" и "дорогой" тариф. Это разные звери для разных целей.

Цифры по стоимости сознательно опускаю — они меняются каждый квартал. Но принцип стабилен: Flex дешевле на 30-50% за тот же объем токенов для моделей того же класса. Например, обработка миллиона токенов через Gemini 3 Flash на Flex обойдется примерно в $0.15, а на Priority — в $0.25. Мелочь? Умножьте на ваш месячный объем.

Тихий убийца бюджета: как вы неосознанно сжигаете деньги

Вот три сценария, которые я вижу в 9 из 10 проектов:

• Ежедневный отчет в 3:00 ночи. Система формирует аналитический отчет по данным дня. 5000 запросов к Gemini 3 Flash для классификации и суммаризации. Отправляются через обычный синхронный API. Пользователь получит отчет утром. Зачем ему скорость в 500 мс? А вы платите за Priority.
• Пакетная обработка загрузок пользователей. Пользователь загрузил 100 PDF-документов. Ваш агент извлекает из них текст, структурирует, кластеризует. Работает 20 минут. Но каждый отдельный запрос к API — синхронный и с приоритетом. Итог: цена за обработку одного документа становится неприлично высокой.
• Тренировочные циклы для RAG. Вы периодически обновляете эмбеддинги и индексы в вашей RAG-системе. Процесс не интерактивный, может работать часами. И снова — все запросы идут по самому быстрому и дорогому каналу.

Звучит знакомо? Если да, то вы уже потеряли тысячи долларов. Хорошая новость: фикс занимает один день.

1 Аудит: найдите свои фоновые процессы

Откройте мониторинг Google Cloud или ваш собственный лог. Отсортируйте запросы к Gemini API по времени суток. Ищите:

• Пакеты запросов, идущие друг за другом с небольшим интервалом.
• Запросы, которые инициируются не пользователем, а cron-заданием или системной очередью.
• Длинные операции (более 5 секунд), где клиент явно ждет ответа асинхронно.

Вот типичный антипаттерн в коде, который я встречаю постоянно:

# КАК НЕ НАДО ДЕЛАТЬ
# Синхронные запросы для пакетной обработки
docs = load_thousands_of_pdfs()
for doc in docs:
    # Каждый вызов - это дорогой Priority запрос
    response = client.models.generate_content(
        model="gemini-3-flash",
        contents=doc,
        # Тут нет указания на использование Flex!
    )
    process(response)

2 Выбор оружия: асинхронный API или Batch?

У Google есть два механизма для фоновых задач:

1. Асинхронный API (Async) — вы отправляете запрос, получаете ID операции, проверяете статус позже. Подходит для задач, которые выполняются минуты.
2. Batch API — вы пакуете до 5000 запросов в один файл, загружаете его в Cloud Storage, запускаете задание. Результаты появляются через часы, но стоимость минимальна. Идеально для ночной обработки терабайтов данных.

Правило простое: если задача должна завершиться в течение нескольких минут — Async. Если можно подождать до следующего утра — Batch. Batch дешевле еще на 15-20% по сравнению с асинхронным Flex.

3 Переписываем код: практический пример

Вот как выглядит переход на асинхронный Flex API для того же процесса обработки PDF. Обратите внимание на ключевой параметр routing="flex" (актуальный на 12.04.2026).

# Правильный способ: асинхронный Flex API
import asyncio
from google.cloud import aiplatform
from google.cloud.aiplatform_v1.types import content

# Инициализируем клиент с явным указанием routing
# Важно: используйте последнюю версию google-cloud-aiplatform (на 12.04.2026 это v1.30+)
client = aiplatform.gapic.PredictionServiceClient(
    client_options={"api_endpoint": "us-central1-aiplatform.googleapis.com"}
)

async def process_doc_async(doc_content):
    # Формируем запрос с флагом flex routing
    req = content.GenerateContentRequest(
        model="projects/your-project/locations/us-central1/publishers/google/models/gemini-3-flash",
        contents=[{"role": "user", "parts": [{"text": doc_content}]}],
        # Вот он, волшебный переключатель
        routing="flex"
    )
    
    # Асинхронный вызов
    operation = await client.generate_content_async(request=req)
    # Operation - это будущий результат, мы можем сохранить его ID и проверить позже
    return operation.name

# Основной цикл обработки
async def main():
    docs = load_pdfs()
    tasks = []
    for doc in docs:
        task = asyncio.create_task(process_doc_async(doc))
        tasks.append(task)
    
    # Ждем отправки всех запросов, но не ждем немедленных ответов
    operation_ids = await asyncio.gather(*tasks)
    
    # Теперь можем периодически проверять статус операций
    for op_id in operation_ids:
        # ... проверка статуса через client.get_operation
        pass

# Запускаем
asyncio.run(main())

4 Мониторинг и алерт: не дайте Flex стать узким местом

После перехода на Flex вы должны мониторить две метрики как ястреб:

• Среднее время выполнения (P95) для Flex-запросов. Если оно вырастет сверх допустимого для вашего процесса (например, больше 30 секунд), возможно, нужно вернуть часть нагрузки на Priority или использовать гибридный подход.
• Квота ошибок. У Flex может быть другая квота на количество concurrent-запросов. Не упирайтесь в лимиты.

Настройте алерты в Cloud Monitoring. Пример запроса для дашборда:

-- Мониторинг задержек по разным типам роутинга
fetch aiplatform.googleapis.com/PredictionRequestLatency
| filter metric.model_id == 'gemini-3-flash'
| group_by [resource.project_id, metric.routing],
    [value_request_latency_percentile: percentile(value.request_latency, 95)]

Подводные камни, о которых молчит документация

Я сам напоролся на эти грабли, чтобы вам не пришлось.

• Не все модели доступны в Flex. Gemini 3 Ultra, например, может быть доступна только в Priority для гарантии производительности. Всегда проверяйте актуальный список моделей (партнерская ссылка на документацию Google Cloud).
• Streaming-ответы не работают с Flex. По понятным причинам. Если вам нужно получать токены по мере генерации для интерактивного чата — только Priority. Для пакетной обработки это не нужно.
• Контекстное окно не урезается, но... Обработка очень длинных контекстов (128K+ токенов) на Flex может занимать минуты. Учитывайте это при проектировании пайплайнов. Об этой особенности потребления токенов я подробно писал в статье «Context Lens».
• Холодный старт. Если ваш Flex-запрос первый за несколько часов, задержка может быть значительно выше. Проектируйте систему с буфером по времени.

Частые вопросы (FAQ)

Одна последняя мысль: не экономьте на мозгах

Переход с Priority на Flex для фоновых задач — это не "хакинг" или обход системы. Это intended use case, заложенный инженерами Google. Они понимают, что не всем нужна latency в 200 мс, и дают вам рычаг для управления бюджетом.

Но самый большой выигрыш — даже не в деньгах. Он в том, что вы начинаете думать об архитектуре вашего AI-приложения как о системе с разными классами качества обслуживания (SLA). Вы отделяете критичное от фонового. Это признак зрелости проекта. И это, в конечном счете, спасет вас, когда в один прекрасный день ваше приложение вырастет в 100 раз, а счет — нет.

P.S. Если вы все еще используете Gemini 2.0 — остановитесь. Переходите на Gemini 3 Flash для фоновых задач. Он не только дешевле, но и быстрее даже в режиме Flex. Детали — в обзоре Gemini 3 Flash. А если хочется копнуть глубже в инфраструктуру Google, посмотрите, как они масштабируют Gemini для миллиардов.

Подписаться на канал