WebRTC при масштабе: каскадные SFU, региональные мосты, ИИ-агенты

TL;DR

Один Selective Forwarding Unit, или SFU, исчерпывает себя где-то между 500 и 1500 одновременных видеоучастников на одну машину – и этот потолок не имеет отношения к WebRTC как протоколу, а целиком определяется CPU и сетевой картой коробки. Ответ 2026 года – каскад SFU: меш региональных медиасерверов, в котором каждый участник подключается к ближайшему узлу, а узлы пересылают трафик друг другу по бэкбону дата-центра, превращая SFU-слой в распределённую систему, которая масштабируется добавлением узлов, а не покупкой более мощной коробки. Когда аудитория вырастает за пределы конференции, где каждый зритель ещё и публикует, – town hall на 50 000 слушателей, live-shopping-стрим на 100 000 покупателей – архитектура меняется снова, на этот раз на мост SFU → HLS, фанаутящий интерактивный WebRTC через CDN на read-only-аудиторию по Low-Latency HLS или chunked CMAF. И третья ось масштабирования в 2026 году уже не человеческая: голосовые и видеоагенты на ИИ – собранные на LiveKit Agents 1.5, Pipecat 1.0, Vocode и новой волне интеграций OpenAI Realtime, Google Live API и Anthropic Realtime – присоединяются к WebRTC-комнатам как headless-участники, открывая ту же архитектуру SFU + мост новому классу real-time-нагрузок.

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

Если вы продакт-менеджер, основатель или операционный руководитель компании, которая поставляет конференции, телемедицину, e-learning, live-shopping, видео в контакт-центре или продукт с ИИ-агентом, разница между системой, которая выдерживает удвоение трафика, и системой, которая лежит, почти целиком определяется архитектурным решением, принятым задолго до того, как трафик придёт. Уверенный покупатель должен спокойно отвечать на три вопроса: сколько одновременных участников выдерживает система, прежде чем потребуется добавить сервер; что происходит, когда один из этих серверов падает; и что меняется, когда ИИ-агенты входят в комнату как полноправные участники. Эта статья отвечает на эти три вопроса для нетехнического читателя, указывает старшему инженеру нужные кодовые пути и ссылки и даёт рабочую ментальную модель каждого значимого паттерна масштабирования WebRTC в 2026 году.

Где один SFU перестаёт масштабироваться

Selective Forwarding Unit – это коробка в середине многоточечного WebRTC-звонка, которая принимает медиа каждого участника, решает, какие потоки кому отправлять, и пересылает их. Шире про топологии – Mesh, MCU, SFU – см. SFU, MCU, Mesh: три топологии WebRTC.

Один SFU – это один процесс на одной машине. Его пределы – физические, и под нагрузкой они всплывают в таком порядке.

Первый потолок – CPU. Хотя SFU не транскодирует, он разбирает RTP-заголовки на каждом входящем пакете, выполняет SRTP-шифрование на каждом исходящем, гоняет RTCP-обратные связи и обслуживает ICE consent freshness для каждого peer connection. Современный x86-сервер с 32 ядрами и AES-NI спокойно пересылает 600–1200 видеопотоков по 1 Mbps, прежде чем ядра насытятся. Mediasoup, SFU на C++/Node.js, в продакшне с хорошей настройкой выдаёт порядка 500–800 одновременных видеоучастников на узел; SFU LiveKit на Go – в том же диапазоне; C-движок Janus при аккуратном тюнинге выжимает больше. Цифры плавают в зависимости от кодека, числа simulcast-слоёв и формы звонка, но порядок величины тот же.

Второй потолок – сеть. NIC на 10 Gbps при 80% утилизации передаёт 1 ГБ/с медиа. Видеопоток на 1 Mbps съедает ~125 КБ/с egress на подписчика. Конференция из 100 участников, где каждый подписан на каждого, – это 100 × 99 ≈ 9900 потоков egress в секунду; на 1 Mbps каждый – это 9,9 Gbps, что насыщает 10 Gbps-линк. Картина жёсткая: egress растёт O(N²) для full-mesh-конференций, потому что N участников подписываются каждый на N−1 чужих. LastN-форвардинг (см. ниже) ломает квадрат; без него стеной становится сетевая карта.

Третий потолок – операционный. Один SFU – это одна точка отказа. Если процесс падает, валятся все активные звонки. Kernel panic – те же. Региональный сбой облака – те же. Дальше нескольких сотен пользователей ни одна продакшн-команда такой риск не принимает.

