Visko OrbisワールドモデルがGoogle Cloud TPUでリアルタイム動作を実現、しかし時計は止まらない

Viskoは30日間でOrbisパイプラインをGoogle Cloud TPUへ移行し、Visko Orbisワールドモデルで再生速度の1.07倍を達成したと報告している。この数値は、わずかではあるものの重要な一線を越えたことを示す。視聴者が前のセグメントを見終える前に、システムが次のセグメントを生成できるようになり、約7%の余裕が生まれた。

これは、単に動画生成を高速化したベンチマークではない。Orbisは動画を生成し、アップスケールし、同期した音声を生成しながら、終わりのないセッション全体で連続性を維持しなければならない。平均スループットが十分でも、1つの遅いセグメントが体験を中断させる可能性がある。

この点でViskoは、オフライン動画生成器とは異なるエンジニアリングの道を進んでいる。また、同様に厳しいレイテンシー制約の下でインタラクティブな世界を構築するOdysseyやDecartのような企業と並ぶ位置にある。競争は、最も印象的なクリップをレンダリングできる企業から、生成された世界を生き続けさせられる企業へと移りつつある。

Visko Orbisワールドモデル、再生期限を突破

中心的な変化はシンプルだ。Orbisは、現在の動画セグメントが終わる前に次のセグメントを生成できるほど高速になったと報告されている。

Viskoは2026年9月1日に公開Orbisデモを開始した。同社は8月からGoogle Cloud TPUのエンジニアと協業を始めていたと、10月15日に公開された共同のTPU本番運用レポートは伝えている。

30日以内に両チームは、以前の環境から完全なマルチモーダルパイプラインを単一のCloud TPUスライスへ移行した。スライスとは、1つの計算ユニットとして割り当てられる、接続されたTPUチップ群のことである。

報告によれば、結果は再生速度の1.07倍でレンダリングされる。実用上は、視聴中の1秒ごとに、パイプラインが完成済みメディアをわずかに1秒以上生成することを意味する。再生が生成処理に追いつくまでには、約7%のレイテンシー余裕が残る。

この余裕が重要なのは、Orbisがロード画面の裏で完成済みクリップを作っているわけではないからだ。テキストまたは画像のプロンプトから始まり、視聴者が見ている間も生成を続ける。ユーザーは別のクリップを始めることなく、新しいプロンプトを送信して展開中のシーンを誘導できる。

Google Cloudは、暖炉のそばで眠る猫からOrbisが始まるテストを説明している。その後のプロンプトで食べ物を導入すると、猫が起き上がって鳴く間にボウルが現れる。この例には、オフライン生成なら回避できる複数の要件が組み合わさっている。

視覚的な状態はセグメント間で維持されなければならない。新しいオブジェクトは既存のシーンに入る必要がある。動物はもっともらしく反応しなければならない。生成された音はアクションと同期し続ける必要がある。

Orbisは、3つの生成モデルを含むパイプラインでこれらの処理を担う。中核となる拡散モデルが動画を生成する。超解像モデルが出力を毎秒18フレーム、1664×936ピクセルまで引き上げる。別のモデルが同期音声を生成する。

3つのモデルはすべて1つのTPUスライスを共有し、各チャンクを順番に実行する。独立したハードウェアプールを持つ無関係なサービスとして動作するわけではない。この設計はインフラの複雑化を抑える一方で、共通の締め切りを生む。

各チャンクは、再生バッファが尽きる前に、ノイズ除去、潜在表現のデコード、アップスケーリング、音声生成を通過しなければならない。潜在表現は圧縮された数値表現であり、モデルは出力のすべてのピクセルを直接扱うことなく視覚情報を処理できる。

したがってViskoとGoogle Cloudによれば、この1.07という数値はエンドツーエンドのパイプラインを測ったものである。特に有利なモデル操作1つの速度を示すだけではない。この違いにより、この結果は本番システムとの関連性をより高めている。

