Свой голосовой ассистент на базе локальной модели

MAATRIX

«Окей, Гугл» и «Алиса» слушают вас постоянно и отправляют каждую фразу на серверы компании, которая эту фразу потом использует по своему усмотрению — для рекламы, для обучения следующей модели, для чего угодно, о чём в пользовательском соглашении сказано в общих словах. Для бытового «поставь таймер на десять минут» это не страшно. Но если голосовой ассистент нужен в кабинете, где обсуждают договоры, в кабинете врача, где звучат диагнозы, или просто дома, где вы не хотите, чтобы корпорация имела стенограмму вашей семейной жизни — облачный вариант не подходит в принципе, вне зависимости от того, насколько он удобен. Собрать замену из трёх открытых моделей на собственном сервере — реально, и ниже разобрано, как эти три компонента связываются в рабочий ассистент, чего ждать от задержки и когда такая связка действительно нужна.

Схема связки: три модели вместо одного облачного API

Голосовой ассистент — это не одна модель, а конвейер из трёх независимых сервисов, которые передают друг другу результат работы:

Голос → [Whisper: речь → текст] → [Ollama: текст → текст-ответ] → [Piper: текст → голос] → Голос

Каждое звено решает свою узкую задачу и ничего не знает о соседях — Whisper не понимает смысла того, что распознал, Ollama не имеет представления, что её ответ прочитают вслух, а Piper озвучит любой текст, который ему передадут, хоть инструкцию к стиральной машине. Связывает их только код-оркестратор: он принимает аудио на входе, дергает три сервиса по очереди и отдаёт аудио на выходе. Все три модели — открытые веса, и все три можно развернуть на одном обычном сервере без видеокарты: диалоговая скорость GPU нужна для звонка в реальном времени, а не для ассистента, который отвечает через несколько секунд после вопроса.

Практическая схема развёртывания — три процесса на localhost, наружу торчит только точка входа (веб-интерфейс, Telegram-бот, десктопное приложение — выбор зависит от того, как вы хотите обращаться к ассистенту):

Ничего из этого не обязано быть доступным из интернета — сервисы общаются между собой локально, и в фаерволе, кроме SSH и, возможно, порта вашего интерфейса, открывать нечего.

Распознавание речи: Whisper слушает первым

Первое звено конвейера — превратить аудио в текст. Whisper (в связке обычно берут ускоренную реализацию faster-whisper, а не оригинальный пакет OpenAI — она заметно легче на CPU) принимает WAV 16 кГц моно и отдаёт распознанный текст с таймкодами. Если голос приходит не в этом формате — например, записан браузером в WebM или пришёл из мессенджера в OGG/Opus — между «получили звук» и «отправили в Whisper» в коде всегда стоит перекодирование через ffmpeg.

Для голосового ассистента, где реплики короткие и произносятся сразу, важны две настройки, если ваша сборка их поддерживает: жёстко заданный язык ru (экономит проход автоопределения и не даёт короткой фразе случайно уехать в распознавание на английском) и фильтр тишины (VAD), без которого модель на паузах и фоновом шуме иногда домысливает слова, которых не было. Модель small — разумная отправная точка: заметно легче medium, а на короткой бытовой фразе разница в точности обычно небольшая; апгрейд до medium или large-v3, если точность станет важнее скорости, — не архитектурное решение, а смена одного параметра.

Подробно про установку faster-whisper, диаризацию (кто говорит) и автоматизацию вокруг распознавания — в отдельном разборе: расшифровка звонков на своём сервере через Whisper. Там же — честные цифры про то, во сколько раз large медленнее small на CPU, без выдуманных бенчмарков.

Генерация ответа: Ollama — мозг ассистента

Распознанный текст уходит второму звену — языковой модели через Ollama. Устанавливается она одной командой:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2.5:7b

Сервис слушает 127.0.0.1:11434 и по умолчанию наружу не торчит — ровно то, что нужно для локального ассистента. Обращение к нему — обычный HTTP-запрос:

curl http://127.0.0.1:11434/api/chat -d '{
  "model": "qwen2.5:7b",
  "messages": [{"role": "user", "content": "Какая сегодня погода?"}],
  "stream": false
}'

Для голосового сценария выбор модели — это в первую очередь выбор между скоростью ответа и его качеством, а не только между размером весов: компактные модели (3B–7B параметров в квантовании Q4) отвечают заметно быстрее на CPU, а разница в связности ответа для бытового диалога часто менее заметна, чем разница в ожидании. Отдельно стоит прописать в системном промпте запрет на markdown — списки, звёздочки, заголовки — потому что TTS читает их вслух буквально, и «звёздочка звёздочка важно» в озвученном ответе производит странное впечатление. Как подобрать модель под конкретные ресурсы сервера и что означают квантования вроде Q4 и Q8, подробно разобрано в статье как поднять локальный запуск LLM через Ollama на сервере.

Синтез речи: Piper озвучивает ответ

