Видеозвонки: платформа с ИИ реального времени

TL;DR

Этот финальный проект превращает весь «конференц-блок» курса в реальный продукт – рабочую платформу для видеовстреч, где у каждого участника автоматически размывается фон и очищается звук, в реальном времени появляются субтитры и перевод, а в комнату заходит ИИ-ассистент, который ведёт заметки. Всё это собрано на конкретном стеке технологий 2026 года, а не на основе абстрактных пожеланий. Основой архитектуры становится один open-source медиасервер и паттерн «агента»: небольшая программа подключается к каждой встрече как обычный участник, анализирует звук и публикует субтитры и краткие резюме обратно в чат. Мы предоставляем точный список компонентов с рекомендацией «разрабатывать или использовать готовое решение» по каждому, схему развёртывания, которую можно передать команде инфраструктуры, модель затрат с расчётами на 2026 год и план из пяти этапов, позволяющий запустить рабочий продукт уже на первой неделе. В отличие от итоговый проект главы 6, который объяснял, как думать об ИИ-звонках, этот проект – реальное выполнение задачи от начала до конца, вплоть до чек-листа запуска.

Почему это важно

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

Что именно вы строите

Сначала зафиксируйте продукт, потом технологии. Вы строите многопользовательское приложение видеовстреч – представьте сфокусированный Zoom или Google Meet – с пятью ИИ-функциями поверх обычного звонка: размытие и замена фона, шумоподавление микрофона, живые субтитры, перевод этих субтитров на другой язык и ИИ-ассистент, который после встречи выдаёт резюме со списком задач. Ни одна из этих пяти функций в 2026 году не экзотична; инженерная работа – заставить все пять работать одновременно, на одной встрече, не делая звонок медленным и не позволяя облачному счёту расти вместе с числом молчащих слушателей.

«Реальное время» – ограничение, которое определяет каждое последующее решение, и оно имеет измеримый смысл. Разговор кажется естественным, пока промежуток между тем, как один закончил говорить, и тем, как другой начал отвечать, остаётся коротким. Исследования и практика в продакшене показывают, что комфортный двусторонний обмен звуком возможен при задержке не более 200 миллисекунд в одну сторону – миллисекунда, или ms, это тысячная доля секунды, так что 200 мс – это одна пятая секунды. Практический предел для ИИ-ассистента «услышать вопрос и начать отвечать» составляет около 800 мс: если задержка превышает это значение, он начинает казаться медленным. Каждая дополнительная функция «съедает» часть одного из этих двух временных бюджетов. Искусство сборки – добавлять интеллект, не выходя за их пределы.

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

Хребет: один медиасервер и паттерн агента

Две идеи лежат в основе всей сборки. Сделайте их правильно – и всё остальное станет второстепенным.

Первая – медиасервер, а точнее его разновидность под названием SFU (Selective Forwarding Unit, «модуль выборочной пересылки»). Во встрече с участием более двух-трёх человек участники не передают видео напрямую друг другу, потому что в этом случае каждый ноутбук должен был бы одновременно отправлять свой видеопоток всем остальным – это быстро разряжало бы батареи и перегружало домашний интернет. Вместо этого каждый участник отправляет одну копию аудио и видео на центральный сервер, который затем пересылает эти потоки остальным. «Выборочная пересылка» – вот суть его работы: он просто ретранслирует потоки и, при нехватке пропускной способности, решает, какой уровень качества передавать, но при этом никогда не декодирует и не перекодирует видео – а это самая ресурсоёмкая операция. Поскольку перекодирование не требуется, один скромный SFU может эффективно обслуживать большую группу людей. Все серьёзные платформы 2026 года используют именно эту модель.

Вторая идея – ИИ-агент как участник. Вместо того чтобы внедрять ML-модели внутрь сервера, вы создаёте небольшую программу, которая подключается к комнате встречи так же, как обычный человек: подписывается на аудио и видео, запускает модели и публикует результаты – субтитры, переведённый голос, текущее резюме – обратно в комнату. Этот подход формализован в фреймворке LiveKit Agents, который определяет агента как любую программу на Python или Node.js, подключённую к комнате как полноценный участник в реальном времени. Преимущество здесь – в разделении ответственностей: агент масштабируется независимо от медиасервера, его разрабатывает продуктовая команда, а не команда инфраструктуры, и он запускается ровно один раз на встречу, не затрагивая при этом медиапоток.

