vLLM与Novita AI联手：PegaFlow如何让大模型推理的“记忆”独立存活？

起因：为什么需要让KV缓存“独立”？

对于任何部署过大模型推理服务的工程师来说，KV缓存（Key-Value Cache）都是一个熟悉又“昂贵”的存在。它存储了模型在生成文本时对上下文的理解状态，是实现高效自回归生成的关键。然而，在传统的设计中，这个动辄占用数百GB内存的“记忆资产”与推理引擎进程（如vLLM worker）是深度绑定的。这意味着，一旦引擎进程因为崩溃、滚动升级或模型切换而重启，整个巨大的缓存池就会瞬间蒸发。重新分配和预热（warming up）这些缓存需要大量时间，导致服务中断或性能抖动。在生产环境中，这种耦合带来了高昂的运维成本和脆弱的故障域。PegaFlow的提出，正是为了解决这个痛点——将KV缓存的生命周期与单个推理进程解耦，使其成为一种可持久化、可共享的服务基础设施。

拆解：PegaFlow的核心架构与工作原理

PegaFlow的本质，是一个独立的、用Rust编写的守护进程（daemon），它运行在每台机器上，接管了原本由vLLM worker管理的KV缓存资源。其核心创新在于构建了一个三级缓存层次结构：

1. 固定主机内存（Pinned Host Memory）：作为最快的一级缓存，存储最热的KV数据。
2. RDMA可访问的远程内存：利用高速网络（如测试中使用的8x400Gbps网卡）在集群节点间共享缓存，实现跨节点的缓存池化。
3. SSD：作为容量最大、速度最慢的持久化层，用于存储冷数据或作为溢出缓冲。

vLLM worker进程通过CUDA IPC（用于高速数据传输）和gRPC（用于控制指令）与本地的PegaFlow服务通信。这种设计带来了几个关键优势：

• 进程故障隔离：vLLM进程可以随时崩溃、重启或升级，而PegaFlow服务保持存活，宝贵的缓存数据安然无恙。反之亦然。
• 资源池化与共享：同一台主机上的多个vLLM实例（可能运行不同模型、不同并行配置）可以共享同一个由PegaFlow管理的缓存池，极大提高了内存利用率。文章中的测试显示，8个Qwen3-8B实例共享一个缓存池，比各自拥有独立缓存池的吞吐量高出56%。
• 更快的启动速度：由于巨大的缓存池由常驻的PegaFlow服务预先持有，vLLM进程启动时无需再进行耗时的内存分配。在500 GiB缓存的测试场景下，vLLM的就绪时间从71.4秒缩短至33.2秒，提升2.15倍。这对于需要快速弹性伸缩的服务至关重要。

趋势洞察：从“引擎内置”到“基础设施化”

PegaFlow的实践揭示了LLM推理栈的一个清晰演进趋势：关键资源的基础设施化。就像数据库将存储与计算分离、Kubernetes将应用与底层机器解耦一样，LLM推理中最昂贵的运行时资产——KV缓存——也正在从引擎的“内部状态”转变为平台级的“外部服务”。

这不仅仅是技术架构的优化，更是一种运维范式的转变。它使得缓存管理（如容量规划、数据迁移、跨模型复用）可以独立于推理引擎进行，为构建更稳定、更高效、更易于管理的大规模推理服务铺平了道路。文章中提到的对DeepSeek-V3.2 MLA（一种需要特殊张量并行处理的注意力机制）的优化，通过避免为每个TP rank重复存储逻辑KV数据，实现了72%的吞吐量提升，这进一步证明了专业化、外部化的缓存服务能针对特定模型架构进行深度优化，这是通用推理引擎难以兼顾的。

实用价值与反常识点

对于正在使用或评估vLLM的团队，PegaFlow提供了一个即插即用的解决方案。它通过标准的kv_transfer_config接口集成，无需修改vLLM源码或维护长期分支，这大大降低了采用门槛。你可以立即思考：你的服务是否受困于推理引擎更新导致的缓存失效？是否在同一主机上运行着多个模型实例，存在内存浪费？如果是，那么外部缓存服务可能是一个值得探索的方向。

一个可能反常识的点是：将缓存移出进程，反而可能提升整体性能。直觉上，进程内访问应该是最快的。但PegaFlow通过CUDA IPC实现了高效的进程间数据传输，同时通过资源池化和消除重复存储（如TP rank的重复KV），在系统整体层面获得了更大的吞吐量收益。这提醒我们，在复杂的分布式系统设计中，局部最优（进程内最快）不等于全局最优（系统吞吐最高）。

---

原文地址: vLLM x Novita AI: PegaFlow for Production-Grade External KV Cache