Skip to main content

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

Три предложения:
  1. «Умеет видеть изображения» и «умеет создавать изображения» — это две разные возможности. Почти каждая современная чат-модель умеет читать изображения (обычно именно это означает «мультимодальная»), но не умеет генерировать изображения — для этого существует отдельный класс специализированных моделей генерации изображений.
  2. Только семейство моделей Gemini для работы с изображениями действительно возвращает текст и изображение из одного эндпоинта — gemini-3-pro-image (Nano Banana Pro), gemini-3.1-flash-image (Nano Banana 2) и другие модели этого семейства чередуют текстовые и графические части в одном ответе.
  3. Всё остальное — это оркестрация: чат-модель и отдельный эндпоинт генерации изображений (Images API), работающие вместе. Встроенный инструмент image_generation OpenAI Responses не рекомендуется использовать в APIYI — его можно тарифицировать только по фиксированной ставке за вызов, что не является разумной моделью ценообразования, а его стабильность не гарантируется.

​
Сначала отделите входящие изображения от исходящих

Большая часть путаницы связана со словом «multimodal» — в контексте API по умолчанию оно относится к стороне входных данных, то есть «вы можете подать модели изображение», а не «модель может создать изображение для вас». Эти два сценария используют разные пулы моделей, разные эндпоинты и разную тарификацию:
Так что если кто-то спрашивает: «у вас есть multimodal chat API»: если ему нужно загрузить изображение, чтобы модель его проанализировала, ответ — «это поддерживают почти все». Если же он хочет, чтобы модель нарисовала изображение, это совершенно другой набор моделей. Один такой уточняющий вопрос экономит большую часть последующего разговора.

​
Четыре способа получить изображение

Самый стандартный, дешёвый и простой для отладки способ. GPT-Image, FLUX, Seedream и Grok Imagine используют именно его.
FLUX и Seedream обычно возвращают data[0].url; семейство GPT-Image возвращает data[0].b64_json. Этот способ вообще не возвращает диалоговый текст — это не эндпоинт чата.Полная таблица моделей: Модели для генерации изображений и видео. Отличия эндпоинтов, тайм-аутов и форматов вывода для отдельных моделей: Примечания и рекомендации по Image API.
Серия Nano Banana (gemini-3-pro-image, gemini-3.1-flash-image и другие модели) использует встроенный эндпоинт Gemini, а candidates[0].content.parts представляет собой гетерогенный массив: он может содержать только часть с изображением или чередовать текстовые части с частями изображений. Именно это семейство действительно позволяет получить и текст, и изображение за один вызов.Важно заранее учесть один нюанс: ни количество частей, ни их порядок не гарантируются. При тестировании наблюдались три варианта:Поэтому жёстко заданные parts[0] или parts[1] периодически будут приводить к ошибке. Правильный подход — отфильтровать элементы по наличию поля и взять последний inlineData (для сложных промптов модель возвращает несколько изображений, и последнее из них является финальной версией):
Полная информация: руководство разработчика по серии Nano Banana.
Этот способ вызывает POST /v1/responses с помощью gpt-5.5 и подключает встроенный инструмент изображений:
Модель самостоятельно решает, нужно ли рисовать, а изображение возвращается в виде base64 внутри элемента image_generation_call в массиве output ответа вместе с обычным текстовым выводом. По своей структуре это ближе всего к «чат-модели, которая рисует» на стороне OpenAI — но APIYI не рекомендует этот способ.
Почему: на APIYI инструмент изображений внутри Responses можно тарифицировать только за каждый вызов — фиксированная плата за вызов инструмента составляет примерно $0.20 за изображение, без варианта оплаты по использованию, как в способе A, — это нерациональная модель тарификации. Кроме того, из-за ограничений поставок мы не можем гарантировать стабильность этого способа.Для генерации изображений всегда используйте Images API способа A (/v1/images/generations / /v1/images/edits), тарифицируемый по использованию. Если вы хотите, чтобы «агент сам решал, рисовать ли», реализуйте это с помощью приведённой ниже оркестрации «чат и рисование» — результат будет тем же, но с прозрачной тарификацией.
gpt-image-2-all и gpt-image-2-vip можно вызывать через /v1/chat/completions, при этом изображение встраивается в виде ссылки Markdown внутри choices[0].message.content.Это выглядит как «один эндпоинт чата, который и разговаривает, и рисует», но это не чат-модель, способная рисовать — фактически это всё ещё модель изображений, обёрнутая в схему чата, без общих диалоговых возможностей. Кроме того, она использует только image_url в последнем сообщении user в качестве исходного изображения; изображения в истории сообщений ассистента игнорируются.Этот способ больше не рекомендуется — для новых интеграций используйте способ A.

