Форма ИИ внутри видеопродукта

TL;DR

Современный видеопродукт – это не «одно место, где живёт ИИ», а пять разных точек, у каждой – свой бюджет задержек, своя топология развёртывания и свой режим отказа. Любой проект по интеграции ИИ либо с самого начала выбирает правильную точку подключения, либо переписывается через квартал, когда сгорает бюджет по задержкам. В этой статье – карта пяти точек (захват, real-time-транспорт, серверная обработка во время сессии, near-real-time post-processing после сессии, аналитика над архивом), какая возможность ИИ относится к какой точке и как направлять любой новый запрос на фичу в нужный слой. После прочтения вы сможете посмотреть на любой product spec – «нужны live-субтитры», «нужны ИИ-главы», «нужно размытие фона» – и поставить его на карту ещё до того, как нанят первый инженер.

Зачем это вам

Если вы product manager, фаундер или operations-лид в компании, которая делает видео-софт, вы уже слышали этот вопрос и услышите ещё раз: «можем ли мы добавить ИИ в наш видео-продукт?». Честный ответ полностью зависит от того, в каком слое продукта этот ИИ должен жить – а слои ведут себя по-разному. Размытие фона на 80 строках WebGPU на ноутбуке пользователя – это двухнедельный проект; серверная модель понимания видео, которая анализирует каждую встречу в реальном времени, – двухквартальный; офлайн-модератор, обрабатывающий архивы ночью, – месячный. Пока вы не видите форму продукта, вы не можете сказать инженерам, куда интегрировать ИИ, и не можете объяснить финансовому отделу, во сколько это обойдётся. Эта статья – карта.

Почему «где» важнее, чем «что»

Когда кто-то говорит: «давайте добавим ИИ в видеопродукт», следующим обычно идёт название модели – Whisper, YOLO, Sora, Gemini. Но такой порядок перевёрнут. Выбор модели – задача простая: в 2026 году для почти любой задачи с видео и ИИ есть хорошие open-weights или коммерческие API. Настоящий вызов – определить, где в пайплайне она будет работать.

В каждом слое видеопродукта выделяются три параметра, и модель, корректная в одном слое, оказывается некорректной в следующем.

Ручка задержки – это время в миллисекундах, отведённое на возврат ответа. Модель для распознавания речи, работающая с задержкой в 200 мс в прямом эфире, не может быть той же самой, что используется для расшифровки записи, где на обработку отводится 4 часа.

Ручка стоимости – во сколько обходится каждый вызов на минуту видео. Модель, работающая на устройстве пользователя, не стоит вам ни копейки за минуту; та же модель, вызываемая как API на 30 fps, обходится примерно в один доллар за минуту на каждый поток.

Ручка приватности – покидают ли кадры машину пользователя. Модель на устройстве невидима ни для вашего облачного счёта, ни для юридического отдела; та же модель в облаке открывает новый privacy-ревью, новый разговор о data residency и новую строку в audit log по EU AI Act.

Эти три ручки не независимы. Меньше задержка → модель ближе к пользователю → меньше модель → ниже качество. Меньше стоимость → батчинг → больше задержка. Выше приватность → on-device → опять меньше модель. Каждый видео-ИИ-фича – это точка в трёхмерном пространстве, и большая часть работы опытного видео-ИИ-инженера – это выбор правильной точки.

Прежде чем выбрать точку, нужна карта.

Пять точек подключения

Видео-продукт можно представить в виде пайплайна с пятью точками, где может применяться ИИ. У каждой точки – своя логика. Ниже – карта; далее статья следует по ней.

Нажмите, чтобы увеличить

Точка 1 – Захват (устройство)

Точка захвата живёт на телефоне, ноутбуке или камере пользователя – до того, как хоть один бит покинул здание. Latency-бюджет – один кадр (16 мс на 60 fps, 33 мс на 30), потому что результат должен прийти до того, как захвачен следующий кадр. Топология развёртывания – on-device: WebGPU, Core ML, TensorFlow Lite, NVIDIA Broadcast SDK, MediaPipe или собственный Metal/Vulkan-шейдер.

Что здесь живёт: размытие фона, виртуальные фоны, beauty-фильтры, коррекция взгляда, шумоподавление на устройстве, повышение разрешения на устройстве, префильтр аномалий на устройстве. Общее свойство любой функции на этапе захвата – пользователь видит её мгновенно: нет задержки round-trip, которая нарушила бы когнитивное ожидание, что камера показывает мир в реальном времени.

