Сборка полноценного ИИ-видеозвонка

Автор: Николай СапуновОбновлено: август 202631 мин чтения
Содержание статьи +

Кратко

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

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

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

Что На Самом Деле Значит «ИИ-Видеозвонок»

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

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

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

Три Плоскости: Одна Ментальная Модель, Которая Всё Упорядочивает

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

Первая – медиа-плоскость. Это та часть, что переносит сам звук и видео – байты звука и картинки – от каждого человека ко всем остальным. Медиа-плоскость – это дорога, по которой едет разговор. В современном звонке она построена на WebRTC, браузерном стандарте реал-тайм-звука и видео, который стал официальной рекомендацией W3C в январе 2021 года, в паре с сервером по имени SFU, который мы объясним через минуту. У медиа-плоскости самый жёсткий бюджет времени, потому что всё, что встаёт на пути живого звука и видео, добавляет задержку, которую слышно и видно.

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

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

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

Медиа-Плоскость: WebRTC И SFU

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

Слова «не переобрабатывая» – самая важная часть. Более старая конструкция, MCU (Multipoint Control Unit), декодировала видео каждого, смешивала в одну общую картинку и заново кодировала – дорогая работа, требующая мощного сервера на каждый звонок. SFU не делает почти ничего из этого. Он принимает поток каждого по реал-тайм-транспортному протоколу RTP (защищённому как SRTP, то есть зашифрованному в транзите) и пересылает пакеты дальше, в худшем случае выбирая, какой слой качества переслать, когда не хватает полосы. Поскольку он никогда не транскодирует, один SFU обслуживает заметно больше участников за те же деньги. Поэтому практически каждая продакшен-платформа видеозвонков в 2026 году – LiveKit, mediasoup, Janus и коммерческие SDK поверх них – использует модель SFU.

Сам звук несёт Opus, открытый и не требующий лицензионных отчислений кодек для голоса и музыки, стандартизованный как IETF RFC 6716, – на нём говорит каждая WebRTC-точка. Кодек – это метод сжать звук в маленький поток байтов и распаковать его на другой стороне. Opus важен для ИИ-плоскости по одной причине, к которой мы возвращаемся снова и снова: большинству аудио-ИИ-моделей нужен сырой, несжатый звук, а не Opus-сжатые байты. То, где фича стоит относительно Opus-энкодера, решает, сможет ли она вообще работать.

Практический вывод: медиа-плоскость – во многом решённая, стандартизованная задача. Её не изобретают; берут WebRTC и SFU. Урок 6.2 про WebRTC AI-API и выбор SDK разбирает, как выбирать между сборкой на чистом WebRTC и покупкой видео-SDK. Все интересные решения живут в том, куда крепить ИИ-плоскость, – об этом весь остаток урока.

Три Дома Для ИИ-Фичи

Каждая ИИ-фича в звонке работает в одном из ровно трёх мест. Назвать их точно – самое полезное, что можно сделать в начале проекта, потому что выбор тянет за собой стоимость, приватность, задержку и то, какие устройства вы сможете поддержать.

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

Браузер делает это возможным через небольшое семейство стандартов. WebCodecs даёт низкоуровневый доступ к кодированию и декодированию кадров, поддержан в Chrome, Edge, Firefox 130+ и Safari 26. MediaStreamTrackProcessor разбивает живой трек камеры или микрофона на отдельные кадры, которые можно править. WebGPU, теперь поддержанный во всех основных браузерах, позволяет править на графическом чипе устройства, так что обработка достаточно быстра для живого видео. Для звука AudioWorklet гоняет небольшой шумодав на сыром звуке вне главного потока. Урок 6.3 про размытие фона и урок 6.5 про интеграцию шумоподавления – это глубокие разборы.

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

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

Рисунок 2. Где живёт каждая фича. Сопоставляйте фичу с домом, у которого есть нужный ей сигнал и требуемая граница доверия, – а не с тем слоем, который проще править.

Проходим По Пайплайну, Фича За Фичей

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

Сигнал начинается у камеры и микрофона отправителя. Первое, что он встречает, – предобработка на устройстве. Модель размытия фона заменяет пиксели за человеком с помощью модели сегментации – той, что решает попиксельно «это человек, а то стена», – работающей на WebGPU. Параллельно шумодав чистит звук микрофона внутри AudioWorklet, убирая стук клавиатуры и фоновые голоса до того, как звук сжат. Если продукт предлагает бьюти-фильтры или коррекцию взгляда, они тоже работают здесь, об этом урок 6.8 про AR-эффекты. Золотое правило этой стадии: в цепочке должен быть ровно один шумодав. Браузеры поставляют бесплатный встроенный; если вы добавляете свой, встроенный надо выключить, иначе два дерутся и дают роботизированный, «подводный» голос. Два шумодава одновременно – самый частый аудиобаг, который мы видим в ИИ-продуктах для звонков.

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