Архитектура «один SFU» – правильный ответ для туториала, MVP и любого продукта, чей пик одновременных участников не превышает нескольких сотен. Дальше архитектура обязана меняться.

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

Каскад SFU: стандартный паттерн масштабирования в 2026

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

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

LiveKit называет эту архитектуру распределённым мешем и держит её по умолчанию в облачном продукте; Jitsi Videobridge называет это Octo и поставляет внутри Jitsi Meet для любых конференций, переваливших настраиваемый порог; mediasoup даёт примитив Pipe Transport, который соединяет два экземпляра SFU на уровне API и оставляет сборку каскада приложению; Janus достигает того же эффекта плагином VideoRoom с multistream-форвардингом. Twilio Video до закрытия в 2024-м работал на каскаде; Daily.co работает на каскаде; SFU Cloudflare Realtime построен на каскаде по определению, потому что edge Cloudflare распределён по природе. К 2026-му каскадный режим есть в каждом продакшн-уровневом SFU – встроенный или как примитив, который собирает приложение.

Как каскад работает на самом деле

Три вещи должны быть правильными, чтобы каскад выдавал обещанные свойства по латентности и надёжности.

Первое – маршрутизация «комната → узел»: когда новый участник входит в комнату, система должна решить, к какому узлу его подключать. Две распространённые стратегии – локальность участника (ближайший к нему узел) и аффинность комнаты (узел, на котором уже больше всего участников этой комнаты). В продакшне их комбинируют: предпочесть ближайший узел, если только это не заставляет добавить лишний каскадный хоп, которого мог бы избежать другой узел. Роутер LiveKit использует Redis как координацию; Octo в Jitsi – центральный bridge selector; mediasoup оставляет выбор сигнальному слою приложения.

Второе – межузловой транспорт: как SFU A пересылает медиа участника на SFU B. Pipe Transport в mediasoup использует обычный RTP по UDP внутри общей сети дата-центров; LiveKit – внутренний протокол на QUIC; Octo в Jitsi – собственный UDP-релей. Общая идея: межузловой хоп – это не обычный WebRTC peer connection – нет DTLS-хендшейка на каждый поток, нет ICE, нет SRTP-перешифровки – потому что оба конца находятся внутри доверенной сети, а накладные расходы полного DTLS-SRTP на каждый поток в каскаде были бы катастрофой. Аутентификация между узлами проводится один раз – при старте, обычно через mTLS или общий HMAC-ключ.

Третье – целостность сессии: когда участник в Токио входит в комнату, где уже есть участник во Франкфурте, токийский SFU должен узнать про франкфуртского и наоборот вовремя, чтобы новый участник успел подписаться. Это распределённая задача состояния, которую решает слой координации; типичный выбор – Redis, etcd, Apache ZooKeeper. В продакшне распространение работает суб-секундно: новый участник видит существующий состав через 50–200 мс после входа.

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

Чем каскад не является

Каскад – это не федерация: WebRTC-платформы разных организаций, обменивающиеся медиа через границы доверия (рабочая группа rtcweb в IETF исследовала федерацию, но в продакшне она остаётся редкостью). Каскад – это одна платформа, гоняющая одну комнату на нескольких физических площадках.

Каскад – это не горизонтальное масштабирование сигнального слоя: добавление web-серверов перед SFU. Сигнал тривиально масштабируется горизонтально (stateless HTTP + WebSocket), и любой серьёзный WebRTC-продукт масштабирует сигнал отдельно от медиа. Но медиа-плоскости нужен каскад; одной балансировкой сигнала ёмкость медиа не увеличишь.

И каскад – это не multi-region failover. Каскад активен-активен: каждый регион несёт живой трафик. Failover – побочное свойство, которое каскад даёт почти бесплатно, потому что потеря одного региона деградирует звонок (участники в нём переподключаются к следующему ближайшему узлу), а не убивает его.

LastN и forwarding по доминирующему говорящему

Даже с каскадом счёт за сеть на 100-местной конференции остаётся неадекватным, если каждый подписчик получает видео каждого другого публикатора. LastN – оптимизация, которую реализует почти каждый современный SFU: каждому подписчику пересылаются только видео N самых недавно активных говорящих. Аудио всех остальных по-прежнему миксуется (аудио дешёво); ограничивается только видеофорвардинг.