Держите эти две идеи вместе – и у платформы появляется чистая форма. SFU гоняет пиксели и звук между людьми. Агенты добавляют интеллект, заходя в комнаты. Всё остальное в статье – это решения о том, что куда поместить, что строить, а что купить, и как это масштабируется. За более глубоким обоснованием этого разделения – мысленной моделью «трёх плоскостей» медиа, ИИ и управления – обращайтесь к итоговому проекту главы 6; здесь мы берём её как решённую и строим поверх.

Производственная архитектура, блок за блоком

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

Клиент – это вкладка браузера или мобильное приложение, которым пользуется каждый участник. Он подключает камеру и микрофон, запускает on-device-ИИ (размытие фона, шумоподавление), кодирует медиа и отображает других участников. Здесь обрабатываются данные, чувствительные к приватности, потому что необработанные кадры с камеры и звуковые сигналы с микрофона существуют только на устройстве, где они были получены.

Сервер токенов – небольшой бэкенд-сервис, который вы разрабатываете. Перед тем как кто-то войдёт в комнату, ваше приложение проверяет, имеет ли он право на доступ, и выдаёт короткий подписанный токен – пропуск, который медиасервер примет. Это ваша бизнес-логика: кто может вести встречу, а кто – только смотреть. Он не обрабатывает медиаданные, поэтому дешёв в эксплуатации и легко масштабируется. А его отделение от медиасервера позволяет менять правила доступа, не затрагивая инфраструктуру реального времени.

SFU – медиасервер, описанный выше. В продакшене он работает не как единая машина, а как пул экземпляров, обычно на Kubernetes – open-source-системе для запуска и автоматического масштабирования контейнеров на множестве серверов, – так что в час пик выделяется больше мощности SFU, а ночью она сворачивается обратно.

TURN-сервер решает сетевую проблему, из-за которой около 15–20% соединений не устанавливаются, если её игнорировать. Многие корпоративные файрволы и сети мобильных операторов блокируют прямое соединение между двумя устройствами. TURN-сервер (от «Traversal Using Relays around NAT») – это ретранслятор, к которому обе стороны всегда могут подключиться, обеспечивая путь для медиа даже через враждебную сеть. Стандартная open-source-реализация – coturn, поддерживающая стандарты TURN и STUN (IETF RFC 8656 и RFC 8489). Пропустите его – и каждый пятый пользователь просто не сможет подключиться; сбой будет выглядеть случайным и сводить с ума при отладке.

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

Хранилище и бэкенд приложения хранят всё, что остаётся после встречи: учётные записи, историю комнат, транскрипты и резюме от заметочника. Это обычная веб-инфраструктура – база данных, API, объектное хранилище для записей – и она намеренно проста, потому что сложные задачи в реальном времени решены в другом месте.

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

Build vs Buy: вердикт 2026 года, по компонентам

Хорошая команда не пишет всё с нуля и не покупает целиком. В 2026 году граница проходит в довольно стабильном месте, и правильно её определить – это разница между «выпустили за квартал» и «потратили год». Эвристика: используйте готовую тяжёлую real-time-инфраструктуру, покупайте быстро меняющиеся модели и создавайте только то, что действительно является вашим продуктом.

Две ячейки заслуживают пометки, потому что изменились в 2026 году. Шумоподавление стало дороже: с 1 мая 2026 года Krisp перевёл свой SDK по подавлению фоновых голосов на платную модель. А RNNoise – старая бесплатная «палочка-выручалочка» – с 2024 года больше не поддерживается и плохо справляется с современным шумом. Из доступных open-source и бесплатных решений остаётся DeepFilterNet – нейросетевой подавитель шума, работающий на устройстве в полном качестве звука 48 кГц.

Что касается медиа-слоя, он теперь стал настоящим commodity-продуктом, который можно использовать «из коробки». Сервер LiveKit лицензирован под Apache 2.0 и поддерживает Self-hosting, поэтому вопрос больше не в том, «строить или покупать», а в выборе между self-host и managed-облаком – решением, зависящим от стоимости, к которому мы вернёмся ниже.