Типичная маленькая модель – MediaPipe Selfie Segmentation v2 (около 3 мс на кадр 720p на GPU ноутбука класса M) – используется для размытия фона. W3C-стандартизованный примитив, позволяющий модели получать кадры, – MediaStreamTrack Insertable Media Processing using Streams, браузерный API, передающий сырые объекты VideoFrame в JavaScript, WebAssembly или WebGPU до их поступления в энкодер.

Стоимость фичи точки 1 в облачном счёте – ноль. Сложность с инженерной точки зрения оказывается выше, чем кажется: модель нужно доставить на каждую поддерживаемую платформу (iOS, Android, Chrome, Safari, Edge, Electron), сделать достаточно компактной, чтобы она работала даже на самом слабом железе из вашей инсталляционной базы, и обеспечить грациозную деградацию, когда GPU занят. Фичи точки 1 дешёвы в эксплуатации, но дороги в запуске.

Точка 2 – Реальное время в звонке

Транспортная точка существует между камерой и экраном, пока медиа передаются. Бюджет задержки – 100–200 мс «от конца до конца» для реального времени. Топология, как правило, серверная – на основе Selective Forwarding Unit (SFU) или на ИИ-воркере, который подключается к звонку как обычный участник.

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

Доминируют два архитектурных паттерна. Первый – server-side fan-out: SFU отправляет копию аудиопотока ИИ-воркеру, который запускает streaming Whisper или Deepgram и рассылает полученные субтитры всем участникам. Второй – agent-as-participant: ИИ подключается к звонку через тот же WebRTC-стек, что и человек, получает аудио- и видеокадры, обрабатывает их своей моделью и передаёт результаты либо как дополнительный медиа-трек, либо через data-канал.

Здесь жёсткий латентный бюджет. У streaming Whisper примерно 300 мс на частичный результат и около секунды на финальный – пока зритель не заметит задержки. Медленнее – и live-субтитры перестают казаться живыми. Именно здесь большинство видео-интеграций с ИИ либо преуспевают, либо исчерпывают бюджет.

Точка 3 – Серверная обработка (во время сессии)

Серверная точка похожа на транспортную, но с более мягким временным бюджетом – секунды вместо сотен миллисекунд. Типичная топология – stateful ИИ-воркер, размещённый рядом с SFU или ingest-сервером.

Что здесь живёт: выделение action items из идущего транскрипта, mid-call-резюме, real-time-аналитика дашбордов, in-call- сентимент, in-call-OCR содержимого слайдов, in-call object detection для surveillance, in-call anomaly detection. Логика пункта 3 – «звонок ещё идёт, но пользователь согласен на задержку в 3 секунды».

Одна и та же модель может находиться на уровне 2 или 3 в зависимости от того, насколько быстро нужен ответ. Streaming Whisper на уровне 2 выдаёт частичные субтитры; batched Whisper на уровне 3 запускается раз в минуту на основе последних 60 секунд и генерирует более качественный и отфильтрованный транскрипт. Продукт сам определяет, какая версия важнее, – можно использовать обе.

Точка 4 – Постобработка в режиме близком к реальному времени (сразу после сессии)

Точка постобработки срабатывает после завершения сессии. Бюджет задержки – от одной до десяти минут. Топология: очередь плюс пул воркеров. Файл записывается в object storage, задача извлекается из очереди, воркер скачивает файл, запускает модель и сохраняет результаты обратно.

Здесь обрабатываются: краткие итоги встреч, маркеры глав, задачи для выполнения (action items) из полного транскрипта, автоматически созданные ролики с выделенными моментами, коррекция синхронизации губ для ИИ-дубляжа, очистка архивных записей от шума, генерация B-роликов, а также полная модерация контента. Пользователь ожидает, что результат будет готов к моменту, когда он вернётся на страницу встречи, но ему не нужен результат до того, как он закончит разговор.

Это самая выгодная точка с точки зрения стоимости минуты видео. Работа выполняется батчами, загрузка GPU высокая, запросы не являются пиковыми – можно использовать spot-инстансы. Здесь же размещаются и самые качественные модели, поскольку в отличие от точек 1–3 здесь отсутствуют ограничения по задержке. Флагманский пример 2026 года – пайплайн для создания заметок по встречам, используемый всеми продуктами для записи встреч: Otter, Fireflies, Fathom, Supernormal, а также платформенные аналоги от Zoom и Google Meet.

Точка 5 – аналитика длинных записей (long-form) (над архивом)

