Skip to main content
Обычный вопрос, который мы получаем: «Совпадает ли поддерживаемое вами количество референсных изображений с официальным лимитом?» Официальные модели изображений Gemini от Google ограничены 14 референсными изображениями на один запрос — это самый высокий лимит, доступный сегодня в отрасли. Ответ — да, мы это поддерживаем — но «мы это поддерживаем» не должно быть просто голословным утверждением. Эта страница дает вам методику тестирования, которую вы можете воспроизвести сами, а также результаты реального теста объединения 14 изображений.

Почему стоит проверить это самостоятельно

14 reference images — это крайний сценарий: в повседневном использовании вы можете с ним не столкнуться, но если вам когда-нибудь нужно будет объединить несколько независимо созданных элементов в один композиционный результат (постер, рекламный визуал), вам нужно проверить две вещи:
  1. Действительно ли вызов проходит успешно? При добавлении 14 изображений размер тела запроса заметно увеличивается — не будет ли он отклонен из-за слишком большого объема?
  2. Результат слияния выглядит разумно? При таком количестве входных изображений модель не пропускает часть из них, не смешивает ли элементы и не размещает ли их неправильно?
Каждый из двух методов ниже нацелен на один из этих вопросов, и ни один из них не опирается на субъективную оценку эстетики — вы можете с первого взгляда понять, корректен ли результат.

Метод 1: Тест объективных маркеров (Сделайте это сначала)

Идея: вместо сложной сцены из реального мира сгенерируйте N карточек, которые визуально различимы и поддаются индивидуальному подсчету — самый простой вариант: числа от 1 до 14. Затем попросите модель скомпоновать их в одно изображение.
  • Для каждой карточки задайте совершенно разные цветовые схемы и стили материала (неоновая трубка, матовый металл, меловая надпись, пиксель-арт, резное дерево…), чтобы в объединенном результате каждое число можно было отследить до исходной карточки только по цвету и стилю;
  • После объединения просто оцените на глаз: есть ли все 14 чисел, без дубликатов и пропусков? Не нужно судить, «красиво ли это выглядит» — только «полно ли и правильно ли это».
14 креативных карточек с числами, объединенных в постер-сетку 3 ряда на 5 столбцов, при этом каждое число сохраняет свой уникальный цвет и стиль материала

14 visually distinct number cards fused into a single poster: 1–14 all clearly legible, each retaining the color and material style of its source image

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

Метод 2: Тест декомпозиции реального сценария

Идея: разбейте фактическую сцену, которую вы хотите получить, на N независимых элементов, сгенерированных отдельно, а затем попросите модель собрать их обратно в одну сцену. Это ближе к реальному использованию — например, отдельно управлять персонажем, одеждой, реквизитом и фоном, а затем скомпоновать итоговый кадр. В качестве примера мы декомпозировали сцену fashion-редакции на 14 независимых элементов: портрет модели, верхнюю одежду, транспортное средство, фон, питомца/аксессуар, сумку, украшения, обувь, багаж и так далее — каждый сгенерирован как отдельное изображение с единым базовым стилем (например, все снято на «светло-сером студийном фоне, реалистичная фотография»).
14 независимых fashion-элементов, объединенных в полноценную сцену fashion-редакции, где модель опирается на розовый автомобиль, а также присутствуют попугай, собака, сумка и другие элементы

14 independently generated fashion elements (model, outfit, car, pet, bag, accessories, etc.) fused into a single fashion editorial scene — all elements present, composition coherent

На что смотреть: все ли 14 элементов присутствуют в кадре, согласованы ли размещение и масштаб, и нет ли очевидной потери или искажения какого-либо элемента. Слияние в реальном сценарии естественно сложнее, чем «коллаж по числам» (разным элементам нужно единое освещение и перспектива), поэтому этот шаг — более реалистичный тест качества слияния в сложных реальных бизнес-сценариях.
Мы рекомендуем запускать оба метода: Метод 1 отвечает на вопрос «действительно ли модель обработала каждое входное изображение», Метод 2 — «достаточно ли хорошее качество слияния для сложного реального сценария». Если выполнять только Метод 2, сбой трудно диагностировать — вы не сможете понять, вызван ли он тем, что «модель пропустила изображение», или тем, что «композиция просто получилась неудачной».

