vLLM向けPegaFlow外部KVキャッシュ
起動が2.15倍高速化――これがvLLMとNovita AIのPegaFlowに関する共同記事の見出しですが、より深いポイントはアーキテクチャにあります。本番のLLMサービングでは、単一の推論エンジンプロセス外部でKVキャッシュを所有する必要があります。PegaFlowはKVキャッシュをスタンドアロンサービスとし、vLLMデプロイメントが再起動、ローカルインスタンス、リモートノードをまたいでキャッシュを保持、共有、スケールできるようにします。
この記事では、なぜPegaFlowを構築したのか、公開されているvLLM統合が示す内容、既にソースで裏付けられている主張、そして開発者が現在オープンソース実装をどのように調査できるかについて、Novita AIの視点から解説します。
PegaFlow GitHubリポジトリをご覧いただくか、vLLM x Novita AI共同記事で完全な技術解説をご参照ください。
PegaFlowはvLLMサービングにおいてどのような問題を解決するのか？
PegaFlowは、高スループットLLM推論におけるプロセスローカルなKVキャッシュのもろさに対処します。KVキャッシュが1つのvLLMエンジンプロセス内にしか存在しない場合、再起動中に有用なキャッシュ状態が失われたり、1つのインスタンス内に閉じ込められたり、ノード間で効率的に移動できなかったりします。
これは、長いプロンプトを再利用するワークロード、類似したリクエストをレプリカ間でルーティングする場合、あるいはプリフィルとデコードを分離する場合に特にコストがかかります。キャッシュがすでにシステムが再計算すべきでない作業を含んでいる可能性があるにもかかわらず、サービングトポロジがそれを常に再利用できるとは限りません。
PegaFlowはその境界を変えます。Rustコアで実装された外部KVキャッシュサービスとして動作し、長期にわたるフォークではなく、外部KVコネクタメカニズムを通じてvLLMに接続します。
PegaFlowはどのようにvLLMと統合するのか？
PegaFlowは、kv_transfer_config、PegaKVConnector、kv_connector_module_pathを通じてvLLMと統合します。公開記事では、コネクタによりPegaFlowが実行時に主要なKVキャッシュ操作を引き継ぎ、vLLMはスケジューリング、モデル実行、バッチ処理、OpenAI互換サービングパスを引き続き処理します。
現在公開されているリポジトリは、フレームワーク統合テーブルでvLLMを「準備完了」としてリストし、クイックスタートで次のコネクタ設定を示しています：
vllm serve Qwen/Qwen3-0.6B \
--kv-transfer-config '{"kv_connector": "PegaKVConnector", "kv_role": "kv_both", "kv_connector_module_path": "pegaflow.connector"}'
実際の利点は、よりクリーンな所有モデルです。vLLMはサービングエンジンであり続け、PegaFlowは外部KVキャッシュの保存、転送、共有、および関連するキャッシュ可観測性を所有します。
Novita AIのアーキテクチャは何を追加するのか？
Novita AIの設計目標は、KVキャッシュを一時的なプロセスメモリではなく、本番サービングインフラストラクチャのように動作させることです。つまり、PegaFlowはスタンドアロンサービスの境界、Rustデータパス、共有キャッシュプール、マルチティアストレージを中心に設計されています。
| アーキテクチャの選択 | 開発者にとっての重要性 | 公開ソース |
|---|---|---|
| 独立したサイドカーサービス | KVキャッシュは推論エンジンの再起動後も存続し、vLLMプロセスとは別にスケール可能 | PegaFlow README |
| GILフリーのRustコア | キャッシュホットパスはPythonのオーバーヘッドを回避し、推論エンジンスレッドがサービングに集中できる | PegaFlow README |
| ピンメモリ、RDMAリモートメモリ、SSDキャッシュ | キャッシュは高速ローカルメモリ、リモートノードメモリ、さらに大容量SSDバックアップにまたがることが可能 | vLLM記事 |
| PrometheusメトリクスとOTLPエクスポート | オペレーターはKVの再利用を隠れたエンジン詳細として扱うのではなく、キャッシュ動作を観測可能 | PegaFlow README |
最終確認日：2026-05-20。これらの詳細はvLLM共同記事および公開novitalabs/pegaflow READMEに基づきます。
どのようなパフォーマンス結果が公開されているか？
公開されているパフォーマンス主張は、vLLMの共同記事およびリポジトリベンチマークからのPegaFlow評価結果として読むべきであり、あらゆるワークロードに対する一般的な保証ではありません。キャッシュヒット率、プロンプト再利用、モデル形状、ハードウェア、ネットワークトポロジ、リクエストルーティングはすべて実際のデプロイメントに影響します。
| シナリオ | 報告された結果 | ソース |
|---|---|---|
| 所有済み500 GiBホストKVプールを使用したvLLM起動 | 起動が2.15倍高速化 | vLLM共同記事 |
| 8つのQwen3-8Bインスタンスが1つのホストキャッシュを共有 | スループット56%向上 | vLLM共同記事 |
| TP8のDeepSeek-V3.2 MLA | スループット72%向上 | vLLM共同記事 |
| 内部RDMAクラスタのリモート読み取り | 平均リモート読み取りスループット194 GB/s | vLLM共同記事 |
| H800参照ベンチマーク、Llama-3.1-8B、ウォームキャッシュ対コールドキャッシュ | TTFT平均が572.5 msから61.5 msに減少；P99 TTFTが1113.7 msから77.0 msに減少 | PegaFlow README |
最終確認日：2026-05-20。RDMAの数値はソース記事で内部クラスタ結果として説明されているため、普遍的なスループットの約束ではなく、報告された評価データとして位置づけるべきです。
外部KVキャッシュはいつ最も有用か？
外部KVキャッシュは、プロンプトの再利用が十分に高く、再計算がレイテンシ、スループット、またはGPU使用率に顕著になる場合に最も有用です。ほぼすべてのリクエストが一意であり、キャッシュの再利用が自然に低いワークロードではあまり有用ではありません。
- 頻繁な再起動： キャッシュをエンジン外部に保持することで、キャッシュ状態が有用であり続ける場合、再起動ペナルティを削減できる。
- マルチインスタンスサービング： ホストキャッシュを共有することで、ローカルvLLMインスタンス間での重複プリフィル作業を削減できる。
- マルチノードデプロイメント： RDMA対応リモートキャッシュにより、有用なKVブロックを1台のマシンを超えて利用可能にできる。
- プリフィル/デコード分離： 外部キャッシュは、サービングシステムに段階間のより明確なハンドオフポイントを提供できる。
Novita AIにとって、これはより広範なインフラストラクチャの原則の一部です。トラフィックパターンが複雑になると、本番AIシステムではサービングエンジン、メモリ層、ルーティング層、可観測性層が独立して進化する必要があります。
開発者は今日どのようにPegaFlowを調査できるか？
開発者は公開GitHubリポジトリを調査し、READMEで参照されている公開パッケージをインストールできます。リポジトリには、CUDA 12パッケージ、CUDA 13パッケージ、vLLMコネクタの例、サーバー設定、P2P RDMAセットアップ、プリフィル/デコードルーティング、メトリクス、プロジェクト目標が文書化されています。
uv pip install pegaflow-llm # CUDA 12
uv pip install pegaflow-llm-cu13 # CUDA 13
READMEにある最も簡単なローカルサーバーコマンドは次のとおりです：
pegaflow-server
本番評価では、自身のプロンプト再利用プロファイル、対象モデル、GPUトポロジ、メモリ容量、RDMAまたはSSDの仮定から始めてください。PegaFlowはキャッシュ再利用のためのインフラストラクチャです。ワークロードが、どれだけの価値を獲得できるかを決定します。
プラットフォームチームが採用前に検証すべきことは？
プラットフォームチームは、公開ベンチマーク数値を計画のインプットとして扱う前に、自身のサービングトポロジに対してPegaFlowを検証する必要があります。適切なテストは、コールド対ウォームキャッシュだけでなく、実際にコストやレイテンシを引き起こすトラフィックパターンにキャッシュ再利用が現れるかどうかです。
- 実際のルーティング下でのプロンプト再利用と予想KVキャッシュヒット率を測定する。
- 外部所有KVキャッシュがある場合とない場合の再起動動作を比較する。
- RDMAに拡張する前に、シングルノードのマルチインスタンス共有をテストする。
- 可観測性を検証する：キャッシュヒット、ミス、転送レイテンシ、メモリプレッシャー、SSD動作。
- デプロイメントで使用するvLLMコネクタパスとのバージョン互換性を確認する。
これこそが、オープンソースの境界が重要である理由でもあります。開発者は、ブラックボックスのキャッシュサービスに依存するのではなく、コネクタ、サーバー設定、メトリクス、ベンチマークセットアップを調査できます。
FAQ
PegaFlowとは何ですか？
PegaFlowは、Novita AIによるLLM推論向けのオープンソースKVキャッシュストレージエンジンです。独立したサービスとして動作し、外部KVコネクタパスを通じてvLLMに接続します。
PegaFlowはvLLMのフォークを必要としますか？
いいえ。公開されているvLLM記事では、PegaFlowはkv_transfer_configとPegaKVConnectorを通じて接続し、外部パッケージはkv_connector_module_pathを通じてロードされると説明されています。
どのパフォーマンス結果が公開されていますか？
vLLM共同記事では、起動が2.15倍高速化、共有ホストキャッシュ設定でスループット56%向上、DeepSeek-V3.2 MLA設定でスループット72%向上、内部RDMAクラスタでの平均リモート読み取りスループット194 GB/sが報告されています。READMEでは、ウォームキャッシュ参照ベンチマークでのH800 TTFT削減も報告されています。
開発者はどこでPegaFlowを試せますか？
開発者は公開novitalabs/pegaflowリポジトリを確認し、CUDA 12用pegaflow-llmまたはCUDA 13用pegaflow-llm-cu13をインストールし、リポジトリのクイックスタートに従ってください。
結論
PegaFlowは、vLLMを使用した本番LLM推論のためのNovita AIによる外部KVキャッシュの取り組みです。スタンドアロンキャッシュサービス、Rustデータパス、共有キャッシュプール、vLLMフォークを避けるコネクタ境界を備えています。重要なポイントはシンプルです：KVキャッシュがプロセスローカル状態ではなくインフラストラクチャになると、サービングチームは再起動、共有、スケーリング、可観測性をより細かく制御できるようになります。PegaFlowリポジトリをご確認いただき、公開結果を自身のワークロードと比較し、モデルAPI、エージェント実行、またはそのサービングスタック周辺のGPUワークフローが必要な場合には、Novita AIのより広範な開発者インフラをご利用ください。
