Realtime-Venus：Ant Groupの全二重9B、ローンチなしで出荷

2026年9月12日、arXivに技術レポートが公開され、Realtime-Venusについて説明していた。これは、別々に訓練された2つの9Bモデルから構築された全二重インタラクションシステムである。音声視覚インタラクション用のRealtime-Venus-Omniと、音声対話用のRealtime-Venus-Audioからなり、Ant GroupのVenus Teamが清華大学と共同で取り組んだものとクレジットされている。数日以内に、Apache-2.0リポジトリがinclusionAI/Realtime-VenusとしてHugging Face上に現れ、両チェックポイントがダウンロード可能なBF16 safetensorsとして、プロジェクトページと付随するGitHubリポジトリとともに収められていた。現れなかった部分こそ注目に値する。ローンチ投稿も、製品ページも、APIも、価格表もなく、Ant Group自身のプロパティ上でそのいずれかの存在を告知するものも何もなかった。これは発表以外のすべてを出荷したリリースであり、そのため、確立された事実と主張を切り分けることが仕事のすべてになる。

ディスクには実際に何が入っているのですか

リポジトリはスタブではありません。2つのモデルディレクトリがあり、それぞれにシャーディングされたsafetensors重み、config、そしてカードが次のコードで読み込むよう指示しているカスタムHugging Face Transformersコードが含まれていますtrust_remote_code=True。requirementsファイル、トークンから波形へのリソースと参照音声を収めたassetsフォルダ、そしてトップレベルにはApache-2.0ライセンスがあります。カードには、CUDAとFFmpegを使ったPython 3.10向けのインストール方法、およびModelScopeミラーとHugging Faceからのダウンロード経路の両方が記載されています。重みは本物で、コードもそこにあり、今日ダウンロードすることを妨げるものは何もありません。

2つの不在は、内容と同じくらい多くのことを物語っている。第一に、そのリポジトリは、いかなる推論プロバイダーによってもデプロイされていないと明白に述べている——ホストされたエンドポイントも、サーバーレスオプションも、それを提供するサードパーティプラットフォームも存在しない。第二に、ダウンロードは一切追跡されていない。つまり、何人がそれを取得したかを示す公開シグナルは存在しない。Hugging Face上では、モデルが採用されているようにも、無視されているようにも見えることがあるが、このモデルはそのようには読み取れない。

2つのチェックポイント、そしてそれらを隔てるもの

どちらも9Bで、両方ともストリーミングのバックボーンを共有しており、両者の違いは何を知覚できるかにある。

• Realtime-Venus-Omni — 音声視覚チェックポイント。ストリーミングフレーム用のSigLIP2視覚エンコーダ、Whisper-Medium音声エンコーダ、およびQwen3-8B言語バックボーン。動画または画像、音声、テキストを受け取り、テキストと、オプションで音声波形を返します。

• Realtime-Venus-Audio — 読み込み時にビジョンをオフにした、同じバックボーンです。オーディオとテキストを入力し、テキストと音声を出力します。カメラが無関係で、より小さなメモリフットプリントとよりシンプルな経路を求める場合のために存在します。

・共通仕様 — 両方とも40,960トークンのコンテキスト、両方ともBF16重み、音声は、末尾に後付けされた別個のテキスト読み上げモデルではなく、ストリーミング・フローマッチング・デコーダによってデコードされる離散S3トークンとして生成される。

• 系譜 — モデルカードには、Omniチェックポイントが、OpenBMBが2026年初頭にオープンソース化した9BのオムニモーダルモデルであるMiniCPM-o 4.5から適応されたものだと記載されている。これは脚注ではない。つまり、Ant Groupの貢献は、他社のストリーミング基盤の上に重ねられたポストトレーニング、ランタイム、そして委譲設計にあり、これは「新しい9Bオムニモデル」とは異なる、より具体的な主張である。

真に新しいアイデアはただ一つ：委譲をファーストクラスのストリームイベントとして扱うこと

2026年のあらゆる全二重システムは、同じ矛盾を解決しなければならない。会話制御はミリ秒から1秒の粒度で動作する。ツール呼び出し、検索、高度な推論には数秒から数十秒かかる。考えるために一時停止するモデルは全二重ではなくなり、決して一時停止しないモデルはツールを使えない。

