Автор технического разбора поделился опытом превращения серийной умной колонки Яндекс.Станция Мини 3 в самодельного голосового ассистента с моделью Claude в роли «мозга». Исходное устройство с кодовым именем bergamot построено на четырёхъядерном процессоре и оснащено микрофонным массивом, динамиком и кольцом светодиодов, однако вся эта аппаратная часть была жёстко привязана к голосовому помощнику Алисе. Задача формулировалась просто: заменить активационное слово «Алиса» на «Клод» и получать ответы от модели, которую пользователь выбирает сам, причём с минимальной задержкой и без обращения к инфраструктуре Яндекса. Автор отдельно оговорил, что не прибегал к пайке и отладке через UART, а работал исключительно программными методами и предусмотрел путь отката, чтобы не вывести колонку из строя окончательно.

Ключевым шагом стало получение прав суперпользователя через отладочные интерфейсы, включая ADB на порту 5555, о чём уже достаточно написано на профильных площадках вроде Хабра и 4PDA. Важная техническая деталь: корневая файловая система смонтирована как UBIFS и доступна на запись, а механизм dm-verity на системном разделе не задействован, поэтому переделывать прошивку можно прямо на работающем устройстве. После установки SSH-сервера dropbear автор удалил весь яндексовский userspace, включая голосовой стек и служебные демоны, оставив голый Buildroot. Попутно выяснилась неочевидная деталь: в dropbear нет sftp-сервера, поэтому scp не работает, и файлы приходилось передавать через конструкции вида ssh root@host 'cat > file'. Ещё одна особенность железа заключается в том, что ядро 64-битное, а весь userspace 32-битный armhf, что позволяет запускать как armhf-бинари через системную glibc, так и статические aarch64-сборки.

Архитектура конвейера выстроена вокруг локальной обработки звука и двух облачных вызовов. Микрофоны передают поток в детектор активационного слова, затем Vosk выполняет распознавание речи прямо на устройстве, после чего запрос уходит в Claude API, а синтез ответа выполняет ElevenLabs, и результат воспроизводится через aplay. Индикация кольца тоже переосмыслена: оранжевое вращение означает прослушивание, пульсация — обработку запроса, ровный свет — произнесение ответа. Кросс-компиляция велась на macOS с использованием Zig в качестве компилятора для armhf и статических aarch64-сборок, а для Rust применялся cargo-zigbuild. Значительную часть кода, по признанию автора, написал Claude Code: он предлагал реализацию, собирал бинарники, заливал их на колонку и анализировал логи, тогда как человек задавал направление работ.

Выбор движка распознавания речи оказался результатом прямого сравнения двух вариантов на самом устройстве. Статическая сборка whisper.cpp с моделью tiny в квантовании q5_1 распознавала русский язык и укладывалась в память с пиком около 138 МБ, но обработка четырёх секунд аудио занимала почти двенадцать секунд, поскольку модель всегда анализирует тридцатисекундное окно. Для живого диалога такая задержка неприемлема. Vosk с моделью small-ru-0.22 работает потоково и почти в реальном времени, пик потребления памяти составляет около 157 МБ, при этом он же выступает детектором активационного слова, мгновенно распознавая «клод» в частичных результатах. В процессе интеграции пришлось решать несколько прикладных проблем: библиотека libvosk.so поставляется без SONAME, из-за чего линкер прописывает полный путь, и это лечится через patchelf, а клиент требуется собирать под glibc 2.30. Кроме того, микрофоны отдают четыре канала, из которых живые — только первые три, а четвёртый служит для обратной связи.

В роли «мозга» выступает прямой HTTPS-запрос к Claude Messages API без каких-либо агентных надстроек. Клиент написан на Rust с использованием ureq и rustls и собран статически под aarch64, что позволило уложить работу с TLS в десяток строк. Используется модель claude-haiku, ориентированная на скорость и низкую стоимость, и ответ приходит примерно за секунду. В процессе эксплуатации обнаружился неожиданный сбой: API начал возвращать блок extended thinking, из-за чего наивный парсер, бравший content[0].text, не находил текста и отправлял в синтез речи весь сырой JSON. Многомегабайтный ответ уходил в ElevenLabs и приводил к исчерпанию памяти и аварийному завершению процесса. Исправление состоит в обходе массива content с извлечением только блоков типа text, а также в системном промпте с требованием отвечать кратко, в одно-три предложения и без markdown, поскольку голосовой ассистент не должен зачитывать вслух звёздочки разметки.

Отдельная сюжетная линия проекта связана с неисправностью воспроизведения звука: сгенерированная голосом фраза проигрывалась примерно втрое медленнее, чем следовало. Диагностика потребовала вмешательства в регистры тактового генератора, то есть в настройки на уровне драйверов, а не прикладного кода. Этот эпизод иллюстрирует общий контекст подобных проектов: замена штатного ассистента на кастомного требует не только интеграции языковой модели, но и глубокого погружения в особенности конкретной аппаратной платформы. На фоне растущего интереса к локальным голосовым интерфейсам и доступным API больших моделей такие эксперименты показывают, что серийные потребительские устройства вполне пригодны для пересборки под собственные сценарии, хотя порог входа остаётся высоким и предполагает уверенное владение кросс-компиляцией, отладкой встраиваемых систем и работой с сетевыми API.

Для российского рынка умных колонок этот опыт показателен с нескольких точек зрения. С одной стороны, он демонстрирует, что аппаратная база популярных устройств допускает полную программную замену экосистемного слоя, а значит, часть пользователей теоретически может уходить от привязки к одному вендору и его облачным сервисам. С другой стороны, реализация опирается на зарубежные облачные API для генерации ответов и синтеза речи, что в условиях ограничений на доступ к внешним сервисам делает подобные конфигурации скорее полигоном, чем массовым решением. Практическая ценность проекта прежде всего в задокументированных подводных камнях: совместимость glibc, отсутствие SONAME у библиотек, особенности многоканального захвата звука и обработка неожиданных форматов ответа API — всё это пригодится разработчикам встраиваемых систем независимо от того, какую модель они выберут. Перспективы направления зависят от двух факторов: доступности компактных моделей распознавания и синтеза, способных работать полностью офлайн в жёстких рамках памяти, и стабильности форматов облачных API, на которые опирается логика клиента. Полностью автономным ассистент автора назвать нельзя, поскольку два ключевых этапа обработки вынесены в облако, хотя распознавание и активационное слово уже работают на самом устройстве. Открытым остаётся вопрос энергопотребления и теплового режима при длительной работе тяжёлых моделей на компактном железе, а также вопрос о том, насколько подобные модификации совместимы с гарантийными и сервисными обязательствами производителя. Тем не менее опубликованный код даёт сообществу воспроизводимую отправную точку, и можно ожидать появления форков под другие модели колонок и другие языковые бэкенды.