Аналитическая точка обрабатывает всю библиотеку – каждый записанный звонок, каждое загруженное видео, каждый архивный стрим – чтобы построить индексы поиска, обучить модели, сгенерировать агрегированные инсайты или модерировать контент на уровне всего корпуса. Бюджет задержки – часы и дни. Топология: периодический батч-задача – пайплайн на Spark или Beam, векторная база данных, мультимодальная foundation-модель и множество объектов в S3.

Что здесь живёт: мультимодальный видео-поиск («найди момент в прошлоквартальной earnings call, когда CFO упомянул AV1»), video RAG над архивом, рекомендации на основе схожести контента, оценка brand safety по всему VOD-каталогу, подготовка обучающих данных для собственной модели. Netflix Media Data Lake – внутренняя система на базе LanceDB и унифицированной foundation-модели – канонический крупный пример реализации пункта 5 в production 2026.

Форма стоимости здесь противоположна точке 2. В точке 2 деньги тратятся непрерывно и только на активные потоки. В точке 5 расходы происходят периодическими всплесками – например, пересборка корпуса раз в полгода может обойтись дороже, чем квартал работы streaming-ИИ, – после чего система простаивает.

Что живёт в каждой точке – карта возможностей

Пять точек чётко отображают наиболее востребованные возможности ИИ, необходимые для видеопродукта. Таблица ниже – это печатная версия карты, которую можно разместить над product backlog.

Таблица – практический артефакт этой статьи. Когда в инбокс поступает новый feature spec, вы находите его строку, читаете точку и сразу понимаете, какая инженерная команда возьмёт задачу, какова будет операционная стоимость и какие вопросы приватности нужно решить.

Real-time vs batch ИИ в одном продукте

Самая частая ошибка при интеграции видео и ИИ – рассматривать real-time и batch-обработку как одну инженерную задачу. Это не так. У них общее только название модели, а во всём остальном – почти ничего.

У real-time-решений есть три ключевых свойства, которых нет у batch-подходов. Во-первых, оно должно выдавать частичный ответ до завершения ввода – streaming ASR не может ждать конца предложения и вынужден эмитить слова по ходу. Во-вторых, оно обязано работать в рамках фиксированного бюджета задержки независимо от нагрузки на модель: batch-задачу можно поставить в очередь, а live-субтитры – нет. И, в-третьих, сбой становится заметен пользователю мгновенно: пятисекундная задержка в потоке субтитров вызовет обращение в поддержку, тогда как пятиминутная задержка при генерации резюме встречи останется незамеченной.

Batch-обработка позволяет расслабиться по всем трём аспектам. Она может ждать полного набора данных. Может встать в очередь. Её отказ – «результат пришёл позже, чем ожидалось» – раздражает, но не фатален.

Из этой разницы вытекают два следствия. Во-первых, одна и та же модель может быть настроена по-разному с разных сторон: streaming Whisper в точке 2 и batched Whisper-Large-v3 в точке 4 используют разные кодовые пути, разные стратегии разбиения на чанки, разные параметры beam search и, как следствие, разное качество. Во-вторых, один и тот же продукт почти всегда нуждается в обоих вариантах: в live-субтитрах во время звонка (точка 2 – быстро и грубо) и в чистом транскрипте после звонка (точка 4 – медленно и точно). Предоставляйте оба варианта и переключайте пользователя с одного на другой в момент окончания звонка. Попытка использовать live-результат в качестве архивного – самый распространённый баг.

Нажмите, чтобы увеличить

Числовой пример – размытие фона на трёх слоях

Возьмём одну фичу и проведём её через три точки. Размытие фона – самый простой пример, потому что его хочет каждый видеопродукт, а арифметика не перегружена.

Представим, что продукт работает в разрешении 720p при 30 кадрах в секунду, а звонок – один на один. Рассчитаем стоимость и задержку размытия фона в трёх различных точках.

Вариант A – на устройстве (точка 1). MediaPipe Selfie Segmentation v2 с WebGPU работает примерно 3 мс на кадр на GPU ноутбука M2. На кадр:

latency_per_frame = 3 мс
frames_per_second = 30
GPU_time_per_second_of_video = 3 мс × 30 = 90 мс (≈ 9% утилизации GPU)
cost_to_you_per_minute = $0 (работу делает железо пользователя)

Вариант B – серверный, на поток (точка 2). Та же модель работает в облачном GPU-воркере, который извлекает сырые кадры из SFU, размывает их и отправляет обратно. Скромная L4 при $0.65/час – это примерно $0.011 за минуту. Один поток использует 9% одной GPU на 720p30, значит, на поток:

