> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Руководство по тестированию слияния нескольких изображений
> Клиенты часто спрашивают, совпадает ли лимит на reference image с официальным ограничением Google (14 изображений). Ниже приведены два повторно используемых метода тестирования, а также реальный тест слияния 14 изображений, который мы провели сами.
Обычный вопрос, который мы получаем: **«Совпадает ли поддерживаемое вами количество референсных изображений с официальным лимитом?»** Официальные модели изображений Gemini от Google ограничены **14 референсными изображениями на один запрос** — это самый высокий лимит, доступный сегодня в отрасли. Ответ — **да, мы это поддерживаем** — но «мы это поддерживаем» не должно быть просто голословным утверждением. Эта страница дает вам методику тестирования, которую вы можете воспроизвести сами, а также результаты реального теста объединения 14 изображений.
## Почему стоит проверить это самостоятельно
14 reference images — это **крайний сценарий**: в повседневном использовании вы можете с ним не столкнуться, но если вам когда-нибудь нужно будет объединить несколько независимо созданных элементов в один композиционный результат (постер, рекламный визуал), вам нужно проверить две вещи:
1. **Действительно ли вызов проходит успешно?** При добавлении 14 изображений размер тела запроса заметно увеличивается — не будет ли он отклонен из-за слишком большого объема?
2. **Результат слияния выглядит разумно?** При таком количестве входных изображений модель не пропускает часть из них, не смешивает ли элементы и не размещает ли их неправильно?
Каждый из двух методов ниже нацелен на один из этих вопросов, и ни один из них не опирается на субъективную оценку эстетики — вы можете с первого взгляда понять, корректен ли результат.
## Метод 1: Тест объективных маркеров (Сделайте это сначала)
**Идея**: вместо сложной сцены из реального мира сгенерируйте N карточек, которые **визуально различимы и поддаются индивидуальному подсчету** — самый простой вариант: числа от 1 до 14. Затем попросите модель скомпоновать их в одно изображение.
* Для каждой карточки задайте совершенно разные цветовые схемы и стили материала (неоновая трубка, матовый металл, меловая надпись, пиксель-арт, резное дерево…), чтобы в объединенном результате **каждое число можно было отследить до исходной карточки только по цвету и стилю**;
* После объединения просто оцените на глаз: **есть ли все 14 чисел, без дубликатов и пропусков?** Не нужно судить, «красиво ли это выглядит» — только «полно ли и правильно ли это».
Преимущество этого метода — **устранение шума**: если модель успешно проходит самый базовый проверочный шаг — «числа верны» — это весомое доказательство того, что она действительно обрабатывает каждое входное изображение, а не просто выбирает несколько наугад.
## Метод 2: Тест декомпозиции реального сценария
**Идея**: разбейте фактическую сцену, которую вы хотите получить, на N независимых элементов, сгенерированных отдельно, а затем попросите модель собрать их обратно в одну сцену. Это ближе к реальному использованию — например, отдельно управлять персонажем, одеждой, реквизитом и фоном, а затем скомпоновать итоговый кадр.
В качестве примера мы декомпозировали сцену fashion-редакции на 14 независимых элементов: портрет модели, верхнюю одежду, транспортное средство, фон, питомца/аксессуар, сумку, украшения, обувь, багаж и так далее — каждый сгенерирован как отдельное изображение с единым базовым стилем (например, все снято на «светло-сером студийном фоне, реалистичная фотография»).
На что смотреть: **все ли 14 элементов присутствуют в кадре**, согласованы ли размещение и масштаб, и нет ли очевидной потери или искажения какого-либо элемента. Слияние в реальном сценарии естественно сложнее, чем «коллаж по числам» (разным элементам нужно единое освещение и перспектива), поэтому этот шаг — более реалистичный тест качества слияния в сложных реальных бизнес-сценариях.
Мы рекомендуем запускать **оба метода**: Метод 1 отвечает на вопрос «действительно ли модель обработала каждое входное изображение», Метод 2 — «достаточно ли хорошее качество слияния для сложного реального сценария». Если выполнять только Метод 2, сбой трудно диагностировать — вы не сможете понять, вызван ли он тем, что «модель пропустила изображение», или тем, что «композиция просто получилась неудачной».
## Формат запроса: как уместить 14 изображений в один запрос
В нативном формате Gemini правило для слияния нескольких изображений простое: **одна часть `text` (инструкция для слияния) + N частей `inlineData` (по одной на каждое референсное изображение)**. Каждая часть может быть только `text` или `inlineData`, но не обоими сразу.
```python theme={null}
import requests
import base64
API_KEY = "sk-your-api-key"
def to_b64(path):
with open(path, "rb") as f:
return base64.b64encode(f.read()).decode()
# Up to 14 reference images
image_paths = ["01.png", "02.png", "03.png", "..."] # max 14
parts = [{"text": "Fuse the elements from these images into a single coherent scene, keeping the style consistent and the composition balanced"}]
for path in image_paths:
parts.append({"inlineData": {"mimeType": "image/png", "data": to_b64(path)}})
response = requests.post(
"https://api.apiyi.com/v1beta/models/gemini-3.1-flash-image:generateContent",
headers={"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"},
json={
"contents": [{"parts": parts}],
"generationConfig": {
"responseModalities": ["IMAGE"],
"imageConfig": {"aspectRatio": "1:1", "imageSize": "2K"}
}
},
timeout=600 # more images and a larger request body — allow a generous timeout
).json()
img_data = response["candidates"][0]["content"]["parts"][0]["inlineData"]["data"]
with open("fused.png", "wb") as f:
f.write(base64.b64decode(img_data))
```
Для полного формата редактирования нескольких изображений (структуру `parts`, распространенные ошибки) см. [Справочник API редактирования изображений](/ru/api-capabilities/nano-banana-image/image-edit) и [Руководство разработчика серии Nano Banana](/ru/api-capabilities/nano-banana-dev-guide).
## Вопрос, который больше всего волнует клиентов: будет ли отклонён большой запрос?
Отправка 14 несжатых исходных изображений заметно увеличивает тело запроса. Мы провели реальный тест с фактическими цифрами (14 изображений в разрешении 2K, без сжатия):
| Параметр | Измеренное значение |
| -------------------------------------------------- | ------------------------------------------------------------------------------ |
| Размер одного исходного изображения | \~1.7MB – 4.0MB |
| 14 изображений вместе (после кодирования в Base64) | **\~42–43MB** |
| Результат запроса | **Все успешно выполнены** — отклонения из-за размера полезной нагрузки не было |
Лимит APIYI на image-payload для одного запроса составляет **100MB** (для синхронных вызовов, чтобы избежать чрезмерного использования памяти); одно изображение соответствует официальному правилу Google — не более **7MB**. Наши 14 изображений в 2K в сумме заняли 42–43MB, что с большим запасом укладывается в оба лимита, поэтому запросы прошли без проблем.
**Вывод**: даже без сжатия 14 референсных изображений в 2K обычно не упираются в потолок полезной нагрузки. Тем не менее, **сжатие по-прежнему рекомендуется** — не потому, что несжатые загрузки отклоняются, а потому, что сжатые загрузки завершаются **заметно быстрее** (в нашем тесте та же задача слияния после сжатия заняла примерно в 1/2–1/3 от исходного времени, так как при этом не требуется передавать и выполнять серверное декодирование гораздо более крупной полезной нагрузки). Для конкретных параметров сжатия (целевой размер по длинной стороне, качество JPEG, суммарный бюджет размера для нескольких изображений) см. [Сжатие изображений и выходное разрешение](/ru/api-capabilities/image-compression-resolution).
## Если изображение не возвращается, сначала проверьте наличие блокировки по соображениям безопасности
Задачи с объединением нескольких изображений иногда сталкиваются с `finishReason: IMAGE_SAFETY` (статус HTTP по-прежнему 200, но `content.parts` пустой). В ходе тестирования **повторный запуск с теми же самыми входными данными один или два раза часто помогает** — у этого типа блокировки есть элемент случайности, и это не обязательно означает, что с входными данными действительно есть проблема.
Изображения, заблокированные по соображениям безопасности, **не тарифицируются**. Мы рекомендуем встроить автоматический повтор для `IMAGE_SAFETY` в вашу интеграцию, а не считать это критической ошибкой. С другими типами ошибок (блокировки по соображениям безопасности, модерация контента, тайм-ауты) и тем, как с ними работать, см. [Руководство по обработке ошибок Gemini Image API](/ru/api-capabilities/gemini-image-error-handling).
## Краткая справка
* Официальный лимит Google — **14 reference images на запрос**; APIYI подтвердил полную поддержку — вызовы проходят, а результаты fusion получаются согласованными.
* При самостоятельном тестировании запускайте **оба метода**: тест с числовыми карточками проверяет полноту, а тест декомпозиции в реальном сценарии — качество fusion.
* 14 исходных изображений в 2K — это примерно 40 МБ в сумме, что **с запасом укладывается в лимит запроса APIYI в 100 МБ и лимит Google в 7 МБ на изображение**, так что запрос не будет отклонен. Сжатие по-прежнему рекомендуется для более быстрой обработки.
* Структура запроса с несколькими изображениями: **1 text part + N inlineData parts** — никогда не объединяйте оба в одном part.
* Если в ответе с `IMAGE_SAFETY` вы получаете пустое изображение, сначала повторите запрос еще один-два раза — часто это срабатывает, а заблокированные изображения не попадают в тарификацию.
## Связанные документы
* [Руководство разработчика серии Nano Banana](/ru/api-capabilities/nano-banana-dev-guide)
* [Сжатие изображений и выходное разрешение](/ru/api-capabilities/image-compression-resolution)
* [Руководство по обработке ошибок Gemini Image API](/ru/api-capabilities/gemini-image-error-handling)
* [Как получать изображения, которые вас устраивают](/ru/api-capabilities/image-generation-success-tips)