Спроектировать end-to-end карту ускорения CPU-диаризации #45

New Issue

2026-09-01T01:09:43+03:00

ddmitry commented

2026-09-01 01:09:43 +03:00

Результат

Построить отдельную карту end-to-end ускорения CPU-диаризации после исхода new map в #42. Карта должна превратить результаты #41/#42 в повторно используемый журнал гипотез, определить новые архитектурные кандидаты и подготовить следующую измерительную задачу без полного перепрогона старой матрицы.

Почему

Эксперимент #41/#42 установил границу локальных оптимизаций: сокращение окон теряет голосовой кластер, а безопасный shared-session C2 дает на Ryzen медиану 23,57% при пороге 30%. Публичные отчеты хорошо фиксируют решение, но история проверки распределена между спецификацией, Intel-отчетом, Ryzen-отчетом и закрытой капсулой. Перед новым запуском нужен единый ledger: что проверено, каким рецептом, почему ветвь остановлена и какое изменение предпосылок оправдывает повтор.

Сначала прочитать

#41 и все комментарии, включая HANDOFF READY.
#42 и финальный комментарий new map.
Intel-отчет.
Ryzen-отчет и PR #44.
docs/specs/2026-08-30-cpu-diarization-experiment.md.
Связанные исследования: diarization-speaker-count, diarization-embedding-inference, sherpa-window-shift, diarization-cpu-cost и ADR-007.

Замороженный вход

Результаты #41/#42 и закрытая капсула ryzen-42-20260831 считаются существующим набором доказательств. Их агрегаты, рецепты и хеши нужно переносить в карту, а не получать заново. Приватные пути, записи, текст, интервалы и идентификаторы не публикуются.

Выполнить

Собрать единый ledger всех проверенных гипотез #41/#42. Для каждой строки указать:
- стабильный ID и механизм;
- точный переносимый рецепт и измененную относительно baseline ось;
- этап и машину;
- время, ускорение, память и обязательные показатели качества;
- решение продолжить / остановить / требует слуховой проверки;
- точную причину решения и ссылку на публичную строку результата либо SHA-256 приватного результата.
Отдельно перечислить непройденные гейты и незакрытые вопросы. C1 не считать проигравшей или победившей: ее диагностическая слуховая проверка не выполнена.
Разложить wall time действующего конвейера на segmentation, embeddings, clustering и orchestration. Для каждого компонента записать измеренную долю, уже проверенные способы сокращения и оставшийся теоретический потолок. Не подменять отсутствующее измерение оценкой.
Сформировать не меньше трех end-to-end архитектурных гипотез. Для каждой зафиксировать:
- что меняется сразу в нескольких стадиях конвейера;
- почему предыдущий quality gate может не сработать тем же образом;
- ожидаемый потолок ускорения и главный риск качества;
- самый дешевый falsification test;
- какие существующие ячейки и артефакты переиспользуются.
Устранить пересечения с открытыми задачами: параллельный ASR и диаризация остается в #22, автоматическое включение - в #23. Если кандидат зависит от них, дать ссылку, но не включать их реализацию в эту карту.
Выбрать максимум два кандидата для следующего измерительного issue. До выбора модели не запускать.
Зафиксировать карту в docs/research/YYYY-MM-DD-end-to-end-cpu-diarization-map.md. Если измерительный контракт уже однозначен, дополнительно подготовить узкую спецификацию и отдельную ready-for-agent задачу на эксперимент.

Политика повторных прогонов

Полный replay #41/#42 запрещен по умолчанию.

Старая ячейка повторяется только когда явно изменилось хотя бы одно из следующего:

код или модель внутри измеряемого механизма;
runtime, wheel либо переносимый рецепт;
машина или условия стенда, для которых нет совпадающего baseline;
обязательный показатель качества или правило решения;
целостность исходного результата не подтверждается опубликованным хешем.

Для новой гипотезы запускать только затронутый минимальный срез, затем один совпадающий baseline и первичный A/B. Пять чередующихся циклов и полные записи разрешены только после прохождения заранее записанных порогов. Обычные unit/integration tests запускаются по измененному коду; весь Python-suite нужен перед PR, но он не требует повторного запуска аудиомоделей.

Границы

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

Приемка

ledger покрывает каждую гипотезу и каждую принятую/остановленную ветвь #41/#42;
по любой строке видно, что именно проверялось, что получилось и почему повтор нужен или не нужен;
C1 отмечена как незакрытый listening gate без выдуманного вердикта;
decomposition отделяет измерения от оценок и показывает потолок локальных оптимизаций;
описаны минимум три falsifiable end-to-end гипотезы и выбраны максимум две;
следующая измерительная задача может стартовать с минимального среза, не прогоняя заново старую матрицу;
документ и новая задача не содержат приватных путей, текста, интервалов и идентификаторов записей.