ИИ-агент подписывается на потоки и делает лингвистически тяжёлую работу. Он гоняет потоковое распознавание речи – automatic speech recognition, или ASR, – чтобы выдавать живые субтитры, тема урока 6.9 про fan-out субтитров на стороне SFU. «Потоковое» здесь значит, что модель выдаёт слова по мере произнесения, а не ждёт конца предложения, – именно это делает субтитры живыми. Из того же транскрипта модель перевода выдаёт субтитры или синтезированный голос на другом языке – урок 6.11 про реал-тайм-перевод речи, – а ассистент встречи копит транскрипт, чтобы выдавать бегущее резюме и список задач, территория урока 6.14 про ИИ-ассистента встреч на LiveKit. Если ваш продукт предлагает ИИ-аватара, который синхронизирует синтетическое лицо с сгенерированной речью, его тоже публикует в комнату агент, по уроку 6.13 про аватаров внутри звонка.

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

Два Бюджета, Которые Надо Держать: Интерактивное Медиа И Голосовой ИИ-Цикл

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

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

Второй – бюджет голосового ИИ-цикла: сколько ИИ-ассистент слышит вопрос и начинает отвечать. Этот цикл – распознавание речи, затем языковая модель, затем синтез речи, и его практический потолок около 800 мс, после чего ассистент ощущается вялым. Показательная раскладка 2026 года, взятая с продакшен-платформ голосовых агентов, выглядит так: детекция голосовой активности и решение о смене реплики – 150–300 мс; финальный транскрипт распознавания – 50–150 мс после того, как человек замолчал; время до первого токена языковой модели – 150–400 мс; первый аудио-чанк синтеза речи – 100–200 мс; накладные расходы сети – 30–80 мс. Сложите нижние границы – будете около 480 мс; сложите верхние – улетите за 1000 мс. Покажем один путь явно: 200 мс смена реплики + 100 мс транскрипт + 300 мс первый токен модели + 150 мс первый чанк речи + 50 мс сеть = 800 мс. Вот бюджет, потраченный целиком, без запаса.

Рычаг, который прячется на виду, – смена реплики, то есть решение, что человек действительно договорил. Неуклюжий детектор конца реплики добавляет 500 мс ощущаемой задержки, которой нет ни в одном бенчмарке модели, потому что время теряется в ожидании, а не в вычислении. Современные фреймворки используют небольшую трансформерную модель, обученную предсказывать конец реплики, а не фиксированный таймер тишины, – поэтому стек LiveKit Agents и подобные системы поставляют детекцию смены реплики как первоклассный компонент. Потоковость каждой стадии – частичные транскрипты в модель, токены модели в синтезатор речи до конца предложения – это и есть то, что позволяет хорошо собранному циклу уложиться под секунду. Урок 6.1 про бюджет задержки sub-100 мс раскладывает эти числа по стадиям.

Рисунок 3. Два бюджета, идущих параллельно. Медиа-цикл (сверху) решает, будут ли люди говорить друг через друга; голосовой ИИ-цикл (снизу) решает, будет ли ассистент отзывчивым. Их настраивают отдельно.

Разобранный Пример: Один Звонок С Пятью Фичами

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

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

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

Урок разобранного примера – в форме стоимости. Фичи на устройстве не стоят оператору ничего на участника; фичи агента стоят за минуту речи и за токен, а не за участника. Продукт, который это понимает, ценит и масштабирует правильно; продукт, который гоняет всё в облаке, платит за 25 GPU-слотов там, где нужен был один агент.

Частая Ошибка: Поставить ИИ Не В Ту Плоскость

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

Первая – гонять аудио-ИИ-фичу после Opus-энкодера, а не до него. Команда заводит шумодав в путь WebRTC Encoded Transform – API, позволяющий править закодированные кадры, – и недоумевает, почему он ничего полезного не делает. Причина в том, что закодированные кадры – это Opus-сжатые байты, а не звук; шумодаву нужна сама звуковая волна. Шумоподавление должно работать на сыром звуке, в AudioWorklet, до кодирования. Encoded Transform – правильный инструмент для другой задачи: добавить дополнительный слой сквозного шифрования, который SFU пересылает, не умея прочитать, – но это неправильный инструмент для всего, что должно понимать медиа.

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

Третья – складывать модели на устройстве без бюджета. Каждая фича на устройстве – размытие, шумодав, бьюти-фильтр – тратит миллисекунды в живом пути. Добавьте их без измерения, и вы тихо толкнёте одностороннюю задержку за грань, где разговор ломается, и расплавите батарею на телефонах среднего класса. Дисциплина – держать письменный бюджет на устройство и измерять реальную цену каждой фичи на реальном железе, ровно как предписывает урок 6.1. Если бюджет полон, фича переезжает в агент или режется; её не впихивают в путь, который её не вытянет.

