Skip to main content

Краткий ответ

Если API генерации изображений Gemini возвращает HTTP 200, но в ответе нет candidates и присутствует только promptFeedback.blockReason (чаще всего OTHER), запрос был заблокирован проверкой входных данных провайдера до начала генерации.
  • Такая блокировка обычно возвращается в течение нескольких секунд — гораздо быстрее, чем обычное изображение
  • OTHER не указывает причину, а safetyRatings часто пуст
  • Это не обязательно связано с тем, как составлен prompt; часто блокировку вызывает одно референсное изображение
  • gemini-3-pro-image (Nano Banana Pro) проверяет входные данные строже, чем gemini-3.1-flash-image, поэтому один и тот же запрос может быть заблокирован на Pro и успешно пройти на flash
Подход следующий: сначала определите, какое именно изображение вызывает блокировку, а затем единообразно выполните предварительную обработку всех референсных изображений.

Как это распознать

Типичный ответ выглядит следующим образом:

Протестированный кейс

В сентябре 2026 года (UTC+8) мы повторно запустили запрос для каталога одежды: один prompt плюс 6 референсных изображений (поза, человек, сцена, наряд, коллаж из обуви и носков, а также головной убор), 2:3, 2K, responseModalities: ["IMAGE"].
  • gemini-3-pro-image вернула blockReason: OTHER 3 раза подряд; тот же запрос успешно выполнился на gemini-3.1-flash-image
  • Путем последовательного разделения набора изображений пополам мы выяснили, что единственным триггером было референсное изображение человека: сгенерированный ИИ модельный лист персонажа с ракурсами спереди, сзади, сбоку и крупным планом лица
  • Это изображение блокировалось с любым prompt, включая несвязанные инструкции вроде «измени фон на светло-серый»
  • Два изображения, вызывавшие наибольшие подозрения — фото позы реального человека с водяным знаком и фото головного убора с логотипом, — по отдельности прошли проверку
Ключевой вывод: Иными словами, эта проверка может быть очень чувствительна к точным значениям пикселей конкретных изображений, и однократный повторный экспорт изображения позволяет пропустить запрос. Провайдер не публикует информацию о том, на чем основан OTHER, поэтому мы не можем установить более точную причину.
Этот пример показывает, что отправка большого количества референсных изображений в одном запросе или объединение нескольких шагов в одну генерацию сами по себе не являются проблемой. Когда вы видите OTHER, сначала найдите проблемное изображение, прежде чем переписывать prompt или разделять рабочий процесс.

Как найти изображение

1

Шаг 1: Проверьте воспроизводимость

Отправьте запрос без изменений 2–3 раза. Блокировка blockReason обычно стабильно воспроизводится. Если сбой происходит лишь иногда, проблема, скорее всего, относится к типу NO_IMAGE.
2

Шаг 2: Исключите prompt

Оставьте все изображения и замените prompt простой несвязанной инструкцией, например «сделайте фон светло-серым». Если запрос по-прежнему блокируется, причина кроется в изображениях.
3

Шаг 3: Разделите изображения пополам

Отправьте каждую половину по отдельности, затем продолжайте делить только ту половину, которая по-прежнему блокируется, пока не дойдете до одного изображения. Для шести изображений потребуется максимум три раунда.
4

Шаг 4: Исправьте это изображение

Экспортируйте изображение повторно, как описано ниже в разделе «Рекомендации», затем отправьте полный запрос еще раз для подтверждения.
В процессе сужения круга поиска одного сгенерированного изображения достаточно, чтобы пометить группу как «пройдено», поэтому повторять запрос нет необходимости. Двух блокировок подряд достаточно, чтобы пометить ее как «заблокировано». Весь поиск обычно занимает всего около десятка вызовов.

Рекомендации