ただし、この数値はシステムを構築・展開した企業自身によるものだ。両社とも、長時間セッション、多様なプロンプト、同時ユーザー、あるいはより大規模な本番環境でのレイテンシーを対象とした第三者ベンチマークは公表していない。

そのため、この成果は普遍的な性能保証ではなく、文書化されたデプロイ結果として読むべきだ。その意義は、完全なライブパイプラインが1つのアクセラレータースライス上で再生期限を越えられることを示した点にある。

この締め切りが、この記事の中心的な緊張関係を生む。オフライン生成器はスループットと待ち時間を最適化する。一方、ライブワールドは連続するすべてのステップを最適化しなければならない。過去の平均値では、今この瞬間に遅れて届くフレームを救えないからだ。

リアルタイム動画ではレイテンシーが重大な障害になる

ライブワールドモデルは、数分後により速いセグメントを生成しても、遅れたセグメントを補えない。

従来の動画生成では、バックエンドにはかなりのスケジューリング自由度がある。リクエストはキューで待機でき、大きなバッチを共有でき、利用可能なアクセラレーター間を移動することもできる。ユーザーが体験するのは、完成したアセットを受け取る前の一度の待機時間だ。

連続生成では、その柔軟性の大半が失われる。各ユーザーは、個別に変化し続ける状態を占有する。次のセグメントは、システムがすでに生成した内容と、ユーザーが新たに提供するアクションに依存する。

その結果、バッチサイズは1になる。通常、バッチ処理ではアクセラレーターが似たリクエストをまとめて処理でき、利用率と全体のスループットが向上する。しかし、各ワールドが独自の履歴と操作コマンドを持つ場合、Orbisは無関係なセッションを自由に統合できない。

2つ目の制約は逐次依存だ。Orbisは直近の動画潜在表現のローリングメモリを保持し、次のチャンクが現在のシーンを継続できるようにする。チャンクN+1はチャンクNに直接依存する。

システムは遠い将来のチャンクを事前にレンダリングできない。視聴者がプロンプトを変えたり、意図したアクションを変更したり、シーンの方向を変えたりする可能性があるためだ。そうした入力が届いた時点で、先回りした出力は無関係になる。

このため、ライブワールドモデルのレイテンシーは、メディア書き出しベンチマークよりもインタラクティブサービスのサービスレベル目標に近い。パイプラインの各段階は、同じ締め切りの一部を消費する。ばらつきは平均値とほぼ同じくらい重要だ。

7%の余裕は小さなスケジューリング変動を吸収できるかもしれないが、大きな安全余裕ではない。コンパイルの停止、ネットワーク遅延、メモリ圧迫、あるいは特に難しいセグメントが、それを使い切る可能性がある。したがって本番の信頼性は、レイテンシー分布の最悪の部分に依存する。

この違いは、チームがアクセラレーター利用率をどう解釈すべきかも変える。キューに入った処理が再生期限を逃す恐れがある場合、すべてのチップを常に稼働させることが自動的に望ましいとは限らない。スループットのグラフでは非効率に見えても、予約済み容量が必要になることがある。

Viskoのワークロードは、大規模言語モデルのサービング手法がそのまま移植できない理由を示している。LLMサービスは、最初のトークンとトークン間のレイテンシーを管理しながら、ユーザー全体の毎秒トークン数を報告することが多い。互換性のある形状のリクエストをバッチ化し、スケジュールできる。

ライブ動画ワールドは、各ステップでさらに多くのデータを扱う。空間・時間トークンを調整し、フレームへデコードし、フレームを拡大し、音を同期させなければならない。このワークロードは、終点が計画されていないシーケンス全体で視覚的状態も維持する。

技術文献も同じ広範な困難を指摘している。2026年のワールドモデル調査は、この分野のボトルネックを、制御可能性、長期記憶、応答性に分類している。高速レンダリングが直接対処するのは、3つ目のカテゴリーだけだ。

