Skip to main content
Краткий ответ: все image-модели в APIYI работают синхронно — вы отправляете запрос, держите соединение открытым, и сгенерированное изображение возвращается в том же ответе. Здесь нет async ID задачи и нет эндпоинта опроса; если ваш клиент отключится раньше, результат будет потерян, но запрос всё равно будет учтён в тарификации. Достаточный timeout — правило номер один при разработке API для изображений.

Три факта, которые нужно знать перед началом

Все выполняется синхронно

Один HTTP-запрос блокируется до завершения, что соответствует форме официального upstream API — режима «отправить и затем опрашивать» нет. Даже у upstream-провайдеров с асинхронной моделью (например, FLUX) шлюз оборачивает вызовы в синхронные, так что вам никогда не придется писать цикл опроса.

Нет task_id

Эндпоинта для поиска по task_id нет, и вы не можете позже восстановить изображение по request_id. APIYI прозрачно проксирует запросы и не хранит сгенерированные результаты — как только соединение разрывается, результат восстановить нельзя.

Отключения по-прежнему тарифицируются

Если ваш клиент истекает по тайм-ауту и отключается, сервер и upstream все равно завершают генерацию, и запрос тарифицируется как обычно. Слишком маленький тайм-аут означает, что вы платите за изображения, которые так и не получаете.

Краткая справка по сериям моделей

Рекомендуемые тайм-ауты, форматы вывода и поддержка URL для каждой серии моделей изображений:
response_format имеет узкую область поддержки: только GPT-Image-2-All / VIP и Seedream принимают его; официальный канал GPT-Image-2 возвращает 400 unknown_parameter, если вы его передадите. Если поддерживается, всегда передавайте его явно, а не полагайтесь на значение по умолчанию — исторически оно различалось между группами и при разных нагрузках.

Тарификация и что влияет на цену

Самый частый вопрос о тарификации от новичков: «Каждое референсное изображение оплачивается по фиксированной ставке или более крупные изображения потребляют больше tokens?» Начните с трех интуитивных выводов:

Стоимость определяется выходом

Возьмем gpt-image-2 в качестве примера: входной text $5/M, image input $8/M, output $30/M. Главные рычаги цены — это всегда размер и качество output (quality × size); количество референсных изображений идет на втором месте.

Входные изображения — не по фиксированной ставке

Входные изображения семейства GPT сопоставляются с tokens по размерам/соотношению сторон (чем больше, тем больше tokens, с нижним и верхним пределом), а количество суммируется строго линейно. У семейства Gemini все наоборот — output images стоят фиксированное количество tokens на каждый уровень разрешения.

Доверяйте возвращаемым usage

И входные, и выходные tokens указаны в ответе: у семейства GPT — в usage.input_tokens_details.image_tokens, у семейства Gemini — в usageMetadata.promptTokensDetails. Сверяйте и рассчитывайте цену по ним — никогда не оценивайте по количеству изображений.

Учет tokens: два семейства моделей

Интуиция по стоимости при нескольких входных изображениях

  • Одно референсное изображение обходится примерно в 800-1600 image tokens ≈ $0.008-0.012 (gpt-image-2, измерено, зависит от размеров/соотношения сторон);
  • Количество суммируется линейно: 16 изображений ≈ $0.13, то есть примерно того же порядка, что и один high output (≈$0.21) — стоимость входа больше не является незначительной в многоизображенческой fusion;
  • Tokens определяются размерами в пикселях, а не размером файла: сжатие файлов помогает стабильности загрузки, но не экономит tokens; чтобы сэкономить tokens, уменьшайте количество изображений (слишком большие изображения все равно ограничиваются, так что бесконтрольного роста счетов тоже не будет).
Полная таблица измерений: gpt-image-2 — Как несколько входных изображений влияют на цену; учет tokens для семейства Gemini: руководство по usageMetadata и ценообразование Nano Banana.

Настройка таймаута

Почему стандартные таймауты ломают работу

Большинство HTTP-клиентов по умолчанию используют таймауты 30–60 секунд (requests сам по себе не имеет ограничения, но его часто оборачивают фреймворки, добавляющие ~30 с), тогда как генерация изображений — это действительно долгий запрос:
  • GPT-Image-2 в качестве high с разрешением 2K/4K занимает 3–5 минут от начала до конца;
  • изображения серии Nano Banana в 4K обычно начинаются примерно с 50 секунд, а в пиковые периоды — дольше;
  • запросы на слияние нескольких изображений и редактирование изображений, как правило, медленнее, чем text-to-image.