Алгоритм определения доминирующего говорящего, опубликованный Jitsi в 2015 году (Politis, Tsioutas, Mavridis – «Last N: Relevance-Based Selectivity for Forwarding Video in Multimedia Conferences»), – фактически базовая ссылка: он работает по RTP-расширению заголовка audio-level (RFC 6464) без декодирования аудио, ранжирует участников по недавней голосовой активности, и SFU форвардит только верхние N видеопотоков каждому подписчику. Измерения Jitsi того времени: SFU с LastN N=10 потреблял на 45% меньше CPU и на 63% меньше bandwidth, чем тот же SFU без LastN. На современном железе цифры на порядок ниже, но соотношение сохраняется: LastN превращает O(N²)-счёт за сеть в O(N), а это разница между звонком, который выдерживает 100 участников, и звонком, который выдерживает 1000.

В каскадном меше LastN работает на каждом узле: каждый региональный SFU вычисляет доминирующих говорящих по всей комнате (используя тот же сигнал audio-level, который получает от каждого другого узла) и форвардит только их локальным подписчикам. Вычисление доминирующего – глобальное; решение о форвардинге – локальное. Это вторая причина, по которой каскад масштабируется: меж узлами каскад несёт каждый аудиопоток (аудио дёшево – Opus 32 kbps × 100 участников × 3 узла укладывается в 10 Mbps), но только доминирующие N видеопотоков.

В сочетании с simulcast и SVC (подробнее в Simulcast и SVC в SFU) LastN даёт SFU выбор per-subscriber: какой пространственный слой какого доминирующего говорящего отправить. Подписчику с телефона уходит низкоразрешающий слой активного говорящего; подписчику с десктопа в сетке 4-up – средний слой четырёх говорящих. Один SFU, одна комната, разные счета.

Численный пример: масштабирование 100-местной конференции

Посчитаем стоимость масштабирования 100-местной конференции с паттернами и без.

Наивная звезда, один SFU, без LastN. Каждый участник публикует видеопоток 1 Mbps; каждый подписан на все. Egress SFU = 100 × 99 × 1 Mbps = 9,9 Gbps. Один NIC 10 Gbps насыщен; звонок не выдерживает больше ~80 участников на этом железе. Дневной egress при 4 часах в день: 9,9 Gbps × 4 ч × 3600 с × 1 ГБ / 8 Гб ≈ 17,8 ТБ/день на звонок.

Тот же звонок, LastN N=4. Каждый подписчик получает 4 самых недавно активных + миксованное аудио всех. Egress SFU на подписчика: 4 × 1 Mbps + 100 × 32 kbps (аудио) = 7,2 Mbps. Egress SFU всего: 100 × 7,2 Mbps = 720 Mbps. NIC 10 Gbps теперь на 7% утилизации; звонок комфортно живёт на одной коробке. Дневной egress: ~1,3 ТБ/день – в 14 раз меньше.

Тот же звонок, LastN N=4, каскад на трёх региональных SFU (33 участника на регион). Каждый региональный SFU форвардит: 4 видео активных × 33 локальных подписчика = 132 локальных видеопотока, плюс 4 видео активных, разделяемых между узлами = 4 × 2 межузловых хопа = 8 межузловых видеопотоков. Egress на регион: 132 × 1 Mbps + 33 × 100 × 32 kbps = 232 Mbps. Межузловой egress на пару: 4 × 1 Mbps + 67 × 32 kbps аудио (нелокальных участников) = 6,1 Mbps. Архитектура теперь переживает падение региона (один узел вниз – звонок деградирует, но не падает), даёт токийским участникам токийскую латентность, и счёт «на регион в час» – около 104 ГБ, треть того, что несла одна SFU-LastN-модель, распределённая по трём регионам.

Цифры иллюстративные; реальные ставки в продакшне зависят от кодека, simulcast-слоёв, накладных RTCP и конкретного межузлового протокола. Но порядок величины верный, и паттерн универсален: LastN даёт первую 10× прироста; каскад – вторую.

Архитектура «100 000 зрителей»: мост SFU → HLS

Каскад SFU масштабирует конференции – звонки, где большинство участников ещё и публикуют, – до нескольких тысяч. Но с другой стороны есть другая задача масштаба: town hall, live-shopping-стрим, спортивный watch-along, где горстка ведущих вещает на десятки или сотни тысяч зрителей, почти никто из которых ничего не публикует. WebRTC – неподходящий инструмент для такой аудитории по двум причинам.