Помодельное обоснование выбора между разработкой и покупкой аудиофункций – тема урока 6.6 про Krisp, Maxine и Dolby.

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

Прослеживаем одну встречу: от клика до резюме

Числа и блоки приобретают конкретное значение, когда вы проводите одну встречу через систему. Рассмотрим пример участницы Марии, которая заходит на стендап команды из шести человек.

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

Её браузер использует токен для подключения к SFU. Если корпоративный файрвол блокирует прямое соединение, оно автоматически переключается на TURN-ретранслятор – в любом случае медиа-поток устанавливается. Перед тем как видео покинет ноутбук, запускается on-device-конвейер: модель размытия фона по пикселям определяет, где находится Мария, а где – стена за ней, и размывает фон; одновременно модель шумоподавления устраняет гул кондиционера из сигнала микрофона. Только очищенные и сжатые потоки отправляются на SFU, который ретранслирует их остальным пяти участникам. Важно: SFU также делает эти потоки доступными ещё одному «участнику» – агенту, подключившемуся в начале встречи.

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

Заметьте симметрию. Тяжёлые вычисления с пикселями и звуком распределены между устройствами, где хранится исходный сигнал, и каждый новый участник добавляет свой процессор. Обработка языка происходит в одном агенте, где модель видит весь диалог. SFU посередине остаётся лёгким – он просто пересылает данные без перекодирования. Эта архитектура – не просто украшение; именно она позволяет системе укладываться в заданные временные и финансовые рамки.

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

Два бюджета, которые нельзя нарушать

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

Бюджет интерактивного медиа определяет, будут ли участники говорить одновременно: сколько времени требуется голосу Марии, чтобы дойти до ушей остальных пятерых. Цель – удерживать задержку в одном направлении примерно на уровне 200 мс. Функции, работающие на устройстве, напрямую расходуют этот бюджет: шумоподавление добавляет 20 мс, а размытие – 15 мс, и оба эти процесса происходят в реальном времени. Арифметика здесь неумолима. Допустим, односторонняя задержка сети составляет 120 мс. Тогда остаётся 80 мс на захват звука, on-device-обработку с помощью ИИ, кодирование и воспроизведение – всё вместе. Поэтому модели, работающие на устройстве, должны быть компактными, и поэтому нельзя просто ставить четыре таких обработки подряд без предварительного замера.

Бюджет ИИ-голосового цикла определяет, насколько ассистент кажется отзывчивым: сколько времени проходит с момента, когда он «услышал вопрос», до начала ответа. Его практическая граница – около 800 мс. Представим разбивку 2026 года, основанную на данных продакшен-платформ голосовых агентов: определение начала и конца реплики – 50 мс, финальное распознавание речи – 150 мс, время до первого слова языковой модели – 400 мс, первый фрагмент синтезированной речи – 150 мс, задержка сети – 50 мс. Суммируем: 50 + 150 + 400 + 150 + 50 = 800 мс – бюджет полностью исчерпан, запаса нет. При превышении 800 мс ассистент воспринимается как медленный; при задержке более 1500 мс пользователи сообщают, что разговор «сломался».

Рычаг, который прячется на виду, – определение конца реплики: понять, действительно ли человек закончил говорить, а не просто сделал паузу. Грубый детектор добавляет сотни миллисекунд задержки, которой нет ни в одном бенчмарке модели, потому что время теряется на ожидании, а не на вычислениях. Современные фреймворки заменяют старый фиксированный таймер тишины небольшой моделью, обученной предсказывать конец реплики по самим словам: стек LiveKit 2026 года сочетает акустический детектор голосовой активности с языковой моделью примерно на 135 миллионов параметров, которая работает локально и оценивает, звучит ли фраза завершённой. Потоковость каждого этапа – частичные транскрипты в модель, слова модели в синтезатор речи до конца предложения – и есть то, что удерживает хороший цикл в пределах секунды. Урок 6.1 про бюджет задержки до 100 ms разбирает эти цифры по этапам.

Масштабирование: три уровня, три разные сборки

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

