HiCache、分散モデル配信のキャッシュを調整

LMSYSチームは、再利用可能なキー・バリュー（KV）キャッシュを、コンテキスト並列化（処理を複数のランクに分割）、パイプライン並列化（モデル層を段階ごとに分割）、投機的デコーディング、プリフィルとデコードの分離にまたがって調整するHiCacheの仕組みを説明しました。Iflytek Astron MaaSの本番ワークロードでは、リクエストの入力トークン数は通常3万～20万で、一部は100万に達します。チームによると、外部ストレージとHiCacheを導入した結果、キャッシュヒット率は約30%から95%に上がり、初回トークンまでの時間の中央値は3秒未満になりました。

コンテキスト並列化では、各ランクが同じ論理ラジックス木とページIDを保持しながら、各GPUには割り当てられたKVページだけを保存します。ページの論理IDから、検索表をページごとに持たずに、担当ランクとローカルアドレスを算術的に決めます。リクエストがキャッシュ済みの接頭部分を延長するとき、割り当て器はページ所有権のローテーションを保ち、互換性のないローテーションが混在する挿入を拒否します。アテンション処理がキャッシュ済みの接頭部分を読む前に、各ランクは層ごとにページを一時バッファーへ集約します。交互に使う2つのバッファーにより、次の層の集約を現在の層の計算と重ねられます。対応構成では、NCCLのSMカーネルではなく、GPUのコピーエンジンが集約を実行します。

HiCacheは、ページの物理アドレスが変わっても、各ページを所有ランク上でバックアップし、復元します。各層の集約は復元完了を待ち、アテンション処理は集約済みデータを待ちます。GLM-5.2-NVFP4、TP4/CP4、EAGLE MTP、静的メモリー比率0.9を用いた本番比較では、各配置にプリフィルエンジンを2基ずつ置き、各エンジンがNVIDIA GB300を4基使用しました。ベースラインと分割構成はいずれも、エンジンごとのホストキャッシュ予算を960 GBに設定しました。分割構成では4ランクに240 GBずつ割り当てました。3時間のトラフィック計測では、キャッシュ階層を特定できたリクエストを各構成で約2万4,500件処理しました。平均入力長は13万6,000～13万7,000トークンで、入力総量の差は1.8%でした。分割によりGPUトークンヒット率は40.48ポイント上昇し、GPUとホストを合わせたヒット率は約93%を維持しました。ホストから配信したトークンは17億1,200万から3億2,200万へ81.2%減少し、プリフィル待ち時間の平均は56.2%、プリフィル前向き計算時間の平均は31.3%短縮しました。チームは層ごとの集約に追加のオーバーヘッドがあり、コンテキスト並列化の分割は引き続き最適化中だとしています。

パイプライン並列化では、転送の完了時刻が異なっても、各段階が同じ順序でキャッシュを更新する必要があります。pp_syncプロトコルでは、最初の段階が準備できた転送数について合意し、その数を後続段階に伝えます。各段階は選ばれた転送を待ってからキャッシュ記録を更新します。外部ストレージを使う場合、バックグラウンドスレッドがランク間で読み込み済み接頭部分の最短長に合意し、順序付き確認応答キューを通じて進捗を共有します。各段階はキャッシュ確認のたびに同じ応答を処理するため、後続の読み込みがすでに進んでいても、リクエストには同じ長さのキャッシュ済み接頭部分を使います。

投機的デコーディングでは、ターゲットモデルの接頭部分に加え、ドラフトモデルのKV、インデクサーバッファー、別管理の再帰状態も復元する必要があります。HiCacheには、行形状、データ型、トークン索引が適合する場合にスロット対応を共有するパック形式と、ホストプールを分け、ターゲットKVやSWAなど指定された情報源から転送索引を導くサイドカー形式があります。どちらの形式も、バッファーを読み出す前に、転送完了イベントへドラフト状態のコピー完了を含めます。

LMSYSチームは、再利用可能なキー・バリュー（KV）キャッシュを、コンテキスト並列化（処理を複数のランクに分割）、パイプライン並列化（モデル層を段階ごとに分割）、投機的デコーディング、プリフィルとデコードの分離にまたがって調整するHiCacheの仕組みを説明しました。Iflytek Astron MaaSの本番ワークロードでは、リクエストの入力トークン数は通常3万～20万で、一部は100万に達します。チームによると、外部ストレージとHiCacheを導入した結果、キャッシュヒット率は約30%から95%に上がり、初回トークンまでの時間の中央値は3秒未満になりました。

コンテキスト並列化では、各ランクが同じ論理ラジックス木とページIDを保持しながら、各GPUには割り当てられたKVページだけを保存します。ページの論理IDから、検索表をページごとに持たずに、担当ランクとローカルアドレスを算術的に決めます。リクエストがキャッシュ済みの接頭部分を延長するとき、割り当て器はページ所有権のローテーションを保ち、互換性のないローテーションが混在する挿入を拒否します。アテンション処理がキャッシュ済みの接頭部分を読む前に、各ランクは層ごとにページを一時バッファーへ集約します。交互に使う2つのバッファーにより、次の層の集約を現在の層の計算と重ねられます。対応構成では、NCCLのSMカーネルではなく、GPUのコピーエンジンが集約を実行します。

HiCacheは、ページの物理アドレスが変わっても、各ページを所有ランク上でバックアップし、復元します。各層の集約は復元完了を待ち、アテンション処理は集約済みデータを待ちます。GLM-5.2-NVFP4、TP4/CP4、EAGLE MTP、静的メモリー比率0.9を用いた本番比較では、各配置にプリフィルエンジンを2基ずつ置き、各エンジンがNVIDIA GB300を4基使用しました。ベースラインと分割構成はいずれも、エンジンごとのホストキャッシュ予算を960 GBに設定しました。分割構成では4ランクに240 GBずつ割り当てました。3時間のトラフィック計測では、キャッシュ階層を特定できたリクエストを各構成で約2万4,500件処理しました。平均入力長は13万6,000～13万7,000トークンで、入力総量の差は1.8%でした。分割によりGPUトークンヒット率は40.48ポイント上昇し、GPUとホストを合わせたヒット率は約93%を維持しました。ホストから配信したトークンは17億1,200万から3億2,200万へ81.2%減少し、プリフィル待ち時間の平均は56.2%、プリフィル前向き計算時間の平均は31.3%短縮しました。チームは層ごとの集約に追加のオーバーヘッドがあり、コンテキスト並列化の分割は引き続き最適化中だとしています。

パイプライン並列化では、転送の完了時刻が異なっても、各段階が同じ順序でキャッシュを更新する必要があります。pp_syncプロトコルでは、最初の段階が準備できた転送数について合意し、その数を後続段階に伝えます。各段階は選ばれた転送を待ってからキャッシュ記録を更新します。外部ストレージを使う場合、バックグラウンドスレッドがランク間で読み込み済み接頭部分の最短長に合意し、順序付き確認応答キューを通じて進捗を共有します。各段階はキャッシュ確認のたびに同じ応答を処理するため、後続の読み込みがすでに進んでいても、リクエストには同じ長さのキャッシュ済み接頭部分を使います。

投機的デコーディングでは、ターゲットモデルの接頭部分に加え、ドラフトモデルのKV、インデクサーバッファー、別管理の再帰状態も復元する必要があります。HiCacheには、行形状、データ型、トークン索引が適合する場合にスロット対応を共有するパック形式と、ホストプールを分け、ターゲットKVやSWAなど指定された情報源から転送索引を導くサイドカー形式があります。どちらの形式も、バッファーを読み出す前に、転送完了イベントへドラフト状態のコピー完了を含めます。