リアルタイムクラウドゲーミングの本質的な課題は、ゲームそのものを動かすことではなく、リソース割り当て、インスタンス起動、フレーム転送を極めて短い時間で完了させることにあります。ゲームグラフィックの高度化と、ユーザーの即時アクセス需要の高まりを受け、従来のデータセンター型モデルではコスト、拡張性、地理的カバレッジの面で限界が顕在化しています。
DePIN(分散型物理インフラネットワーク)分野の主要プロジェクトであるYOMは、世界中の遊休GPUリソースを活用し、リアルタイムコンピューティングネットワークの構築を目指しています。AIトレーニングを主目的とするGPUネットワークとは異なり、YOMは低遅延のインタラクティブ体験に特化しており、スケジューリングロジック、ノードアーキテクチャ、ストリーミングシステムはすべてリアルタイムゲームを前提に設計されています。
YOMのクラウドゲーミングモデルでは、ゲームはユーザーのローカル端末ではなく、リモートのGPUノード上で動作します。ユーザーのデバイスは画面表示と操作コマンドの送信のみを担い、計算処理とグラフィックスのレンダリングはすべてリモートノードが処理します。
この方式により、エンドデバイスのハードウェア要件が大幅に軽減されます。一般的なノートパソコン、タブレット、ブラウザからでも、本来は高性能GPUを必要とする大型ゲームにアクセスできます。
デベロッパーにとっては、YOMが統一されたクラウド実行環境を提供するため、デバイスごとの複雑な対応をせずとも、アプリケーションをネットワーク経由で直接ユーザーに届けられます。
プレイヤーがゲームページでプレイボタンをクリックすると、システムはまず新たなセッションリクエストを生成します。
このリクエストには、ユーザーの位置情報、ネットワーク品質、デバイスの種類、ゲームに必要なリソース情報が含まれ、YOMネットワークのスケジューリングシステムへ送信されます。
この時点ではまだゲームは開始していません。システムはまずサービスを提供するノードを決定し、その後でコンピューティングリソースを割り当てます。
この一連の流れは、単なる動画サイトへのアクセスとは本質的に異なります。クラウドゲーミングではフレームの転送に加え、ユーザー入力を継続的に処理し、リアルタイムの双方向通信を維持する必要があるためです。
HyperOrchは、YOMネットワークにおけるインテリジェントリソースオーケストレーションシステムです。
セッションリクエストを受け取ると、HyperOrchはネットワーク内の利用可能なノードを評価します。評価軸は通常、ノードとユーザー間の距離、現在のレイテンシ、GPU性能、リソース使用率、ノードの動作ステータスです。
システムはノードをランダムに選ぶのではなく、最適な体験を提供できるノードを優先します。
特定の地域に十分なノードリソースがない場合、HyperOrchはタスクを自動的に近隣地域に移行し、サービスを継続します。
タスクを受け取ったノードは、自動的に対応するゲームインスタンスを作成します。
ゲームインスタンスとは、GPUサーバー上で動作する分離された実行環境であり、ゲームファイルのロード、エンジンの起動、ランタイム状態の準備を担います。
このフェーズでは、ノードはCPU、GPU、メモリ、ネットワークリソースをゲームに割り当てます。
ゲームが正常に起動すると、システムはリアルタイムストリーミングフェーズへ移行し、最初のフレームをユーザーのデバイスに送信します。
インスタンス化の処理速度は起動時間に直結するため、YOMネットワークはリソーススケジューリングとプリロード機構の継続的な最適化を行っています。
ゲームが開始されると、GPUはレンダリング済みのフレームを連続的に生成します。
Universal Streamerの役割は、これらのフレームをリアルタイムでビデオストリームにエンコードし、ユーザーのデバイスへ送信することです。
通常の動画配信プラットフォームと違い、クラウドゲーミングではエンコード、転送、デコードの全工程を極めて短時間で完了しなければなりません。遅延が生じると、ユーザーは操作の遅れをはっきりと感じ取ります。
YOMは、リアルタイムインタラクション向けに最適化された転送機構を採用し、フレームが素早くエンドデバイスに届くようにしています。
ユーザーは大容量のクライアントをダウンロードする必要はなく、ブラウザ経由でゲームコンテンツを受信・表示できます。
クラウドゲーミングのインタラクティブ体験は、双方向のデータ転送に支えられています。
プレイヤーがマウスをクリックしたり、キーボードを押したり、コントローラーを操作すると、その入力情報は即座にゲームを実行中のGPUノードに送り返されます。
ゲームエンジンがコマンドを受け取り、画面状態を更新して次のフレームを生成します。
生成された新しいフレームは、Universal Streamerを通じてユーザーのデバイスに戻されます。
このサイクルは毎秒数十回から数百回繰り返されるため、ネットワークレイテンシはゲーム体験に直接影響します。
リアルタイムゲームでは長時間のダウンは許されないため、ネットワークには障害復旧機能が不可欠です。
GPUノードに障害が発生すると、HyperOrchがノードステータスの変化を検知します。
状況に応じて、システムはリソースの再割り当て、タスクの移行、またはバックアップノードへの切り替えを実行します。
この仕組みにより、単一ノードの障害がユーザー体験に与える影響を抑え、分散型インフラで安定したサービスを提供する基盤を実現しています。
YOMも従来のクラウドゲーミングプラットフォームも、リモートサーバー上でゲームを動作させる点は共通ですが、リソースの編成方法が大きく異なります。
従来型は少数の大規模データセンターに依存するのに対し、YOMは分散型GPUノードのネットワークでコンピューティングレイヤーを構成します。
| 比較項目 | YOM | 従来のクラウドゲーミングプラットフォーム |
|---|---|---|
| ノードの提供元 | コミュニティGPUノード | エンタープライズサーバー |
| スケジューリング方式 | 分散型オーケストレーション | 集中管理 |
| ネットワーク構造 | 分散型 | 集中型 |
| 拡張性 | ノード追加による拡張 | データセンターの増設 |
| インセンティブ | トークン報酬 | 企業運営 |
つまり、YOMはオープンなインフラネットワークであるのに対し、従来のプラットフォームはクローズドなサービスプラットフォームという位置づけです。
ユーザーがプレイをクリックしてからゲームが実際に動作するまでのYOMの流れは、次の6ステップにまとめられます。
このプロセスにより、世界中に分散したGPUリソースが単一のサービスネットワークに統合され、デベロッパーとユーザーは従来のクラウドゲーミングプラットフォームに近い体験を得ながら、分散型インフラならではの拡張性とリソース効率を享受できます。
YOMの本質的な価値は、単にゲームをクラウドで実行することではなく、分散型GPUネットワークによる動的なリソーススケジューリングとリアルタイム配信にあります。ユーザーがプレイをクリックした瞬間から、HyperOrchスケジューリング層が最適ノードを選定し、GPUサーバーがゲームインスタンスを実行し、Universal Streamerが低遅延のフレーム転送と入力同期を提供します。
このアーキテクチャはクラウドゲーミングだけでなく、リアルタイム3Dレンダリング、仮想空間、AI推論など、さまざまなシナリオに新たなインフラモデルを提供します。
YOMはノードのマッチングとゲームインスタンスの起動を数秒以内に完了することを目標としています。実際の起動時間は、ノードリソースの空き状況、ネットワーク状態、ゲームのロード要件によって変動します。
HyperOrchはYOMのインテリジェントリソースオーケストレーションシステムであり、ノードステータスの評価、コンピューティングリソースの最適マッチング、ユーザーとGPUノード間の接続経路の最適化を担当します。
Universal Streamerは、GPUノードがレンダリングしたゲームフレームをリアルタイムのビデオストリームに変換すると同時に、ユーザー入力を受け付けることで、完全な双方向体験を実現します。
YOMはエッジへのノード配置、インテリジェントなノード選定、リアルタイムストリーミング技術を活用し、ユーザーとコンピューティングリソース間の距離を最小化することでネットワークレイテンシを低減しています。
YOMネットワークのGPUノードは、主にコミュニティオペレーターによって提供されています。ハッシュレートリソースを提供したノードは、ネットワークサービスに参加し、その対価としてインセンティブを受け取ることができます。