Первая – экономика. Broadcast на 100 000 зрителей через каскадный SFU-меш – это 100 000 активных peer connections, каждое со своим DTLS-состоянием, ICE consent freshness, RTCP-обратной связью и SRTP-контекстом. Счёт за CPU и память на стороне SFU – враждебный, а счёт за egress не лучше, чем у CDN. У WebRTC нет кэширующего слоя; у CDN – есть.

Вторая – что нужно аудитории. Ведущим важна латентность – они хотят, чтобы реакции в чате прилетали, пока они ещё говорят, – но аудитории в основном важна надёжность, перемотка назад и возможность присоединиться позже. Эти свойства – ровно то, для чего был спроектирован HTTP-streaming, и ровно то, чем WebRTC специально не является.

Продакшн-паттерн 2026 – мост SFU → HLS: SFU по-прежнему держит сторону публикаторов и небольшую интерактивную аудиторию (ведущие, панелисты, VIP, агенты контакт-центра – все, чей бюджет латентности – sub-second), а упаковщик, прицепленный к SFU, переупаковывает микс активного говорящего в Low-Latency HLS или chunked-CMAF, который CDN раздаёт остальной аудитории. Мост даёт остальной аудитории 2–5 секунд glass-to-glass через LL-HLS – медленнее, чем 100–300 мс у WebRTC, но всё равно достаточно живо, чтобы реакции в чате ощущались синхронными, и на порядки дешевле в раздаче. Упаковщик появляется в SFU как обычный подписчик: входит в комнату, забирает раскладку активного говорящего и выдаёт LL-HLS-сегменты на origin, который CDN – Cloudflare Stream, Fastly, AWS CloudFront, Akamai – раздаёт.

Этот паттерн – архитектура продукта livestreaming у LiveKit (см. их пост WebRTC vs HLS с цифрами 2026), архитектура продукта Mux Real-Time Streaming, архитектура Daily.co Egress. Cloudflare Realtime SFU стыкуется с Cloudflare Stream для того же эффекта. Паттерн настолько стандартен, что новые семейства протоколов – см. Media over QUIC – изначально проектируются так, чтобы мост был менее шовным, обращаясь с интерактивным и broadcast-медиа на одном транспорте.

Подробная механика моста – как RTP-кадры SFU становятся CMAF-сегментами, как собирается раскладка активного говорящего, как работает микс аудио – в Запись, broadcasting и мост WebRTC → HLS. По стороне reader-а LL-HLS – в LL-HLS подробный разбор.

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

ИИ-агенты входят в комнату

До 2023 каждый участник WebRTC-комнаты был человеком с браузером. К 2024 первое поколение ИИ-голосовых агентов – Vapi, Retell, Vocode – входило в комнаты как headless-участники по WebSocket. В 2025 фреймворк LiveKit Agents 1.0 и фреймворк Pipecat 1.0 от Daily формализовали паттерн, OpenAI выкатил Realtime API, Google – Live API, Anthropic – мультимодальный realtime-voice, и всё это спроектировано так, чтобы быть обёрнутым агент-фреймворком и присоединиться к WebRTC-комнате как peer-участник. В 2026 «ИИ-агент-участник» – рутинная нагрузка поверх той же SFU-инфраструктуры, что и человеческие звонки.

ИИ-агент в WebRTC-комнате с точки зрения механики – простейший peer. Он крутится как процесс где-то (обычно внутри того же дата-центра, что и региональный SFU, чтобы минимизировать хопы), входит в Room как участник, подписывается на одну или несколько человеческих аудиодорожек, публикует свою аудиодорожку и запускает внутри voice-agent pipeline: voice-activity detection (VAD) для детекции конца речи, speech-to-text (STT) для транскрипции сказанного, large language model (LLM) для генерации ответа и text-to-speech (TTS), который синтезирует ответ обратно в аудио, уходящее через publish-track агента. В простейшем случае агент никогда не видит видеокадра; в 2026 всё чаще видит – потому что API уровня GPT-4o «Realtime» принимают видео, и LLM делает базовое визуальное рассуждение внутри того же хода.

LiveKit Agents 1.5 – самый деплоимый фреймворк

