Шумоподавление в реальном времени в проде – Krisp, RNNoise и DeepFilterNet

TL;DR

Шумоподавление в реальном времени – это программное обеспечение, которое удаляет фоновый шум (стук клавиш, лай собаки, гул кафе) из живого голосового потока прямо во время речи. В 2026 году на практике выбор сводится к трём решениям: RNNoise (лёгкий, бесплатный, с открытым исходным кодом), DeepFilterNet (более требовательный, бесплатный, но заметно лучше по качеству) и Krisp (платный коммерческий SDK, используемый внутри Discord и сотен других приложений). Ключевой показатель, определяющий пригодность любого из них для живого звонка, – дополнительная задержка: каждый алгоритм задерживает звук на несколько миллисекунд, а эта задержка «съедает» бюджет, необходимый для естественного восприятия разговора. RNNoise работает на одном ядре CPU и добавляет около 10 миллисекунд; DeepFilterNet звучит заметно чище, но требует больше вычислительных ресурсов и добавляет примерно 40 миллисекунд задержки; Krisp занимает промежуточное положение по задержке и берёт на себя обслуживание и обновления. Статья объясняет, как устроены эти три движка, какие у них в 2026 году реальные показатели по задержке, цене и качеству, и предлагает чёткое правило выбора между вариантами «бесплатно и самохостинг» и «платно и под ключ».

Зачем это нужно

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

Статья для продакт-менеджера, основателя или техлида, которому нужно решить, какую систему шумоподавления внедрить в продукт и стоит ли использовать open-source модель или платить за управляемое решение. К концу вы поймёте, как эти системы отделяют голос от шума, почему «добавленная задержка» – ключевая метрика, от которой зависит, будет ли работать живой звонок, как сравниваются RNNoise, DeepFilterNet и Krisp по скорости, качеству, цене и лицензии, и получите тест из пяти вопросов, который поможет сделать правильный выбор.

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

Что на самом деле делает «шумоподавление»

Начнём с проблемы. Когда вы говорите в микрофон, он улавливает не только ваш голос – он ловит всё: ваши слова, шум кондиционера, стук клавиатуры, гул газонокосилки соседа – всё это смешивается в один звуковой поток. Шумоподавление – это программа, которая берёт этот смешанный сигнал и пытается выделить из него только голос.

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

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

Почему это так важно для живого продукта? Потому что шум наносит два вида ущерба. Очевидный – людям: звонок с орущим фоном неприятен и выглядит непрофессионально. Менее очевидный – машинам: если продукт ещё и транскрибирует разговор, точность распознавания речи резко падает на шумном фоне, и тогда чистка сигнала напрямую улучшает качество субтитров и транскриптов (см. нашу статью о потоковом ASR). Чистый звук – фундамент, на котором строятся все последующие аудиофичи.

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

Как современный подавитель решает, что оставить

Чтобы выбрать между тремя вариантами, полезно понять, как они устроены, потому что различия в скорости и качестве напрямую вытекают из их устройства.

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

Вопрос «какие частоты – речь» – вот где и проявляется машинное обучение, и где три подхода начинают расходиться. Звук можно разбить на частотные полосы: низкий гул – внизу, шипение – вверху, человеческий голос – в основном в середине. Модель анализирует энергию в каждой полосе и предсказывает для неё усиление (gain): число от 0 (полностью заглушить полосу) до 1 (оставить полосу без изменений). Умножьте каждую полосу на её усиление – и шумовые компоненты сойдут на нет, а голосовые останутся.

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

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

Цифра, которая открывает живой звонок: добавленная задержка

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

У задержки два источника – оба связаны с устройством выше по цепочке. Первый – размер кадра: подавитель не может начать обработку, пока кадр не поступит полностью, поэтому кадр продолжительностью 10 миллисекунд означает задержку в 10 миллисекунд до начала обработки. Второй – заглядывание вперёд (look-ahead): модель, использующая данные из нескольких будущих кадров (например, вторая стадия DeepFilterNet), должна дождаться их поступления. Сложив оба фактора, получаем вклад подавителя в общую задержку.