Ниже 100 участников на одну комнату достаточно одного экземпляра SFU. Этого хватает для подавляющего большинства деловых встреч, занятий и консультаций. Вы всё равно поддерживаете пул экземпляров SFU – ради надёжности и возможности одновременно вести множество комнат, – но ни одной комнате не требуется больше одного. Именно с этого уровня стоит начинать; не проектируйте под другие сценарии, пока у вас нет клиентов, которым они действительно нужны.

От 100 до примерно 1000 участников комната переходит на единый путь пересылки видео, и здесь применяются два приёма. Simulcast означает, что каждая камера отправляет сразу несколько версий видео разного качества, так что SFU может пересылать низкое разрешение тем, кому нужна лишь миниатюра, и высокое – тем, кто хочет видеть детали. SVC (scalable video coding) упаковывает эти слои в один поток более эффективно. Вместе они позволяют одному SFU обслуживать большую аудиторию, состоящую в основном из зрителей, в то время как видео публикуют лишь единицы. Хорошо настроенный open-source узел SFU способен поддерживать на этом уровне примерно 500–800 одновременных видеоучастников.

Выше 1000 участников вы попадаете в распределённую территорию: комната охватывает несколько экземпляров SFU, часто расположенных в разных регионах и соединённых в mesh-сеть так, что медиа поступает на сервер, ближайший к говорящему, и ретранслируется на серверы, ближайшие к каждой части аудитории. Такой «каскад» позволяет далёким зрителям не платить полный сетевой штраф за каждый кадр, а архитектура LiveKit рассматривает ретрансляционную связь как ещё одного участника. Для самых масштабных трансляций команды часто переводят основную аудиторию на стриминговый протокол, оставляя WebRTC только для активных спикеров – гибридный подход, описанный в инженерном гайде по конференц-связи.

Пул агентов масштабируется по другой оси – по минутам обработанной речи, а не по количеству голов. На all-hands из 200 человек с одним выступающим одновременно вы обрабатываете один поток, а не 200. Эта асимметрия – ключ к модели затрат, на которой тихо рушатся многие бизнес-планы.

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

Модель затрат с подробной арифметикой

Правильно оценить эту платформу – значит понять, что затраты проявляются в трёх формах, и только одна из них растёт с увеличением числа участников. Рассмотрим конкретный пример: часовая встреча на 25 человек со всеми пятью включёнными ИИ-функциями.

On-device-функции – размытие фона и шумоподавление – работают на каждом из 25 ноутбуков. Это 25 работающих моделей, но каждая – на «железе» своего владельца и не стоит вам, оператору, ни копейки. Вот в чём тихая суперсила on-device-размещения: она масштабируется бесплатно с ростом числа участников, потому что каждый новый участник приносит свой процессор.

Медиа-минуты – основа работы SFU. На управляемой платформе в 2026 году стандартное соединение «человек–человек» обходится примерно в $0,0004–0,0005 за минуту на участника. Для нашей встречи: 25 участников × 60 минут × $0,0005 = $0,75 на медиа в час. Самостоятельный хостинг SFU заменяет это прямой стоимостью серверов и трафика – он выгоднее при большом стабильном объёме, но становится дороже, если учесть инженеров, которые всё это поддерживают.

Агент- и модель-минуты – это стоимость использования ИИ, которая зависит от речи, а не от количества участников. При одном говорящем одновременно вы выполняете около 60 минут потокового распознавания речи, 60 минут перевода и генерацию резюме. Потоковая транскрипция в 2026 году обходится примерно в $0,0077 за минуту (Deepgram Nova-3), то есть 60 × $0,0077 = $0,46. Сама сессия агента на управляемой платформе стоит около $0,01 за минуту: 60 × $0,01 = $0,60. Перевод и финальное резюме с помощью frontier-модели добавляют ещё несколько центов. Округлим общую стоимость ИИ-обработки до примерно $1,20 за час.

Сложим: около $0 на устройстве + $0,75 на медиа + $1,20 на ИИ ≈ менее $2,00 за полностью усиленный ИИ час встречи на 25 человек на управляемой инфраструктуре – до ваших наценок и бэкенда приложения. Важна не точная цифра, а форма: продукт, работающий исключительно в облаке, платил бы за 25 GPU-слотов там, где достаточно одного агента. Поймите эту форму – и вы правильно построите ценообразование и масштабирование. Полный набор рычагов управления стоимостью – от точки окупаемости при самостоятельном хостинге до выбора модели – раскрывается в уроке 8.4 про оптимизацию затрат на video-ИИ.