これらのカテゴリーは相互に影響し合う。より強い記憶にはより多くのコンテキストが必要となり、計算量が増える可能性がある。応答性を高めるために短いチャンクを採用すると、調整のオーバーヘッドがより頻繁に発生する可能性がある。より精密な制御は、追加の条件付け処理を導入し得る。

そのため、システムは速度テストに合格しても、時間の経過とともにオブジェクトを見失ったり、レイアウトを変えたり、指示を無視したりする可能性がある。反対に、ユーザーが求めた変更を拒むことで視覚的一貫性を保つこともある。最も難しい製品上の課題は、これらの性質を同時にバランスさせることだ。

これが、Viskoの結果がアクセラレーターベンダー以上のものに圧力をかける理由である。モデルアーキテクトは増分生成を前提に設計しなければならない。インフラエンジニアはテールレイテンシーを目標にしなければならない。プロダクトチームは、途切れない体験の中でユーザーがどの程度の不整合を受け入れるかを決めなければならない。

オフライン動画企業も戦略的な選択を迫られる。洗練された、範囲が限定されたクリップを改善し続けるか、連続状態と入力を中心にシステムを再構築するかだ。後者には、既存モデルのレンダリング時間を短縮する以上のことが必要になる。

1つのTPUスライスで3つのモデルが同じ時計を共有する

Viskoは、すべてのPyTorchコンポーネントを置き換えるのではなく、パイプラインを1つの制約されたシステムとして最適化することでリアルタイム再生を実現した。

最終アーキテクチャは、機械学習計算に適した16ビット数値形式であるBF16精度を採用している。BF16は広い数値範囲を維持しつつ、メモリと演算の負荷を削減する。

エンジニアリングレポートによれば、ViskoとGoogle Cloudはより低精度のFP8計算も検討した。しかし、小さな量子化誤差が連続チャンクをまたいで蓄積し、視覚品質に影響することを確認したという。BF16は、報告された同様の劣化を伴わずにレイテンシー予算内に収まった。

この選択は、範囲の限定されたリクエストと終わりのないストリームの重要な違いを明らかにする。孤立した1枚の画像における小さな誤差は、その画像で終わる。再帰的な誤差は、その後に続くすべてを生成するために使われる状態の一部になり得る。

チームはJAX、torchax、Pallasを中心にソフトウェアスタックを構築した。JAXは、XLAがアクセラレーター向けにコンパイルする配列操作を提供する。Torchaxは、PyTorchプログラムをJAXとXLAを介してTPU上で動かす。

この組み合わせにより、即時の全面書き換えを必要としない移行経路が生まれた。動画拡散モデルと超解像モデルはtorchaxを介してPyTorchのまま維持された。音声ステージだけが完全にネイティブJAXへ移行した。

この選択的な移植により、音声生成は報告によれば5.8倍高速化した。また、パイプライン全体を締め切り内に収めた。この結果は、すべてを書き換えるべきだという一律の推奨よりも有用な教訓を示している。

互換性レイヤーは移行を加速するが、特定の実行経路にはオーバーヘッドを残す可能性がある。プロファイリングによって、そのオーバーヘッドが重要かどうかを特定できる。ネイティブコードは、それがエンドツーエンドの結果を変える箇所に導入すべきだ。

Viskoの動画ノイズ除去ステージは、全体の計算予算のほぼ3分の2を消費した。ノイズ除去とは、拡散モデルが初期状態ではノイズを含む潜在表現を構造化された動画コンテンツへ変換する反復プロセスである。

チームはUlyssesコンテキスト並列化でこのステージに取り組んだ。Ulyssesは、モデルの重みをチップ間で分割するのではなく、長い動画トークン列を分割する。

アテンション計算の前に、チップ間でデータを交換し、各チップがアテンションヘッドの一部について全シーケンスを処理する。別の交換によって、フィードフォワード処理用にシーケンス分割の配置を復元する。