При стандартных настройках клиент разрывает соединение, пока сервер все еще нормально выполняет генерацию — вы видите волну «таймаутов», которые на самом деле являются успешными запросами, от которых вы отключились сами, и каждый из них тарифицируется.

Уровни таймаута по моделям

Стратегия повторных попыток

Не каждая ошибка заслуживает повторной попытки — начните с того, как каждый случай тарифицируется:
Тарификация при блокировке модерацией зависит от модели: модели с тарификацией по token (официальный GPT-Image-2 и т. д.) обычно возвращают ошибку 400, когда срабатывает модерация, — не тарифицируется. Только Nano Banana Pro с тарификацией за изображение попадает под блокировку на стороне Google вида «HTTP 200, но генерация не удалась», и такой вызов тарифицируется — APIYI покрывает эти сбои не по вине пользователя по Плану возмещения кредитов за неудачную генерацию, который возмещает кредиты на основе подсчета по каждому изображению.

Работа с выводом base64

Различия префикса

base64-данные не одинаковы для разных серий — это самая распространенная ловушка при новых интеграциях: Поведение префикса менялось между версиями канала, поэтому всегда сначала проверяйте startsWith("data:"): удаляйте префикс перед декодированием (или используйте значение напрямую как img src), если он присутствует, а сырые значения декодируйте как есть — это позволяет избежать и ошибки с двойным префиксом, и сбоев декодирования для данных с префиксом.

Декодирование в файл

Ограничения рендеринга в Playground

ответы base64 часто занимают несколько мегабайт, и браузерный Playground может показать unable to complete request — это не означает, что запрос не выполнен. Запрос был успешно обработан и тарифицирован; браузер просто не может отрендерить строку такой длины. Проверьте результат через код или переключитесь на модель/параметр, который возвращает url.

Предобработка входных изображений

Эндпоинты image-edit / reference-image (например, /v1/images/edits для gpt-image-2) принимают только png / jpg / webp. В продуктах, где пользователи могут загружать собственные фотографии, есть одна особенно коварная ловушка: фотографии прямо с камеры телефона часто не являются стандартным JPEG.

Типичный симптом: 400 invalid_image_file

Обычно это вызвано форматом MPO (Multi-Picture Object, многокадровый JPEG-контейнер): .jpg файлы прямо с телефонов Huawei Mate-серии и похожих моделей встраивают HDR gain-map sub-frame и на самом деле являются MPO. Коварство в том, что файл начинается с того же заголовка FFD8расширение, HTTP Content-Type и команда file все сообщают JPEG — и только разбор с учетом кадров показывает правду:
Проверено в июле 2026 года (эндпоинт редактирования gpt-image-2): изображения MPO всегда отклоняются, тогда как то же изображение, перекодированное в стандартный JPEG/PNG, успешно проходит с полным исходным разрешением (3072×4096) — проблема в формате, а не в размере. Этот 400 возвращается быстро на этапе проверки входных данных и не тарифицируется.

Рекомендация: перекодируйте на стороне сервера, единообразно

Вместо отладки фотографий по одной добавьте в ваш upload pipeline один шаг перекодирования — он также обрабатывает HEIC, CMYK и другие нестандартные входные данные:
Во время перекодирования уменьшайте и размер payload (длинная сторона до 4096, качество JPEG 80-92) и держите каждое изображение меньше 1.5MB — это повышает успешность загрузки и скорость генерации, а качество результата не зависит от размера входного файла. См. редактирование изображений gpt-image-2: требования к формату reference image и предварительная обработка.

Предварительная обработка формата входного изображения

Эндпоинты для редактирования изображений / работы с референсным изображением (например, /v1/images/edits у gpt-image-2) принимают в качестве входных данных только png / jpg / webp. В продуктах, где используются фотографии, сделанные пользователем, есть одна особенно коварная ловушка: фотографии, прямо снятые на камеру телефона, часто не являются стандартным JPEG.

Типичный симптом: 400 invalid_image_file

Обычная причина — формат MPO (Multi-Picture Object, многофреймовый JPEG-контейнер): .jpg файлы, полученные прямо с телефонов серии Huawei Mate, содержат HDR gain-map sub-frame и на самом деле являются MPO. Коварство этих файлов в том, что заголовок у них тот же FFD8расширение, HTTP Content-Type и команда file все сообщают JPEG — и распознать это может только разбор с учетом кадров:
Проверено в июле 2026 года (эндпоинт редактирования gpt-image-2): файлы MPO всегда отклоняются; то же изображение, перекодированное в стандартный JPEG/PNG, успешно проходит при полном исходном разрешении (3072×4096) — проблема в формате, а не в размере. Этот 400 возвращается быстро на этапе валидации входных данных и не тарифицируется.