Одна важная точка окупаемости: самостийный медиасервер начинает выигрывать перед управляемым облаком примерно при 500 и более стабильных одновременных сессиях – там, где экономия на поминутной оплате превышает затраты на команду, поддерживающую Kubernetes и дежурство по медиасерверам. Ниже этого порога управляемое облако остаётся дешевле, если учесть инженерное время. Принимайте решение осознанно, а не автоматически.

Частая ошибка: привязка к облачному провайдеру на уровне архитектуры

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

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

Вторая – заставить SFU декодировать видео, чтобы запустить модель внутри потока. Вся эффективность SFU основана на пересылке без перекодирования. Как только вы заставляете его декодировать каждый видеопоток, чтобы, например, запустить модель модерации, вы фактически превращаете SFU в дорогой микширующий сервер – тот самый, ради замены которого он и был придуман. В результате стоимость обслуживания комнаты резко возрастает. Решение – паттерн агента: направьте копию потока на отдельный воркер, который будет заниматься декодированием и запуском модели, оставив SFU максимально «тонким». Модерация в реальном времени как раз относится к этой категории задач – подробнее об этом в уроке 6.12.

Третья – использовать два шумоподавителя одновременно. Браузеры имеют встроенный бесплатный шумоподавитель; если вы добавляете свой, не отключив встроенный, они конфликтуют и создают роботизированный «подводный» голос. В цепочке должен быть ровно один шумоподавитель – на необработанном звуке, до сжатия. Это самый частый аудио-баг, с которым мы сталкиваемся, и его исправление – однострочная правка в конфигурации, на которую команды тратят дни. Подробности интеграции – в уроке 6.5 про шумоподавление.

План сборки: пять этапов, ценность на каждом шаге

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

Майлстоун 1 – простой надёжный звонок. Запустите SFU, сервер токенов и TURN-ретранслятор и выпустите встречу, которая просто работает: стабильный звук и видео, автоматическое переподключение после обрыва сети, надёжность на реальных устройствах ваших пользователей. Пока без ИИ. Всё остальное строится на этом фундаменте, и если он шаткий, никакой продукт с ИИ не поможет. На этом этапе вы выбираете между self-host и managed решением для медиа-слоя.

Майлстоун 2 – on-device-очистка. Добавьте размытие фона и шумоподавление в клиент. Это функции, которые пользователь замечает в первые десять секунд, они ничего не стоят оператору на участника и не требуют нового бэкенд-сервиса. Это лучшее соотношение ценности к усилию во всей системе, поэтому они идут раньше всего облачного. Толпа «как размыть мой фон» конвертируется здесь; урок 6.3 – глубокий разбор.

Майлстоун 3 – агент субтитров. Запустите одного агента, который заходит в комнату и выдаёт живые субтитры с помощью потокового распознавания речи. Это момент, когда продукт становится по-настоящему «ИИ-усиленным», и он закрепляет паттерн агента, который будет использоваться каждой последующей языковой функцией. Урок 6.9 про fan-out субтитров на стороне SFU разбирает паттерн доставки.

Майлстоун 4 – перевод и заметки как расширения одного и того же агента. Когда субтитры работают, перевод становится простым дополнением: транскрипт уже готов, остаётся добавить этап перевода и опубликовать вторую дорожку субтитров (урок 6.11). Заметочник использует тот же накопленный транскрипт, чтобы после встречи выдавать краткое резюме – это тема урока 6.14 про ассистента для встреч на LiveKit и урока 6.18 о том, как устроены коммерческие заметочники. Один агент, три языковые функции, один транскрипт.

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

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

Эксплуатация: наблюдаемость, безопасность и закон

Встреча, которая работает в демо, – ещё не продукт. Три ключевые проблемы отделяют прототип от того, что можно продавать.