Порядок Сборки: Выдавать Ценность Рано, А Не Всё Сразу

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

Фундамент – обычный, надёжный звонок на WebRTC и SFU, вообще без ИИ. Доведите звук и видео, доведите переподключение, добейтесь стабильности на тех устройствах, что реально есть у пользователей. Всё остальное крепится к этому; если фундамент шаткий, никакой ИИ продукт не спасёт. Это же правильный момент выбрать build-versus-buy для медиа-слоя – решение, которое формулирует урок 6.2.

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

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

Последний слой – специализированное и регулируемое: модерация контента, аватары внутри звонка, ассистенты для продаж или предметной области. Это выше по усилию, уже по аудитории или несёт вес комплаенса, поэтому идёт, когда ядро доказано. Модерацию особенно лучше добавлять обдуманно, а не наспех, потому что она трогает и модель доверия, и – на регулируемых рынках – закон. Отметьте одно жёсткое требование на всю сборку: там, где ваш продукт генерирует или существенно меняет изображение или голос человека – ИИ-аватар, клонированный голос, синтетический перевод, звучащий собственным голосом пользователя, – статья 50 EU AI Act требует, чтобы это раскрывалось участникам. Встройте раскрытие с самого начала; это намного дешевле, чем дорабатывать потом.

Рисунок 4. Лестница сборки. Каждая ступень сама по себе выдаёт работающий продукт, так что ценность накапливается, а не ждёт большого запуска разом.

Build Versus Buy: Где Проходит Граница В 2026

Разумная команда не пишет всё это с нуля и не покупает всё это целиком. Граница в 2026 году проходит во вполне устойчивом месте.

Медиа-плоскость – WebRTC плюс SFU – это то, что почти всегда берут, а не строят: либо как open source, который вы хостите (LiveKit, mediasoup), либо как управляемый SDK. Реал-тайм-медиа в масштабе несёт длинный хвост сетевых краевых случаев, мобильных причуд и логики переподключения, на правильную отладку которых уходят годы; нет деловой причины переучивать это заново. Фреймворк агента всё чаще тоже берут: SDK LiveKit Agents и его аналоги уже решают детекцию смены реплики, обработку перебиваний и потоковую обвязку STT-LLM-TTS, которую утомительно и легко с ошибками собирать самим.

Что вы строите – это часть, которая и есть ваш продукт: какие фичи вы показываете, как они настроены под вашу вертикаль, бизнес-правила в вашем агенте и пользовательский опыт вокруг них. Что вы покупаете как сервис – обычно отдельные модели: провайдер ASR, модель перевода, голос синтеза речи, – потому что они улучшаются помесячно, а самохостинг окупается только на большом, стабильном объёме. Решение по каждой модели – это рамка build-versus-buy урока 6.6 про Krisp, Maxine и Dolby: покупайте ради скорости и широты поддержки устройств, самохостьте, когда объём велик и предсказуем, а правила приватности требуют, чтобы данные не покидали ваши серверы.

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

Фора Софт строит реал-тайм-видеософт с 2005 года, и описанная здесь сборка – WebRTC-медиа, SFU и ИИ-фичи, разложенные по устройству, серверу и агенту, – это хребет продуктов для видеоконференций, e-learning и телемедицины, которые мы выпускаем. Мы встраивали обработку фона и шумоподавление на устройстве в живые звонки, поднимали ИИ-агентов, выдающих живые субтитры и резюме, и добавляли модерацию контента к пользовательскому видео, не обрушивая бюджет задержки звонка. Дисциплина трёх плоскостей в этом уроке – для нас не теория; это чек-лист, который мы применяем при оценке новой сборки, потому что именно она отличает фичу, которая выходит, от той, что тихо делает каждый звонок хуже. Наши вертикали здесь – видеоконференции, e-learning, телемедицина и видеонаблюдение, где реал-тайм-ИИ на живом видео – ядро продукта, а не украшение.

Главное

  • У звонка три плоскости: медиа (звук/видео), ИИ (модели) и control (координация). Держите их раздельно.
  • Каждая ИИ-фича работает в одном из трёх домов: устройство отправителя, SFU или облачный ИИ-агент.
  • Устройство – для пикселей и сырого звука; агент-как-участник – для языка; SFU остаётся лёгким.
  • Параллельно идут два бюджета: интерактивное медиа (~200 мс в одну сторону) и голосовой цикл (~800 мс).
  • Шумодав работает на сыром звуке до Opus – никогда в пути закодированных кадров; никогда два шумодава.
  • Стройте шагами: обычный звонок, очистка на устройстве, агент субтитров, затем специализированные фичи.

Что Читать Дальше

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.