orbitkv

OrbitKVは、LLM推論エンジン向けの外部キーバリューキャッシュレイヤーです。vLLMとSGLangのKVキャッシュをGPUメモリの範囲を超えて拡張します。再利用可能なプレフィックスはDRAMとSSDに保持され、一致するリクエストが到着したときに復元されます。想定される用途は、繰り返し登場するドキュメント、共有システムプロンプト、プレフィックスがエンジンのGPUキャッシュに収まらなくなった長い会話などのワークロードです。 デプロイモデル 独立したCache Managerがホストごとに動作し、そのホスト上のエンジンが共有キャッシュに接続します。GPUメモリとスケジューリングの所有権はエンジンが保持し、OrbitKVは外部レプリカと転送を管理します。シングルノード経路は、vLLM 0.29.0とSGLang 0.5.20でGPUテスト済みと説明されています。マルチノードのキャッシュ共有は実験的と位置づけられており、1.0より前にインターフェースが変更される可能性があります。 主な機能 - DRAMおよびSSDキャッシュ: Cache Managerが稼働し続けていれば、GPU退避後やエンジン再起動後もプレフィックスを再利用できます。 - 任意の再利用ポリシー: Rustコンポーネントが、バイト上限内で再利用ページを保護し、SSD書き込みを選択的に受け入れることができます。ドキュメントではコールド再利用のトレードオフが指摘されています。 - 直接GPU転送: 両エンジンはCUDA IPCを通じてGPUバッファを登録します。アダプタは生成側CUDAストリームをフェンスし、Rustがキャッシュクエリ、読み取り、転送完了を処理します。 - モデル認識リカバリ: キャッシュIDにはモデルアーティファクト、計算設定、ストレージレイアウトが含まれます。コンパイル済みリカバリルールは、アテンションページ、スライディングウィンドウ、リカレント/convチェックポイントを選択し、3つすべてを組み合わせたレイアウトも含みます。 - リソース使用量の上限: バイト予算は、保留中の読み取り、準備完了ページ、アクティブなGPU転送を対象とします。キャンセル時も、送信済みI/Oは完了まで保持されます。 - 可観測性: Prometheusメトリクスと任意のリクエストタイムライン、公開測定値の再現コマンドを提供します。 - 実験的な共有キャッシュ: 組み込みカタログシャードがピアレプリカを特定し、Mooncake Transfer Engineがバイトを移動し、etcdがクラスタメンバーシップを追跡します。 クイックスタートの概要 ホイールはPythonおよびCUDAランタイムごとにビルドおよびインストールされ、vLLMとSGLang用に別々の環境が用意されます。ホイールにはCache ManagerとMooncakeライブラリが含まれ、Managerには互換性のあるPyTorchも必要です。最初のPythonリリースは準備中と説明されているため、パッケージ公開状況はリリースドキュメントで確認する必要があります。 Cache Managerは、`orbitkv-cache-manager --addr 127.0.0.1:50055 --http-addr 127.0.0.1:9091 --pool-size 8gb` のようなコマンドで起動します。次にvLLMを、プレフィックスキャッシュを有効にし、OrbitKVコネクタモジュールを指定するKV転送設定で起動します。SGLangは、OrbitKVエンドポイント環境変数、ページサイズ、external linkerおよびradix cacheバックエンドオプションを指定して起動します。SSDキャッシュは、Managerコマンドに `--ssd-cache-path` と `--ssd-cache-capacity` を追加することで有効になります。SSDキャッシュはManagerの再起動時に再作成されます。デフォルトのSSDバックエンドは、サポートされているマウントでネイティブcuFileを試み、失敗するとio_uringにフォールバックします。`--ssd-read-path uring|cufile` オーバーライドは、保存表現とは独立にデマンド復元経路を選択します。ストレージエンコーディングオプションには、nvCOMP ANS可逆圧縮、FP8、3/4ビットTurboQuantがあり、`--storage-codec` で選択します。デフォルトは正確なストレージで、非可逆モードにはモデル品質の認定が必要です。`orbitkv_load_bytes_total` メトリクスの上昇が、外部復元の確認として示されています。 アーキテクチャとステータス エンジンアダプタは欠落状態を特定し、GPU宛先を提供します。OrbitKVは互換性のあるキャッシュ範囲を選択し、設定された階層から読み取り、GPUコピーが完了するまでページ所有権を保持します。新しく計算されたKVは、後で再利用できるように公開されます。同じアダプタAPIがDRAM、SSD、実験的なリモートフェッチにサービスを提供し、物理的な配置はCache Manager内で行われます。プロジェクトは、ピン留めされたLMCache、FlexKV、Mooncakeのメカニズムをデプロイと検証作業にマッピングする実装計画を文書化しています。Rustの有界コスト観測、raw-copyシャドウ予測、独立したSSD読み取り経路は実装済みと説明されています。動的コスト選択は計画段階のままで、観測はデフォルトで無効です。クロスエンジンのバイト変換、本番カタログHA、KV認識リクエストルーティングは計画作業として挙げられています。 パフォーマンスドキュメント パフォーマンスは、プレフィックス再利用、キャッシュ容量、ストレージ、エンジンスケジューリングに依存すると述べられています。レポートは、シングルノード比較（ネイティブHBM、エンジンCPUキャッシュ、OrbitKV、LMCache、FlexKV）、SSD復元、Qwen3-8Bのホスト読み取りとGPU転送による通常復元、リクエスト準備、共有キャッシュ認定を対象としています。リクエスト準備はデフォルトで無効です。文書化されたQwen3-8Bの対照では両エンジンでスループットが向上しますが、SGLangのP95レイテンシは悪化し、単一H20での測定は他のキャッシュに対する普遍的な優位性として提示されていません。ベンチマークコードと要約は `benches/` ディレクトリにあります。 ライセンスとコントリビューション OrbitKVはApache-2.0の下でライセンスされています。ドキュメントは、インストール、アダプタ設定、Managerオプション、メトリクス、障害認定、デプロイパターン、コントリビュータガイド、Pythonパッケージの詳細、テストゲート、リリースを扱っています。コントリビューションには、関連するチェックとドキュメント変更が含まれることが期待されています。