Рекомендация: перекодируйте единообразно на стороне сервера

Вместо отладки изображений по одному добавьте один шаг перекодирования в ваш конвейер загрузки — он также покрывает HEIC, CMYK и другие нестандартные входные данные:
Во время перекодирования сразу выполняйте сжатие (длина длинной стороны не более 4096px, качество JPEG 80-92) и удерживайте каждое изображение в пределах 1.5MB — успешность загрузки и скорость генерации изображений обе улучшаются, а качество результата не зависит от размера входного файла. См. gpt-image-2 Image Edit — Требования к формату референсного изображения и предварительная обработка.

Получение URL-вывода вместо этого

Существует три пути, в порядке надежности:
  1. URL — это upstream-значение по умолчанию — FLUX (действительно только около 10 минут, без заголовков CORS; скачайте и немедленно повторно разместите на server-side) и Seedream (BytePlus TOS, около 24 часов) нативно возвращают URL, без необходимости какой-либо настройки.
  2. Группы OSS (детерминированный вывод URL — рекомендуется для production):
    • image2_OSS группа: охватывает GPT-Image-2-All / VIP (коэффициент тарифа 1x, без доплаты); переключите свой token на эту группу, чтобы получать стабильный вывод URL без fallback на base64. Официальный канал GPT-Image-2 пока не покрывается.
    • NB_OSS beta-группа: охватывает серию Nano Banana, при этом URL изображения передается в поле text — см. руководство по группе NB-OSS.
  3. Явный response_format: "url" — его принимают только GPT-Image-2-All / VIP (R2 CDN, около 24 часов) и Seedream; поверхность узкая, а официальный канал GPT-Image-2 возвращает 400, если вы его передадите. Это переключатель на уровне запроса для группы по умолчанию — бизнесу, который зависит от URL, следует использовать группу OSS вместо этого.
GPT-Image-2 (Official) в настоящее время вообще не имеет пути вывода URL — только base64.
Каждый URL изображения, который возвращают эти платформы, — это временная ссылка (от 10 минут до 24 часов). Все, что требует долгосрочного хранения — изображения продуктов, пользовательские создания, история — должно быть немедленно повторно размещено в вашем собственном object storage / CDN сразу после генерации, а ваш собственный URL должен быть сохранен в вашей базе данных.

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

Если вы уже увеличили таймаут SDK и все еще видите частые «таймауты», пройдите по этому чек-листу:
1

Проверьте фактический таймаут на стороне клиента

Фреймворки часто оборачивают HTTP-клиент еще одним слоем таймаута (лимиты worker’ов очереди задач, ограничения времени выполнения serverless). Любой слой, который короче времени генерации модели, прервет запрос.
2

Проверьте промежуточные звенья: nginx / балансировщики нагрузки / CDN

Самостоятельно размещенные reverse proxy (proxy_read_timeout), таймауты простоя cloud load balancer и таймауты origin у CDN обычно по умолчанию составляют 60 секунд и оборвут соединение раньше, чем это сделает ваш клиент. Для каждого перехода на пути длинного запроса нужно увеличить лимит.
3

Включите keep-alive, чтобы простаивающие соединения не сбрасывались

Соединения, по которым долго не передаются байты, могут незаметно разрываться устройствами NAT или firewall; TCP- или HTTP keep-alive значительно снижает риск.
4

Используйте request ID и логи консоли, чтобы проверить тарификацию

Запишите заголовок ответа x-request-id и найдите его в логах вызовов консоли APIYI. Если вызов там отображается, сервер завершил генерацию и выставил тарификацию за запрос — соединение было разорвано на вашей стороне пути.

Хотите асинхронное управление в стиле задач?

Платформа не предоставляет async API, но вы можете самостоятельно построить асинхронную оболочку поверх синхронных эндпоинтов:

Почему нет асинхронного API

FAQ: Есть ли async API для изображений? Могу ли я получать результаты по task ID?

Создайте собственную асинхронную очередь

Руководство для инженеров: оберните синхронные вызовы в очередь задач с собственным task_id, персистентностью и повторными попытками

Группа вывода URL NB-OSS

Переключите вывод Nano Banana на URL и сократите накладные расходы на передачу base64