Бюджет задержки ИИ реального времени: как уложиться в 100 мс

Кратко

Real-time ИИ в видеопродукте означает, что весь цикл – захват, сеть, ИИ-инференс и воспроизведение – должен завершиться раньше, чем человек заметит задержку, а человек замечает её примерно на 200 миллисекундах. Этот бюджет – не цель, которую оптимизируют потом; это фиксированная сумма, которую вы делите между физикой, сетью и моделью ещё до первой строки кода. В статье даны цифры по каждому этапу, показана арифметика «влезает ли ИИ-функция в бюджет» и объяснено, почему «просто дёрнем облачный API» тихо ломает real-time, как только пользователь оказывается дальше пары сотен километров от GPU. В конце вы сможете прикинуть бюджет любой real-time ИИ-функции на салфетке и понять – ещё до разработки – пойдёт она вживую или только после звонка.

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

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

Что «real-time» на самом деле значит для человека

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

Три числа из исследований восприятия задают границы, и их стоит запомнить.

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

Второе – лестница времени отклика из исследований интерфейсов. Отклик системы быстрее 0,1 секунды – 100 миллисекунд – воспринимается как мгновенный, будто пользователь сам его вызвал. Отклик около секунды держит человека в потоке, но уже заметен. Десять секунд – предел удержания внимания. Есть и порог Доэрти: когда система отвечает быстрее 400 миллисекунд, люди работают измеримо быстрее и вовлекаются сильнее, потому что перестают ждать машину.

Третье – синхронизация звука и видео, она же lip-sync. Глаз и ухо удивительно придирчивы к тому, совпадает ли голос с движением губ. Стандарт из вещательного мира, Rec. ITU-R BT.1359-1, установил, что ошибка становится заметной, когда звук опережает картинку примерно на 45 миллисекунд или отстаёт примерно на 125 миллисекунд, и задаёт сквозной допуск примерно от +90 миллисекунд (звук раньше) до −185 миллисекунд (звук позже). Рекомендация EBU R37 строже: +40 / −60 миллисекунд на всю цепочку. Практический вывод: любой ИИ-этап, трогающий звук или видео, обязан сохранять синхронизацию, а не только скорость.

Сложите это вместе – и появляется рабочее правило. Для всего разговорного и интерактивного стремитесь завершить весь цикл меньше чем за 200 миллисекунд, а проектируйте под 100 миллисекунд, чтобы был запас на плохую минуту сети. Отсюда и рамка «sub-100ms». Это не маркетинг; это граница, ниже которой функция перестаёт ощущаться софтом и начинает ощущаться рефлексом.

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

Голосовой стандарт, который правит этим 25 лет

Ещё до того, как в дело вошёл ИИ, телефонная индустрия уже измерила, сколько задержки терпит разговор. Релевантный стандарт – Rec. ITU-T G.114, «One-way transmission time», и его вывод – самый полезный единственный факт во всей этой статье.

G.114 измеряет односторонний путь от рта одного человека до уха другого – инженеры зовут это mouth-to-ear задержкой – и делит результат на три зоны. Ниже 150 миллисекунд практически все приложения получают прозрачную интерактивность; задержка есть, но её никто не замечает. Между 150 и 400 миллисекундами разговор ещё работает, но деградирует: люди всё чаще перебивают друг друга. Выше 400 миллисекунд стандарт называет задержку недопустимой для планирования.

Вот почему это важно для ИИ. Когда вы вставляете ИИ-этап – шумоподавитель, переводчик, голосового агента – в живой звонок, вы тратите часть того же mouth-to-ear бюджета. У ИИ нет собственных отдельных часов. Если сеть уже стоит 120 миллисекунд туда-обратно, а модель добавляет 200, вы пробили линию прозрачности в 150 миллисекунд и ушли глубоко в зону, где звонок кажется лагающим, какой бы хорошей ни была модель. Бюджет общий, фиксированный и задан стандартом старше, чем большинство читающих это инженеров.

Бюджет – это сумма, и не всем в ней управляете вы

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

Для видеозвонка со вставленным ИИ-этапом этапы примерно такие.

Захват – это время, за которое камера и микрофон превращают свет и звук в цифровые кадры. Оно невелико, часто несколько миллисекунд, но не ноль.