Realtime-Venus は二重ループのランタイムで応答する。インタラクションループは固定の1秒単位で動作し、音声と映像の特徴を継続的に取り込み、会話状態を更新し、聞くべきか話すべきかを判断しながら、テキストとそれに同期した音声をストリーミングする。バックグラウンド処理が進行中でも一時停止しない。2つ目のループは、論文が Realtime-Venus-Harness と呼ぶスケジューラである。フロントエンドが、あるタスクをインラインで実行できる範囲を超えると判断すると、自身の隠れたシーケンスに埋め込まれたプライベートマーカーを通じて非同期の委譲を発行し、ハーネスがそのタスクをバックグラウンドで実行して、結果を進行中の対話に再統合する。

これを単なる図以上のものにしている細部は、論文が「因果的タスク捕捉」と呼んでいるものである——委任されたタスクは会話状態の隔離されたスナップショットに対して実行されるため、長時間動くバックグラウンドタスクが、実行中に会話が先へ進むことで破壊されることがない。これこそが、ほとんどの「委任して話し続ける」設計が実運用でつまずく失敗モードであり、報告書の中で最も興味深い点である。

ハーネスは重みの中にはない。それは別個のコンポーネントとしてGitHubリポジトリに存在する。つまり、そのアーキテクチャを特徴づける部分は、自分で組み立て、自分で信頼しなければならない部分だということになる。

その数字、そしてそれが正確に誰のものなのか

以下の数値はすべて、技術報告書とモデルカードから引用したものです。著者以外の誰によっても再現されておらず、第三者による評価も公表されておらず、照合できるリーダーボードの登録もありません。これらは著者自身の測定値として読んでください。

• 動画ベンチマーク、Realtime-Venus-Omni — レポートが使用する8つのベンチマークのうち6つで最高スコア、StreamingBench 70.2、OVO-Bench 64.7、Daily-Omni 81.3を含む。

• 音声ベンチマーク、Realtime-Venus-Audio — MMAU 78.0、MMAU-Pro 63.2、Llama Questions 83.8、Speech CMMLU 67.8、そしてVoiceBench AlpacaEvalスコア4.81は、レポートが最高の比較値に匹敵すると説明しているものである。

• Full-Duplex-Bench v1.5 — ユーザーの中断の75%に応答し、継続率はあいづちで97%、他者に向けられた発話で88%、背景音声で86%。報告書は、これが3つすべての継続指標でGemini 3.1 LiveとGPT-4oを上回ると述べている。

Daily-Omniの数値こそ、少し立ち止まって考える価値がある。このチェックポイントの適応元であるMiniCPM-o 4.5は、同じベンチマークで80.2を報告している。Realtime-Venus-Omniは81.3を報告している。両方の数値が持ちこたえるなら、大規模なポストトレーニングとランタイムの取り組みによる改善は、ベースモデルがすでに強かったベンチマークでおよそ1ポイントということになる——これはこの種の作業としては現実的な結果であり、「8つのうち6つで最高」という見出しよりもはるかに劇的でない話だ。

確立されていないものは何か

未解決の問いのリストは解決済みのものより長く、それが、生まれてまだ六日しかたっていないモデルの正直な状態だ。

• 独立した評価は存在しない。アリーナの順位でもなく、第三者による再現でもなく、数値を公表した外部グループも一つとしてない。

• ミリ秒単位のレイテンシ数値がない。レポートには1秒間隔のインタラクション・ケイデンスが記載され、カードには毎秒のストリーミング呼び出しが記録されているが、公開されている time-to-first-audio の数値はなく、これはこのカテゴリが実際に購入判断の基準としている指標である。

• APIも価格もなく、どちらかが提供されるという表明もない。これが発売待ちの製品なのか、それともダウンロード提供のみで留まる研究上の成果物なのかは、本当に不明である。

• ベンダーからの明言された意図はない。アナウンスがないことは、静かなローンチ戦略の証拠にはならない。それは、論文のために公開されたリポジトリであり、それ以上ではないこととも整合する。

• ハーネスについては本番環境での裏付けとなるエビデンスが一切ない。これはアーキテクチャの要となる構成要素でありながら、最も文書化が進んでいない部分である。

なぜ静かなルートが起こり続けるのか

