OpenLake レビュー: vLLM の KV キャッシュを GPU ノードのローカルストレージに逃がす Rust 製ストレージエンジン
OpenLake is a high performance storage engine for efficient LLM inference and GPU Training
ひと目でわかる
- これは何？
- OpenLake は io_uring ベースの Rust 製ストレージエンジンで、vLLM の KV キャッシュを GPU ホスト上の永続ストレージに置き、プレフィルを再利用する。S3 互換のオブジェクトストアとしても動く。導入の実際の手順と、向き不向きを整理する。
- 誰に向いている？
- OpenLake が向くのは、長いコンテキストを繰り返し処理する推論クラスタと、チェックポイント書き込みの帯域で GPU を待たせている学習環境だ。vLLM 側は kv-transfer-config に OpenLakeConnector を差し込むだけで、モデル側のコード変更は要らない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
OpenLake が埋めようとしている穴はプレフィルの再計算
長いシステムプロンプトや同じ文書を何度も読ませる推論では、同じプレフィルの KV キャッシュを毎回計算し直している。GPU 時間のうち、最初のトークンが出るまでのプレフィルが占める割合は小さくない。OpenLake はこの KV キャッシュを GPU ホストの RAM とディスクに永続化し、別のリクエストや別の GPU ホストから読み戻せるようにする。README はこの効果を「66× speedup on time to first token when cached (128K context window)」と表現している。数値の真偽はこちらでは確認していないが、狙っている構造は明確で、プレフィルを計算ではなくストレージ読み出しに置き換えるという発想だ。想定読者は、自前の GPU クラスタを運用していて、推論のスループットか学習のチェックポイント帯域のどちらかに不満があるエンジニアになる。マネージド推論サービスだけを使っている人には関係がない。
KV オフロードは vLLM のコネクタ差し替えで動く
仕組みは vLLM の KV 転送コネクタ機構に乗る形だ。vLLM は kv-transfer-config で KV キャッシュの転送先を差し替えられる。OpenLake はここに OpenLakeConnector を提供し、kv_connector_module_path に openlake_client.openlake_connector を指定させる。kv_role は kv_both、つまり読み書き両方を受け持つ。openlake_nodes に openlaked のアドレスを並べ、openlake_device で転送に使うデバイスを指定する。単一ホストなら local、InfiniBand クラスタなら mlx5_ib0 のような RDMA デバイス名を入れる。データの流れはこうだ。vLLM のワーカーがプレフィルの KV を計算し、コネクタ経由で openlaked に書き出す。openlaked はそれをホストの RAM とディスクに置く。同じプレフィルを持つ別のリクエストが来たら、vLLM は再計算せずコネクタ経由で読み戻す。README のマルチホスト構成の説明では「A prefix computed on one GPU host is served to any other from the shared pool」とあり、クラスタ全体で1つのプールとして扱う設計だと読み取れる。
openlaked の起動と S3 クライアントからの接続
導入手順は2系統ある。KV プールとして使う場合は pip install openlake-vllm でコネクタを入れ、openlaked を起動する。既定では同じホストにオフロードする。GPU フリート全体で共有するなら openlaked に --config を渡す。オブジェクトストアとして使う場合はソースからビルドする。apt-get で build-essential、pkg-config、clang、cmake、libhwloc-dev、libudev-dev などを入れ、rustup でツールチェーンを用意し、cargo build --release --bin openlaked を実行する。起動は ./target/release/openlaked --config crates/openlake_server/configs/storage-tcp-local.toml。データディレクトリは事前に data/d0 から data/d3 まで作る例が README に載っている。S3 互換のエンドポイントは 127.0.0.1:90 で、認証情報は AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY の両方に openlakeadmin を設定する例が示されている。aws --endpoint-url http://127.0.0.1:90 で通常の S3 クライアントから叩ける。Kubernetes の場合は charts/openlake/README.md の Helm 手順でノードごとに1インスタンスを配置し、vLLM のピア設定を生成する流れが案内されている。
RDMA 構成は self_id とデバイス名の整合が前提になる
マルチホスト構成は kv_rdma.toml を雛形にする。README の例では kv_rdma_0.toml を self_id 0、kv_rdma_1.toml を self_id 1 として起動し、vLLM 側の openlake_nodes に 10.0.0.1:9400 と 10.0.0.2:9400 を id 順に並べる。ここで効いてくるのは順序と一意性だ。self_id が重複すればクラスタの同一性が壊れるし、openlake_nodes の並びが self_id と対応していなければ、vLLM は意図しないノードに書きに行く。openlake_device に渡す RDMA デバイス名も、そのホストに実際に存在する NIC でなければならない。README はこの2点の検証方法までは示していない。設定ファイルを配る仕組みを別途用意するか、ノードごとに手で確認するかになる。GPU ノードの台数が増えるほど、この手作業は効いてくる。
ストレージ側の圧縮と、向かないワークロード
v0.8 で ExANS と呼ぶ BF16 KV キャッシュ向けの可逆 GPU コーデックが入ったとリリース情報にある。ブログでは 1.51× のコスト削減と説明されている。KV キャッシュは BF16 のままでは容量を食うので、可逆圧縮でホスト側のフットプリントを下げる狙いは理解できる。ただし圧縮は CPU か GPU のどちらかで展開コストを払う。レイテンシに敏感な推論で、圧縮率と展開時間のどちらを取るかはワークロード次第で、README からはどちらのトレードオフを選んだのか読み取れない。OpenLake が向かないのは、まず単一ノードで完結する小規模な推論だ。openlaked という常駐プロセスが増え、KV プールの容量管理も自分で見ることになる。次に、ストレージをクラウドのマネージドサービスに寄せている構成。OpenLake は GPU ホストに同居させる前提なので、その前提が崩れると利点が出ない。最後に、書き込みが一度きりで読み戻しがほとんど発生しないバッチ処理。プレフィル再利用が効かないため、永続化のコストだけが残る。
比較対象としての LMCache と、設計思想の違い
同じ問題領域には LMCache がある。vLLM の KV キャッシュを CPU RAM や外部ストレージに逃がし、プレフィルを再利用する点は共通だ。違いはストレージ層をどこまで自前で持つかにある。LMCache は既存のストレージバックエンドに接続する形を取るのに対し、OpenLake は io_uring を使う Rust 製のストレージエンジン自体を配布物に含め、S3 互換のエンドポイントまで提供する。つまり OpenLake を入れる判断は、KV オフロードの導入であると同時に、GPU ノード上に独自のストレージ層を1つ増やす判断でもある。既にオブジェクトストレージ基盤が整っていて、KV の逃がし先だけが欲しいチームにとっては、LMCache のほうが変更が小さい。逆に、チェックポイント書き込みの帯域そのものがボトルネックで、ストレージエンジンの選択から見直したいチームには、OpenLake のほうが踏み込んだ選択肢になる。
ライセンスとバージョンの追い方
ライセンスは Apache-2.0。特許条項を含む標準的な条件で、商用利用や改変、再配布に追加の制約は課されない。ただしこれは法的助言ではないので、自組織のポリシーに照らした確認は別途必要になる。バージョンは 0.9.0 が最新で、0.8.1 と 0.8.0 がその前に並ぶ。0.x 系が続いており、マイナーごとにコーデックの追加のような機能が入っている。設定ファイルのキーやコネクタのパラメータがマイナー更新で変わる可能性は残るので、kv-transfer-config の JSON と kv_rdma.toml はバージョンとセットで管理したほうがよい。Rust ツールチェーンは 1.91 以上が要求される。ビルドを自前で回す場合、この下限が CI のイメージ選定に影響する。
編集部の結論
OpenLake が向くのは、長いコンテキストを繰り返し処理する推論クラスタと、チェックポイント書き込みの帯域で GPU を待たせている学習環境だ。vLLM 側は kv-transfer-config に OpenLakeConnector を差し込むだけで、モデル側のコード変更は要らない。逆に、単一ホストの小規模推論や、ストレージをマネージドサービスに任せたいチームには、運用対象が増えるだけで見合わない。導入前に確認すべきは3点。kv_rdma.toml の self_id がノードごとに重複していないこと、openlake_device に渡す RDMA デバイス名が実際の NIC と一致すること、openlaked を再起動したときに KV プールを再構築する必要があるかどうかがドキュメントに書かれていないことだ。最後の点は自前で検証するしかない。
コミュニティノート