Бюджет задержки ИИ реального времени: как уложиться в 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 миллисекунд стандарт считает задержку неприемлемой для планирования.

Вот почему это важно для ИИ. Когда вы добавляете этап с ИИ – например, шумоподавитель, переводчик или голосового агента – в живой звонок, вы тратите часть общего бюджета времени от «рта до уха». У ИИ нет собственных отдельных часов. Если задержка сети уже составляет 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 миллисекунд.

Джиттер-буфер – это своего рода амортизатор на стороне приёмника. Пакеты поступают неравномерно, поэтому плеер намеренно поддерживает небольшой запас звука, чтобы сгладить колебания. В конфигурациях реального времени буфер делают минимальным – 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. Этот API позволяет коду встраиваться в медиаконвейер – между декодером и рендером или между камерой и кодером – и выполнять определённую функцию на каждом кадре. Именно в этой функции и работает ваша модель.

Сама платформа 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 раз медленнее без аппаратного ускорения – и это разница между «влезли в покадровый бюджет» и «разнесли его».

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

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

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

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

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

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

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