Skip to main content
С июня 2026 года Google сделал Interactions API общедоступным (Generally Available) и рекомендует его для всех новых проектов, тогда как классический generateContent API теперь считается устаревшим, но по-прежнему полностью поддерживается. Официальная документация (например, страница генерации изображений Nano Banana) теперь предлагает переключатель между двумя парадигмами, и у многих developers возникает вопрос: чем именно они отличаются и какой вариант следует использовать через APIYI? Эта страница содержит подробное сравнение и проверенные выводы.
Статус шлюза APIYI (проверено 4 июля 2026 (UTC+8)): Interactions API пока не поддерживается через шлюз — как /v1beta2/interactions, так и /v1beta/interactions возвращают 404. При вызове Gemini через APIYI продолжайте использовать нативный формат generateContent; вся документация Gemini на этом сайте основана именно на нем. Мы обновим эту страницу, как только шлюз добавит поддержку Interactions API.

Что собой представляют два подхода

generateContent — это классический интерфейс без сохранения состояния: один запрос передает весь контекст, один ответ возвращает полный результат, по адресу POST /v1beta/models/{model}:generateContent. Google отмечает, что «хотя сейчас он считается устаревшим, он по-прежнему полностью поддерживается». Interactions API — это новый интерфейс Google, получивший статус GA с июня 2026 года, по адресу POST /v1beta2/interactions. Он построен вокруг базового ресурса Interaction (один полный ход диалога или задача), а ответ представляет собой хронологическую временную шкалу шагов выполнения — рассуждения модели, вызовы инструментов и результаты, а также итоговый вывод — все это явные шаги. Google прямо указывает, что новые модели за пределами основной линейки и новые agentic-возможности будут запускаться в Interactions API в дальнейшем (источник: ai.google.dev/gemini-api/docs/interactions-overview).

Основные различия вкратце

Частая ошибка при работе с состоянием Interactions API на стороне сервера: previous_interaction_id переносит только историю диалога. tools, system_instruction и generation_config (включая thinking_level, temperature и т. д.) привязаны к конкретному взаимодействию — вам нужно отправлять их заново на каждом ходе, иначе они тихо перестают применяться.

Структуры запроса и ответа (один текстовый ход)

Пример generateContent работает напрямую через шлюз APIYI; пример Interactions API обращается напрямую к эндпоинту Google (пока не поддерживается APIYI):
Чем отличаются две формы ответа для одного и того же запроса:

Сравнение многоходовых диалогов

Именно здесь два подхода ощущаются наиболее по-разному. generateContent требует заново отправлять всю историю на каждом ходе; Interactions API нужен только id предыдущего хода:
Помимо того, что это избавляет от кода для управления историей, продолжение на стороне сервера значительно упрощает попадание неявного кэширования в префикс диалога — Google говорит, что это снижает затраты на token в многоходовых сценариях. Обратная сторона в том, что данные по умолчанию хранятся на стороне Google (55 дней на платном тарифе); организациям с требованиями к соблюдению правил обработки данных следует оценить семантику store.

Различия для моделей изображений

Модели изображений Gemini 3 (например, gemini-3-pro-image) по умолчанию выполняют рассуждение, и два парадигмы полностью по-разному представляют «промежуточные черновики рассуждения»:
  • generateContent (текущий формат шлюза APIYI): промежуточные черновики рассуждения возвращаются как обычные image parts внутри candidates[0].content.partsthoughtSignature, без флага thought). В тестах один ответ может содержать 2–10 изображений, каждое тарифицируется по 1120/2000 tokens в выходных данных — всегда проходите по всем parts и берете последнее как финальную версию. Полные измерения и правила сверки: Usage Fields & Output Explained.
  • Interactions API: рассуждение явно представлено как шаги type: "thought" (текст мысли и промежуточные изображения), а финальное изображение находится в шаге model_output; SDK также предоставляют удобные свойства .output_image / .output_text. Для чередующегося текстово-изображенческого вывода (например, иллюстрированных историй) по-прежнему требуется вручную проходить по шагам.

Тест совместимости шлюза APIYI

Проверено на api.apiyi.com с тестовым ключом 4 июля 2026 года (UTC+8): Вывод: шлюз APIYI пока не передает Interactions API, поэтому возможности, доступные только через Interactions, — продолжение на стороне сервера, вызовы агентов, фоновое выполнение — сейчас недоступны через шлюз.

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

  1. Через APIYI: продолжайте использовать generateContent. Он обладает самым полным набором функций (Batch, явное кэширование и video_metadata доступны только в generateContent), и Google взял на себя обязательство полностью поддерживать его — в ближайшей перспективе риска вывода из эксплуатации нет.
  2. Многоходовые диалоги с generateContent: собирайте историю на стороне клиента; см. Нативный формат Gemini и Многоходовые диалоги.
  3. Если вы вызываете Google напрямую и рассматриваете миграцию на Interactions API, обратите внимание на четыре вещи: tools / system_instruction / generation_config нужно пересылать на каждом ходе; store по умолчанию включён и хранится 55 дней на платном тарифе; Batch API и явное кэширование пока недоступны; обновите google-genai / @google/genai до версии 2.3.0+.
  4. Когда Interactions API стоит начинать отслеживать: когда вам нужны официальные агенты (Deep Research, Antigravity), background: true длительно выполняющиеся задачи или серверное состояние, чтобы снизить расходы на token в многоходовых диалогах. Мы обновим эту страницу, как только APIYI добавит поддержку.

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

Нативный формат Gemini

Полное руководство по нативному формату generateContent через APIYI

Обработка ответов Gemini

Корректный разбор candidates, parts и finishReason

Пояснение полей использования и вывода

Семантика usageMetadata для image-model и измеренное поведение thinking-draft

Многоходовые беседы

Реализация многоходового чата в интерфейсе без сохранения состояния