LiveKit Agents – open source, работает на Python 3.11+ и на момент релиза 1.5 в апреле 2026 является самым деплоимым агент-фреймворком поверх WebRTC. Архитектура трёхслойная: Worker регистрируется на сервере LiveKit, сервер диспатчит worker в Room, когда туда входит человек, и worker запускает VoicePipelineAgent, который оркестрирует VAD/STT/LLM/TTS через plug-and-swap-модули.

Релиз 1.5 добавил две фичи, важные для продакшна: adaptive interruption handling – агента можно прервать в середине реплики, проигрывание TTS останавливается, частичная транскрипция коммитится в контекст LLM, и следующий пользовательский ход обрабатывается чисто, – и нативную поддержку Model Context Protocol (MCP), которая позволяет агенту вызывать внешние инструменты (поиск в БД клиентов, букинг календаря, подтверждение платежа) внутри того же хода, без отдельной оркестрации.

Поскольку LiveKit Agents входит как обычный участник, каскадный SFU-меш распределяет трафик агентов так же, как и человеческий. Флот worker-ов крутится в каждом регионе; токийский человек получает токийского агента; латентность остаётся sub-second.

Pipecat 1.0 – vendor-neutral-альтернатива

Pipecat дошёл до 1.0 14 апреля 2026, поддерживается Daily.co и полностью vendor-neutral. Pipecat – pipeline-first: вы декларируете направленный граф процессоров – VAD, STT, LLM, TTS, бизнес-логика – и аудиокадры текут сквозь него. Модель гибче, чем у LiveKit Agents, и история деплоя разнообразнее: Pipecat-worker умеет говорить по WebRTC (через SDK Daily или любой WebRTC-адаптер транспорта), по SIP (для телефонии), по WebSocket или даже по MQTT для embedded-сценариев. Платой за гибкость становится отсутствие медиасервера в коробке – приносите свой, тогда как LiveKit Agents и LiveKit SFU спроектированы как единый стек.

Калькулятор 2026: брать LiveKit Agents, когда WebRTC и single-vendor-стек приемлемы; брать Pipecat, когда телефония или embedded-транспорт – жёсткое требование, или команда хочет свободно перемешивать поставщиков STT/LLM/TTS. Оба фреймворка сосуществуют и взаимодействуют на границе комнаты: LiveKit-комната может принять Pipecat-агента, если тот использует LiveKit-адаптер транспорта.

Vocode и остальные

Vocode – более старая линия, на Python, изначально связанная со своей инфраструктурой, сейчас тоже vendor-neutral. Retell, Vapi, Bland.ai, Dograh – коммерческие SaaS-продукты на тех же примитивах, каждый над своим медиасервером. В продакшне типовой паттерн – взять managed-фреймворк (LiveKit Agents или Pipecat) для нового билда и принять, что один-два vendor API окажутся залочены.

Что меняет ИИ-агент в SFU

Присутствие агента в комнате меняет три вещи на уровне SFU.

Первое – геометрия подписок. Типовой звонок 1-на-1 с голосовым агентом контакт-центра – это один человеческий участник, один агент и два потока (аудио человека, аудио агента). Типовой multi-party-звонок с агентом – три человека + один агент – это четыре участника и либо шесть потоков (если все подписаны на всех в стиле mesh), либо меньше с LastN. Агент – обычный участник с точки зрения SFU.

Второе – бюджет латентности. Человек-к-человеку живёт в 300 мс glass-to-glass. Звонок с агентом имеет более жёсткий бюджет на стороне агента, потому что пользователь воспринимает паузу «LLM думает» как неловкость, если она переваливает ~800 мс от конца речи до старта ответа. Из этих 800 мс STT + LLM + TTS на стороне агента съедают большинство; WebRTC-round-trip в агент и обратно должен быть невидим. Каскад SFU помогает здесь ровно так же, как и в человеческом звонке: worker агента крутится в том же регионе, межузловой хоп не нужен на леге человек-агент, бюджет остаётся целым.

Третье – масштаб. Worker агента вычислительно на порядок дороже человеческого участника (GPU под LLM, GPU под TTS, сеть под STT-API). Серьёзный агент-продукт масштабирует флот worker-ов отдельно от флота SFU, часто перед GPU-инстансами другого облачного провайдера, а SFU видит их просто как участников. Автомасштабирование флота worker-ов гонится по concurrency звонков; LiveKit Agents и Pipecat поставляют референсные автоскейлеры.

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

Четыре оси масштабирования рядом

