Яндекс Дропс — первое носимое устройство Яндекса с голосовым ассистентом Алиса — вышло сегодня. Инженер команды голосовых технологий Григорий Афанасенко описал, как команда адаптировала споттер — компонент, распознающий ключевую фразу прямо на устройстве, без обращения к серверу — под жёсткие ограничения наушникового железа.
В умных колонках задача голосовой активации решается относительно просто: стабильное питание от розетки, несколько микрофонов, производительный процессор. Наушники — другая история. Крошечный аккумулятор, 208 КБ встроенной SRAM, флеш-память от 256 КБ до 1 МБ и чип с NPU (Neural Processing Unit), заточенным под нейросетевые вычисления при минимальном энергопотреблении. Модели из пайплайна колонок весят около 1,7 МБ — в такое железо они не помещаются физически.
| Параметр | Умные колонки | Яндекс Дропс |
|---|---|---|
| Размер модели споттера | ~1,7 МБ | ~200 КБ |
| Количество моделей (споттер + команды) | 2 отдельные | 1 объединённая |
| Снижение нагрузки от VAD | — | в 5 раз |
| Снижение энергопотребления от master-slave | — | в 1,8–2 раза |
Чтобы уложиться в ограничения, команда применила три техники сжатия одновременно. Depthwise-separable convolution разбивает обычную свёртку на два последовательных шага — пространственный и межканальный, — сокращая число параметров примерно в 20 раз при минимальной потере качества. Дистилляция знаний позволила обучить лёгкую модель-«ученика» на предсказаниях тяжёлой серверной модели-«учителя»: ученик перенимает поведение учителя, не копируя его размер. Квантование в 8 бит сжало веса ещё в четыре раза — с 32-битного до 8-битного формата хранения. В итоге споттер уместился примерно в 200 КБ.
Двухэтапный пайплайн VAD + споттер снизил нагрузку на систему в 5 раз; VAD активен лишь около 15% времени.
Отдельной проблемой стал SDK производителя чипа. Он ограничивает размер ядра свёртки до 15 фреймов для обычных операций и до 11 для depthwise (один фрейм — 10 мс звука), не поддерживает padding и не умеет работать с функцией активации Hardswish. Отсутствие padding означает, что временна́я размерность уменьшается на каждом слое, поэтому для набора нужного контекста пришлось делать сеть глубже. Глубокая сеть с ReLU вместо Hardswish дала классическую проблему затухания градиента — нижние слои почти не обучались. Переход на residual-архитектуру (добавление прямых связей, «перепрыгивающих» через несколько слоёв) решил проблему, хотя из-за отсутствия padding residual-связи пришлось прокладывать нестандартно, согласуя размерности вручную. Позже команда разобралась, как использовать стриминговый режим NPU для свёрточных моделей — это позволило увеличить размер модели вдвое без выхода за пределы памяти.
Энергопотребление оптимизировали на двух уровнях. Первый — двухэтапный пайплайн: постоянно работает только VAD (Voice Activity Detector) на основе быстрого преобразования Фурье, который отделяет голос от фонового шума. Споттер включается лишь тогда, когда VAD зафиксировал речь. На тестовой записи длиной 7,5 часа VAD был активен около 15% времени — нагрузка на систему упала в 5 раз по сравнению с непрерывной работой споттера. VAD также адаптирует чувствительность под уровень шума: три режима от максимальной чувствительности в тишине до минимальной в шумной обстановке. Второй уровень — режим master-slave: в каждый момент голосовой активацией занимается только один наушник, второй уходит в режим пониженного энергопотребления. При снижении заряда роли меняются. Синхронизация происходит по Bluetooth, потребление на голосовую активацию снижается в 1,8–2 раза по сравнению с параллельной работой обоих наушников.
В колонках быстрые команды — «Громче», «Тише», «Дальше» — обрабатывает отдельная модель, которую удобно обновлять независимо от споттера. Для наушников две модели означали бы двойную нагрузку на память и вычисления. Команда объединила их в одну сеть, перебалансировав датасет так, чтобы каждая команда встречалась примерно одинаково часто. Для разметки сложных активаций в шуме использовался ансамбль серверных моделей и моделей споттера.
Остаётся нерешённой проблема холодного старта: на момент начала разработки данных с реальных наушников не существовало. Аудио с устройства логируется в сжатом формате Opus — несжатый PCM не передать из-за ограничений пропускной способности и памяти. Сжатие вносит артефакты, которых нет в исходном сигнале, поэтому обучающие данные неизбежно содержат следы кодека, и модель должна быть к ним устойчива. Как команда решала проблему сбора данных на старте — в статье не раскрывается, это обозначено как отдельная история.