この戦略は扱いにくいワークロードに適している。システムはバッチサイズを拡大できないが、1つの動画チャンクには空間と時間にまたがる大きなシーケンスがなお含まれる。そのシーケンスを分割すれば、1人の視聴者セッションの中でも複数のチップに有用な作業を与えられる。

このアプローチは高速なチップ間通信に依存する。インターコネクトがテンソルを十分に速く移動できない場合、all-to-all交換は高コストになり得る。GoogleのTPUアーキテクチャは、スライス内でこの通信パターンを実用的にしている。

チームはMaxDiffusionのカスタムPallas splash-attentionカーネルも使用した。Pallas kernelsにより、開発者はJAXエコシステム内で特化したアクセラレーター操作を記述できる。

Splash attentionは、FlashAttentionに関連するタイル実行の考え方をTPUに適用したものだ。高帯域幅メモリ上に完全な二次元のattention行列を実体化することを避け、代わりに高速なオンチップメモリでコンパクトなタイルを処理する。

この最適化が重要なのは、attentionのコストがシーケンス長に応じて急速に増大するためだ。動画トランスフォーマーは、多くのテキスト要求よりはるかに多くの時空間位置を扱う。メモリトラフィックの削減は、演算量の削減と同じほど重要になり得る。

Google Cloudによると、この単一ストリームのワークロードでは、Ulyssesはtensor parallelismとring attentionを上回った。この結果をあらゆるモデルに一般化すべきではない。性能はアーキテクチャ、形状、ハードウェア、通信パターンに左右されるためだ。

このデプロイでは、コンパイル済みのXLAアーティファクトもキャッシュする。キャッシュされていない初回起動では、計算グラフのコンパイルに数分を要する可能性がある。これらのアーティファクトを再利用すれば、ワーカーの再起動は1分未満になるという。

ただし、1分未満の再起動でもアクティブなセッションには長すぎる。コンパイルのキャッシュは主に、サービス復旧とキャパシティ管理を改善するものだ。ユーザー単位の継続性には、ルーティング、バッファリング、または別の復旧メカニズムが必要となるが、両社は詳細を明らかにしていない。

より大きな仕組みは、狙いを定めた妥協の連続である。Viskoは、torchaxが要件に間に合った箇所ではPyTorchを維持した。互換性レイヤーが対応できない箇所ではネイティブJAXを使った。連続出力を保護するため、より高速な形式ではなくBF16を選択した。

これは、Viskoがアクセラレータを魔法のような速度向上策として扱わず、リアルタイムの世界をストリーミングする方法だ。ハードウェア、コンパイラの挙動、カーネル、モデル分割、出力品質のすべてが、同じレイテンシ予算に関わる。

本当の競争はフレームレートではなく連続状態にある

Viskoは一つの性能上のしきい値を越えたが、競合各社を見ると、リアルタイム世界モデルはすでにインタラクションモデルと対象市場によって分岐しつつある。

Odysseyは2025年に、最大毎秒30フレームでストリーミングしたとされるプレイ可能な世界モデルを発表した。そのシステムは米国と欧州のNvidia H100 GPUクラスターを使用していた。

同社によると、アクションは最短40ミリ秒で動画に影響を与えられるという。同社のplayable world modelは、現在の状態、直近の履歴、入力されたユーザー操作から新しいフレームを予測する。

この設計は、再生前に有限のシーケンスを確定させる従来型のクリップ生成器とは異なる。また、Orbisとの重要な比較対象にもなる。両システムは、生成動画を完成済みファイルではなくインタラクティブなループとして扱う。

公開仕様を直接比較することはできない。OdysseyはGPUクラスター上での個々のフレーム応答性と最大フレームレートを報告した。Viskoは、1つのTPUスライスにおける毎秒18フレームのエンドツーエンドのチャンク生成を報告した。