Кодирование сжимает сырые кадры, чтобы они пролезли в сеть. Современный аппаратный кодер H.264 или VP9 добавляет порядка 10 миллисекунд, иногда меньше. Аудиокодек добавляет свою задержку: Opus, стандартный аудиокодек WebRTC из IETF RFC 6716, по умолчанию имеет алгоритмическую задержку 26,5 миллисекунды при обычном размере кадра 20 миллисекунд, и её можно опустить примерно до 5 или поднять до 65 миллисекунд в зависимости от настройки.

Сеть обычно – самый крупный и наименее управляемый этап, и у неё есть пол, заданный физикой (о нём отдельно ниже). Поверх распространения реальные системы добавляют релеинг и маршрутизацию: TURN-релей обычно добавляет 10–30 миллисекунд, а Selective Forwarding Unit – сервер, раздающий ваше видео другим участникам, – ещё 5–20 миллисекунд.

Джиттер-буфер – это амортизатор приёмника. Пакеты приходят неравномерно, поэтому плеер намеренно держит небольшой запас звука для сглаживания. В real-time-конфигурациях его держат тесным, 10–50 миллисекунд, но на плохой связи адаптивный буфер может вырасти до 120 миллисекунд и больше, меняя задержку на стабильность.

Декодирование разворачивает сжатие, стоит ещё около 10 миллисекунд на железе, а рендер на экран добавляет 8–16 миллисекунд, потому что дисплеи обновляются по своему расписанию, обычно 60 раз в секунду.

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

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

Разбор примера: можно ли добавить живой переводчик?

Цифры делают это конкретным. Пусть двое на WebRTC-звонке внутри одного континента, и вы хотите добавить живой перевод «голос-в-голос». Сложим сначала фиксированные этапы, потом посмотрим, что остаётся на ИИ.

Начнём с сети туда-обратно на хорошем региональном соединении: пусть 60 миллисекунд. Голосовой путь через кодек и джиттер-буфер с каждой стороны: Opus 26,5 миллисекунды плюс джиттер-буфер 40 миллисекунд, примерно 66 миллисекунд. Захват, кодирование, декод и рендер вместе: около 35 миллисекунд. Значит, до любого ИИ фиксированный конвейер стоит:

60  (сеть туда-обратно)
+ 66  (кодек Opus + джиттер-буфер)
+ 35  (захват + кодирование + декод + рендер)
= 161 мс фиксированной, неустранимой задержки

Против разговорной цели в 200 миллисекунд это оставляет 39 миллисекунд на ИИ. Модель «голос-в-голос» не переведёт за 39 миллисекунд; самые быстрые продакшн-системы, такие как OpenAI Realtime API, возвращают первый звук примерно за 300–500 миллисекунд, и это до учёта качества транскрипции и перевода. Арифметика сразу даёт ответ: полный живой перевод сегодня не помещается в разговорный бюджет. Честный инженерный ход – запускать его как near-real-time-наложение: переведённые субтитры на такт позади или последовательный перевод, принимающий намеренную паузу, – а не обещать мгновенный дубляж, который физика не позволит.

Теперь переверните пример на функцию, которая влезает. Виртуальный фон на сегментации на устройстве работает локально, до кодирования, и не тратит сетевого времени вовсе. Модель MediaPipe Selfie Segmentation на GPU устройства в браузере обрабатывает кадр меньше чем за 3 миллисекунды – на свежем телефоне меньше 1 миллисекунды. При 30 кадрах в секунду у вас 33 миллисекунды на кадр, так что модель на 3 миллисекунды оставляет конвейер кадров целым с огромным запасом. Поэтому размытие фона вышло на годы раньше живого перевода: одно влезает в бюджет на порядок, другое – нет.

Физика задаёт пол, который не обсуждается

Самая частая и дорогая ошибка в real-time ИИ – забыть, что у сети есть жёсткий пол, заданный скоростью света. Свет в оптоволокне идёт примерно на две трети скорости в вакууме – около 200 000 километров в секунду, – потому что стекло его замедляет. Инженеры пользуются прикидкой: около 4,9 микросекунды односторонней задержки на километр волокна, что выходит примерно в 10 миллисекунд задержки туда-обратно на каждые 1000 километров.

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

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

«Частая ошибка: команда бенчмаркает ИИ-функцию на ноутбуке рядом с сервером, видит 40 миллисекунд и выкатывает. В проде пользователи в 4000 километров от сервера, путь туда-обратно – 120 миллисекунд, и та же функция теперь кажется поломанной. Всегда бенчмаркайте на той сетевой дистанции, что будет у реальных пользователей, а не на дистанции вашего офиса.»

