gemini-omni-1.2-flash на практике: 3 бизнес-сценария генерации видео и чек-лист внедрения

Сначала определите форму входных данных и границы параметров

Публичная модель gemini-omni-1.2-flash, подключённая в HiAPI, генерирует видео и поддерживает четыре режима: текст-в-видео, видео из стартового кадра, переход между стартовым и конечным кадрами и видео по референсным изображениям. Прежде чем писать код, полезнее определить, «что именно я подам на вход в этот раз», чем сразу выбирать сценарий.

Сейчас недоступны следующие возможности: редактирование видео, продолжение видео, видео или аудио в качестве входных данных, параметр seed. Процессы, зависящие от этих возможностей, нельзя реализовать через эту модель.

Параметры запроса

• prompt: единственное обязательное поле, должно быть непустой строкой длиной до 20000 символов.
• duration: целое число от 3 до 15 секунд, по умолчанию 10 секунд.
• resolution: 360p / 720p / 1080p / 4k, по умолчанию 720p. 1080p и 4k — это увеличенный вывод; 4k может не содержать звуковую дорожку.
• aspect_ratio: 16:9 или 9:16, по умолчанию 16:9.

Параметры изображений и отношения взаимоисключения

• image_urls: от 1 до 10 публичных HTTP(S) референсных изображений, включает режим видео по референсным изображениям. Если передать только одно изображение, это всё равно референсное изображение, режим стартового кадра автоматически не включится.
• first_frame_url: задаёт начальный кадр, может использоваться отдельно, образуя видео из стартового кадра.
• last_frame_url: должен использоваться вместе с first_frame_url, образуя переход между стартовым и конечным кадрами. Режим стартового и конечного кадров длится максимум 10 секунд, и в запросе нельзя передавать negative_prompt или system_prompt.
• image_urls и first_frame_url, last_frame_url взаимоисключающие: в одном запросе можно выбрать только один из этих режимов.
• Все параметры изображений принимают только публично доступные HTTP(S) URL, Base64 не поддерживается.

Ожидания, которые нужно сформировать заранее: не гарантируется наличие звука во всех режимах, синхронизация губ, точность текста, а также полное совпадение субъекта или бренда в результате с референсом. Всё это требует ручной приёмки.

Стоимость: посекундная цена по уровням разрешения

Модель тарифицируется по длительности запроса, а цена зависит от уровня разрешения. При текущем коэффициенте по умолчанию цены такие:

• 360p: $0.0229/сек.
• 720p: $0.0343/сек.
• 1080p: $0.0343/сек.
• 4k: $0.0800/сек.

Бюджет рассчитывается так: цена выбранного разрешения × длительность запроса × количество. При одинаковых параметрах и одинаковой длительности каждая новая успешная задача обычно увеличивает бюджет на стоимость одной задачи, а не удваивает накопленный бюджет каждого раунда.

Фактический счёт и применимый коэффициент определяются панелью цен на сайте. Тарификация идёт по длительности запроса, и её нельзя выводить из дробных секунд в контейнере выходного файла.

Две операционные нормы, напрямую связанные с бюджетом: повторное создание задачи из-за неудовлетворительного результата добавляет бюджет ещё одной задачи; при сетевом тайм-ауте сначала проверьте статус уже существующей задачи и только после подтверждения, что она не была создана, решайте, создавать ли новую.

Сценарий первый: черновые текстовые креативы

Когда применять: есть только текстовый бриф и нужно сравнить несколько визуальных направлений до перехода к正式 производству. Это самый прямой способ использования текст-в-видео.

Как делать

• Перепишите бриф в визуализируемое описание. «Молодая женщина быстро идёт по городской улице ранним утром с чашкой кофе в руке, камера следит за ней» выполнимее, чем «передать энергичный образ жизни».
• Передавайте только prompt, без параметров изображений, и отправляйте по одной задаче на каждое направление.
• Контролируйте бюджет одной задачи более коротким duration; на этапе черновиков длинное видео не нужно. В одной партии держите duration и resolution одинаковыми для удобного横向 сравнения.
• Ведите структурированные записи: сохраняйте prompt, duration, resolution, ID задачи и адрес результата вместе, чтобы следующая итерация имела точку опоры.

Границы

Результат черновика предназначен для выбора направления, а не для размещения как рекламный материал; детали раскадровки, брендинг и комплаентные субтитры обычно всё ещё требуют последующего профессионального производства. Если итоговое изображение должно точно соответствовать имеющимся материалам, следует перейти на видео из стартового кадра или видео по референсным изображениям.

Сценарий второй: оживление стартового кадра

Когда применять: уже есть качественное статичное изображение — товарное фото, обложка, иллюстрация, постер — и нужно заставить изображение двигаться, сохранив субъект исходной картинки.

Как делать