Почему важны несколько миллисекунд? Потому что подавитель шума – не единственный элемент в звуковом тракте. В живом звонке звук проходит путь: от микрофона говорящего – захват, кодирование, передача по сети, декодирование и, наконец, доходит до уха слушателя. Международный стандарт качества голоса – Рекомендация ITU-T G.114 – задаёт чёткий ориентир: суммарная односторонняя задержка «рот-ухо» должна составлять 150 миллисекунд или меньше, чтобы разговор воспринимался естественно. Диапазон от 150 до 400 миллисекунд ещё допустим, но уже с заметным ухудшением качества (ITU-T, 2003). Каждая миллисекунда, добавляемая подавителем шума, ложится на общий бюджет этих 150 мс. Подавитель, вносящий задержку в 40 миллисекунд, «тихо» расходует более четверти всего допустимого времени ещё до того, как звук покидает устройство.

Сделаем бюджет конкретным с помощью арифметики. Допустим, ваш сетевой переход добавляет типичные 80 миллисекунд в одну сторону, а захват, кодирование и декодирование – ещё 30 миллисекунд. Итого:

80 мс (сеть) + 30 мс (захват/кодирование/декодирование) = 110 мс базы

Теперь у вас есть запас в 40 миллисекунд до пересечения линии в 150 миллисекунд:

150 мс (цель G.114) − 110 мс (база) = 40 мс остаётся

Подставьте RNNoise на ~10 миллисекунд – и вы остаётесь в бюджете с запасом. Подставьте DeepFilterNet на ~40 миллисекунд – и весь оставшийся запас уйдёт на одно шумоподавление: нормально, если остальной конвейер лёгкий, опасно – если нет. Это расчёт, который должна сделать каждая команда перед выбором модели, и почти никто его не делает.

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

Сопутствующая цифра – real-time factor (фактор реального времени), сокращённо RTF: сколько времени модель тратит на обработку одной секунды звука. RTF ниже 1 означает, что модель обрабатывает звук быстрее, чем он поступает – это минимальное требование для работы в реальном времени. RNNoise работает с RTF значительно ниже 1 на одном ядре CPU. DeepFilterNet демонстрирует RTF 0.19 на одном потоке скромного ноутбучного процессора и 0.42 на Raspberry Pi 4 – уверенно в реальном времени, но выполняет больше вычислений, поэтому для стабильной работы ему нужен более мощный чип, чем RNNoise (Schröter et al., 2022; Schröter et al., 2023).

Знакомство с тремя вариантами

RNNoise – крошечная бесплатная open-source рабочая лошадка

RNNoise – это open-source библиотека шумоподавления от фонда Xiph.Org (группы, стоявшей за аудиокодеком Opus), созданная аудиоинженером Жан-Марком Валеном. Её устройство описано в статье 2018 года с названием, которое точно передаёт суть: «A Hybrid DSP/Deep Learning Approach to Real-Time Full-Band Speech Enhancement» (Valin, 2018). Ключевое слово – «гибридный»: RNNoise сочетает классический цифровой сигнальный процессинг с небольшой нейросетью, что и делает его таким лёгким.

Цифры говорят о его компактности. RNNoise обрабатывает звук фрагментами по 10 миллисекунд при полной частоте дискретизации 48 килогерц, предсказывает усиление на 22 частотных полосах с помощью компактной сети с памятью – Gated Recurrent Unit (GRU) – и легко работает на одном ядре CPU (Valin, 2018). Размер файла модели – несколько сотен килобайт. Благодаря своей компактности он компилируется в WebAssembly – формат, позволяющий выполнять код почти на скорости нативного кода прямо в браузере, – поэтому RNNoise стал популярным решением для добавления шумоподавления в браузерные звонки без использования сервера (Gcore, 2026).

Лицензия так же дружелюбна, как и размер. RNNoise выпущен под лицензией BSD – разрешительной open-source лицензией, допускающей как бесплатное, так и коммерческое использование почти без ограничений (Xiph.Org, 2026). Вы можете использовать его в коммерческом продукте, не платя ни цента. Подвох – в качестве: RNNoise отлично справляется с устойчивым простым шумом, например, шумом вентилятора или фоновым гулом, но на сложных случаях – перекрывающаяся фоновая речь, внезапный грохот, сильная реверберация – его конструкция «одно усиление на полосу» выглядит устаревшей по сравнению с современными моделями. Это правильный выбор, когда вычислительные ресурсы ограничены, а шум – типичный.

DeepFilterNet – лидер open-source решений по качеству

DeepFilterNet – новый open-source подавитель шумов, разработанный исследователями Университета Эрлангена специально для преодоления потолка качества, к которому упираются простые модели по полосам, такие как RNNoise, при сохранении работы в реальном времени. Проект прошёл три опубликованные версии: оригинальная в 2021 году, DeepFilterNet2 в 2022 году с акцентом на работу на маломощных встраиваемых устройствах и DeepFilterNet3 в 2023 году (Schröter et al., 2021; 2022; 2023).