## Результат Построить отдельную карту end-to-end ускорения CPU-диаризации после исхода `new map` в #42. Карта должна превратить результаты #41/#42 в повторно используемый журнал гипотез, определить новые архитектурные кандидаты и подготовить следующую измерительную задачу без полного перепрогона старой матрицы. ## Почему Эксперимент #41/#42 установил границу локальных оптимизаций: сокращение окон теряет голосовой кластер, а безопасный shared-session C2 дает на Ryzen медиану 23,57% при пороге 30%. Публичные отчеты хорошо фиксируют решение, но история проверки распределена между спецификацией, Intel-отчетом, Ryzen-отчетом и закрытой капсулой. Перед новым запуском нужен единый ledger: что проверено, каким рецептом, почему ветвь остановлена и какое изменение предпосылок оправдывает повтор. ## Сначала прочитать 1. #41 и все комментарии, включая `HANDOFF READY`. 2. #42 и финальный комментарий `new map`. 3. [Intel-отчет](https://git.dementev.space/ddmitry/local-transcriber/src/branch/master/docs/benchmarks/2026-08-31-cpu-diarization-intel.md). 4. [Ryzen-отчет](https://git.dementev.space/ddmitry/local-transcriber/src/branch/issue-42-ryzen-cpu-experiment/docs/benchmarks/2026-08-31-cpu-diarization-ryzen.md) и PR #44. 5. `docs/specs/2026-08-30-cpu-diarization-experiment.md`. 6. Связанные исследования: `diarization-speaker-count`, `diarization-embedding-inference`, `sherpa-window-shift`, `diarization-cpu-cost` и ADR-007. ## Замороженный вход Результаты #41/#42 и закрытая капсула `ryzen-42-20260831` считаются существующим набором доказательств. Их агрегаты, рецепты и хеши нужно переносить в карту, а не получать заново. Приватные пути, записи, текст, интервалы и идентификаторы не публикуются. ## Выполнить 1. Собрать единый ledger всех проверенных гипотез #41/#42. Для каждой строки указать: - стабильный ID и механизм; - точный переносимый рецепт и измененную относительно baseline ось; - этап и машину; - время, ускорение, память и обязательные показатели качества; - решение `продолжить / остановить / требует слуховой проверки`; - точную причину решения и ссылку на публичную строку результата либо SHA-256 приватного результата. 2. Отдельно перечислить непройденные гейты и незакрытые вопросы. C1 не считать проигравшей или победившей: ее диагностическая слуховая проверка не выполнена. 3. Разложить wall time действующего конвейера на segmentation, embeddings, clustering и orchestration. Для каждого компонента записать измеренную долю, уже проверенные способы сокращения и оставшийся теоретический потолок. Не подменять отсутствующее измерение оценкой. 4. Сформировать не меньше трех end-to-end архитектурных гипотез. Для каждой зафиксировать: - что меняется сразу в нескольких стадиях конвейера; - почему предыдущий quality gate может не сработать тем же образом; - ожидаемый потолок ускорения и главный риск качества; - самый дешевый falsification test; - какие существующие ячейки и артефакты переиспользуются. 5. Устранить пересечения с открытыми задачами: параллельный ASR и диаризация остается в #22, автоматическое включение - в #23. Если кандидат зависит от них, дать ссылку, но не включать их реализацию в эту карту. 6. Выбрать максимум два кандидата для следующего измерительного issue. До выбора модели не запускать. 7. Зафиксировать карту в `docs/research/YYYY-MM-DD-end-to-end-cpu-diarization-map.md`. Если измерительный контракт уже однозначен, дополнительно подготовить узкую спецификацию и отдельную ready-for-agent задачу на эксперимент. ## Политика повторных прогонов Полный replay #41/#42 запрещен по умолчанию. Старая ячейка повторяется только когда явно изменилось хотя бы одно из следующего: - код или модель внутри измеряемого механизма; - runtime, wheel либо переносимый рецепт; - машина или условия стенда, для которых нет совпадающего baseline; - обязательный показатель качества или правило решения; - целостность исходного результата не подтверждается опубликованным хешем. Для новой гипотезы запускать только затронутый минимальный срез, затем один совпадающий baseline и первичный A/B. Пять чередующихся циклов и полные записи разрешены только после прохождения заранее записанных порогов. Обычные unit/integration tests запускаются по измененному коду; весь Python-suite нужен перед PR, но он не требует повторного запуска аудиомоделей. ## Границы - Не менять production-профиль, CLI, конфигурационный контракт и модель по умолчанию. - Не начинать новую полную измерительную кампанию внутри этой задачи. - Не считать ссылку на закрытую капсулу заменой публичной причины отсева. - Не публиковать приватные данные. ## Приемка - ledger покрывает каждую гипотезу и каждую принятую/остановленную ветвь #41/#42; - по любой строке видно, что именно проверялось, что получилось и почему повтор нужен или не нужен; - C1 отмечена как незакрытый listening gate без выдуманного вердикта; - decomposition отделяет измерения от оценок и показывает потолок локальных оптимизаций; - описаны минимум три falsifiable end-to-end гипотезы и выбраны максимум две; - следующая измерительная задача может стартовать с минимального среза, не прогоняя заново старую матрицу; - документ и новая задача не содержат приватных путей, текста, интервалов и идентификаторов записей.

ddmitry added the ready-for-agent label 2026-09-01 01:09:43 +03:00

ddmitry referenced this issue from a commit

2026-09-01 01:36:59 +03:00

docs(diarization): расширен отчет Ryzen-эксперимента

ddmitry added a new dependency 2026-09-01 01:37:18 +03:00

#42 Продолжить CPU-эксперимент на Ryzen и принять финалиста

ddmitry referenced this issue

2026-09-01 01:37:36 +03:00

feat(diarization): завершить Ryzen-этап CPU-эксперимента #44

ddmitry referenced this issue

2026-09-01 15:05:14 +03:00

Эксперимент: проверить Streaming Sortformer v2 Q8_0 против свежего W0 на Ryzen CPU #46