PegaFlow 外部 KV 缓存（用于 vLLM）
2.15 倍更快的启动速度是联合 vLLM 与 Novita AI PegaFlow 文章中的核心数字，但更深层的意义在于架构层面：生产环境中的 LLM 服务需要将 KV 缓存的所有权置于单个推理引擎进程之外。PegaFlow 将 KV 缓存作为独立服务，使 vLLM 部署能够在重启、本地实例和远程节点之间保留、共享和扩展缓存。
本文从 Novita AI 的角度出发，阐述我们构建 PegaFlow 的原因、公开的 vLLM 集成所展示的内容、哪些声称已有源代码支持，以及开发者今天如何检查开源实现。
探索 PegaFlow GitHub 仓库 或阅读 vLLM x Novita AI 联合文章 获取完整技术讲解。
PegaFlow 为 vLLM 服务解决了什么问题？
PegaFlow 解决了高通量 LLM 推理中进程本地 KV 缓存的脆弱性问题。当 KV 缓存仅存在于单个 vLLM 引擎进程内部时，有用的缓存状态会在重启期间丢失、被困在一个实例内，或无法高效地在节点间迁移。
当工作负载重复使用长提示、将相似请求路由到多个副本、或分离预填充和解码工作时，这个问题会变得代价高昂。缓存可能已经包含系统不应重新计算的工作，但服务拓扑并不总能重用它们。
PegaFlow 改变了这个边界。它作为一个外部 KV 缓存服务运行，核心采用 Rust 实现，并通过外部 KV 连接器机制（而非长期 fork）连接到 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 评估结果，而非适用于所有工作负载的通用保证。缓存命中率、提示重用、模型形状、硬件、网络拓扑和请求路由都会影响实际部署。
| 场景 | 报告结果 | 来源 |
|---|---|---|
| vLLM 启动时使用预占用的 500 GiB 主机 KV 池 | 启动速度提升 2.15 倍 | 联合 vLLM 文章 |
| 八个 Qwen3-8B 实例共享一个主机缓存 | 吞吐量提升 56% | 联合 vLLM 文章 |
| DeepSeek-V3.2 MLA 搭配 TP8 | 吞吐量提升 72% | 联合 vLLM 文章 |
| 内部 RDMA 集群远程读取 | 远程读取平均吞吐量达 194 GB/s | 联合 vLLM 文章 |
| H800 参考基准测试，Llama-3.1-8B，热缓存 vs 冷缓存 | 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 块跨越单机可用。
- 预填充/解码分离： 外部缓存可为服务系统提供更清晰的阶段间交接点。
对于 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 连接器路径的版本兼容性。
这也是开源边界的意义所在。开发者可以检查连接器、服务器配置、指标和基准测试设置，而非依赖黑盒缓存服务。
常见问题
什么是 PegaFlow？
PegaFlow 是来自 Novita AI 的用于 LLM 推理的开源 KV 缓存存储引擎。它作为独立服务运行，并通过外部 KV 连接器路径连接到 vLLM。
PegaFlow 是否需要 vLLM 的 fork？
不需要。已发表的 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 仓库，安装 pegaflow-llm（CUDA 12）或 pegaflow-llm-cu13（CUDA 13），并按照仓库快速入门操作。
结论
PegaFlow 是 Novita AI 为使用 vLLM 的生产级 LLM 推理提供的外部 KV 缓存方案：独立缓存服务、Rust 数据路径、共享缓存池，以及避免 vLLM fork 的连接器边界。关键在于：当 KV 缓存成为基础设施而非进程本地状态时，服务团队能对重启、共享、扩展和可观测性获得更多控制。查阅 PegaFlow 仓库，将公开结果与您自己的工作负载对比，当您需要模型 API、代理执行或该服务栈上的 GPU 工作流时，可使用 Novita AI 的开发者基础设施。