Его качество обеспечивается двухстадийной конструкцией, описанной выше. На первой стадии происходит обработка широкой формы звука с помощью усилений на перцептивно распределённых полосах – полосах, ширина которых подобрана с учётом особенностей человеческого слуха: они уже в тех диапазонах, где ухо наиболее чувствительно. Вторая стадия, называемая глубокой фильтрацией (deep filtering), применяет короткий многокадровый фильтр к низким частотам (ниже примерно 5 килогерц, где сосредоточена большая часть энергии голоса), чтобы восстановить детали, которые простое усиление могло бы размыть (Schröter et al., 2023). Полученный результат измеримо превосходит подходы, основанные только на усилении по полосам.

У этой мощи есть своя цена – в вычислениях и задержке. DeepFilterNet использует окна по 20 миллисекунд с шагом 10 миллисекунд и предпросмотром вперёд на два кадра, что даёт около 40 миллисекунд дополнительной алгоритмической задержки – примерно в четыре раза больше, чем у RNNoise (Schröter et al., 2023). У него около 2 миллионов внутренних параметров против десятков тысяч у RNNoise, и он написан на Rust для максимальной производительности. Лицензия также разрешительная – двойная MIT или Apache 2.0, обе допускают бесплатное коммерческое использование (Rikorose, 2026). DeepFilterNet – правильный выбор, когда вам нужно наилучшее качество в open-source, а оборудование и допустимая задержка позволяют компенсировать дополнительную нагрузку.

Krisp – коммерческий SDK с управлением

Krisp – коммерческая компания в области Voice ИИ, чей SDK для шумоподавления (software development kit – готовая библиотека кода, которую разработчик интегрирует в своё приложение) используется в Discord, RingCentral и, по данным самой компании, более чем в сотне других приложений (Krisp, 2026). В отличие от RNNoise и DeepFilterNet, которые представляют собой модели, которые вы подключаете и используете самостоятельно, Krisp – это полноценный продукт: вы лицензируете его, внедряете SDK, а поставщик берёт на себя ответственность за модель, обновления и поддержку на разных платформах.

Технический питч стоит на трёх точках. Во-первых, он работает целиком на устройстве – вся обработка звука происходит локально, и, по заявлению Krisp, голосовые данные никогда не загружаются на их серверы, что важно для приватных развёртываний вроде телемедицины (Krisp, 2026). Во-вторых, он широкий: SDK выходит для Windows, macOS, Linux, Android, iOS и основных браузеров через сборку WebAssembly, так что одни отношения с вендором покрывают каждую поверхность (Krisp, 2026). В-третьих, задержка конкурентна: Krisp обрабатывает кадрами по 10 миллисекунд с типичной добавленной алгоритмической задержкой около 25 миллисекунд, а облегчённый вариант изоляции голоса достигает около 15 миллисекунд (Krisp, 2026).

Размен – цена и контроль. Krisp – платный сервис: его потребительское приложение предлагает бесплатный тариф с 60 минутами шумоподавления в день, тариф Pro примерно за 8 долларов в месяц, а также бизнес- и enterprise-тарифы по более высокой цене. SDK для разработчиков лицензируется коммерчески через менеджера по продажам, а не по публичному прайсу (Krisp, 2026). Вы не контролируете и не можете проинспектировать модель, а также зависите от дорожной карты вендора. Для многих команд это как раз правильный компромисс: они получают продукт высокого качества на любой платформе, не тратя ресурсы на создание и поддержку аудио-ML-конвейера.

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

Сравнение 2026 года, бок о бок

Таблица содержит ключевые цифры, определяющие большинство выборов. Задержки – это алгоритмические задержки, указанные в документации или статьях каждого проекта; показатели реального времени взяты из опубликованных измерений в статьях DeepFilterNet; лицензии получены из репозиториев проектов на май 2026 года. Единого победителя нет – подходящая колонка зависит от приоритетов вашего продукта.

Читайте не как таблицу лидеров, а как сравнение решений. RNNoise выигрывает по размеру и поддержке в браузере. DeepFilterNet – по качеству обработки «сырых» аудиоданных. Krisp – по охвату платформ и тому, что берёт на себя всю техническую нагрузку. Стоит помнить и о четвёртом бесплатном варианте: каждый современный браузер уже имеет встроенный подавитель шума (об этом – ниже), так что на практике вопрос часто сводится к другому: «Достаточно ли встроенного решения, или стоит выбрать один из этих трёх вариантов?»

