Быстрая on-device диаризация: как ускорить 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 MPS | DER | RTF | Speedup |
|---|---|---|---|
| CAM++ baseline, stride 1 | 0.081 | 0.061 | 1.0x |
| stride 2 | 0.080 | 0.025 | 2.4x |
| stride 3 | 0.082 | 0.015 | 4.1x |
| stride 3 + per-chunk | 0.082 | 0.006 | 9.9x |
| + relative min cluster size | 0.083 | 0.005 | 12.2x |
| AMI vs VoxConverse | AMI DER | Vox DER | AMI RTF | Vox RTF |
|---|---|---|---|---|
| Baseline | 0.081 | 0.075 | 0.061 | 0.004 |
| stride 3 + per-chunk + fixed mcs | 0.082 | 0.113 | 0.006 | 0.001 |
| + relative mcs | 0.083 | 0.079 | 0.005 | 0.00083 |
Авторы также проверили file-adaptive stride и фактически отвергли его: oracle дает только 1.10x на VoxConverse, потому что 83% файлов требуют stride 1, а turn density почти не коррелирует с оптимальным выбором stride (ρ=-0.04).