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

TL;DR

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

Зачем это вам

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

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

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

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

Ручка задержки – сколько миллисекунд у вас есть на возврат ответа. Captioning-модель, у которой 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-фильтры, коррекция взгляда, on-device-шумодав, on-device super-resolution, on-device-префильтр аномалий. Общее свойство любой фичи в точке захвата – пользователь видит её мгновенно: нет 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 – Real-time-транспорт (в звонке)

Транспортная точка живёт между камерой и экраном, пока медиа летит. Latency-бюджет – 100–200 мс end-to-end для real-time-разговора. Топология обычно серверная – на Selective Forwarding Unit (SFU) или на ИИ-воркере, который присоединяется к звонку как участник.

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

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

Latency-бюджет здесь жестокий. У streaming Whisper примерно 300 мс на partial-результат и около 1 секунды на финальный, пока зритель не заметит лаг. Что-то медленнее – и 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 эмитит partial-субтитры; batched Whisper в точке 3 запускается раз в минуту на последних 60 секундах и выдаёт более качественный, очищенный транскрипт. Продукт решает, какая версия важна; можно делать обе.

Точка 4 – Near-real-time post-processing (сразу после сессии)

Post-processing-точка стреляет, когда сессия закончилась. Latency-бюджет – от одной до десяти минут. Топология – очередь плюс фуллер воркеров: запись падает в object storage, job снимается с очереди, воркер скачивает файл, гоняет модель и записывает результаты назад.

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

Это самая дешёвая точка по стоимости минуты видео. Работа батчится, GPU-утилизация высокая, запросы не bursty, можно использовать spot-инстансы. Это же и точка, где живут самые качественные модели, потому что никаких latency-ограничений из точек 1–3 здесь нет. Флагманский пример 2026 года – meeting-notes-пайплайн, который используют все meeting-bot-продукты: Otter, Fireflies, Fathom, Supernormal и платформенные эквиваленты от Zoom и Google Meet.

Точка 5 – Long-form-аналитика (над архивом)

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

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

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

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

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

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

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

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

У real-time-возможности три свойства, которых нет у batch-возможности. Она обязана выдать частичный ответ до завершения ввода (streaming ASR не может ждать конца предложения; ему приходится эмитить частичные слова на лету). Она обязана работать внутри фиксированного latency-бюджета вне зависимости от нагрузки на модель (batch-задача может встать в очередь; live-субтитры – нет). И её отказ виден пользователю мгновенно (5-секундный freeze в потоке субтитров – это support-тикет; 5-минутная задержка в резюме встречи невидима).

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

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

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

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

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

Допустим, продукт идёт в 720p, 30 fps, в звонке один-на-один. Считаем стоимость и задержку размытия фона в трёх разных точках.

Вариант A – на устройстве (точка 1). MediaPipe Selfie Segmentation v2 c 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 fps и типичных $0.001 за вызов это $1.80/минуту/поток – на три порядка хуже варианта A и непригодно ни в каком масштабе. Архитектурная ошибка – отнестись к размытию фона как к задаче генерации, когда это задача сегментации. Форма модели определяет стоимость.

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

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

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

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

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

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

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

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

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

Фора Софт строит видео-продукты с 2005 года – видеоконференции, OTT и Internet TV, live-стриминг, surveillance, e-learning, телемедицина, AR/VR – и делала ИИ-интеграцию на всех пяти точках. В конференциях мы шипим on-device-размытие фона и ИИ-шумодав в точке 1, live-субтитры и ИИ-перевод в точке 2, выделение action items в точке 3 и резюме встреч в точке 4. В OTT точка 4 кормит наши пайплайны chapter-markers, а точка 5 – поиск по архиву. В surveillance anomaly detection работает многоуровневой архитектурой через точки 1, 3 и 5. Карта из этой статьи – это та же карта, которую мы рисуем на доске в начале каждого ИИ-проекта.

Главное

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

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

• Latency, deployment topology и решение real-time vs batch
• Форматы артефактов моделей и решение open-vs-closed
• Реальная стоимость ИИ в видео-продукте – Gemini, OpenAI, GPU