Как добавить шумоподавление в браузерный звонок – сначала бесплатный базис

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

Спецификация W3C Media Capture and Streams – стандарт, определяющий, как веб-страница получает доступ к микрофону, – включает ограничение noiseSuppression. При запросе доступа к микрофону вы передаёте его как опцию, и браузер применяет встроенный подавитель эха (W3C, 2026). Вот всё целиком:

// Запрос микрофона со встроенным шумоподавлением браузера.
navigator.mediaDevices.getUserMedia({
  audio: { noiseSuppression: true, echoCancellation: true }
});

Firefox включает эту функцию по умолчанию; Chrome использует встроенный подавитель – модуль шумоподавления, поставляемый в составе движка WebRTC (W3C, 2026). Для многих продуктов этого бесплатного решения вполне достаточно, и правильное инженерное решение – использовать его и двигаться дальше.

Тянуться за базис вы начинаете, когда встроенный подавитель недостаточно хорош – когда пользователи жалуются на конкретный шум, который он пропускает, или когда вам нужно одинаковое поведение во всех браузерах, а не своя версия в каждом. Тогда вы подставляете RNNoise, скомпилированный в WebAssembly, или лицензируете браузерный SDK Krisp, прогоняя звук микрофона через выбранную модель через аудиотракт браузера до того, как он дойдёт до звонка. Глубокая механика вшивания кастомного подавителя в живой WebRTC-звонок – где именно он сидит в конвейере, как избежать двойной обработки – это своя тема, разобранная в нашем разборе шумоподавления в реальном времени в WebRTC.

Как понять, хорош ли подавитель на самом деле – метрики

Вендоры любят демонстрировать запись «до и после», но это ничего не доказывает – выбор материала остаётся за ними. Чтобы честно сравнивать подавители, нужны объективные метрики, а базовый набор таких метрик позволяет критически оценивать любой бенчмарк.

Золотой стандарт – живое прослушивание, формализованное международным стандартом. Рекомендация ITU-T P.835 описывает субъективный тест, разработанный специально для оценки шумоподавления: слушатели оценивают каждый аудиоклип трижды – отдельно качество речи (SIG), степень навязчивости остаточного фонового шума (BAK) и общее качество (OVRL), по шкале от 1 до 5 (ITU-T, 2003). Разделение оценок – ключевая особенность метода: подавитель может выигрывать за счёт устранения шума, но проигрывать из-за искажения голоса, а единая оценка скрыла бы этот компромисс. Родственный стандарт ITU-T P.808 определяет процедуру проведения таких прослушивательных тестов в масштабах интернета с использованием краудсорсинговых слушателей (ITU-T, 2021).

Поскольку живые тесты требуют много времени и дорогостоящи, в области активно используют автоматические метрики, которые компьютер вычисляет мгновенно. Наиболее релевантной из них является DNSMOS – модель от Microsoft, которая анализирует аудиоклип и предсказывает оценки по шкалам P.835 SIG, BAK и OVRL, которые обычно выставляет человеческая экспертная панель, позволяя тем самым оценивать тысячи клипов без проведения прослушиваний (Reddy et al., 2021). Среди устаревших, но всё ещё встречающихся объективных метрик – PESQ (определён в ныне отменённой рекомендации ITU-T P.862) и его преемник POLQA (ITU-T P.863), а также STOI для оценки разборчивости речи и SI-SDR для измерения чистоты сигнала (ITU-T; Taal et al., 2011; Le Roux et al., 2019). Для большинства практических задач DNSMOS по шкале P.835 на собственных записях шума становится основным инструментом; полноценный тест P.835 или P.808 с участием людей стоит проводить только на финальном этапе перед крупным запуском.

Большая часть современной культуры бенчмаркинга в шумоподавлении зародилась в рамках Microsoft Deep Noise Suppression (DNS) Challenge – исследовательского соревнования, проводившегося на крупных конференциях по обработке сигналов с 2020 по 2023 год. Оно стандартизировало датасеты и метрику DNSMOS, а также представило базовые модели NSNet и NSNet2, которые до сих пор остаются полезными опорными точками (Reddy et al., 2022). Когда вы читаете результаты статьи по шумоподавлению, они почти всегда измерены на данных DNS Challenge с использованием DNSMOS – знание этого позволяет сравнивать цифры между различными публикациями.

Частая ошибка – выкрутить подавление на максимум

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

