Diarization On-device Pyannote
Diarization

Быстрая on-device диаризация: как ускорить Pyannote 3.1 без потери качества

Pyannote 3.1

Прикладная работа от Fumiaki Yamaguchi (один автор, 7 июня 2026), которая мало кому интересна в академическом сообществе, но важна для всех, кто строит meeting-transcription или voice-агентов под жёсткими SLA по latency и cost.

Речевые приложения вроде meeting transcription и голосовых агентов выиграли бы от on-device speaker diarization, но практическое внедрение ограничено inference cost. Автор изучает, насколько можно ускорить Pyannote 3.1-based pipeline на потребительском железе (RTX 5070 Ti GPU и Apple M4 laptop) при сохранении DER (diarization error rate). Простая стратегия — более грубый segmentation stride и per-chunk embedding — даёт многократные ускорения и DER-нейтральна на AMI, но резко деградирует на in-the-wild данных: на VoxConverse DER растёт с 0.075 до 0.113.

Pyannote 3.1 сегодня — фактический стандарт open-source диаризации, многие коммерческие пайплайны построены поверх него. Стандартный pipeline: VAD/segmentation сеть (TDNN на 5-секундных окнах с stride 0.5 с), embedding сеть (ResNet-based speaker embedder), затем агломеративная кластеризация. На длинном meeting (час+) основной cost — embedding network, которая считает эмбеддинг для каждого сегмента, и количество сегментов растёт с продолжительностью аудио.

Что предлагает Yamaguchi. Две ортогональные оптимизации. Coarser segmentation stride: вместо 0.5 с делаем 1-2 с — в 2-4 раза меньше сегментов на выходе, значит в столько же раз меньше embedding-инференса. Per-chunk embedding: вместо подсчёта эмбеддинга на каждом окне делается batched processing по фиксированным чанкам — лучше использование GPU/MPS.

Интересная находка: на AMI (стандартный академический бенчмарк с относительно чистым meeting-аудио) этот трюк DER-нейтрален. То есть на классических данных ускорение в несколько раз достигается бесплатно. На VoxConverse — данные с YouTube, с реальной in-the-wild сложностью (фоновый шум, перекрытия, разнородное качество) — DER растёт с 0.075 до 0.113. Это значимая деградация (~50% относительной), которая показывает: оптимизация работает, но не везде.

Прикладная значимость работы в том, что она честно очерчивает trade-off. Многие подобные ускорения в литературе рекламируются как «бесплатные» с осторожной формулировкой «на нашем бенчмарке». Здесь автор прямо говорит: на чистых meeting-данных бесплатно, на грязных — нет. Это позволяет инженеру принимать осознанное решение, в зависимости от характера своего production-аудио.

Шире такая работа отражает движение всего поля: производительность frontier-моделей растёт, но edge-deployment остаётся отдельным треком исследования. RTX 5070 Ti и Apple M4 — потребительское железо, на которое теперь можно деплоить серьёзные speech-пайплайны без облака. Это меняет архитектурные решения: например, можно делать предварительную диаризацию прямо на телефоне или ноутбуке клиента, а в облако отправлять только сегменты для облачного ASR.

Фишка из статьи. Статья про on-device diarization хороша диагностикой: speedup-рецепт отлично работает на AMI, но ломается на VoxConverse, пока не учесть embedding budget на спикера. У VoxConverse примерно 10 embeddings/speaker против около 200 на AMI, поэтому фиксированный minimum cluster size начинает выкидывать редких спикеров.

AMI, Apple MPSDERRTFSpeedup
CAM++ baseline, stride 10.0810.0611.0x
stride 20.0800.0252.4x
stride 30.0820.0154.1x
stride 3 + per-chunk0.0820.0069.9x
+ relative min cluster size0.0830.00512.2x
AMI vs VoxConverseAMI DERVox DERAMI RTFVox RTF
Baseline0.0810.0750.0610.004
stride 3 + per-chunk + fixed mcs0.0820.1130.0060.001
+ relative mcs0.0830.0790.0050.00083

Авторы также проверили file-adaptive stride и фактически отвергли его: oracle дает только 1.10x на VoxConverse, потому что 83% файлов требуют stride 1, а turn density почти не коррелирует с оптимальным выбором stride (ρ=-0.04).

Оригинальная статья на arXiv