Сценарий 1: Ручная работа (генерация на холсте или в инструменте)

  1. Экспортируйте референсные изображения повторно перед их загрузкой: используйте любой графический редактор (например, встроенную программу «Просмотр» или Photoshop), чтобы экспортировать JPEG с качеством 90–95 и длинной стороной не более 2048px.
  2. Уменьшайте разрешение больших изображений: оригиналы с длинной стороной 3000–4000px можно уменьшить до 2048px без ущерба для результата, при этом они будут загружаться быстрее.
  3. Если запрос завершается с ошибкой в течение нескольких секунд, в первую очередь проверьте референсное изображение: повторно экспортируйте изображение, добавленное последним, и повторите попытку. Если это не помогло, проверьте изображения по очереди, как описано выше.
  4. Отдавайте предпочтение изображениям в полный рост в качестве референсов персонажей: в описанном выше случае фронтальный вид в полный рост прошел проверку сам по себе после разделения листа персонажа. Если лист персонажа постоянно блокируется, попробуйте использовать только его вид в полный рост.
  5. Временная альтернатива: если изображение не проходит проверку на Pro, используйте для этого шага gemini-3.1-flash-image.

Сценарий 2: Код (автоматизированная обработка)

1. Предварительно обрабатывайте каждое референсное изображение перед отправкой, а не обрабатывайте изображения по отдельности: преобразуйте в sRGB → примените ориентацию EXIF → ограничьте длинную сторону до 2048px → повторно закодируйте в JPEG (качество 90–95) → удалите метаданные. Основное преимущество — значительно меньший размер тела запроса и более быстрая загрузка (исходный запрос в описанном выше случае составлял около 4,6 МБ). Это также снижает количество блокировок OTHER такого рода. Пример для Node.js:
Тот же пайплайн на Python с использованием Pillow:
2. Обрабатывайте каждый тип сбоев по-разному:
Автоматические повторные попытки применимы только к OTHER, причина которых неизвестна. При явных причинах безопасности повторное кодирование изображений не может и не должно использоваться для изменения результата; вместо этого попросите пользователя скорректировать контент.
3. Логируйте детали для устранения неполадок: при каждом сбое сохраняйте responseId, а также хеш и размеры каждого референсного изображения. Это позволит вам быстро найти изображение и предоставит нам необходимую информацию, если вы обратитесь в службу поддержки.

Часто задаваемые вопросы

Эти две модели используют разные проверки входных данных, и Pro строже. Ситуация, когда референсное изображение проходит в flash и блокируется в Pro, является ожидаемым поведением и не означает, что сам запрос некорректен.
Да. Заблокированное изображение в примере выше представляло собой лист персонажа, повторно сгенерированный из собственных фотографий клиента. Блокировка изображения не зависит напрямую от источника его происхождения; найдите и выполните его предварительную обработку, как описано на этой странице.
В рассмотренном выше случае 6 изображений не были проблемой: после замены одного изображения человека весь запрос из 6 изображений сгенерировался нормально.
Проверьте журналы вызовов APIYI, чтобы подтвердить, была ли создана запись о списании средств по данному запросу.

Проблема не решилась? Свяжитесь с поддержкой

Пожалуйста, укажите следующую информацию, чтобы мы могли помочь:
  • Название модели и группу token;
  • Полный ответ (как минимум promptFeedback и responseId), а также request ID;
  • Время возникновения (с часовым поясом);
  • Референсное изображение, которое вы определили, если вы можете им поделиться.
Никогда не отправляйте API-ключ полностью. Скройте ключ перед отправкой скриншотов или логов.

Поддержка в WeCom

QR-код поддержки в WeComОтсканируйте QR-код или нажмите на эту карточку, чтобы связаться с поддержкой напрямую.

Поддержка по электронной почте

Поддержка: [email protected]Рекомендуем указать «blockReason» и название модели в теме письма.

Связанная документация

Почему API изображений Gemini возвращает NO_IMAGE?

Отсутствие изображений из-за неясного намерения в prompt и способы это исправить

Сбои генерации изображений Nano Banana

Распространенные причины, включая безопасность, удаление водяных знаков, известные объекты интеллектуальной собственности и несовершеннолетних

Обработка ошибок в API изображений Gemini

Полный порядок проверки ответов и понятные пользователю сообщения об ошибках

Как читать суммы тарификации в логах?

Используйте логи вызовов, чтобы проверить, был ли запрос успешным и была ли списана плата