Потому что агрессивное подавление шума вредит качеству голоса. Когда модель пытается заглушить каждую полосу, где может быть шум, она неизбежно подавляет и тихие элементы речи – мягкие согласные, окончания слов, вдохи, придающие речи естественность. В результате получается плоский, роботизированный звук с эффектом «выпадения», который вы слышали на переобработанных звонках, где человек будто говорит через плохое соединение. Именно поэтому ITU-T P.835 оценивает качество речи (SIG) отдельно от уровня подавления шума (BAK): подавитель, настроенный на идеальную оценку BAK, часто демонстрирует ужасные показатели SIG, а общий результат оказывается хуже, чем при более мягком подходе.

Исправление – настраивать на общее качество, а не на максимальное подавление шума, и тестировать на реальном шуме, а не на демо-образце от вендора. Запишите образцы в условиях, близких к реальным для ваших пользователей (домашний офис с собакой, больничная палата, шумный класс), протестируйте каждый кандидат на разных уровнях интенсивности и оцените результаты с помощью DNSMOS P.835. Почти всегда лучшая настройка – не самая агрессивная. Подавитель, убирающий 90% шума и сохраняющий естественность голоса, превосходит тот, что удаляет 99% шума, но делает речь роботизированной.

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

Мы создаём продукты, в которых критически важен чистый, живой звук – платформы видеоконференций, телемедицинские системы, где врач должен слышать каждое слово пациента, онлайн-обучение и инструменты для наблюдения и вещания. В этой работе выбор подавителя шума – это не всегда вопрос максимального качества; важнее адаптировать модель под реальные ограничения продукта. В приватных телемедицинских решениях часто используется локальная модель – open-source самохостинг или локальный SDK Krisp – чтобы звук пациента ни при каких условиях не покидал устройство. В браузерных конференциях с ограниченным вычислительным бюджетом обычно начинают с встроенного базового решения noiseSuppression и переходят к RNNoise в WebAssembly только тогда, когда пользователи сталкиваются с его ограничениями. Наш подход: сначала фиксируем допустимый бюджет задержки, затем учитываем требования к приватности и поддерживаемым платформам, и только после этого сопоставляем качество с затратами, потому что подавитель, превышающий лимит задержки, – это не высокое качество, а полная неработоспособность.

Как выбирать – пять вопросов

Пройдите по ним по порядку – каждый сужает поле.

1. Достаточно ли уже встроенного браузерного подавителя? Включите noiseSuppression: true, протестируйте на реальных пользователях, и если жалобы прекратились, отгрузите и остановитесь здесь. Не интегрируйте модель, которая вам не нужна.
2. Какой у вас бюджет задержки? Сделайте арифметику G.114 для вашего конвейера. Если у вас меньше ~20 миллисекунд запаса, RNNoise – единственный безопасный вариант для самохостинга; ~40 миллисекунд DeepFilterNet не влезут.
3. На каком железе это должно работать? Одно ядро CPU, или телефон, или браузер указывают на RNNoise. Способный современный CPU, готовый впитать нагрузку, указывает на DeepFilterNet ради качества. Нужно везде без работы под каждую платформу? Krisp.
4. Можете ли вы потянуть эксплуатацию или хотите от неё откупиться? Самохостинг RNNoise или DeepFilterNet бесплатен по лицензии, но стоит инженерного времени на интеграцию, тюнинг и поддержку. Krisp стоит денег, но снимает эту ношу на каждой платформе.
5. Запрещает ли приватность или регуляция отправлять звук с устройства? Все три работают на устройстве, так что все три проходят – но проверьте конкретное развёртывание и предпочтите open-модели или локальный SDK Krisp любому облачному API-подавителю.

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

• Шумоподавление приглушает фон, оставляя голос чётким – это не эхоподавление.
• Добавленная задержка – метрика, определяющая качество живого звонка; ориентируйтесь на цель в 150 мс по стандарту G.114.
• RNNoise – компактный, бесплатный, работает в браузере и хорошо справляется с постоянным фоном; задержка около 10 мс.
• DeepFilterNet – лидер среди open-source решений по качеству, но добавляет около 40 мс и требует больше вычислительных ресурсов.
• Krisp – платное управляемое решение, работает на устройстве на любой платформе, задержка около 25 мс.
• Встроенное решение noiseSuppression в браузере – базовый бесплатный вариант; попробуйте его перед любой интеграцией.

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

• Потоковый ASR в продакшене – Deepgram, Whisper и AssemblyAI в 2026
• Потоковый TTS – Kokoro, ElevenLabs Turbo, Cartesia и OpenAI TTS
• Задержка, топология развёртывания и реальное время против батч-обработки