解像度、モデルサイズ、視覚品質、セッション長、入力方式、ハードウェア割り当ても異なる。共通の評価がなければ、より高いフレームレートがより優れた世界モデルを意味するわけではない。

Odyssey自身も、初期の体験は不安定で制約が多いと説明している。この率直さは、基本的な速度指標では見えない弱点を示している。世界は素早く応答しても、空間的にずれたり、物体の同一性を変えたり、因果構造を失ったりする可能性がある。

DecartはOasisで別の道を取っている。現在のphysical AI modelは、アクション条件付きのマルチカメラシミュレーションを通じてロボティクスのワークフローを対象とする。Decartは、このシステムのエンドツーエンドレイテンシが200ミリ秒未満だと報告している。

この用途には、楽しい視覚的連続性以上のものが必要となる。複数のカメラビューが同一環境について整合しなければならない。ロボットの方策には、クローズドループの訓練と評価に引き続き役立つ応答が必要だ。

Viskoは、Orbisの用途としてエンターテインメント、コマース、コンパニオン、教育、ロボティクスシミュレーションを挙げている。これらの市場が課す基準は異なる。意外な物体変化はエンターテインメントのユーザーを楽しませるかもしれないが、ロボティクス実験を損なう可能性がある。

したがって、この分野には単一のリアルタイムというラベル以上のものが必要だ。有用な比較では、最初のフレームまでの時間、操作応答レイテンシ、持続フレームレート、出力解像度、セッション時間、ハードウェア割り当て、失敗率を開示すべきである。

また、指示追従性と長期にわたる一貫性も測定すべきだ。操作に即座に従っても部屋を忘れるモデルは、インタラクティブシミュレーションを解決していない。部屋を維持しても操作を無視するモデルは、制御を解決していない。

オープンエンドな世界は単純な採点に適さないため、共通ベンチマークは依然として未成熟だ。人間の判断は視覚品質を評価できるが、費用がかかり一貫性にも欠ける。自動化指標では、生成された環境が因果的に有用であり続けるかを見落としがちだ。

Visko Orbis世界モデルは、この状況にインフラストラクチャの選択肢をもう一つ加える。ライブ生成動画への道がGPUクラスターだけではないことを示唆する。ただし、コストや品質において1つのTPUスライスが競合デプロイメントを上回ることを立証するものではない。

ViskoもGoogle Cloudも、正確なTPUバージョン、チップ数、モデルのパラメータ数、チャンク時間、利用率、運用コストを開示していない。こうした欠落は、アーキテクチャ比較や商業的結論を制限する。

同時実行性も未解決の問いである。1ストリームはバッチサイズ1で動作するが、本番サービスには多数の個別ストリームが必要となる。運用者は、各セッションに専用容量を割り当てるのか、あるいはスケジューリングでワークロードを安全にインターリーブできるのかを判断しなければならない。

需要が均等に到来する可能性は低い。ライブエンターテインメントのイベント、授業、コマースセッションは、突然の急増を生み出し得る。レイテンシの余裕が小さいシステムには、アクティブな世界を遅延させずにこうした急増を吸収する十分なウォーム容量が必要だ。

プラットフォームの問題もある。Google Cloudエンジニアの直接支援を受けて完了した移植は、一般的なセルフサービス移行を代表しない可能性がある。この協業は技術的に可能なことを示しているが、別のスタートアップがどれだけの専門的労力を必要とするかを示すものではない。

Googleは、JAX、torchax、Pallas、MaxDiffusionを含む関連コンポーネントを公開している。オープンコードは重複を減らす。しかし、モデル固有のプロファイリング、デバッグ、データ移動、品質評価を不要にするものではない。

両社の30日間というスケジュールはプロジェクトの記録としては信頼できるが、読者はそれを標準的な移行期間と捉えるべきではない。Viskoにはすでに機能するモデルがあり、TPUの専門家と直接作業していた。開始条件がインフラストラクチャのタイムラインの大半を決定する。

