Зафиксировать аппаратную матрицу и бюджет памяти #35
Notifications
Due Date
No due date set.
Blocks
#34 Собрать минимальную матрицу следующего CPU-эксперимента
ddmitry/local-transcriber
Reference: ddmitry/local-transcriber#35
Reference in new issue
Block a user
Часть карты: Спроектировать следующее ускорение CPU-диаризации (#31)
Question
Какие правила аппаратной матрицы и жесткие границы по ускорению и памяти должен использовать следующий эксперимент, если у проекта нет целевого процессора или обязательного SKU?
Контролируемые доступные ориентиры:
Intel Core i5 11-го поколения - пример распространенного пользовательского класса, а не приемочная машина. Прогоны на других Intel/AMD-ноутбуках и новом Mac при их доступности дают сведения о переносимости, но не заменяют контролируемую матрицу.
Нужно зафиксировать нижний порог ускорения (сейчас 30%), ориентир около 2x, допустимый peak RSS с учетом наблюдавшихся дополнительных 147-149 MiB у TitaNet и правило, разрешены ли разные профили по ISA или архитектуре.
Зафиксировать целевые CPU-классы и бюджет памятиto Зафиксировать аппаратную матрицу и бюджет памятиРешение
Проект не рассчитан на одну модель процессора. Следующий эксперимент использует две доступные контрольные машины с разными ролями:
Полную матрицу на Ryzen повторять не нужно. Его достаточно использовать для узких A/B-проверок INT8/QDQ, параллельного расчета эмбеддингов и других вариантов, чей результат зависит от ISA или числа ядер, а затем для финальной проверки выбранной комбинации. В отчете нужно указывать фактические CPUID-флаги и доступные наборы команд: название поколения процессора их не заменяет.
Другие x86-машины дают дополнительные сведения о переносимости. Совместимость с Mac поддерживаем по мере возможности; отдельного приемочного прогона и обещаний производительности для него нет.
Скорость
Итоговая комбинация проходит критерий по скорости, если сокращает время диаризации на Ryzen минимум на 30%. Ориентир - примерно двукратное ускорение. На старом Intel заранее не задается допустимый процент регрессии: вариант должен корректно работать и проходить действующую проверку качества, а решение о приемлемости фактического замедления принимается после замеров.
Сначала проверяются главные источники ускорения: уменьшение числа окон, быстрая модель эмбеддингов с надежной оценкой числа говорящих и существенные изменения исполнения. Мелкие оптимизации не отбрасываются по отдельному процентному порогу, но откладываются до проверки крупных оптимизаций.
Память
Для каждой ячейки сохраняются пиковый RSS процесса и его изменение относительно исходного варианта на той же машине. Если RSS превышает 2 ГиБ на ноутбуке с 16 ГиБ RAM, причину нужно разобрать. Само по себе превышение не означает отказа от варианта.
Поводы остановить эксперимент: OOM, активное использование подкачки, рост RSS от повтора к повтору без выхода на плато или рост потребления памяти пропорционально числу воркеров или сессий. Если RSS превышает 2 ГиБ без этих признаков, отдельно сопоставляем память, скорость и качество.
Условия замеров
Число потоков не превышает числа физических ядер: не более 4 на Intel и 8 на Ryzen. Прежние результаты на Intel, снятые с 8 потоками, не годятся для прямого сравнения; базовый замер следующего эксперимента нужно повторить с тем же числом потоков и в тех же условиях, что и вариант.
Для каждого результата фиксируются точный SKU, физические ядра и логические потоки, RAM, CPUID/ISA, ОС и версии библиотек, питание, power mode, governor, turbo и power limits, температура, throttling и фактическое число потоков. A/B-пары прогоняются в стабильном режиме одной машины.
Ограничение по физическим ядрам само по себе не доказывает, что приложение не мешает фоновой офисной работе. Пригодность к фоновой работе не входит в критерии приемки этого эксперимента и не считается проверенной.
Отдельный пользовательский профиль по ISA или автоматический выбор резервного пути по возможностям процессора заранее не проектируются. Если полный эксперимент покажет, что они нужны, это будет отдельное решение после замеров.