Исследовать облегчённый CPU-профиль диаризации #25

New Issue

2026-08-14T21:43:32+03:00

ddmitry commented

2026-08-14 21:43:32 +03:00

Связано с реализацией диаризации: #24.

Контекст

Текущий профиль Pyannote segmentation 3.0 FP32 + WeSpeaker ResNet34 LM качественно прошёл калибровку, но диаризация занимает примерно 60% полного времени обработки и увеличивает wall-clock транскрипции в 2,2–2,6 раза.

Минутный debug-профиль показал:

segmentation: 1,243 с (~19%);
speaker embeddings: 5,150 с (~81%);
clustering: около 0 с.

Высокая стоимость ожидаема из-за 10-секундных окон Pyannote с шагом 1 с и отдельного embedding для каждого локального говорящего каждого окна. При этом sherpa-onnx официально поддерживает INT8-сегментацию и nemo_en_titanet_small, которые потенциально быстрее.

Исходные данные:

docs/research/2026-08-14-diarization-cpu-cost.md;
docs/benchmarks/2026-08-14-diarization-calibration.md;
docs/benchmarks/2026-08-14-diarization-intel-i7.md;
официальный benchmark sherpa-onnx: https://k2-fsa.github.io/sherpa/onnx/speaker-diarization/models.html.

Цель

Найти более лёгкий CPU-профиль диаризации без недокументированной потери качества либо зафиксировать, что текущий WeSpeaker остаётся оправданным default.

Что проверить

На одних и тех же трёх контрольных записях сравнить:

Pyannote FP32 + WeSpeaker ResNet34 LM — baseline.
Pyannote INT8 + WeSpeaker ResNet34 LM.
Pyannote FP32 + NeMo TitaNet small.
Pyannote INT8 + NeMo TitaNet small.
CAMPPlus zh/en не пересвипывать с нуля, а использовать существующие результаты как дополнительный кандидат только для режима с известным --speakers N.

Для каждой новой комбинации:

подобрать единый clustering threshold для автоматического режима;
отдельно проверить известное число участников;
измерить segmentation / embeddings / clustering / total, RTF, peak RSS и загрузку CPU;
зафиксировать число всех и содержательных кластеров, малые кластеры и неназначенные слова;
посчитать mapped speaker purity для T2 BDMA и Yantar по существующим references;
выборочно прослушать границы коротких реплик и смен говорящего;
убедиться, что ASR-текст не меняется и не теряется.

Критерии приёмки

Все новые модели и их SHA-256, лицензии и источники зафиксированы.
Есть воспроизводимый benchmark на Data Test, T2 BDMA и Yantar с одинаковыми условиями.
Автоматический кандидат оценивается одним общим threshold, а не отдельным значением на каждый файл.
Отчёт явно сравнивает скорость, purity, 3/2/2 ожидаемых содержательных голоса, малые кластеры и unknown words с baseline.
Если облегчённый профиль проигрывает по качеству, результат всё равно считается завершённым: кандидат отклоняется с измеренным обоснованием.
Если кандидат проходит, отдельно описаны минимальные изменения кеша, manifest, CLI/конфига и миграции текущего default; production-код в рамках benchmark-этапа не переключается.
Итог сохранён отдельным Markdown-отчётом в docs/benchmarks/ и отражён в ADR-007.

Вне scope

Параллельный запуск ASR и диаризации. Он уменьшает wall-clock, но не CPU-работу и требует отдельного benchmark конкуренции за ядра и общего peak RSS.
GPU/NPU-провайдеры.
Изменение шага окна через нестандартный Python binding.

Связано с реализацией диаризации: #24. ## Контекст Текущий профиль `Pyannote segmentation 3.0 FP32 + WeSpeaker ResNet34 LM` качественно прошёл калибровку, но диаризация занимает примерно 60% полного времени обработки и увеличивает wall-clock транскрипции в 2,2–2,6 раза. Минутный debug-профиль показал: - segmentation: 1,243 с (~19%); - speaker embeddings: 5,150 с (~81%); - clustering: около 0 с. Высокая стоимость ожидаема из-за 10-секундных окон Pyannote с шагом 1 с и отдельного embedding для каждого локального говорящего каждого окна. При этом sherpa-onnx официально поддерживает INT8-сегментацию и `nemo_en_titanet_small`, которые потенциально быстрее. Исходные данные: - `docs/research/2026-08-14-diarization-cpu-cost.md`; - `docs/benchmarks/2026-08-14-diarization-calibration.md`; - `docs/benchmarks/2026-08-14-diarization-intel-i7.md`; - официальный benchmark sherpa-onnx: https://k2-fsa.github.io/sherpa/onnx/speaker-diarization/models.html. ## Цель Найти более лёгкий CPU-профиль диаризации без недокументированной потери качества либо зафиксировать, что текущий WeSpeaker остаётся оправданным default. ## Что проверить На одних и тех же трёх контрольных записях сравнить: 1. Pyannote FP32 + WeSpeaker ResNet34 LM — baseline. 2. Pyannote INT8 + WeSpeaker ResNet34 LM. 3. Pyannote FP32 + NeMo TitaNet small. 4. Pyannote INT8 + NeMo TitaNet small. 5. CAMPPlus zh/en не пересвипывать с нуля, а использовать существующие результаты как дополнительный кандидат только для режима с известным `--speakers N`. Для каждой новой комбинации: - подобрать единый clustering threshold для автоматического режима; - отдельно проверить известное число участников; - измерить segmentation / embeddings / clustering / total, RTF, peak RSS и загрузку CPU; - зафиксировать число всех и содержательных кластеров, малые кластеры и неназначенные слова; - посчитать mapped speaker purity для T2 BDMA и Yantar по существующим references; - выборочно прослушать границы коротких реплик и смен говорящего; - убедиться, что ASR-текст не меняется и не теряется. ## Критерии приёмки - Все новые модели и их SHA-256, лицензии и источники зафиксированы. - Есть воспроизводимый benchmark на Data Test, T2 BDMA и Yantar с одинаковыми условиями. - Автоматический кандидат оценивается одним общим threshold, а не отдельным значением на каждый файл. - Отчёт явно сравнивает скорость, purity, 3/2/2 ожидаемых содержательных голоса, малые кластеры и unknown words с baseline. - Если облегчённый профиль проигрывает по качеству, результат всё равно считается завершённым: кандидат отклоняется с измеренным обоснованием. - Если кандидат проходит, отдельно описаны минимальные изменения кеша, manifest, CLI/конфига и миграции текущего default; production-код в рамках benchmark-этапа не переключается. - Итог сохранён отдельным Markdown-отчётом в `docs/benchmarks/` и отражён в ADR-007. ## Вне scope - Параллельный запуск ASR и диаризации. Он уменьшает wall-clock, но не CPU-работу и требует отдельного benchmark конкуренции за ядра и общего peak RSS. - GPU/NPU-провайдеры. - Изменение шага окна через нестандартный Python binding.

ddmitry added the ready-for-agent label 2026-08-14 21:43:32 +03:00

ddmitry referenced this issue

2026-08-14 21:56:51 +03:00

feat(diarization): добавлено разделение транскрипта по говорящим #26

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: ddmitry/local-transcriber#25