Паттерны выше стопятся: серьёзный WebRTC-продукт 2026 использует их все одновременно, выбирая per-room, какой микс применим. Таблица ниже подытоживает, когда какая ось важна.

Правильный ответ – объединение строк 1, 2, 3 для любого серьёзного конференц-продукта; 1–4 для broadcast или live-shopping; 1, 2, 3, 5 для агент-продукта; все пять для агент-+-broadcast-продукта (live-shopping-комната 2026, где ИИ-агент отвечает на вопросы покупателей на broadcast-стороне).

Где Фора Софт

Фора Софт строит WebRTC, конференции, телемедицину, e-learning, видео в контакт-центре, live-shopping, surveillance и AR/VR с 2005 года, 239+ проектов. Каскад SFU – архитектурный выбор по умолчанию на каждом проекте, который переваливает несколько сотен одновременных участников. Мост SFU → HLS – стандарт для live-shopping и телемедицинских grand rounds, где небольшая панель вещает на широкую аудиторию. ИИ-агент – самая новая линия: LiveKit Agents и Pipecat – два стека, которые команда сейчас деплоит чаще всего, а выбор определяется тем, заложена ли в спецификацию интеграция с телефонией. Каждый «Где Фора Софт» в статьях Блока 8 отражает тот же паттерн: вертикали реальные, точки прикосновения в продакшне реальные, архитектурные решения – те, что в этой статье.

Типичная ошибка WebRTC при масштабе

Самая частая ошибка продакшна, которую мы видим, разбирая архитектуру WebRTC при масштабе, – деплой каскада без слоя координации, переживающего падение узла. Сам каскад – простое: каждый современный SFU поставляет примитив. Сложное – реестр состояния комнат, который рассказывает каждому узлу, какие другие узлы держат участников в каких комнатах. Один Redis перед SFU-мешем из четырёх регионов – это одна точка отказа, обнуляющая весь смысл каскада. Чинят либо Redis-кластером с кворумом, либо etcd-бэкенд-реестром, либо распределённой стейт-библиотекой типа Hazelcast – что-нибудь, где потеря одной машины в слое координации не замораживает меш. Мы видели архитектуры, где каскад был идеальным, а слой координации – одним t3.medium-инстансом; когда t3.medium перезагружался для security-патчинга в 03:00, каждый звонок во всех четырёх регионах падал. Каскад – это система; слой координации – её часть; вы размеряете слой координации под тот же blast-radius, что и флот SFU.

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

• Один SFU исчерпывает себя около 500–1500 видеоучастников на узел – CPU насыщается первым в плотных комнатах, сеть – в звёздообразных broadcast.
• LastN с simulcast или SVC превращает O(N²)-egress в O(N) и является самой дешёвой победой – универсальный дефолт в 2026.
• Каскадные SFU-меши – продакшн-паттерн за пределами нескольких сотен одновременных; межузловой хоп едет по бэкбону дата-центра, не по публичному интернету.
• Broadcast на 100 000 зрителей принадлежит мосту SFU → HLS, а не WebRTC-фанауту – тиер латентности сдвигается с 300 мс на 2–5 с, стоимость падает на порядок.
• ИИ-агенты – рутинные участники WebRTC-комнат в 2026; флот worker-ов агента масштабируется отдельно от флота SFU; LiveKit Agents 1.5 и Pipecat 1.0 – два доминирующих фреймворка.
• Слой координации (Redis, etcd, Hazelcast) – часть каскада, размерять под тот же blast-radius, что и флот SFU.

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

• SFU, MCU, Mesh: три топологии WebRTC – топологический фон, который эта статья предполагает.
• Выбор SFU: mediasoup, Janus, LiveKit, Jitsi, Pion – поставщик-специфичные цифры ёмкости и матрица фич.
• Запись, broadcasting и мост WebRTC → HLS – детальная механика моста в broadcast-паттерне.

Призыв к действию

• Поговорите со streaming-инженером о вашей WebRTC-архитектуре при масштабе: связаться с Фора Софт.
• Посмотрите наши кейсы в конференциях, телемедицине, live-shopping и ИИ-агент-продуктах: fora-soft.ru.
• Скачайте чек-лист WebRTC Scale-Up Pre-Flight (30-пунктный продакшн-чек-лист по 6 областям – базовый один SFU, LastN/simulcast, дизайн каскада, слой координации, broadcast-мост, флот ИИ-агентов): Скачать PDF.