Gemini 3.1 Flash Live リリース — そしてNextainが準備していたこと
本日、Gemini 3.1 Flash Liveがリリースされました。絶妙なタイミングで、準備していた技術を不完全ながらも今公開することにしました。Naia OSはNaiaアカウントとGoogleプロバイダーを通じてGemini Liveをサポートしており、すぐにGemini 3.1 Flash Liveを適用しました。以下の動画でご確認いただけます。
これらのモデルは、実際にはS2S、あるいはオムニモデルと呼ばれ、従来の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 1台の24GB VRAMでは到底足りず、検証もされていないため除外しました。最終的に決定したのはMiniCPM-oでした。現在韓国語はサポートしていませんが、ある程度の資金投入が可能であれば言語を追加でファインチューニングでき、オーディオはリファレンスオーディオをサポートしているため、ユーザーが望むTTSまで実装可能だと判断しました。
また、そのサイズが小さいため、24GBで余ったVRAMでQwen3-omni-30b-a3bと一緒に動かせば、RTX-3090クラスでもLLM性能を大幅に向上させることができると考えたのです。Qwen3-omniは前述のリアルタイム音声対話（Omniモデル）ですが、採用しなかった理由は、量子化すると音声出力が壊れてしまい、消費者向けGPUの24GBでは動作させられなかったためです。しかし、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を使用しているとのことです。これらの異なるモデルを結合し、マルチモーダルデータで再訓練するプロセスを経ているそうです。大まかに見ればファインチューニングですが、このマルチモーダルデータの規模が非常に大きいため、その費用は数十億から数百億ウォンかかる可能性があるとのことです。先日、韓国の独歩的なモデルで「from scratchか否か」という議論が多かったですが、実際に到達すべき目標はfrom scratchだけではないということを示唆しているようです。
MiniCPM-o-4.5、vllm-omniサポートのためのClaudeコード挑戦記
しかし、内蔵されているQwen3-8bだけでもGPT-4oクラスだというので、見過ごすことはできませんでした。さらに、音声リファレンス、LLMのファインチューニングの可能性まで持っているため、主権AIを追求するNextainが必ず追求すべきモデルだと判断しました。vLLMをフォークしてRunPodに載せたところ、VRAMが48GBも必要でした。ほぼ2日間稼働させました。その後、vLLM-omniという別のプロジェクトが独立して存在すること、そしてMiniCPM-o-4.5の作業がすでに誰かによって進行中であることを知りました。そこで、私たちがl3テストをサポートするとコメントを付けました。(→ vllm-omni #1182) まだ返答はなく、待っている間、内部的にvLLM-omniをベースに試行を続けました。
今回は特に慎重にアプローチしました。以前、AI分析を不完全に検証したまま、他のオープンソースプロジェクトにClaudeコードで作成したPRを提出し、手厳しく批判されたことがあったからです。コード分析が不完全で、コミュニティのルールも守らず、さらにはそのプロジェクトの範囲外のものを作り出してしまったので、当然のことでした。そこで今回は、リポジトリのアップストリームの観点からコンテキストを収集し、敵対的レビューを繰り返すプロセスを経ました。その上でクリーンパスを宣言し、実際にNaia OSに接続して会話ができることも確認し、アップストリームへの貢献のためのドキュメントも作成してレビューしました。
ところが、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の動作映像を公開したかったのですが、一度でうまくいくのは本当に難しいですね。現在、午前3時半を回ろうとしています。何よりもこの作業の目的は、AI-nativeオープンソースエコシステムの実現、AIがAIスロップなしにオープンソースに正しく貢献できることを可能にしたいという実験です。来週にはグラフィックカードを借りて作業することにしたので、状況は少し楽になるだろうと考えています。
引き続き追加作業が進めば、オーディオリファレンスやLLMファインチューニングが可能になるかどうかも共有させていただきます。
参考
- Gemini 3.1 Flash Live — モデルカード (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)