Где работает ИИ – решает, есть ли у вас бюджет вообще

Поскольку доминирует география, важнейшее архитектурное решение для real-time ИИ-функции – это где исполняется модель. Вариантов три, и они меняют задержку на стоимость, приватность и размер модели.

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

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

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

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

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

Как ИИ вставляется в живой видеоконвейер

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

Сама платформа WebRTC теперь – завершённый стандарт: W3C опубликовал WebRTC 1.0 как полную Recommendation 13 марта 2025 года, а нижележащий транспорт описан семейством документов IETF, включая RFC 8825, RFC 8826 и RFC 8834. Расширения для обработки кадров – Encoded Transform и связанный API WebCodecs, который по состоянию на апрель 2026 года был ещё W3C Working Draft, – новее и меняются быстрее, так что проверяйте текущую поддержку браузерами перед коммитом. Глубокие протокольные механики того, как пакеты согласуются и передаются – SDP, ICE, STUN и TURN, – относятся к слою стриминга и доставки и заслуживают отдельного чтения; здесь важно лишь то, что точка вставки существует и стандартизована.

Практическое следствие для бюджета: ИИ-функция выполняется синхронно внутри цикла кадров. Если она занимает больше, чем промежуток между кадрами – 33 миллисекунды при 30 кадрах в секунду, – она не просто добавляет задержку, она роняет кадры. Так что у real-time-модели на устройстве два бюджета сразу: общий цикл в 200 миллисекунд и покадровый дедлайн в 33 миллисекунды. Модель со средними 30 миллисекундами, но редкими всплесками до 50, будет заметно дёргаться – поэтому стабильность важна не меньше среднего.

Компоненты с реальными числами

Для быстрой справки – вот сколько обычно стоит каждый этап real-time ИИ-видеоцикла в 2026 году, по стандартам и текущим вендорским цифрам. Считайте это оценками для планирования; измеряйте свой конвейер перед коммитом.

Паттерн в нижнем блоке – это вся суть. Зрение на устройстве достаточно дёшево, чтобы гнать каждый кадр. Потоковые транскрипция и синтез речи достаточно быстры, чтобы ощущаться вживую, если держать их на edge. Полный разговорный «голос-в-голос» всё ещё слишком медленный, чтобы спрятать его внутри звонка, и его нужно проектировать как near-real-time, а не мгновенный. Заметьте и штраф на порядок за запуск MediaPipe на CPU вместо GPU – та же модель в 30–40 раз медленнее без аппаратного ускорения, а это разница между «влезли в покадровый бюджет» и «разнесли его».

Где в этом Фора Софт

Мы делаем real-time-видеософт с 2005 года – видеоконференции, WebRTC-продукты, e-learning, телемедицину и живое видеонаблюдение, – и бюджетирование задержки – это разговор, который мы ведём в начале каждого такого проекта. Вопросы из этой статьи – это вопросы, которые мы задаём до оценки: где пользователи, где будет работать модель, какова фиксированная цена конвейера и сколько остаётся на функцию. В телемедицине мы выучили, что задержка субтитров, нормальная для вебинара, недопустима для врача, читающего слова пациента в реальном времени; в конференциях – что размытие на устройстве и облачное саммари принадлежат совершенно разным частям архитектуры. Бюджет – это не деталь, которую мы оптимизируем в конце. Это ограничение, вокруг которого мы проектируем с первой схемы.

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

• Real-time – это завершить весь цикл меньше чем за 200 мс; проектируйте под 100 мс для запаса.
• ITU-T G.114 задаёт правило: меньше 150 мс – прозрачно, больше 400 мс – недопустимо.
• Задержка – один общий бюджет; ИИ-этапу достаётся лишь то, что оставили фиксированные.
• Скорость света стоит ~10 мс туда-обратно на 1000 км – доминирует география, а не модель.
• Мгновенные функции – на устройстве, живые-но-крупные – на edge, медленнее – в облаке.
• Зрение на устройстве влезает в каждый кадр; «голос-в-голос» пока не влезает в живой звонок.

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

• Задержка, топология развёртывания и real-time против batch
• Streaming ASR в проде – Deepgram, Whisper, AssemblyAI
• WebRTC + AI: Insertable Streams, Encoded Transform и сравнение 100ms/Video SDK