Gemini 3.1 Flash Live 发布 — 以及 Nextain 正在准备什么
今天，Gemini 3.1 Flash Live 正式发布。时机恰好吻合，我们决定现在公开这项尚未完全成熟的技术。Naia OS 一直通过 Naia 账户和 Google 提供商支持 Gemini Live，并立即应用了 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 的单独设置选项，将其整合为“实时对话模型”，并添加了 Gemini Live API 和 gpt-4o-realtime-preview。然而，由于这两个 API 都是付费的，为了免费用户，我们将其标记为 TTS Only，并将 Edge 加入到对话模型选择中，最新版本 0.1.2（昨天）就是这样发布的。Gemini Live API 也与 Naia 账户进行了集成，经过实际测试对话后，其对话响应在情感反馈和响应速度方面都非常令人满意。
对实时语音对话模型的误解，曾以为它只是 STT/TTS 模型
然而，这里存在一个很大的误解。我曾将 Gemini Live API 理解为下一代 STT/TTS 集成模型，但后来才发现它内置了特定的 LLM 模型，即 Gemini 2.5 Flash，并且无法更换 LLM。
可在本地使用的实时语音对话模型 MiniCPM-o-4.5
我之所以意识到这个误解，是因为 Naia 致力于支持用户可在本地使用的模型，我在寻找并应用可在 RTX-3090 级别上运行的实时语音对话模型时发现了这一点。最初考虑的对象是 Moshi、Qwen3-Omni-30b 和 MiniCPM-o-4.5。Moshi 是该领域的开源先驱，但其支持语言主要为英语/法语，且社区不活跃，因此未被选择；Qwen3-omni-30b 性能优异且最新，但单块 RTX 3090 的 24GB VRAM 远远不够，且未经充分验证，因此也被排除。最终决定采用 MiniCPM-o。虽然目前不支持韩语，但如果投入一定资金，可以进行额外的语言微调，并且由于支持参考音频，我们判断可以实现用户想要的 TTS 功能。
此外，它体积小巧，我们认为如果与 Qwen3-omni-30b-a3b 一起在 24GB 剩余 VRAM 上运行，即使在 RTX-3090 级别也能大幅提升 LLM 性能。Qwen3-omni 也是前面提到的实时语音对话（Omni 模型），但未被采用的原因是，如果进行量化，语音输出会损坏，无法在消费级 GPU 的 24GB VRAM 上运行；但作为 LLM，量化模型据说表现出良好的性能。
因此，我们将 MiniCPM-o 部署到本地 GPU (RunPod RTX 3090) 上，并创建了一个 Websocket 桥接服务器，将其连接到 Naia 应用程序。在操作过程中，我们发现模型并没有吐出它听到的内容。但在这里，我们决定性地了解到，内置的 Qwen3-8B 模型正在响应，并且 Omni 模型是经过端到端训练的，无法替换。所以，称 MiniCPM-o 为 Qwen3-8b-omni 可能更合适。确切地说，它听取部分使用 Whisper-medium，大脑部分使用 Qwen3-8b，语音合成使用 CosyVoice2，视觉部分使用 SigLip2。据说它通过将这些不同的模型连接起来，并使用多模态数据进行再训练。从广义上讲，这是一种微调，但由于多模态数据的规模非常庞大，其成本可能高达数百亿韩元。前段时间，韩国的独派模（Dokpamo）就“从零开始”还是“非从零开始”争论不休，这似乎在说明真正需要攀登的山峰不仅仅是“从零开始”。
MiniCPM-o-4.5，为支持 vllm-omni 而挑战 Claude 代码
然而，既然内置的 Qwen3-8b 已经达到了 GPT-4o 级别，我们就不能轻易放弃。更何况，它还具备语音参考和 LLM 微调的可能性，因此我们判断这是追求主权 AI 的 Nextain 必须追求的模型。 我们 fork 了 vLLM 并将其部署到 RunPod 上，结果发现需要 48GB 的 VRAM。我们几乎运行了两天。后来才发现，有一个名为 vLLM-omni 的独立项目，并且 MiniCPM-o-4.5 的工作已经有人在进行中了。因此，我们评论表示愿意支持 l3 测试。(→ vllm-omni #1182) 目前还没有回应，在等待期间，我们内部继续尝试基于 vLLM-omni 进行开发。
这次我们特别谨慎地处理。因为之前我们曾将未经充分验证的 AI 分析结果，以 Claude 代码的形式提交到其他开源项目，结果遭到了严厉批评。代码分析不完整，没有遵守社区规则，甚至创建了超出项目范围的内容，这当然是情理之中的事。所以这次，我们从仓库的上游视角收集上下文，并反复进行对抗性审查。之后我们宣布了 Clean Pass，并确认它能实际连接到 Naia OS 并进行对话，还创建了用于上游贡献的文档并进行了审查。
然而，RunPod 之前下线了，今天尝试重新上线却又失败了。工作中不完整的记录拖了后腿。无法确认运行时环境，就无法重现问题。我们翻遍了所有之前的会话记录，找到了问题所在，现在正在重新复现并修改记录，但最终又发现了一个关键问题，不得不停止。我们使用了某个特定模式，因为它与 vLLM-omni 其他模型的模式不同，是全新的，结果随着 vLLM-omni 的更新，所有这些都崩溃了。分析结果显示是 harness 和上下文控制失败，我们又写了一份中期报告，并在此基础上再次修改上下文和 harness，并让代码进行重复分析，而不是使用昂贵的 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 的运行视频。但一次性成功真的很难。现在时间已接近凌晨 3:30。最重要的是，这项工作的目的是实现 AI-native 开源生态系统，这是一个实验，旨在让 AI 能够在没有 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)
- 设置 UI 重新设计 (GitHub Issue)
- STT/TTS 管道设计 (GitHub Issue)
