Что такое App AI Assistant и кому он нужен
App AI Assistant - открытый голосовой ассистент на Python 3.12 и Asyncio, который работает на 100% офлайн на компьютере пользователя. Код лежит в открытом доступе под лицензией MIT. Движок диалога - локальная Gemma 3 через llama-cpp-python, распознавание речи - связка Vosk и Faster-whisper, синтез - Silero, интерфейс - CustomTkinter.
Отличие от Алисы, Siri и голосового режима ChatGPT укладывается в одну фразу: аудио и текст не покидают вашу машину. Нет подписки, нет счётчика запросов, нет зависимости от чужого аптайма. Взамен придётся выделить под инференс ресурсы своего ПК и потратить время на настройку.
Автор называет проект «Джарвисом на минималках» и локальным компаньоном, с которым можно поговорить. Стек и список возможностей он перечисляет в статье о релизе на Habr. Дальше разбираем, из чего собрана система, что она умеет на практике и где проходит граница её применимости.
Чем офлайн-ассистент отличается от Алисы, Siri и ChatGPT Voice
Сравнивать удобно по трём осям.
- Приватность. Запросы, транскрипты и аудио остаются локально. Для домашних разговоров, рабочих обсуждений и всего, что не хочется отправлять вендору, разница принципиальная.
- Деньги. Подписки нет, но есть стоимость железа: Gemma 3 и две модели распознавания должны где-то считаться. На слабом ноутбуке облачный ассистент дешевле, на простаивающей мощной машине локальный выгоднее.
- Контроль. Модель, системный промпт, набор голосовых команд и скрипты меняются в коде. Логику можно переписать под свои привычки, чего в закрытых продуктах не сделать.
Честная оговорка: качество распознавания и синтеза у облачных сервисов обычно выше, а локальный ассистент требует возни с зависимостями и моделями. Облачные голосовые агенты учатся работать с компьютером и приложениями, пример - голосовое управление агентами в ChatGPT на десктопе. Локальный проект берёт другим: предсказуемостью и отсутствием внешних зависимостей.
Кому проект реально подойдёт, а кому нет
Подойдёт, если вы узнаёте себя в одном из пунктов:
- пишете на Python и готовы читать чужой код, чтобы что-то поправить;
- уже запускаете локальные LLM и знаете, сколько VRAM или RAM съедает модель;
- хотите управлять ПК голосом: открывать папки и браузер, запускать софт и свои скрипты;
- держите домашний AI-сервер и ищете ещё один сценарий для него;
- принципиально не хотите отдавать аудио в облако.
Не подойдёт, если:
- у вас macOS или Linux: текущая версия рассчитана только на Windows 10/11;
- нужен сценарий «поставил и работает» без чтения README;
- ожидается уровень коммерческого ассистента по качеству распознавания и синтеза;
- вы не готовы носить наушники: без эхоподавления ассистент слышит сам себя.
Если задача шире одной комнаты и одного ПК, пригодится другой разбор - схема с ESP32-микрофонами в комнатах и обработкой на домашнем сервере. Там больше железа и возни, зато ассистент не привязан к одной машине.
Архитектура: четыре изолированных сервиса вместо монолита
Система разбита на четыре компонента, которые общаются по HTTP и WebSocket: GUI-оркестратор и три сервиса. Такая декомпозиция решает конкретные задачи. Каждый сервис запускается отдельно, падение одного не утаскивает за собой остальные, а заменить движок синтеза или распознавания можно, не переписывая диалоговую часть. Автор отдельно подчёркивает, что каждый сервис можно использовать из любого языка, об этом сказано в описании проекта.
Речь идёт о лёгких локальных процессах на localhost, а не о микросервисах в Kubernetes. Поднимать кластер ради разговора с ассистентом никто не станет, а вот три Python-процесса на одной машине вполне разумны. Asyncio здесь нужен, чтобы интерфейс не замирал, пока модель считает токены: аудио, сеть и отрисовка окна работают параллельно.
GUI-оркестратор на CustomTkinter: дирижёр системы
Оркестратор отвечает за жизненный цикл сервисов, маршрутизацию запросов и отображение состояния. Он решает, когда отправить аудио в srv_stt, когда передать готовый текст в srv_llm и какую порцию ответа отдать в srv_tts. CustomTkinter выбран как лёгкий GUI: тянет минимум зависимостей и не требует браузерного движка или тяжёлого фреймворка.
Практический плюс схемы в том, что логика диалога живёт в оркестраторе, а не размазана по трём сервисам. Поменять порядок шагов или добавить проверку перед вызовом LLM можно в одном месте.
srv_llm, srv_stt, srv_tts: что делает каждый сервис
| Компонент | Роль | Технологии |
|---|---|---|
| GUI-оркестратор | Управляет сервисами, маршрутизирует запросы, показывает состояние | CustomTkinter, Asyncio |
| srv_llm | Генерирует ответ потоком | Gemma 3 через llama-cpp-python |
| srv_stt | Слушает, ловит речь и прерывания, делает финальную транскрибацию | Vosk и Faster-whisper |
| srv_tts | Синтезирует речь и нормализует текст | Silero и кастомный пайплайн нормализации |
Отлаживать такую систему удобно по частям: например, гонять текст в srv_llm, пока не настроен микрофон, или проверять синтез отдельным HTTP-запросом без голосового ввода.
Как работает голосовой цикл: от речи до ответа
Полный путь запроса выглядит так:
- Микрофон отдаёт аудио в srv_stt.
- Vosk определяет, что человек начал говорить, и фиксирует конец фразы.
- Faster-whisper превращает законченную фразу в точный текст.
- Текст уходит в srv_llm, Gemma 3 генерирует ответ порциями.
- srv_tts синтезирует первые порции, оркестратор отправляет их в воспроизведение, пока модель дописывает остаток.
Конвейер построен на разведении задач по инструментам: быстрые решения принимает лёгкая модель, точную работу делает тяжёлая. Так экономится вычислительный ресурс, которого на одном ПК всегда не хватает.
Гибридный STT: зачем Vosk и Faster-whisper одновременно
Vosk лёгкий и быстрый. Его задача - слушать постоянно, замечать речь и фиксировать моменты, когда пользователь перебил ассистента. Держать на этом месте Faster-whisper слишком дорого: тяжёлую модель невыгодно гонять на каждый кадр аудио.
Faster-whisper включается после того, как фраза закончилась, и делает финальную транскрибацию с более высоким качеством. Разделение ролей даёт отзывчивость детектора и точность итогового текста одновременно. Цена - два набора зависимостей и две модели на диске.
Потоковый ответ и barge-in: как ассистент не перебивает сам себя
Потоковый ответ снижает воспринимаемую задержку. LLM отдаёт токены порциями, TTS начинает озвучивать первые, и человек слышит реакцию раньше, чем модель закончила предложение. Ждать полной фразы перед синтезом не нужно.
Barge-in решает обратную задачу: если пользователь заговорил во время ответа, Vosk фиксирует речь, оркестратор останавливает воспроизведение, и ассистент замолкает на полуслове. Выглядит как нормальный диалог, но есть условие: без полноценного эхоподавления система может принять собственный голос из колонок за реплику пользователя. Отсюда требование к наушникам.
Практические возможности: скрипты, контекст, автоматизация ПК
Разговор с моделью - только часть сценариев. Вторая часть - управление компьютером голосом.
Голосовой запуск Python-скриптов и изоляция через .venv
Через голосовые команды ассистент запускает любые ваши Python-скрипты: открыть папку, открыть браузер, запустить нужный софт. В проект можно добавлять ссылки и скрипты, у которых есть собственное виртуальное окружение в директории .venv. Разные задачи не смешивают зависимости, и конфликт версий библиотек между скриптами не возникает. По сути ассистент превращается в голосовой лаунчер для рутины.
Для разработчика это самый практичный слой: свои действия проще описать скриптом и вызывать его фразой, чем ждать, пока LLM научится работать с GUI приложения.
Контекст между сессиями: как ассистент «помнит» разговоры
Проект сохраняет краткое резюме диалогов между сессиями. После перезапуска ассистент опирается на это резюме, а не начинает с чистого листа. Уровень памяти скромнее, чем у RAG-систем: векторного поиска по всей истории и базы эмбеддингов здесь нет, хранится сжатое описание прошлых разговоров.
Для бытовых сценариев этого хватает. Если нужна память уровня «найди, что я говорил про отпуск три недели назад», архитектуру придётся расширять самостоятельно.
Установка и запуск: нативный путь вместо Docker
Автор сознательно отказался от контейнеров. Вместо Docker Desktop работает собственный установщик и лаунчер, который поднимает portable Python и Git и запускает лёгкие Python-процессы напрямую. Для пользователя это означает меньше подготовительных шагов перед первым запуском.
Почему не Docker: аргументы автора
Docker Desktop для Windows требует гигабайты дискового пространства, настройки WSL2 и включённой виртуализации в BIOS. Человек, который хочет просто поговорить с ассистентом, проходить через этот квест не обязан, и логика здесь понятная.
Компромисс тоже очевиден. Для серверных сценариев, CI и воспроизводимых окружений Docker остаётся удобнее. Нативный лаунчер улучшает опыт обычного пользователя на Windows и мало что даёт тем, кто разворачивает ассистента в контейнерах на домашнем сервере.
Сборка в один .exe через PyInstaller
Проект можно собрать в один .exe через PyInstaller: пользователю достаточно запустить единственный файл. По описанию автора это идеальный сценарий распространения, а не утверждение, что готовый релизный бинарник уже лежит в общем доступе. Сборка .exe остаётся отдельным шагом для тех, кто хочет отдавать проект людям без Python.
Общий порядок запуска выглядит так:
- Проверить, что система - Windows 10 или 11, и освободить место под веса моделей.
- Запустить установщик и дать ему поднять portable Python и Git.
- Подготовить веса Gemma 3 и модели распознавания речи.
- Запустить сервисы через оркестратор, подключить наушники и микрофон.
Точные команды и версии зависимостей в исходной статье не расписаны: их стоит смотреть в README проекта, там же обновляется порядок шагов.
Ограничения и компромиссы: что важно знать до старта
Проект молодой, и информация о нём идёт от автора: независимой проверки характеристик не было, поэтому производительность лучше измерять на своей машине. Все заявленные возможности и ограничения перечислены в авторской публикации.
Только Windows и только Gemma: цена узкой специализации
Поддержка ограничена Windows 10/11. Это следствие нативного развертывания и сборки через PyInstaller: путь выбран ради простоты установки, и кроссплатформенность в него не заложена. На macOS и Linux проект в текущем виде не заработает без переписывания части кода.
Второе ограничение - адаптация под шаблон Gemma. Системные промпты и обвязка srv_llm настроены под эту модель. Замена на другую LLM потребует правок промптов, а возможно и кода сервиса. Это осознанный компромисс: автор жертвует универсальностью ради работоспособности из коробки.
Отсутствие AEC и другие бытовые неудобства
Эхоподавления (AEC) в проекте нет. Ассистент слышит собственный голос из колонок, поэтому без наушников barge-in срабатывает ложно и диалог разваливается. Сценарий «умная колонка в центре комнаты» с текущей версией не работает.
Второй бытовой момент - ресурсы. Локальный инференс Gemma 3 и двух моделей распознавания нагружает машину, и на слабом железе ответы будут заметно медленнее облачных. Качество Silero и Vosk тоже уступает коммерческим облачным движкам, хотя для домашней автоматизации этого часто достаточно.
Стоит ли брать App AI Assistant за основу: выводы
Ценность проекта в архитектуре, которую можно переиспользовать. Изоляция сервисов, гибридный STT, потоковая выдача ответа и barge-in - это те части голосового ассистента, на которые обычно уходит больше всего времени. Здесь они уже собраны и работают вместе, а лицензия MIT разрешает брать код в свои проекты.
Пробовать стоит, если вы на Windows, готовы к настройке и хотите офлайн-автоматизацию ПК с голосовым управлением. Пройти мимо логично, если нужна кроссплатформенность, готовый продукт без доработок или работа без наушников.
Когда форк оправдан, а когда проще собрать своё
Форк оправдан при совпадении трёх условий: Windows как целевая система, Gemma как движок диалога и потребность в голосовом запуске скриптов. В этом случае вы получаете работающий каркас и дорабатываете детали под свои задачи.
Своё с нуля имеет смысл при кроссплатформенных требованиях, другой LLM в основе или серверном деплое. Там нативные решения проекта придётся разбирать и переписывать, и проще взять отдельные идеи: гибрид быстрого детектора и точной модели, потоковый синтез, остановку воспроизведения по детекции речи.
Если хочется сравнить подходы, посмотрите разбор PersonalJarvis, self-hosted ассистента с локальными моделями и MCP: другая архитектура, другой набор компромиссов. Практический шаг для старта один: поставить проект на Windows-машину с наушниками, прогнать несколько фраз и своих скриптов, а затем решить, хватает ли текущего качества распознавания и синтеза для ежедневной работы.