Наблюдаемость означает, что вы можете понять, почему звонок прошёл плохо, уже после его завершения. Real-time-медиа ломается по причинам, не свойственным обычным веб-приложениям: участник подключён через плохую сеть, регион с потерей пакетов, отставший агент. Вам нужны метрики качества по сессии – время соединения, потеря пакетов, уровень звука, задержка агента – собираемые централизованно, чтобы служба поддержки могла ответить на вопрос «почему у меня рвались встречи?», не прибегая к догадкам. Внедряйте это уже на Майлстоуне 1: дорабатывать действующую медиа-систему телеметрией – болезненно.

Безопасность начинается с уже построенного сервера токенов. Медиа в WebRTC по умолчанию шифруется в транзите, но контроль доступа остаётся за вами: подписанные короткоживущие токены, серверные проверки, кто может вести или записывать, и временные учётные данные на TURN-ретрансляторе, чтобы он не использовался как открытый прокси. Для встреч, которым это требуется – например, телемедицина или финансы, – вы добавляете сквозное шифрование, чтобы даже SFU не мог читать медиа, и выбираете self-host, чтобы данные не покидали вашу инфраструктуру. Режимы комплаенса, такие как SOC 2 и, в случае медицинских данных, HIPAA, достижимы на этой архитектуре; это вопрос конфигурации и процессов, а не принципиально другого дизайна.

Закон получил новый датированный дедлайн, по которому нужно планировать. AI Act Евросоюза, Регламент (ЕС) 2024/1689, вводит правила прозрачности по Статье 50 с вступлением в силу 2 августа 2026 года. Правило, касающееся этой платформы, гласит: если ваш продукт генерирует или существенно изменяет изображение или голос человека – например, ИИ-аватар, клонированный или синтезированный голос, перевод, озвученный голосом пользователя, – участникам необходимо сообщить, что контент создан искусственным интеллектом. Внедряйте это раскрытие с самого начала: это небольшая функция на старте и дорогое дополнение позже. Полная регуляторная картина, включая правила по биометрическим данным, – в уроке 8.5 про инженерию EU AI Act. Это инженерный контекст, а не юридическая консультация – уточняйте детали у юриста для вашего рынка.

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

Фора Софт разрабатывает программное обеспечение для видеосвязи в реальном времени с 2005 года, и описанная здесь платформа – SFU для медиа, паттерн агента для ИИ, обработка данных на устройстве и надёжный бэкенд – составляет основу наших продуктов для видеоконференций, e-learning и телемедицины. Мы поддерживаем продакшен-развёртывания LiveKit, сочетающие SFU с фреймворком Agents при задержке менее 300 миллисекунд, масштабируем их горизонтально на Kubernetes и адаптируем под требования SOC 2, а при работе с медицинскими данными – и HIPAA. Порядок сборки и решения о создании или покупке компонентов в этой статье – не абстрактная теория для нас; это чек-лист, который мы реально применяем при оценке конференц-решений, потому что от него зависит, будет ли функция работать, или она незаметно ухудшит каждую встречу или увеличит стоимость. Наши ключевые направления – видеоконференцсвязь, e-learning, телемедицина и видеонаблюдение, где real-time-ИИ на живом видео является ядром продукта, а не дополнительным украшением.

Ключевые выводы

• Хребет – один SFU-медиасервер плюс паттерн агента: программа подключается к каждой комнате как участник.
• Используйте готовую инфраструктуру, покупайте модели, сосредоточьтесь только на продукте. Всё остальное – обуза.
• Обработку на каждого пользователя (размытие, шумоподавление) выполняйте на устройстве: бесплатно для оператора и лучше для приватности.
• Параллельно работают два бюджета: интерактивные медиа (~200 мс в одну сторону) и ИИ-голосовой цикл (~800 мс).
• Стоимость агента зависит от минут речи, а не от числа участников – один агент справляется с all-hands на 200 человек.
• Выпускайте продукт пятью этапами, каждый – рабочий; раскрытие по AI Act – до использования любого синтетического голоса или лица.

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

• итоговый проект главы 6 – трёхплоскостная архитектура ИИ-звонка
• Урок 6.14 – Ассистент встреч на LiveKit: архитектура и цены
• Урок 9.1 – ИИ в видеоконференцсвязи: инженерный плейбук