この不確実性は成果を損なうものではない。その境界を定義するものだ。ViskoとGoogle Cloudは、狭いレイテンシの境界を越える首尾一貫した技術的経路を示した。残る競争は、耐久性、経済性、再現性に関わる。

7%の余裕は本番運用の判定ではない

報告された余裕は、開示された構成における実現可能性を証明するが、説明されていない変動や製品拡大に対する余地はほとんど残していない。

ライブ生成システムは、制御されたデモよりも長く耐えなければならない。セッションでは、珍しいプロンプト、視覚的に密度の高いシーン、複雑な動き、繰り返される操作変更に遭遇し得る。これらの条件はいずれも実行挙動を変え得る。

Google Cloudの説明では、総レイテンシは再生目標を下回り、余裕はおよそ7%とされる。パーセンタイル分布は公開されていない。読者は、中央値の性能と、成功した中で最も遅いチャンクとの差を確認できない。

この欠けた分布は重要だ。中央値が安全でも締め切り超過が頻発するシステムは、依然として目に見える形でフリーズする。本番チームが通常高パーセンタイルのレイテンシを調べるのは、長時間のセッションや大規模なユーザー集団では、まれな遅延が一般的になるためだ。

報告書は、ドロップフレーム、音声同期エラー、操作遅延、セッション失敗も定量化していない。これらは生の生成速度とは別の問題である。パイプラインは時間内にチャンクを完了しても、質の低い、あるいはタイミングのずれた応答を生成する可能性がある。

長期にわたる安定性も、もう一つの未解決事項だ。Orbisは直近のlatentのローリングメモリを維持し、あるチャンクが前のチャンクに続くことを助ける。ローリングウィンドウが、直近の視界から消えた事実を自動的に保持するわけではない。

そのウィンドウ外の物体が、異なる形状や位置で再び現れる可能性がある。キャラクターの外見が変わることもある。部屋はその幾何構造を失う可能性がある。この問題は、セッションが開発中のデモを超えて長くなるほど大きくなる。

BF16の選択は、Viskoが蓄積誤差の一形態に直面したことを示している。FP8は帯域幅の圧力を減らしたが、量子化による変化がチャンクをまたいで蓄積したとされる。これは、より広く連続生成システムに対する警告である。

最適化は短い出力サンプルだけで判断できない。繰り返しの適用に耐えなければならない。一度の反復での小さな損失が、数十回、数百回の反復後には目に見えるものになり得る。

安全性とモデレーションは、さらにレイテンシ上の課題を生む。オープンエンドな世界はいつでも新しいプロンプトを受け取る可能性がある。入力のスクリーニング、生成動画の監視、安全でない出力への対応はいずれも時間を消費するか、並列システムを必要とする。

公開されたアーキテクチャは生成に焦点を置いている。モデレーションがライブループにどう組み込まれるかは説明していない。この省略はエンジニアリングのケーススタディとして理解できるが、エンターテインメント、教育、コンパニオン製品にとって重要である。

商業的な実現可能性も依然として不確実だ。3つのモデルをすべて1つのスライスで実行すれば、調整とインフラストラクチャの複雑さを減らせる可能性がある。しかし、ユーザー1時間当たりのコスト、許容可能な利用率、同時にサポートできるセッション数を示す公開データはない。

サービスは技術的にはリアルタイムでも、経済的には非現実的であり得る。ユーザーセッションの長さが変動する場合、専用アクセラレータ容量は特に難しい。プロバイダーはアイドル状態の余裕に費用を払うか、システムがサポートできる以上のセッションを受け入れるリスクを負わなければならない。

プロダクト設計者は、バッファリングで変動の一部を隠せる。再生バッファを大きくすれば、生成器は遅いチャンクから回復する時間をより多く得られる。しかし、その分、操作指示に対する可視的な応答は遅れる。

