Лимиты запросов GPT Image 2 в 2026 году: что нужно знать разработчикам

Привет, ребята. Это Дора. Знакомый из команды из трёх человек запустил функцию GPT Image 2 в начале мая. Мягкий запуск, ~200 приглашённых пользователей. Через 90 минут функция сломалась — не потому что модель не справилась, а потому что они были на Tier 2, и всплеск от этих пользователей (каждый генерировал в среднем 3–5 изображений) пробил потолок в 20 IPM уже в первый день.

Вот в чём штука с лимитами запросов GPT Image 2: они не ощущаются как ограничение — до тех пор, пока это не происходит. Номера тиров в таблице документации выглядят абстрактно. Они становятся конкретными в тот момент, когда глубина вашей очереди превышает то, что тир способен обработать за минуту. Этот материал для команд, внедряющих GPT Image 2 в реальный продукт, а не для тех, кто тестирует одиночные промпты — лимиты запросов OpenAI image api проявляются иначе при нагрузочном тестировании, чем в разработке.

Дисклеймер: я пишу об агентной и изображенческой инфраструктуре для WaveSpeedAI. В более раннем посте я рассматривала вопрос оценки модели — подходит ли GPT Image 2 для вашего рабочего процесса вообще. Этот пост предполагает, что вы решили: да, подходит — и теперь разбираетесь, выживет ли она в контакте с вашим трафиком.

Как выглядят лимиты запросов GPT Image 2 в 2026 году

Согласно документации OpenAI по лимитам запросов и странице модели GPT Image 2, модель тарифицируется по двум параметрам: TPM (токены в минуту, включая входные/выходные токены изображений и текстовые токены) и IPM (изображения в минуту — более жёсткий потолок для большинства рабочих процессов).

Структура IPM и TPM по тирам

Это опубликованные лимиты GPT Image 2 по состоянию на апрель 2026 года. Бесплатный тир: не поддерживается.

Тир	TPM	IPM	Примерные требования по расходам
Tier 1	100 000	5	$5 оплачено
Tier 2	250 000	20	$50 оплачено + 7 дней
Tier 3	800 000	50	$100 оплачено + 7 дней
Tier 4	3 000 000	150	$250 оплачено + 14 дней
Tier 5	8 000 000	250	$1 000 оплачено + 30 дней

Два важных момента. Тиры действуют на уровне организации, а не проекта или API-ключа — все проекты делят один бюджет IPM для GPT Image 2. OpenAI может пересматривать эти цифры без предупреждения, поэтому таблица выше — это базис для планирования. Проверяйте актуальные данные в панели лимитов вашего аккаунта перед принятием архитектурных решений.

Что эти лимиты означают на практике

Потолок в 5 IPM на Tier 1 — это одно изображение каждые 12 секунд в устойчивом режиме. Этого хватает для одиночной разработки и небольших прототипов. Этого не хватает для публичной функции с умеренным параллелизмом. Потолок в 250 IPM на Tier 5 звучит высоко, пока не посчитаете: 250 изображений/мин × 60 мин = 15 000 изображений/час. Если ваш запуск в Twitter привлечёт 5 000 регистраций за первый час, и каждый пользователь сгенерирует одно изображение, вы уже на 33% от ёмкости при условии идеального распределения — которого никогда не бывает.

Более тяжёлый сценарий отказа — пиковый трафик. В документации OpenAI указано, что лимиты применяются в окнах короче минуты. 20 IPM не означает, что можно отправить 20 запросов за первую секунду и отдыхать 59. Отправьте 5 за 2 секунды — и вас будут троттлить, даже если средний показатель за минуту далеко ниже лимита.

Как лимиты запросов влияют на планирование продакшена

Оценка модели занимает две недели. Инфраструктура для её стабильной работы под реальной нагрузкой — ещё минимум две. Большинство команд недооценивают это.

Проектирование очередей, батчинг и решения по повторным запросам

Здесь накладываются три уровня. Большинство команд строят только два.

Первый: клиентское ограничение запросов. Ограничьте количество одновременных активных запросов до ~80% от IPM вашего тира, распределив их по минуте. На Tier 3 (50 IPM) это ~40 одновременных изображений в устойчивом режиме с очередью за ними.

Второй: повторные попытки с экспоненциальной выдержкой. OpenAI cookbook рекомендует экспоненциальную выдержку с джиттером при получении 429. Стандартная схема: ждать 1с, 2с, 4с, 8с со случайным джиттером, останавливаться после 6 попыток. Это не опционально. Повторные запросы в тесном цикле при 429 приведут к блокировке аккаунта.

Третий — тот, который команды пропускают — это управление формой запросов. Не каждому изображению нужен quality: high. Не каждый рабочий процесс требует синхронного ответа. Batch API от OpenAI имеет отдельный пул квот и ценообразование 50%, с SLA 24 часа. Для ночной регенерации миниатюр батч — правильный инструмент. Для одиночных генераций с пользовательским интерфейсом — нет. У большинства команд есть смесь того и другого, и они маршрутизируют их как будто это одно и то же. Разница между «лимиты запросов — это проблема» и «лимиты запросов — это фон» в том, направили ли вы асинхронную работу с синхронного пула IPM.

Ожидания команды по времени выполнения и пикам

Это та часть, которую никто не документирует. Это разговор с продуктом и операциями, а не с моделью.

На Tier 2 (20 IPM) медианная задержка примерно ограничена скоростью модели — 8–25 секунд в зависимости от качества и режима мышления. Но p99 при устойчивой нагрузке включает ожидание в очереди. Пользователь, отправляющий 21-й запрос за минуту, ждёт 60 секунд, а не 12. «Изображение генерируется за 15 секунд» — правда только тогда, когда больше никто не генерирует.

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