​
Создание продукта «chat and draw»: рекомендуемая схема

Что большинству агентов и продуктов на самом деле нужно, — это не один волшебный эндпоинт, а четкая цепочка оркестрации:
1

Пусть chat-модель определяет намерение

Используйте chat-модель, которую вы уже используете (gpt-5.5, claude-opus-5, gemini-3-pro и так далее), чтобы обработать ввод пользователя и определить, является ли этот ход диалогом или запросом на генерацию изображений. При необходимости можно вернуть структурированный флаг.
2

Пусть chat-модель сформирует prompt для генерации изображений

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

Вызовите эндпоинт для генерации изображений

Используйте /v1/images/generations маршрута A. Возьмите возвращенный url или b64_json и сохраните его в вашем собственном object storage.
4

Верните изображение обратно в диалог

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

​
Как проверить, принимает ли модель изображения

1

1. Проверьте страницу с подробностями модели

Откройте /models/<model-name> и посмотрите на строку Модальности ввода в таблице характеристик вверху — если там указано «image», модель поддерживает работу с изображениями. Это самый быстрый способ проверки.
2

2. Если сомневаетесь, протестируйте

Отправьте минимальный запрос с изображением и посмотрите на ответ:
3

3. Распознайте строку ошибки

Текстовые модели явно возвращают ошибку. Исходное сообщение выглядит так: Model do not support image input (грамматика у них такая, это не опечатка). Когда вы видите эту строку, модель не принимает изображения — переключитесь на другую модель.
Известные исключения, работающие только с текстом (по состоянию на 2026-08-20): deepseek-v4-pro, deepseek-v4-flash, glm-5.2.Это меньшинство среди «современных моделей, которые всё ещё не принимают входные изображения», и они часто подводят пользователей. Этот список меняется по мере изменения каталога моделей — возможности также различаются между поколениями одного и того же поставщика. Всегда считайте строку «Модальности ввода» на странице модели и результат собственного теста источником истины, а не постоянным списком.

​
Пять распространённых заблуждений

Неверно. В контексте API мультимодальность по умолчанию означает возможность работы со стороны входных данных. gpt-5.5 может прочитать отправленный вами макет дизайна, но не может самостоятельно вывести изображение — чтобы получить его, необходимо отдельное обращение к эндпоинту изображений (маршрут A); встроенный инструмент изображений Responses (маршрут C) не рекомендуется в APIYI.
Неверно. Модели изображений не обладают общими возможностями ведения диалога — не размещайте gpt-image-2 за чат-ботом поддержки. Даже варианты -all / -vip, которые принимают эндпоинт чата (маршрут D), в основе всё равно остаются моделями изображений.
Обратное неверно. Объявление responseModalities: ["TEXT", "IMAGE"] не гарантирует наличие текстовой части в ответе; модель может вернуть только изображение. Однако обратное направление полезно: явное объявление ["IMAGE"] уменьшает количество лишних текстовых частей.
Это не так. Два подхода с жёстко заданным индексом дополняют друг друга — изображение всегда оказывается в [0] или [1], поэтому независимо от выбранного варианта некоторые запросы не найдут его. Изменение индекса лишь меняет набор запросов, завершающихся ошибкой. Стабильным является только фильтр по наличию поля.
Неверно, и ошибка возникает незаметно. Grok Imagine — наиболее наглядный пример: передача image / image_url / images в эндпоинт генерации возвращает 200 с обычным изображением, но эталонное изображение незаметно отбрасывается, а тарификация выполняется как обычно — в результате вы получаете обычный результат преобразования текста в изображение.Редактирование изображений должно выполняться через /v1/images/edits (для Grok Imagine дополнительно требуется multipart/form-data — отправка JSON возвращает жёсткую ошибку 400).

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

Vision (понимание изображений) API

Полное руководство по входным данным: поддерживаемые модели, URL и base64, ввод нескольких изображений, распространённые ошибки

Модели для генерации изображений и видео

Полная таблица моделей для выходных данных с ценами — здесь можно проверить, какие модели поддерживают генерацию изображений

Руководство разработчика по серии Nano Banana

Как правильно вызывать семейство моделей для работы с изображениями Gemini: обход parts, вывод нескольких изображений, обработка mimeType

Примечания и рекомендации по Image API

Матрица эндпоинтов, тайм-аутов и форматов вывода для моделей изображений

Как выбрать подходящую ИИ-модель?

Выбор модели в зависимости от сценария использования, стоимости и скорости