これは本物のトレードオフだ。バッファを増やせば継続性は改善する一方、インタラクティブ性は弱まる。バッファを減らせばアクションは即時に感じられるが、視聴者は計算の変動にさらされる。

Viskoは、Orbisがその曲線のどこに位置するかを開示していない。1.07という数値は、再生に対する生成を表すが、エンドツーエンドの操作応答を明らかにはしない。ユーザーは名目上のレンダリング速度より、制御遅延を重視するかもしれない。

最後の不確実性は検証に関わる。エンジニアリングの詳細は有益であるほど具体的であり、複数のコンポーネントが公開されている。それでも、中心となる性能測定値はViskoとGoogle Cloudによるものだ。

独立したテストはこの主張を強めるだろう。有用な評価では、多様なプロンプトを長時間のセッションで実行し、レイテンシのパーセンタイルを報告し、ハードウェア割り当てを開示し、繰り返しの操作イベント後の継続性を評価する必要がある。

それまでは、この結果を公開ベンチマークが限定された本格的な本番ケーススタディとして理解すべきだ。具体的な制約、最適化、失敗した代替案を明らかにしているため、議論を前進させる。

これによって、どのハードウェアプラットフォーム、モデルアーキテクチャ、商業設計がライブ世界生成を支配するかが決着したわけではない。これらの問いには、継続的な運用上の証拠が必要だ。

Visko TPU移管後に注目すべきこと

次の試験は、Viskoが狭いリアルタイムの余裕を、多数の同時ユーザーに向けた安定的かつ測定可能なサービスへ転換できるかどうかだ。

最初のシグナルは、継続的な本番データである。Viskoは、多様なワークロードにおける高パーセンタイルのチャンクレイテンシ、締め切り超過率、セッション時間、操作応答を開示すべきだ。

これらの数値がより長いセッションでも安定していれば、現在の結果は単なる成功した移植以上のものに見えるだろう。シーンの複雑さやセッション時間に応じてレイテンシが急増するなら、7%の余裕は狭すぎるように見える。

第二のシグナルは、同時実行性の経済性だ。スライス当たりのセッション数、アクセラレータの利用率、コールドスタート、地域ごとのキャパシティに関する詳細に注目したい。これらの指標は、Orbisが過剰な予約ハードウェアなしに一般向け製品を支えられるかどうかを左右する。

経済的なマルチセッション・スケジューリングの実証は、単一スライスのアーキテクチャを強く裏付けるだろう。一方で、専用スライスへの依存が大きければ、多額のコンピューティングコストを負担できる市場に、実用的な用途は限られる。

第三のシグナルは、Odyssey、Decart、その他のインタラクティブシステムとの共通条件による評価だ。フレームレートだけでは不十分である。比較には、同等の解像度、使用ハードウェアの開示、セッション時間、ステアリングテスト、連続性の指標が必要になる。

信頼できるベンチマークがあれば、Orbisが速度のために視覚的忠実度を犠牲にしているのか、あるいは予算内で両方を達成しているのかが明らかになる。また、テキストによるステアリングが、同社が提案するアプリケーションに十分な制御性をもたらすかどうかも判明するだろう。

開発者にとって、当面の教訓はより限定的で実践的だ。リアルタイム世界モデルでは、ユーザーに見えるループ全体を中心に最適化する必要がある。平均スループットは、締め切り前に届けるべきセグメントの代わりにはならない。

この分野を検討するチームは、モデル実験と並行して、カーネルプロファイル、品質劣化、コンパイルの挙動、レイテンシ分布を記録すべきだ。検索可能なエンジニアリング・ナレッジベースは、こうした意思決定とその根拠を結び付けて維持するのに役立つ。

Visko Orbisの世界モデルは、Google Cloud TPU上で重要な閾値を越えた。次にViskoが示さなければならないのは、プロンプト、ユーザー、運用条件がベンチマークのようには振る舞わなくなっても、その世界が動き続けることだ。