Последнее звено превращает текстовый ответ обратно в голос. Piper — открытый нейросетевой TTS-движок, изначально созданный для проекта голосового управления умным домом, лёгкий по требованиям к ресурсам и умеющий говорить на нескольких десятках языков, включая русский, голосами разного качества и «веса» (обычно градации вроде low/medium/high — чем выше, тем естественнее звучание и тяжелее модель голоса). Работает он полностью локально: голосовая модель скачивается один раз, дальше синтез идёт без единого обращения наружу. По сравнению с Whisper и LLM это самое лёгкое звено связки — синтез короткой фразы занимает малую долю от общего времени ответа, и именно поэтому оптимизировать в первую очередь стоит не TTS, а два предыдущих шага.

Точный набор команд для установки, доступные русские голоса и как поднять Piper постоянным сервисом — в отдельной статье, специально под это: как установить и настроить Piper TTS на VPS. Здесь важна общая логика: на входе Piper ждёт текст (тот самый ответ от Ollama, желательно уже без markdown-мусора), на выходе отдаёт аудиофайл, который дальше воспроизводится или пересылается пользователю тем же способом, каким пришёл вопрос.

Честная задержка: почему это не Siri и не Алиса

Здесь стоит быть предельно честным, потому что именно на этом ожидании чаще всего разочаровываются в самодельных голосовых ассистентах. Облачные ассистенты вроде Siri, Google Assistant или Алисы отвечают почти мгновенно не потому, что их модели волшебным образом быстрее — а потому, что за ними стоят кластеры GPU, которые держат модель в памяти постоянно прогретой и обрабатывают запрос параллельно с сотнями тысяч чужих запросов на специализированном железе. Локальная связка на обычном CPU-сервере так не умеет в принципе — и три звена конвейера складываются последовательно, а не параллельно: пока не закончилось распознавание, LLM не начинает генерацию, пока не сгенерирован полный (или хотя бы частично готовый) ответ, TTS не начинает синтез.

Итоговое время ответа — это сумма трёх задержек: распознавание короткой фразы, генерация ответа языковой моделью и синтез речи. На CPU-сервере без GPU эта сумма обычно измеряется секундами, а не долями секунды — конкретные цифры сильно зависят от длины фразы, выбранной модели Ollama, числа ядер и того, крутится ли на сервере что-то ещё одновременно, поэтому не стоит доверять чужим цифрам без замера на своём железе: прогоните типичный диалог через time и посмотрите на свои значения. Качественно порядок такой: распознавание фразы — доли секунды до пары секунд, генерация ответа — самое медленное звено конвейера и главный источник задержки, синтез речи — обычно заметно быстрее первых двух. Если нужен диалог с задержкой, неотличимой от живого разговора — например, полноценный голосовой помощник для звонка — такая CPU-связка не подойдёт, и разговор нужно вести уже про GPU-сервер и потоковую генерацию, где ответ начинает звучать раньше, чем модель закончила думать.

Когда локальный голосовой ассистент оправдан

Прямой вопрос — стоит ли вообще с этим связываться, если облачный ассистент отвечает быстрее — решается не техническими характеристиками, а тем, что важнее в конкретном сценарии: скорость ответа или контроль над тем, куда уходит голос.

Сценарии, где локальная связка оправдана:

• Разговоры с чувствительным содержанием. Юридическая консультация, медицинский приём, обсуждение договоров и финансов — где голос и текст разговора не должны покидать периметр компании ни при каких условиях, а не только «пока всё хорошо с политикой обработчика».
• Регуляторные требования. Работа с персональными данными по 152-ФЗ или отраслевым требованиям, где обработка речи на стороннем облачном сервисе создаёт юридический риск сама по себе, независимо от того, что именно спросили.
• Умный дом и офлайн-устройства. Ассистент, который должен работать даже если пропал интернет или если вы принципиально не хотите, чтобы устройство постоянно слало аудио наружу — классический мотив энтузиастов домашней автоматизации.
• Предсказуемая стоимость при большом объёме. Облачные голосовые API считают по минутам и символам — при сотнях диалогов в день счёт становится заметной статьёй расходов, а свой сервер после развёртывания стоит фиксированную сумму в месяц независимо от нагрузки.

Сценарии, где облачный вариант честнее выбрать:

• Живой разговор в реальном времени. Звонок, где задержка в доли секунды критична для естественности диалога — CPU-связка здесь проиграет, и даже GPU-версия локального решения потребует серьёзной инженерной работы над потоковой генерацией, чтобы приблизиться к качеству облака.
• Разовое использование без штата, который будет это поддерживать. Три сервиса на сервере нужно обновлять, мониторить и чинить при сбоях — если голосовой ассистент нужен на один проект на месяц, аренда готового API часто выходит дешевле по суммарным трудозатратам.

Если по итогам сравнения перевешивает приватность — сравнение экономики и рисков локальной модели против облачного API подробно разобрано отдельно, в том числе с честным разбором, где облако всё же выигрывает: локальная модель против облачного API — что выгоднее и когда.

Частые вопросы