Wan Streamer：聞きながら見ながら話す、リアルタイム AI

4 本のキャラクターデモ ＋ リアルタイム録画

以下の 4 本のデモはすべて同じモデルから出ており、人物・声・シーンを変えただけ。まず効果を見て、それから仕組みを語る。

次の 1 本は違う：これは一度の実際のネット接続対話のスクリーン録画で、リアルタイム応答の全経路が見える。

従来手法はなぜ遅いか：1 工程ずつのリレーで、各ステップが待ち続ける

従来手法が遅いのは、独立したモデルを一列に継ぎ合わせたパイプラインだからだ。音声をまず文字に起こし（ASR）、その文字を言語モデルに渡して答えを考えさせ（LLM）、答えを音声に合成し直し（TTS）、最後に顔を動かす（アニメーションレンダリング）。1 工程進むたびに前の工程の納品を待たねばならず、待ち時間が段ごとに積み上がり、認識と口の動きのずれといった誤差も道中ずっと蓄積していく。

原文はこれについて 1 つの判断を下している。リアルタイム音声・映像対話は「マルチモーダル理解」＋「マルチモーダル生成」の単純な足し算ではなく、本質的に全二重だ。だからストリーミング可能性は一種のモデル化上の制約であって、リリース後のエンジニアリング最適化にとどまらない。オフラインのエンコーダ、双方向のデコーダ、ターン制の対話の上に築いたシステムは、エンジニアリングのチューニングだけでは本物の低遅延な全二重を補えない。これこそ次の節で解きほぐす核心だ。

その手法：1 つのモデルが聞くから話すまで全部担う

Wan Streamer の核は一言だ。視覚・音声・テキストの入力 token と出力 token を、交互に並べて同じ 1 本のシーケンスにし、1 つの Transformer に処理させる。block-causal attention で調整し、届いた端から計算して外へ吐き出させる。

モデルは対話を連続した因果の流れとして捉える。あなたの観測とモデルの応答が、一緒に現在のコンテキストを更新する。各ストリーミング単位で、今得られるユーザーの観測をエンコードし、双方の完全な因果履歴に基づいて次の応答区切りを予測する。言語の応答は離散 token の列で、next-token 予測で訓練する。音声と映像の応答は連続した latent 空間に存在し、条件付き flow matching で一緒に生成する。同じ 1 つのクリーンなコンテキストを条件に、音声・動き・見た目・シーンの変化を 1 つの結合した全体としてまとめてノイズ除去するのであって、別々に生成してから継ぎ合わせるのではない。

Wan Streamer の全体フレームワーク：言語・音声・映像が同じ Transformer の中で入力と出力として同時にモデル化され、block-causal attention で調整しながら、届いた端から計算してストリーミング生成する。出典：Wan Streamer 公式

この流れを支えるため、スタック全体が設計当初から因果的だ。ストリーミング latent エンコード用の厳密に因果な音声映像 VAE、因果な音声映像エンコーダ、因果な音声映像デコーダ、そして block-causal attention で調整される時系列因果な Transformer。ノイズ除去後、推定されたクリーンな latent はそのまま履歴に追記され、後続単位のコンテキストになる。因果デコーダがそれらを最終的な音声映像へレンダリングする。この設計が消し去った外部モジュールは：

聞きながら話す、いつでも割り込める、をどう実現するか

人と世界の関わりは生まれつきストリーミングで全二重だ。私たちは聞き終えてから別に考え、最後にようやく答えるのではなく、見ながら聞きながら話し、いつでも止まったり割り込んだりする。知覚と表現が音声映像の時間スケールで重なって起きる。リアルタイム対話モデルもこういう形に育たねばならない。

この仕組みが成立するのは block-causal attention のおかげだ。小さなブロック（たとえば 160ms の音声映像断片）を 1 つの処理単位とみなす。ブロック内部の token は互いに見える（双方向）が、1 つのブロックは過去のブロックしか見えず、未来のブロックは見えない。こうしてブロック内のコンテキストを保ちつつ、届いた端から計算でき、全部話し終えるのを待たなくて済む。

ブロック内の token は互いに見え、ブロック間は左の過去だけを見る。ブロック 3 は届けばすぐ計算を始められる。ブロック 1、ブロック 2 だけに依存し、未来のブロック 4 を待たないからだ。これがストリーミング生成だ。

デプロイの詳細を開く：thinker–performer がどう遅延を 200ms に抑えるか

Wan Streamer は訓練時には単一のエンドツーエンドモデルだ。リアルタイムのデプロイ時には、同じモデルを 2 枚の GPU にまたがる thinker–performer パイプラインに分け、できるだけ計算を重ねる。システムの prefill 完了後、thinker が初期の KV-cache を performer にブロードキャストし、両者が同じ全履歴状態を共有する。統一されたモデルの振る舞いが完全に保たれる。

thinker は、因果な音声映像エンコーダ、言語予測と状態更新のための一度の短い計算、KV-cache の構築、そして前の単位の latent を音声映像にデコードして即座に出力する役を担う。performer は latent 生成だけを担い、共有された全履歴の KV コンテキストに基づいて、次の音声映像単位のために flow-matching ソルバを走らせる。performer は決してデコーダを走らせず、thinker は決して高コストなソルバを走らせないので、デコードと生成は互いをブロックしない。

performer の所要時間と通信時間が 1 つの 160ms 単位に収まる限り、リアルタイムのスループットを保てる。そして「エンコード → 状態更新 → latent 生成 → デコード」という信号から信号までの経路が、約 200ms のモデル側遅延だ。CUDA graph のキャプチャ、コンパイル、オペレータ最適化で予算内に抑え込む。

thinker–performer のストリーミング推論オーバーラップ：第 k 単位で、thinker は現在の観測をエンコードし、KV-cache を更新し、前の単位の latent をデコードして即座に出力する。performer は flow-matching ソルバだけを走らせて次の latent を生成し、次の単位で返す。知覚・デコード・通信・ノイズ除去が隣り合う単位間で重なる。出典：Wan Streamer 公式

他のシステムと比べて、どこが速く、何ができるか

下の 2 組の遅延の数字は測っているものが別なので、分けて見る必要がある。上の組は完全なエンドツーエンドの対話ループ（ユーザーを知覚して応答を生む）で、そのうち映像も同時に出すのは Wan Streamer だけ。下の組はデジタルヒューマン／音声映像レンダラーで、レンダリング段階までしか数えておらず、それらが依存する外部の言語モデル、ASR、TTS を含まない。だからユーザーが実際に感じる遅延は図より高い。

能力の観点でのカバー範囲は以下のとおりで、Wan Streamer はすべてにチェックが付く唯一の行だ：

✓＝はい　~＝部分対応／非公開　✗＝いいえ。全二重とは、システムが生成中も知覚を続けていること、つまり理解しながら応答することを指す。「~」のマスは、部分対応か、その指標が非公開かのどちらかだ。