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

以下の4本のデモはすべて同一のモデルによるもので、人物・声・シーンを変えただけだ。まず効果を見てから、原理を説明する。

以下の映像は少し違う：実際にオンラインで行われた対話の画面録画で、リアルタイム応答の全プロセスを確認できる。

旧来のやり方はなぜ遅いのか：バトンリレー方式で、各段階が待ち時間を生む

旧来のやり方が遅いのは、一連の独立したモデルを繋ぎ合わせたパイプラインだからだ。まず音声をテキストに変換し（ASR）、そのテキストを言語モデルに渡して回答を考えさせ（LLM）、回答を音声に合成し（TTS）、最後に顔を動かす（アニメーションレンダリング）。工程を1つ通過するたびに前段の受け渡しを待つ必要があり、待ち時間が段階ごとに積み重なり、認識のズレとリップシンクのズレによる誤差も蓄積していく。

原文はこの点について1つの判断を下している：リアルタイム音声・映像対話は「マルチモーダル理解」と「マルチモーダル生成」を単純に足し合わせたものではなく、本質的に全二重（フルデュプレックス）である。したがって、ストリーミング可能性はローンチ後のエンジニアリング最適化ではなく、モデリング上の制約なのだ。オフラインエンコーダー、双方向デコーダー、ターン制の対話の上に構築されたシステムは、いくらエンジニアリングでチューニングしても真の低遅延な全二重を取り戻すことはできない。これがまさに次のセクションで掘り下げるコアの部分だ。

そのやり方：1つのモデルが「聞く」から「話す」まで全部引き受ける

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

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

Wan Streamerの全体フレームワーク：言語・音声・映像は同一のTransformer内で入力と出力の両方として同時にモデル化され、block-causal attentionによって調整され、入力が来た端からストリーミングで生成される。出典：Wan Streamer公式

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

「聞きながら話す」、いつでも割り込み可能をどう実現するか

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

この仕組みが成り立つのは、block-causal attentionのおかげだ。これは小さな塊（例えば160msの音声・映像片）を1つの処理単位として扱う：ブロック内部のトークンは互いを参照できる（双方向）が、あるブロックは過去のブロックしか見えず、未来のブロックは見えない。こうすることでブロック内のコンテキストを保ちながら、入力が来た端から計算でき、話し終わるのを待つ必要がない。

ブロック内のトークンは互いを参照し合い、ブロック間は左（過去）方向だけを見る：ブロック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はすべての項目にチェックが入る唯一の行だ：

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

そのやり方は非常にシンプルだ：上記の一連のリレーパイプラインをすべて1つのモデルに統合し、あなたを見て聞いてから応答するまでを一気通貫で行う（これを「端末間（end-to-end）」と呼ぶ。1つのモデルが最初から最後まで丸ごと引き受け、途中で他のモジュールに渡すことはない）。

しかしいくつかのモジュールを1つに統合するのは、あくまで第一歩にすぎない。本当に難しいのは、AIを人間のように聞きながら話せるようにし、あなたが一言挟んだら即座に止まれるようにすることで、これには処理方式を根本から作り変える必要がある。

その鍵となるのが、block-causal attention（ブロック因果注意）と呼ばれる仕組みだ：あなたの映像と声を小さなブロックに細かく切り分け（各ブロック約160ミリ秒）、モデルはブロックごとに受け取りながら計算していき、あなたが一文を言い終わるのを待つ必要がない。

普通の人は「何倍速いか」にはピンとこないが、「どれくらい待つか」には実感がある。同じく「一文を言い終えてからAIが口を開くまで」というこの一点だけでも、各社のシステムには大きな差があり、しかもWan Streamerだけが応答時に動く顔まで見せてくれる。