これは、今年Ant Groupのモデルに関する取り組みが、ローンチではなくリポジトリを通じて一般に届いた2度目の事例だ。同ラボのGUIエージェントであるUI-Venus-2-9Bは、論文もプロジェクトページも告知もなしに、2026年8月末にHugging Faceに登場し、その後レポートが続いた。Realtime-Venusは逆の順序で登場した。まずレポート、リポジトリは同時に、告知は依然として見送られている。

このパターンはAnt Groupに固有のものではない。特に中国のラボは、研究成果物や消費者向けデプロイを世に送り出しながら、開発者向けの発表を後回しにしたり、省略したりしてきた。この分野を追う者にとってこれは不便だ。というのも、いつものシグナル — ローンチ記事、料金表、ドキュメントサイト — こそが、まさに欠けている部分だからだ。今や成果物が発表そのものであり、何がリリースされたかを知る唯一の方法は、それを注意深く読むことである。

もし実行したいなら

このカードは、これほど新しいリリースとしては異例なほど実用的だ。ロードは標準的だ：AutoModel.from_pretrained をローカルのチェックポイントディレクトリで、リモートコードを信頼し、SDPAアテンション、bfloat16 を使って行う。全二重ストリーミングは、モデルをデュプレックスモードに切り替える1回の呼び出しで開始され、その後、ドキュメント化されたループは、1秒間の streaming_prefill に続いて streaming_generate を繰り返す。長尺動画メモリは、memory-minutes パラメータを40に設定することで有効になり、追加学習不要（training-free）と説明されている。これは通常ファインチューニングを必要とする機能としては注目に値する。2つの注意点は、発見されるのではなく文書化されている：ユーティリティをインポートする前に定数を引き上げない限り、長尺動画を無言で切り詰めるフレーム上限と、デュプレックス動画にレンダリングされる非ラテン文字字幕にCJKフォントが必要であることだ。

このカードが与えてくれないのは、ハードウェアの下限だ。BF16の9Bモデルは、アクティベーションメモリを別にしても、重みだけで約18ギガバイトあり、そのためリアルタイム全二重推論は本格的なGPUを必要とし、派生元のMiniCPM-oファミリーが一部想定して設計していたラップトップ配備には手が届かない。

ここには名付ける価値のある継ぎ目がある。なぜなら、そここそルーターが実際に収まる場所だからだ。Realtime-Venus はその困難な処理——検索、複雑な推論、ビジネスAPI呼び出し——をバックグラウンドモデルに委譲する。その委譲された区間は通常のテキスト推論であり、あなたの会話フロントエンドが有用なのか、それとも単に流暢なだけなのかを決める区間でもある。OrcaRouter は Realtime-Venus を一切含んでいない。ここでの全二重層はセルフホストのダウンロードであり、当社はそれを提供していない。それが引き渡す推論こそ、当社が担う部分である：1つのキーで約200のモデルを、プロバイダーの定価で、マークアップなしで、上流が不調なときの自動フェイルオーバー、複数のモデルを1回の呼び出しに組み合わせるルーティングDSL、そして1つのモデルの判断では足りない場合のためのモデルフュージョン。委譲のマーカーはフロントエンドの決定であり、どのモデルがそれに答えるかは設定上の選択である。そしてその選択を重みの外に置いておくことが、何も再トレーニングせずに変更できるようにする所以である。

それを解決するものは何だろう

Realtime-Venusを、重み付きの論文から誰もが評価できるモデルへと移すには、三つのことが必要だ。独立したグループがFull-Duplex-Benchの継続数値を再現すること。なぜなら、相槌条件下での97%というのは並外れた数値であり、並外れた数値には第二の読者が必要だからだ。公開されたレイテンシ数値。なぜなら全二重システムは初回音声出力までの時間で成否が決まるのに、これには目標が示されていないからだ。そしてハーネスのドキュメント整備。なぜなら非同期委譲設計はこのリリースで真に新しい唯一の部分であり、今のところそれは読むことはできても容易には採用できない部分だからだ。

それまでは、正確な記述は狭くて地味であり、まさにだからこそ書き留める価値がある。すなわち、オープンなバックボーン上に構築された2つの9B全二重チェックポイントの本物のApache-2.0リリースであり、強力な自己申告ベンチマークを備えるが、独立した検証はなく、APIもなく、発表もない。その線より上のものはすべて推測である。