Запуск Gemini 3.1 Flash Live — и что готовила Nextain
Сегодня был запущен Gemini 3.1 Flash Live. Из-за странного совпадения по времени мы решили опубликовать нашу технологию, которую мы готовили, хоть она и не полностью завершена. Naia OS уже поддерживала Gemini Live через аккаунт Naia и провайдер Google, и мы немедленно применили Gemini 3.1 Flash Live. Вы можете убедиться в этом на видео ниже.
Такие модели, называемые S2S или Omni-моделями, обеспечивают более быстрый и естественный диалог по сравнению с существующими конвейерами STT, LLM и TTS.
Модели голосового диалога в реальном времени (S2S, omni model), имитирующие процесс обучения человеческой речи
Режим голосового общения GPT-4o, Gemini Live и MiniCPM-o являются яркими примерами таких моделей, которые позволяют вести диалог не текстом, а голосом, в реальном времени, с передачей эмоций. На английском языке их обычно называют Speech to Speech (S2S) или Omni Model. Мы считали, что они гораздо больше похожи на человека, чем существующие однонаправленные STT (модели преобразования речи в текст) или TTS (модели преобразования текста в речь). Причина, по которой глухим людям трудно учиться говорить, заключается в том, что они не слышат свою собственную речь, что затрудняет процесс обучения.
Поэтому я решил, что это будущее моделей голосового диалога и что они станут мейнстримом. Я удалил отдельные опции настройки STT/TTS, объединив их в 'модель живого диалога', и добавил API Gemini Live и gpt-4o-realtime-preview. Однако, поскольку оба API платные, для бесплатных пользователей я обозначил их как 'TTS Only' и включил Edge в выбор модели диалога. Так вышла недавняя (вчерашняя) версия 0.1.2. Я интегрировал API Gemini Live с аккаунтом Naia и провел реальные тестовые беседы, и был очень доволен реакцией диалога с точки зрения эмоциональной обратной связи и скорости отклика.
Недоразумение относительно моделей голосового диалога в реальном времени, которые я ошибочно считал просто моделями STT/TTS
Однако здесь было большое недоразумение. Я понимал API Gemini Live как интегрированную модель STT/TTS следующего поколения, но позже выяснилось, что в нее встроен определенный LLM, а именно Gemini 2.5 Flash, и что этот LLM нельзя изменить.
MiniCPM-o-4.5: Модель голосового диалога в реальном времени для локального использования
Я осознал это недоразумение, когда начал искать и применять модели голосового диалога в реальном времени, которые можно было бы запускать на уровне RTX-3090, поскольку Naia стремится поддерживать локальные модели, доступные для пользователей. Первыми кандидатами были Moshi, Qwen3-Omni-30b и MiniCPM-o-4.5. Moshi является пионером в этой области среди открытых источников, но поддерживает в основном английский/французский языки, и его сообщество неактивно, поэтому я его не выбрал. Qwen3-omni-30b — это новейшая модель с отличной производительностью, но 24 ГБ VRAM одной RTX 3090 было недостаточно, и она не была проверена, поэтому я ее исключил. В итоге выбор пал на MiniCPM-o. Хотя он в настоящее время не поддерживает корейский язык, я решил, что при определенных инвестициях можно будет провести дополнительную тонкую настройку языка, а поддержка референсного аудио позволит реализовать желаемый пользователем TTS.
Кроме того, я подумал, что благодаря небольшому размеру MiniCPM-o, его можно было бы запускать вместе с Qwen3-omni-30b-a3b, используя оставшуюся VRAM из 24 ГБ, что значительно повысило бы производительность LLM даже на уровне RTX-3090. Qwen3-omni, как уже упоминалось, является моделью голосового диалога в реальном времени (Omni-моделью), но я не выбрал ее, потому что при квантовании голосовой вывод искажался, и ее нельзя было запустить на потребительских GPU с 24 ГБ VRAM, хотя для LLM квантованные модели показывают хорошую производительность.
Поэтому я развернул MiniCPM-o на локальном GPU (RunPod RTX 3090), создал сервер-мост Websocket и подключил его к приложению Naia. В процессе я обнаружил, что модель не воспроизводит то, что слышит. Но здесь я сделал решающее открытие: встроенная модель Qwen3-8B отвечала, и Omni-модель обучается end-to-end, что делает ее незаменяемой. То есть, MiniCPM-o, по сути, было бы точнее называть Qwen3-8b-omni. Точнее, для прослушивания используется Whisper-medium, для 'мозга' — Qwen3-8b, для синтеза речи — CosyVoice2, а для зрения — SigLip2. Эти различные модели объединяются и переобучаются с использованием мультимодальных данных. В широком смысле это тонкая настройка, но поскольку объем мультимодальных данных огромен, затраты могут составлять десятки или сотни миллиардов вон. Недавно в корейском сообществе Dokpamo было много споров о том, 'с нуля' или нет, и, похоже, это говорит о том, что реальная цель не ограничивается только созданием 'с нуля'.
(→ Записи экспериментов с MiniCPM-o)
MiniCPM-o-4.5: История попыток с кодом Claude для поддержки vllm-omni
Однако, поскольку встроенный Qwen3-8b сам по себе считается эквивалентом GPT-4o, я не мог просто так пройти мимо. Более того, учитывая возможность использования голосовых референсов и тонкой настройки LLM, я решил, что это модель, которую Nextain, стремящаяся к суверенному ИИ, обязательно должна развивать. Я форкнул vllm и развернул его на RunPod, но для этого потребовалось 48 ГБ VRAM. Я работал над этим почти два дня. Позже я узнал, что существует отдельный проект под названием vllm-omni, и что кто-то уже работает над MiniCPM-o-4.5. Поэтому мы оставили комментарий, предложив поддержку тестирования l3. (→ vllm-omni #1182) Ответа пока не было, и пока мы ждали, мы продолжали внутренние попытки на основе vllm-omni.
На этот раз я подошел к делу особенно осторожно. Ранее я уже получал резкую критику, когда загружал PR, созданный с помощью Claude Code, в другой проект с открытым исходным кодом, не полностью проверив анализ ИИ. Анализ кода был неполным, правила сообщества не соблюдались, и я даже создал что-то, выходящее за рамки проекта, что было вполне естественно. Поэтому на этот раз я собирал контекст с точки зрения upstream репозитория и повторял процесс 'враждебного' ревью. Только после этого я объявил 'чистый проход', убедился, что диалог работает, подключив его к naia-os, и создал документацию для внесения вклада в upstream, которую затем просмотрел.
Но RunPod снова упал, и сегодня, когда я попытался его поднять, он снова не работает. Неполные записи, сделанные во время работы, помешали мне. Невозможно проверить среду выполнения, поэтому воспроизведение невозможно. Я просмотрел все предыдущие записи сессий, чтобы найти их, и сейчас снова воспроизвожу, исправляя записи, но в итоге снова обнаружил критическую проблему и был вынужден остановить процесс. Я использовал определенный шаблон, потому что он был новым, а не соответствовал шаблонам других моделей vllm-omni, и когда vllm-omni обновился, все сломалось. Результаты анализа показали сбой в управлении тестовой обвязкой и контекстом, что привело к написанию еще одного промежуточного отчета, и на его основе я снова скорректировал контекст и тестовую обвязку, а также провел итеративный анализ кода вместо дорогого RunPod. ㅜㅜ
https://github.com/nextain/vllm-omni/blob/main/.agents/docs/minicpm-o-midterm-review.md
Сегодня, в связи с новостью о запуске Gemini 3.1 Flash Live, я хотел бы опубликовать видео работы MiniCPM-o-4.5. Но, к сожалению, это оказалось не так просто. Сейчас уже полчетвертого утра. Прежде всего, цель этой работы — реализовать экосистему AI-native Opensource, эксперимент, который позволит ИИ корректно вносить вклад в открытый исходный код без 'AI slop'. Я думаю, что на следующей неделе ситуация станет проще, так как я собираюсь одолжить несколько видеокарт.
По мере дальнейшей работы я также поделюсь информацией о том, возможны ли аудиореференсы или тонкая настройка LLM.
Ссылки
- Gemini 3.1 Flash Live — Model Card (Google DeepMind)
- Speech-to-Speech Models in 2026: Three Architectural Bets — Сравнение архитектур интегрированных голосовых моделей
- Introducing gpt-realtime — Simon Willison — Анализ модели gpt-realtime
- GPT-4o vs. GPT-4.1: All the differences — Различия в ролях между моделями
- MiniCPM-o 실험 결과 (GitHub Issue) — Результаты экспериментов с MiniCPM-o (GitHub Issue)
- 설정 UI 재설계 (GitHub Issue) — Переработка пользовательского интерфейса настроек (GitHub Issue)
- STT/TTS 파이프라인 설계 (GitHub Issue) — Проектирование конвейера STT/TTS (GitHub Issue)
