1. 论文信息
| 项目 | 内容 |
|---|---|
| 标题 | Prefill-as-a-Service: KVCache of Next-Generation Models Could Go Cross-Datacenter |
| arXiv | https://arxiv.org/abs/2604.15039 |
| 作者 | Ruoyu Qin, Weiran He, Yaoyu Wang, Zheming Li, Xinran Xu, Yongwei Wu, Weimin Zheng, Mingxing Zhang |
| 机构 | Moonshot AI；Tsinghua University |
| 提交记录 | v1: 2026-04-16；v2: 2026-04-22 |
| 篇幅 | 16 页，5 张图，6 张表 |
2. 为什么这篇论文重要
大模型在线推理有两个阶段：prefill 负责读完整个输入上下文，decode 负责一个 token 一个 token 地生成输出。它们吃的资源完全不同：prefill 更吃算力，decode 更吃显存带宽。把两者拆开跑，本来是大规模推理的自然方向。
问题在于：prefill 结束后会产生 KVCache，decode 必须拿到这份缓存才能继续生成。传统 Transformer 的 KVCache 很大，长上下文请求动辄产生 GB 级状态。于是“拆开跑”虽然在逻辑上合理，在物理上却被网络拴住了。
3. 必须先懂的三个背景概念
3.1 Prefill 和 Decode 为什么要拆
一个 LLM 请求进入模型后，第一步要把输入 prompt 全部读进去，这叫 prefill。之后模型每生成一个新 token，都要基于之前的上下文继续算，这叫 decode。
| 阶段 | 工作内容 | 主要瓶颈 | 适合的硬件 |
|---|---|---|---|
| Prefill | 一次性处理输入上下文 | 算力、矩阵计算吞吐 | 计算密集型加速器 |
| Decode | 逐 token 生成输出 | 显存带宽、状态读取 | 高内存带宽加速器 |
拆开之后，系统可以给 prefill 和 decode 分别分配不同机器，减少互相干扰。这就是 PD disaggregation 的价值。
3.2 KVCache 是什么，为什么它变成系统资源
Transformer 每一层 attention 会为上下文 token 保存 Key 和 Value。生成后续 token 时，不需要重新计算历史 token 的 K/V，而是复用 KVCache。它让 decode 更快，但也带来内存和网络压力。
论文用这个指标衡量单个 prefill 实例“产生 KVCache 的速度”。如果一个实例每秒产生几十 Gbps 的 KVCache，那么跨数据中心传输就很难成立。
3.3 混合注意力为什么改变了边界
传统 dense attention 的 KVCache 随上下文长度线性增长。新一代长上下文模型越来越多采用混合结构：少量 full attention 层搭配大量线性注意力、滑动窗口注意力或有界状态层。这样只有一部分层需要保存随长度增长的 KVCache，其余层保存的状态更小或接近固定。
| 模型类型 | 特点 | 对跨数据中心 PD 的意义 |
|---|---|---|
| Dense Transformer / GQA | KVCache 大，长上下文时网络压力高 | 通常需要同数据中心 RDMA 级网络 |
| MLA | 压缩 KV 表示 | 降低传输体积，但 prefill 仍可能较重 |
| SWA / Linear Attention | 有界状态或局部窗口 | 显著降低 KVCache 增长速度 |
| Hybrid Attention | 少量 full attention + 多数低 KV 层 | 让“跨集群传 KVCache”第一次具备现实可能性 |
4. PrfaaS-PD 总体架构
PrfaaS 的设计原则非常克制：不要把所有 prefill 都外包。只把增量上下文足够长、prefix cache 命中后仍然很长、且值得用远程高算力处理的请求 offload 到 PrfaaS 集群。
三层系统拆解
| 子系统 | 论文中的作用 | 工程直觉 |
|---|---|---|
| Compute | PrfaaS 集群做远程长 prefill；Local PD 集群做短 prefill 和 decode | 不同硬件不用强行放进同一个 RDMA 岛 |
| Network | 集群内 RDMA；集群间 VPC peering 或专线，以太网传 KVCache | 承认跨 DC 链路较慢，所以必须选择性使用 |
| Storage / Cache | 每个集群维护 prefix cache pool，全局管理元数据 | 请求放到哪里，取决于哪里已有可复用前缀 |
5. 混合 Prefix Cache Pool：为什么缓存也要重新设计
混合注意力模型的 KVCache 不是一种东西。线性注意力或 SWA 层的状态更像“请求级状态”，大小不随输入长度线性增长，通常需要精确匹配；full attention 层的 KVCache 是“块级状态”，可以做部分 prefix matching。
这个设计解决了一个容易被忽略的问题：如果模型结构已经不再是全层统一的 Transformer，那么缓存系统也不能继续假设所有层的 KVCache 都同构。
6. 调度模型：什么时候该把请求送去远程 prefill？
PrfaaS 不是一个“越多 offload 越好”的系统。它的核心是找到一个阈值 t：增量 prefill 长度超过 t 的请求去远程 PrfaaS，短请求留在本地 PD。
这组公式表达得很直白：系统吞吐取决于三段流水线里最慢的一段。远程 PrfaaS 的吞吐又取决于两个东西：算得够不够快，以及网络能不能把算出的 KVCache 搬出去。
调度器实际在权衡什么
| 因素 | 如果偏高 | 调度倾向 |
|---|---|---|
| 请求增量长度 l | 远程高算力 prefill 更有价值 | 更可能 offload |
| PrfaaS egress 利用率 | 跨集群链路快成为瓶颈 | 提高阈值，减少 offload |
| 本地 prefix cache 命中 | 本地只需算很短增量 | 留在本地 |
| 远程 prefix cache 命中 | 远程可减少重复 prefill | 可能 offload 或做跨集群 cache transfer |
| decode 队列 | decode 成为下游瓶颈 | 本地 PD 增加 decode 资源 |
7. Case Study：论文怎么证明它可行
作者使用一个内部 1T 参数混合架构模型做案例分析。模型类似 Kimi Linear 路线，采用 KDA:MLA = 3:1 的混合层结构。部署里，PrfaaS 集群使用 32 张 H200 做长上下文 prefill，本地 PD 集群使用 64 张 H20 做短 prefill 和 decode，两者之间约 100 Gbps 跨集群带宽。
模型 KVCache 数据
| 输入长度 | KVCache 大小 | Prefill 延迟 | KV throughput |
|---|---|---|---|
| 1K | 190.8 MiB | 0.44 s | 3.61 Gbps |
| 8K | 308.9 MiB | 0.72 s | 3.59 Gbps |
| 32K | 701.3 MiB | 1.84 s | 3.19 Gbps |
| 128K | 2316.3 MiB | 7.40 s | 2.62 Gbps |
注意一个反直觉点：请求更长时，KVCache 总量更大，但 KV throughput 反而略低，因为 prefill 计算时间增长得更快。这正是“长请求更适合 offload”的原因之一。
三种部署方式对比
| 指标 | PrfaaS-PD | 同构 PD | 朴素异构 PD |
|---|---|---|---|
| 阈值 t | 19.4K | 无 | 无 |
| 实例配置 | PrfaaS / PD-P / PD-D = 4 / 3 / 5 | PD-P / PD-D = 9 / 3 | PrfaaS / PD-D = 4 / 8 |
| Mean / P90 TTFT | 2.22 s / 3.51 s | 4.44 s / 9.73 s | 1.74 s / 3.51 s |
| 最大吞吐 | 3.24 req/s | 2.11 req/s | 2.45 req/s |
| 相对吞吐 | 1.54× | 1.00× | 1.16× |
论文最重要的实验信息不是“用了 H200 就更快”，而是：只做硬件异构还不够，必须配合选择性 offload 和吞吐均衡调度。朴素异构部署把所有 prefill 都给 H200，反而出现 prefill/decode 失衡，只比同构 PD 提升 16%；PrfaaS-PD 通过阈值 19.4K 把约 49.6% 的长请求 offload，吞吐提升到 54%。
8. 通俗理解：把 prefill 当成“远程洗衣房”
如果把一次 LLM 请求看作处理一堆衣服，prefill 是把一大篮衣服洗好、烘干、分类；decode 是之后一件一件拿出来穿。传统系统里，洗衣房和衣柜必须在同一栋楼里，因为洗完的衣服太多，搬起来太贵。
现在混合注意力模型让“洗完要搬的东西”小了很多。于是可以把大型洗衣房建在便宜、适合重计算的地方，本地只保留衣柜和小洗衣机。关键是：袜子、毛巾这种小活没必要送远程；只有大件、耗时、值得集中处理的任务才送出去。
9. 局限、前提和风险
| 问题 | 说明 | 工程影响 |
|---|---|---|
| 依赖混合架构 | dense Transformer 的 KVCache 仍然太大 | PrfaaS 对新一代低 KV 模型更有意义 |
| 案例来自内部 1T 模型 | 模型和线上流量细节无法完全复现 | 外部团队需要用自己的模型和流量重新 profile |
| 跨 DC 延迟 | 论文关注带宽和吞吐，真实部署还要看地理延迟和 jitter | 适合近地域、专线或 VPC peering 的集群 |
| 缓存一致性和元数据 | 全局 KVCache 管理器需要准确知道缓存位置和可复用长度 | 系统复杂度明显上升 |
| 故障恢复 | transfer-cache blocks 传输中断、远程 prefill 失败都要 fallback | 生产系统必须有本地兜底路径 |
所以，这篇论文不是说“以后所有推理都跨数据中心”。更准确的说法是：当模型 KVCache 足够小、请求长上下文占比较高、远程 prefill 硬件足够强、本地 decode 是重要瓶颈时，PrfaaS 是一个非常有吸引力的架构。
10. 我反复阅读后的关键笔记
10.1 这篇论文真正提出的是“部署边界变化”
过去 PD disaggregation 的边界基本是同一个高带宽网络域。论文认为，混合注意力模型把 KVCache throughput 降到一个新量级后，部署边界可以从“单个 RDMA 集群”扩展到“松耦合跨集群”。这是它最大的系统意义。
10.2 模型结构和系统架构必须一起设计
如果只有混合模型，没有调度，短请求也被送去远程，系统会拥塞。如果只有调度，没有低 KVCache 模型，网络根本承受不了。PrfaaS 的贡献在于把二者拼到一起：模型侧减少 KV，系统侧选择性搬运 KV。
10.3 “朴素异构”不是答案
简单地说“H200 做 prefill、H20 做 decode”会造成阶段吞吐失衡。论文用 naive heterogeneous baseline 证明了这一点：它只提升 16%，而 PrfaaS-PD 提升 54%。真正的工程难点在阈值、队列、缓存和资源比例。
10.4 KVCache 正在成为 LLM Serving 的一级资源
早期推理优化更关注 batch、kernel、量化、并行。现在 KVCache 变成一种需要路由、放置、迁移、压缩、复用、淘汰、审计的资源。未来的推理系统很可能像管理对象存储或分布式缓存一样管理 KVCache。
10.5 这对 AI Infra 的启发
未来模型服务商可能会出现专门的 prefill pool、decode pool、KVCache fabric 和全球调度层。对长上下文 Agent、RAG、代码库问答、会议/文档处理这类输入很长的业务，远程 prefill-as-a-service 可能会成为降低 TTFT 和提升吞吐的关键基础设施。
11. 来源与延伸阅读
- arXiv 摘要页：Prefill-as-a-Service: KVCache of Next-Generation Models Could Go Cross-Datacenter
- PDF：https://arxiv.org/pdf/2604.15039
- 论文相关背景：PD disaggregation、vLLM hybrid KVCache manager、Mooncake、DistServe、Splitwise、KVCache compression/reuse 等均来自论文正文的 Related Work 与 Design 部分。