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

TL;DR

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

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

Если ваш продукт несёт живой голос – инструмент видеоконференций, телемедицинская консультация, онлайн-класс, голосовой агент поддержки, – самый быстрый способ сделать его дешёвым на вид это позволить фоновому шуму одного участника долететь до всех остальных. Шумоподавление это исправляет, но оно не бесплатно: выберете не ту модель – и либо добавите слишком много задержки (звонок начнёт звучать как спутниковый телефон), либо сожжёте слишком много процессора (фича посадит батареи ноутбуков и умрёт на телефоне). Статья для продакт-менеджера, основателя или техлида, которому нужно решить, какой подавитель шума пойдёт в продукт и хостить ли open-модель или платить за управляемую. К концу вы поймёте, как эти системы отделяют голос от шума, почему «добавленная задержка» – это метрика, которая открывает или закрывает живой звонок, как 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 работает сильно ниже 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-качество, а железо и бюджет задержки могут впитать лишнюю цену.

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 выигрывает по сырому open-качеству. 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 с людьми приберегите для финального go/no-go перед крупным запуском.

Большая часть этой культуры бенчмаркинга выросла из 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-лидер по качеству, но добавляет ~40 мс и требует больше вычислений.
• Krisp платный и управляемый, работает на устройстве на любой платформе, задержка ~25 мс.
• Встроенный noiseSuppression браузера – бесплатный базис; попробуйте его до любой интеграции.

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

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