NVIDIA Hyperflare Inference v0.1.0：マルチホストのキャッシュ共有、投機的デコーディング

1. 複数のホストが共同で参加する共有キャッシュ

11月11日に公開されたHyperflare Inference v0.1.0には、複数のホストでモデルの計算を分担するテンソル並列構成のキャッシュ共有対応が盛り込まれた。PR #140は、既存のSeleneキャッシュプールをこの構成へ拡張した。プールは、インスタンスやホストの間でリクエストの先頭部分のキャッシュを共有する共通ストレージとして機能する。

接続は代表の処理単位が提案し、すべての処理単位が承認して初めて成立する。メモリ登録を1つでも拒否すると、全体がそれぞれのローカルストレージ層を利用する。この方式に合わせ、運用者はプール設定をすべての処理単位に同じように適用するか、すべて省略する。

2. 2ホストでの検証で復元時間を短縮

同社の発表によると、2台のホストで計算を並列に分担するTP2構成でのキャッシュ復元は約0.1~0.3秒、キャッシュなしで開始する経路は40~60秒だった。SM120で、イーサネット経由のリモートメモリ通信であるRoCEのソフトウェア実装、Soft-RoCEを使って接続し、プール接続は平文TCPと暗号化されたTLSで試験した。

表：2ホスト構成でのキャッシュ復元の検証結果

条件：2ホスト、TP2、SM120上のSoft-RoCE経由、平文TCPおよびTLSのプール接続。復元後の継続生成を、GPU上に保持した場合と上位20個のトークンの対数確率で比較した。

復元後に続けて生成した結果は、GPU上に保持し続けたキャッシュを使った結果と、上位20個のトークンの対数確率で照合した。表のTVは確率分布の差を表す指標だ。同じ検証で復元時間が短く、分布の差も小さくなり、キャッシュ再利用の実用性を示した。

プールマネージャーの再起動後に2つの処理単位が再接続し、1つの処理単位を終了してから再起動し、キャッシュを復元する試験にも合格した。速度だけでなく、中断後の再接続と復元動作も確認したことになる。

3. 投機的デコーディングでは候補の準備と伝達を改良

投機的デコーディングでは、候補を作るNVFP4のドラフト出力部と、以前の状態に基づいて次を決めるMarkov方式の出力部を、それぞれ独立した選択肢として用意するようにした。候補の提案をブロック単位で伝播し、BF16形式のMarkovサンプリング処理を統合する変更も含まれた。候補を準備する段階と、並列実行中に伝達する段階をともに改良した。

DeepSeekの投機的サンプリングでは、語彙ごとの確率を各処理単位に保持するよう変更した。DSparkのドラフトスコア計算を統合し、任意で利用できるMXFP8のドラフト語彙出力部を用意する変更も盛り込まれた。

投機的デコーディングの項目は、提供されたリリースノートの変更タイトルから確認できるが、その効果を数値で示す測定結果は2つの資料にはない。キャッシュの検証もソフトウェア方式の接続で行われ、実際のRoCEネットワークカードやaarch64のプール構成は試験していない。

4. 再計算を減らす代わりにビルドと保存・セキュリティに配慮

Linuxのx86_64環境でRoCE通信を使うには、機能を明示してビルドし、ビルド環境と実行環境の両方にlibibverbsを用意する必要がある。原文が示したビルドコマンドは次のとおりだ。

cargo build --release --locked --manifest-path flare/Cargo.toml --features roce

デフォルトのビルドはGPUリソースを立ち上げる前にマルチホストのサービングを拒否するため、導入時は通信機能を含むビルドを先に用意する。マルチホストのローカルキャッシュはディスクに保持する。ローカルディスクを消去して再起動する際に復元するには、記録がすでにプールマネージャーのストレージへ転送されている必要がある。

共有キャッシュは先頭部分を再計算する負担を減らす代わりに、運用者に通信機能を含むビルドとディスク上での保持の管理を求める。プールと記録の接続はセッションの秘密値と転送トークンを平文で送るため、クラスターネットワークを保護する作業も必要になる。

今回のリリースの価値は、キャッシュ再利用を複数のホストへ広げるとともに、投機的デコーディングの候補準備と並列処理の経路も改良した点にある。