Формат запроса: как уместить 14 изображений в один запрос

В нативном формате Gemini правило для слияния нескольких изображений простое: одна часть text (инструкция для слияния) + N частей inlineData (по одной на каждое референсное изображение). Каждая часть может быть только text или inlineData, но не обоими сразу.
Для полного формата редактирования нескольких изображений (структуру parts, распространенные ошибки) см. Справочник API редактирования изображений и Руководство разработчика серии Nano Banana.

Вопрос, который больше всего волнует клиентов: будет ли отклонён большой запрос?

Отправка 14 несжатых исходных изображений заметно увеличивает тело запроса. Мы провели реальный тест с фактическими цифрами (14 изображений в разрешении 2K, без сжатия):
Лимит APIYI на image-payload для одного запроса составляет 100MB (для синхронных вызовов, чтобы избежать чрезмерного использования памяти); одно изображение соответствует официальному правилу Google — не более 7MB. Наши 14 изображений в 2K в сумме заняли 42–43MB, что с большим запасом укладывается в оба лимита, поэтому запросы прошли без проблем.
Вывод: даже без сжатия 14 референсных изображений в 2K обычно не упираются в потолок полезной нагрузки. Тем не менее, сжатие по-прежнему рекомендуется — не потому, что несжатые загрузки отклоняются, а потому, что сжатые загрузки завершаются заметно быстрее (в нашем тесте та же задача слияния после сжатия заняла примерно в 1/2–1/3 от исходного времени, так как при этом не требуется передавать и выполнять серверное декодирование гораздо более крупной полезной нагрузки). Для конкретных параметров сжатия (целевой размер по длинной стороне, качество JPEG, суммарный бюджет размера для нескольких изображений) см. Сжатие изображений и выходное разрешение.

Если изображение не возвращается, сначала проверьте наличие блокировки по соображениям безопасности

Задачи с объединением нескольких изображений иногда сталкиваются с finishReason: IMAGE_SAFETY (статус HTTP по-прежнему 200, но content.parts пустой). В ходе тестирования повторный запуск с теми же самыми входными данными один или два раза часто помогает — у этого типа блокировки есть элемент случайности, и это не обязательно означает, что с входными данными действительно есть проблема.
Изображения, заблокированные по соображениям безопасности, не тарифицируются. Мы рекомендуем встроить автоматический повтор для IMAGE_SAFETY в вашу интеграцию, а не считать это критической ошибкой. С другими типами ошибок (блокировки по соображениям безопасности, модерация контента, тайм-ауты) и тем, как с ними работать, см. Руководство по обработке ошибок Gemini Image API.

Краткая справка

  • Официальный лимит Google — 14 reference images на запрос; APIYI подтвердил полную поддержку — вызовы проходят, а результаты fusion получаются согласованными.
  • При самостоятельном тестировании запускайте оба метода: тест с числовыми карточками проверяет полноту, а тест декомпозиции в реальном сценарии — качество fusion.
  • 14 исходных изображений в 2K — это примерно 40 МБ в сумме, что с запасом укладывается в лимит запроса APIYI в 100 МБ и лимит Google в 7 МБ на изображение, так что запрос не будет отклонен. Сжатие по-прежнему рекомендуется для более быстрой обработки.
  • Структура запроса с несколькими изображениями: 1 text part + N inlineData parts — никогда не объединяйте оба в одном part.
  • Если в ответе с IMAGE_SAFETY вы получаете пустое изображение, сначала повторите запрос еще один-два раза — часто это срабатывает, а заблокированные изображения не попадают в тарификацию.

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