Когда лимиты запросов становятся продуктовой проблемой

Есть порог, за которым пропускная способность GPT Image 2 перестаёт быть вопросом инфраструктуры и становится продуктовым вопросом. Сигнал однозначный: когда ваша очередь повторных запросов достаточно глубока, чтобы быть видимой для пользователей, у вас продуктовая проблема, а не инфраструктурная.

Признаки того, что вы пересекли этот порог:

• Дисперсия задержки для пользователей превышает ваш допустимый диапазон (например, 80% запросов завершаются за 20с, 5% занимают 90с+ потому что стояли в очереди за пиком)
• Вы урезаете функциональность, чтобы оставаться в пределах тира — «нет батч-генерации в UI» — это признак
• Один недобросовестный пользователь или одна популярная расшаренная ссылка могут насытить вашу минуту и ухудшить опыт для всех остальных
• Ваша заявка на Tier 5 занимает больше 30 дней, а запуск через 14

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

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

Что нужно мониторить перед масштабированием

Три вещи, в таком порядке.

Реальный IPM в пике, а не среднее. Логируйте заголовки x-ratelimit-remaining-images и x-ratelimit-remaining-tokens на каждый ответ. Следите за минимумом, а не за средним. Если минимальный остаток за пиковую минуту падает ниже 20% от тира, вы в одном всплеске трафика от 429.

Распределение режимов отказов. Отслеживайте 429 как процент от общего числа запросов, разбитый по часам суток. 0,5% ошибок 429 звучит нормально, пока вы не обнаружите, что во время рассылки маркетингового письма это 8%. Метрики с временны́ми бакетами это поймают; агрегированные метрики — нет.

Время до повышения тира. Tier 5 требует $1 000 расходов плюс 30 дней жизни аккаунта. Если ваш прогноз указывает на потребность в Tier 5 через 2 месяца, начинайте тратить сейчас, или примите, что ваши первые 30 дней при масштабе будут ограничены по ёмкости.

На этом мои данные заканчиваются — я работала с GPT Image 2 на Tier 2 и Tier 3, но не на Tier 5. Команды на Tier 5 сообщают, что динамика снова меняется: потолком становится не IPM, а эффективность формы запросов.

FAQ

Каковы лимиты запросов GPT Image 2 по тирам?

Согласно документации OpenAI по состоянию на апрель 2026 года: Tier 1 — 100 000 TPM / 5 IPM, Tier 2 — 250 000 / 20, Tier 3 — 800 000 / 50, Tier 4 — 3 000 000 / 150, Tier 5 — 8 000 000 / 250. Бесплатный тир не поддерживается. Лимиты действуют на уровне организации и делятся между всеми проектами. OpenAI может пересматривать их, поэтому проверяйте актуальные данные в панели аккаунта.

Как лимиты запросов влияют на рабочие процессы с изображениями при масштабировании?

Три аспекта: проектирование очереди (вам нужно клиентское ограничение до того, как сработает ограничение OpenAI), распределение задержки (p99 включает ожидание в очереди, а не только время модели) и дорожная карта (возможно, вы откладываете функции, которые создают пики, которые вы не можете поглотить). Типичная картина: команды строят под среднюю нагрузку, а потом обнаруживают, что пиковая нагрузка определяет пользовательский опыт.

Что командам нужно сделать перед запуском высоконагруженной функции?

Четыре шага. Оцените пиковый объём генерации за минуту, а не суточный. Убедитесь, что ваш тир покрывает это с ~30% запасом. Реализуйте экспоненциальную выдержку с джиттером и автоматическим выключателем. Определите запасной вариант на случай, если ёмкость исчерпана — предварительная генерация, альтернативная модель или graceful degradation. Режим отказа в день запуска, который нельзя исправить — это тот, который вы не спланировали.

Когда одного провайдера операционно недостаточно?

Когда пиковый спрос за минуту стабильно превышает ёмкость Tier 5 единственного провайдера, когда ваш SLA не может допустить окно простоя одного провайдера, или когда дисперсия задержки от ожидания в очереди остаётся видимой для пользователей, несмотря на оптимизацию. Большинство команд до этого не доходят. Те, кто доходит — обычно потребительские продукты с вирусными паттернами или корпоративные пайплайны со строгими SLA — добавляют предварительную генерацию, маршрутизацию между провайдерами, или и то и другое. Решение должно исходить из ваших логов пиковой нагрузки, а не из маркетинговой страницы вендора.

Заключение

Краткое резюме о лимитах запросов GPT Image 2: Tier 1 начинается с 5 IPM, Tier 5 ограничен 250 IPM, и пиковый трафик достигает этих потолков значительно быстрее, чем предполагает математика устойчивого состояния. Более развёрнутое резюме: лимиты запросов — это операционное ограничение при проектировании, а не сноска в документации. Они формируют вашу очередь, ваш SLA, область функциональности и план запуска.

Правильный вопрос для разработчиков — не «на каком тире я нахожусь», а «как выглядит моя пиковая минута, и поглощает ли мой тир её с запасом». Большинство команд узнают ответ неправильным способом — после того как запуск прошёл.

Продолжение следует, когда поработаю с GPT Image 2 на Tier 5. Цифры выше — от OpenAI, фреймирование моё, политики ёмкости обновляются быстрее, чем блог-посты.

Предыдущие посты:

• Руководство по GPT Image 2 API для продуктовых команд
• Ценообразование GPT Image 2: объяснение (2026)
• GPT Image 2 vs GPT Image 1.5 для продуктовых рабочих процессов
• Лучшие бесплатные AI-генераторы видео в 2026 году
• GPT-5.5 для разработчиков: что командам действительно стоит оценить