GPU_cost_per_minute = $0.011 × 0.09 = $0.00099
плюс round-trip-задержка: ~80–120 мс дополнительно one-way
total_extra_latency = 100 мс
total_cost_per_minute_per_stream = $0.001

Кажется дёшево, пока не умножишь на пользователей. Продукт со 100 000 одновременных звонков (200 000 потоков) стоит $200/минуту, или $12 000/час, чтобы размывать фоны серверно – каждую минуту каждого звонка. Тот же продукт с размытием на устройстве стоит $0.

Вариант C – генеративный API на кадр (точка 2, но remote-API-путь). Допустим, кто-то предлагает вызывать удалённый inpainting API для каждого кадра. При 30 кадрах в секунду и типичной стоимости $0.001 за вызов это обойдётся в $1.80 в минуту на поток – на три порядка дороже варианта A и неприемлемо в любом масштабе. Архитектурная ошибка заключается в том, чтобы рассматривать размытие фона как задачу генерации, тогда как на самом деле это задача сегментации. Форма модели определяет стоимость.

Смысл примера – не в цифрах (они меняются каждый квартал), а в разбросе значений. Та же функция в зависимости от выбора точки может стоить вам ноль или двенадцать тысяч долларов в час. Это архитектурное решение, а не бюджетное, и оно принимается до того, как инженер откроет IDE.

Частая ошибка – использовать ИИ не в том слое

Самая частая ошибка при интеграции видео-ИИ – не выбрать неправильную модель, а поставить правильную модель в неподходящее место.

Повторяются три паттерна.

Первый – серверное размытие: размытие фона применяется в точке 2, хотя правильный момент – точка 1. Команда продукта выбрала серверную модель, потому что «ИИ-команда работает на сервере», а операционные расходы учитываются раз в квартал, когда компания уже зафиксирована в выбранной архитектуре.

Второй вариант – live-резюме: попытки составить резюме встречи на этапе 2 или 3, тогда как правильный момент – этап 4. Live-резюме всегда уступает post-резюме (из-за неполноты информации), и пользовательский опыт страдает пропорционально. Почти всегда решение – перенести резюме на этап 4 и оставить в прямом эфире только субтитры и краткие пункты с action items.

Третий – модерация всего архива в точке 4: проход модерации по каждой записи в точке 4, когда правильным решением должна быть точка 5. Ночной батч по корпусу дешевле и быстрее в итерациях, а также даёт команде модерации общий обзор, который недоступен при анализе по отдельным записям. Решение – оставить точку 4 за модерацией в режиме скорости мышления, которая должна проводиться до публикации записи, а точку 5 – за аудитом на уровне корпуса.

Если на каждом квартальном ревью вы обмениваете инженерные часы на операционные расходы, диагноз почти всегда один из трёх. Лечение – перерисовать карту.

Где здесь Фора Софт

Фора Софт разрабатывает видеопродукты с 2005 года – видеоконференции, OTT и интернет-телевидение, прямой эфир, видеонаблюдение, электронное обучение, телемедицина, AR/VR – и внедряет ИИ-интеграцию на всех пяти ключевых этапах. В видеоконференциях на первом этапе мы используем on-device-размытие фона и ИИ-шумоподавление, на втором – live-субтитры и ИИ-перевод, на третьем – выделение ключевых задач, на четвёртом – составление кратких резюме встреч. В OTT-сервисах четвёртый этап обеспечивает работу наших пайплайнов с chapter-маркерами, а пятый – поиск по архиву. В системе видеонаблюдения обнаружение аномалий реализовано на основе многоуровневой архитектуры, задействующей первый, третий и пятый этапы. Карта из этой статьи – это та же схема, которую мы рисуем на доске в начале каждого ИИ-проекта.

Главное

• Видео-продукт включает пять точек подключения ИИ; у каждой – свой бюджет задержки, своя топология и своя модель стоимости.
• Архитектурное решение – где работает ИИ – важнее, чем выбор модели – какой ИИ.
• Реалтайм-ИИ и пакетный ИИ – это разные инженерные продукты, а не различные конфигурации одной модели.
• Размытие, субтитры, резюме, поиск, модерация – у каждого есть естественная точка обработки; перепутать их – самая частая ошибка при интеграции.
• Та же функция может стоить ноль или двенадцать тысяч долларов в час – всё зависит только от выбранной точки обработки. Выбирайте точку до формирования команды.

Что читать дальше

• Задержка, топология развёртывания и выбор между real-time и batch
• Форматы артефактов моделей и выбор между открытым и закрытым подходом
• Реальная стоимость ИИ в видеопродукте – Gemini, OpenAI, GPU