• Задайте начальный кадр через first_frame_url, а в prompt описывайте только движение и камеру (лёгкий наезд, медленное вращение вокруг,流动 света и тени), а не заново описывайте субъект.
• Если нужно задать конечный кадр, передайте одновременно first_frame_url и last_frame_url, образуя переход между стартовым и конечным кадрами; в этом случае duration не должен превышать 10 секунд, а в запросе нельзя передавать negative_prompt или system_prompt.
• Сначала разместите изображение в публичном месте: принимаются только публично доступные HTTP(S) URL; внутренние адреса и Base64 не подходят.
• Сохраняйте каждую задачу в базу: записывайте URL исходного изображения, prompt, duration, resolution и ID задачи для последующего анализа и повторного использования.

Отличие от режима референсных изображений

first_frame_url определяет, «откуда начать», а image_urls дают ссылку по стилю и содержанию. Они взаимоисключающие и не могут использоваться в одном запросе одновременно; передача только одного image_urls не превращает запрос в режим стартового кадра.

Сценарий третий: визуал, ограниченный референсными изображениями

Когда применять: нужна партия материалов, более близких к заданному визуалу по цветовой гамме, текстуре и композиционным привычкам, а качество отдельной задачи не является главным противоречием.

Как делать

• Передайте от 1 до 10 публичных референсных изображений через image_urls, выбрав небольшое количество материалов, наиболее точно представляющих целевой стиль; избегайте смешивания конфликтующих по цели референсов и проверяйте фактические результаты генерации.
• Чётко понимайте, что это режим референсных изображений: даже при передаче одного изображения это всё равно видео по референсным изображениям, без стартового или конечного кадра.
• Заведите фиксированные пункты проверки: основной тон, направление света, плотность кадра, текстовая область — и сравнивайте новые партии横向.
• При обнаружении дрейфа сначала проверьте референсные материалы, затем корректируйте prompt, а не слепо перезапускайте — перезапуск добавляет задачи с посекундной тарификацией.

Границы

Референсные изображения могут ограничивать стиль, но не гарантируют полного совпадения субъекта или бренда, и всё ещё требуется ручная выборочная проверка. Понимание этого как «стилевой базовой линии», а не «стилевой страховки», будет ближе к реальности.

Чек-лист внедрения

Проверка по пунктам перед началом работы помогает вовремя выявить проблемы с входными параметрами и бюджетом.

Возможности и параметры

• Ясно ли, какой режим используется в этот раз: текст-в-видео, видео из стартового кадра, переход между стартовым и конечным кадрами или видео по референсным изображениям?
• Является ли prompt непустым и не превышает ли 20000 символов?
• Является ли duration целым числом от 3 до 15 секунд? Сжат ли режим стартового и конечного кадров до 10 секунд или меньше?
• Выбраны ли resolution и aspect_ratio по назначению (по умолчанию 720p, 16:9)?
• Используется ли только один источник изображений: image_urls или first_frame_url/last_frame_url?
• Все ли изображения являются публичными HTTP(S) URL без Base64?
• Удалены ли negative_prompt и system_prompt из запроса со стартовым и конечным кадрами?
• Не используются ли редактирование видео, продолжение, видео/аудио на входе или seed? Сейчас они недоступны.

Стоимость

• Рассчитан ли бюджет как цена выбранного разрешения × длительность × количество, а не на глаз?
• Оценён ли бюджет по «количеству кандидатов», а не по «количеству сдач»?
• Понятно ли, что при одинаковых параметрах и одинаковой длительности каждая новая успешная задача увеличивает бюджет на стоимость одной задачи?
• Определяется ли фактический счёт панелью цен на сайте и применимым коэффициентом, а не выводом из дробных секунд контейнера файла?

Инженерия

• Сделан ли запуск задач асинхронным, чтобы сторона запроса не блокировалась в ожидании видео?
• Сохраняются ли ID задач в базе, включая prompt, duration, resolution и адрес результата?
• Есть ли явная машина состояний и ключи идемпотентности для предотвращения повторных отправок?
• При сетевом тайм-ауте сначала проверяется существующая задача, а не сразу создаётся новая?
• Ограничена ли конкурентность, и ожидают ли пакетные задачи в очереди?

Качество и приёмка

• Зафиксированы ли критерии приёмки заранее: целостность субъекта, элементы бренда, текстовая область, соответствие звука ожиданиям?
• Сохранена ли доля ручной выборочной проверки и не снижается ли она при масштабировании?
• Установлены ли предохранители и оповещения для дневного или партийного бюджета?

Все четыре режима используют одну и ту же форму интерфейса, разница только во входных параметрах. Выберите правильный режим, впишите взаимоисключающие отношения в валидацию параметров, посчитайте бюджет по количеству задач — и путь внедрения станет ясным.