В журналах вашего голосового агента LiveKit вы можете увидеть любое из следующих предупреждений вместе с соответствующей задержкой:
- Виндукация VAD медленнее реального времени
- VAD медленнее реального времени
Точный текст зависит от версии LiveKit Agents, которую вы используете, и от того, написан ли ваш агент на Python или Node.js, но все они означают одно и то же.
Эти предупреждения не связаны с моделями STT, TTS и LLM, которые вы используете через LiveKit Inference. Они означают, что модель обнаружения голосовой активности (VAD), работающая внутри процесса вашего агента, затрачила слишком много времени на обработку небольшого окна аудио.
Что делает VAD? VAD сообщает вашему голосовому агенту, когда человек, который говорит, начал и прекратил говорить. Вместе с обнаружением поворота это определяет, когда агент отвечает.
Как работает VAD? Ваш агент подключается к комнате LiveKit как участник и получает аудио так же, как и все остальные в комнате. VAD работает внутри процесса работы вашего агента, где он анализирует декодированное PCM-аудио для обнаружения голосовой активности. Аудио поступает в реальном времени, а процесс вашего агента имеет много задач помимо VAD, поэтому поддерживать темп означает, что каждое окно аудио длительностью 32 мс должно обрабатываться менее чем за 32 мс.
Что может пойти не так? Если VAD не успевает обработать свое окно аудио вовремя, он продолжает с того места, где остановился, в следующий раз, когда запускается. Если это повторяется, VAD отстает всё дальше и дальше. Отставание на 50 мс не заметно, но если ситуация не разрешается сама по себе, аудио, над которым работает VAD, заметно отстает от аудио, приходящего к вашему агенту.
Предупреждение срабатывает, когда VAD отстает от реального аудио. Триггер отличается немного между агентами Python и Node.js, но в обоих случаях вы увидите предупреждение в журнале, сообщающее, что VAD больше не успевает за приходящим аудио. Для уточнения: задержка, указанная в предупреждении, показывает, насколько VAD отстал, поэтому задержка 1000 мс означает, что VAD обрабатывает аудио с отставанием в 1 с. Это не означает, что VAD работал 1 с.
Также обратите внимание, что Python сообщает задержку в секундах, а Node.js — в миллисекундах.
Симптомы#
VAD, который не успевает, проявляется в широком спектре, кажущихся несвязанными, симптомов агента. Некоторые следуют из того, что END_OF_SPEECH срабатывает с опозданием, поскольку это ключевой ввод для обнаружения поворота. Другие возникают из того, что изначально «голодит» VAD:
- Агент медленно замечает, что вы закончили говорить.
- Агент говорит поверх людей и пропускает прерывания.
- Приветствие обрезано, или появляются ложные прерывания в начале звонка.
- Аудио в выходных записях рычит, но в LiveKit Agent Insights всё в порядке.
- Память растёт в течение долгой сессии, и в крайних случаях приводит к предупреждениям о памяти работы.
Как исправить#
Во-первых, короткая вспышка предупреждений в первые несколько секунд сессии можно игнорировать, поскольку она не влияет на точность VAD. Это, скорее всего, происходит, если вы всё ещё используете плагин Silero VAD.
Во-вторых, ряд проблем, которые вызывали ложные сообщения об этом предупреждении, исправлены со временем, поэтому убедитесь, что вы используете последнюю версию LiveKit Agents и детектор поворотов LiveKit. Также стоит использовать стандартный, встроенный inference VAD, который AgentSession предоставляет вам, а не отдельный .
Две заметки по вышеизложенному:
- Это общее правило. Как фреймворк мы поддерживаем несколько моделей обнаружения поворотов и VAD, и в целом совет всегда будет использовать последнюю версию.
- При переходе от Silero plugin к inference VAD, обратите внимание, что по умолчанию min_silence_duration также изменился (плагин, inference).
Затем, самое главное, исключите заблокированный цикл событий. Любой синхронный код, такой как блокирующий HTTP-запрос, запись в базе данных во время звонка или тяжёлая вычислительная нагрузка, может привести к этому предупреждению, потому что время, проведённое в ожидании блокирующего кода, учитывается внутри таймера инференции VAD. Я написал отдельный блог о диагностике заблокированных циклов событий в LiveKit Agents, и самое простое решение для большинства клиентов — передать этот блог своему коду агента и попросить его искать проблемы.
И наконец, проверьте, что нагрузка процессора на вашей машине не приближается к пределу. Всё ещё возможно заблокировать цикл событий, при этом нагрузка процессора остаётся низкой, поэтому не стоит считать низкую загрузку процессора гарантией того, что цикл не блокируется. Если вы размещаете самостоятельно, следуйте всем советам в наших документах по самостоятельному размещению агента, особенно требованиям по памяти и процессору, и убедитесь, что load_fnc и load_threshold заданы правильно.
Время, которое инференция VAD фактически заняла, сообщается через событие metrics_collected VAD, которое срабатывает примерно раз в секунду, передавая inference_duration_total и inference_count. Разделите одно на другое, чтобы получить среднюю стоимость за окно, как показано:
Стабильно высокий средний показатель указывает на нехватку CPU, тогда как обычно близкий к нулю, но с резкими всплесками, указывает на ваш цикл событий. Для более подробной информации и примеров метрик VAD см. рецепт метрик VAD.
Другие шаги, которые вы можете предпринять:
- Используйте полную версию модели обнаружения поворотов аудио, которая доступна всем агентам LiveKit Cloud. Она работает в облаке, тогда как легковесная модель работает локально и использует ваш CPU.
- Если вы размещаете самостоятельно, проверьте, что количество предварительно разогретых процессов соответствует вашим ожиданиям, поскольку несоответствие может означать, что рабочий процесс имеет неправильное представление о количестве доступных CPU.
Что не стоит делать#
Не пытайтесь дать VAD больше потоков, увеличить max_buffered_speech или увеличить num_idle_processes. Ни одно из этих действий не помогает VAD держать темп с реальным речью, и может ухудшить производительность.
Если предупреждение частое и постоянное, не игнорируйте его: у вас реальная проблема, ухудшающая пользовательский опыт. Эффект может быть небольшим или случайным, но стоит исправить.
Не предполагайте, что это предупреждение связано с рядом сбоев в ваших логах. Когда они коррелируют, обычно это связано с общей причиной, чаще всего с нагрузкой процессора на процесс.
