News

Prefill-as-a-Service: KVCache of Next-Generation Models Could Go Cross-Datacenter

原文链接：https://arxiv.org/abs/2604.15039 HTML 全文：https://arxiv.org/html/2604.15039 作者：Ruoyu Qin、Weiran He、Yaoyu Wang、Zheming Li、Xinran Xu、Yongwei Wu、Weimin Zheng、Mingxing Zhang 机构：Moonshot AI、清华大学发布日期：2026-04-16

速查卡

项目	内容
一句话总结	月之暗面把 Prefill/Decode 分离从“同一 RDMA 机房内优化”推进到“跨数据中心可调度”的生产架构。
大白话版	以前大模型推理像两个人必须坐同一张桌子接力做题；PrFaaS 让“看题的人”和“写答案的人”可以在不同机房协作，只要传过去的中间草稿足够小。
核心数字	吞吐量相对同构 PD +54%；相对 naive 异构方案 +32%；P90 TTFT -64%；PrFaaS 出口平均只占 13Gbps。
评级	A — 不是小优化，而是在改写长上下文推理系统的部署边界。
代码	论文未附公开代码；相关系统脉络与 Mooncake / vLLM hybrid KV 管理器有关。
关键词	PrFaaS、PD disaggregation、KV Cache、hybrid attention、Kimi Linear、cross-datacenter serving、heterogeneous inference

核心 Insight

这篇论文最值钱的洞察，不是“KV Cache 变小了”，而是：

混合注意力模型把 KV Cache 压到“以太网可以承受”的量级；
但仅仅 KV 变小还不够，真正决定系统是否能跑起来的，是谁该被跨机房卸载、何时卸载、以及缓存命中和带宽如何一起调度；
因此，下一代长上下文推理的主战场不再只是模型结构，而是“模型架构 × 调度器 × 网络 × 缓存池”的联合设计。

过去 PD（Prefill-Decode）分离已经是行业标配，但默认前提是 Prefill 和 Decode 仍在同一个高带宽 RDMA 域里。这个前提很贵，也很僵硬：你很难让最适合 Prefill 的算力芯片和最适合 Decode 的带宽型芯片灵活部署在不同机房，更别说跨城市调度。论文的突破在于，它把“是否必须共处一个 RDMA 岛”这条默认假设打穿了。

更重要的是，作者没有停在架构口号层面，而是给出了一套很完整的解释链：为什么 dense attention 会被 KV 传输卡死、为什么 hybrid attention 会改变边界、为什么 naive 地把所有 Prefill 外包仍然会拥塞、以及如何用双时间尺度调度把这个系统真正稳定下来。

为什么这个想法成立？

因为 Prefill 和 Decode 本来就不是同一种计算。

Prefill 更像“把整张卷子读完并建立思维状态”，主要吃计算吞吐。
Decode 更像“边想边往外写答案”，主要吃内存带宽和稳定的逐 token 读取。

把两者强行绑在同一类硬件上，本质上是一种历史妥协，而不是最优设计。PrFaaS 的贡献，是证明只要模型侧足够 KV-friendly，系统侧又足够会挑请求，Prefill/Decode 完全可以跨机房异构化。

方法详解

整体架构

论文的整体流程可以概括成：

请求进入
  ↓
全局调度器根据未缓存长度 l、带宽状态、前缀缓存位置做决策
  ├─ 若 l ≤ t：留在本地 PD 集群完成 Prefill + Decode
  └─ 若 l > t：送往远端 PrFaaS 集群做长上下文 Prefill
                ↓
           生成 KV Cache
                ↓ commodity Ethernet / VPC / 专线
           传回本地 PD 集群
                ↓
             本地 Decode

这里最核心的决策变量是阈值 $t$ ：

短请求不值得跨集群折腾，留在本地；
长请求 Prefill 更吃算力，跨到高吞吐 Prefill 集群才划算；
这个阈值不是写死的，而是跟带宽、请求长度分布、缓存命中情况联动调整。

关键技术组件

组件 1：KV throughput 建模

作者提出一个非常关键的系统指标：单位实例在 Prefill 阶段“制造 KVCache 的速度”。

\Phi_{kv}(l)=\frac{S_{kv}(l)}{T_{prefill}(l)}

其中：

$S_{kv}(l)$ ：长度为 $l$ 的请求在 Prefill 后产生的 KV Cache 大小
$T_{prefill}(l)$ ：对应的 Prefill 延迟
$\Phi_{kv}(l)$ ：可以理解为“这个模型每秒往网络里喷出多少待传输的 KV 状态”

直觉上，这个指标越大，跨机房就越难做。因为你不是只关心 KV 有多大，而是关心它生成得有多快。单份 KV 再大，只要生成很慢，网络也许还能跟上；反过来单份 KV 不算特别夸张，但如果单位时间持续喷发，网络一样扛不住。

论文进一步给出集群出口带宽需求近似：

B_{out} \approx N \cdot P \cdot \Phi_{kv}(L_{avg})

其中：

$N$ ：Prefill 集群实例数
$P$ ：并行度（每实例 GPU 数）
$L_{avg}$ ：被卸载请求的平均未缓存长度

这条式子非常重要，因为它把“模型结构”和“系统部署”连上了：

模型结构决定 $\Phi_{kv}$ ；
调度策略决定 $L_{avg}$ ；
集群规模决定总出口带宽压力。

组件 2：混合注意力把 RDMA 需求打到以太网级

论文对比了多种模型在不同上下文长度下的 KV throughput。

模型	结构	32K tokens KV throughput
Kimi Linear	Hybrid	3.87 Gbps
MiMo-V2-Flash	Hybrid	4.66 Gbps
Qwen3.5-397B	Hybrid	8.25 Gbps
Ring-2.5-1T	Hybrid	2.59 Gbps
MiniMax-M2.5	Dense	59.93 Gbps
Qwen3-235B	Dense	33.35 Gbps

这张表几乎就是整篇论文的物理基础。

32K 长度下，MiMo-V2-Flash 只有 4.66Gbps，而 MiniMax-M2.5 是 59.93Gbps，差了接近 13 倍。Qwen3.5-397B 相比 dense 的 Qwen3-235B，也低了约 4 倍。

为什么会这样？因为 hybrid attention 只让少数 full-attention 层保留随长度增长的 KVCache，其他线性/有界状态层只保留固定大小或受控大小的状态。于是随着上下文变长，增长的那部分被显著削弱。

论文对 Ring-2.5-1T 的解释尤其值得记：

MLA 相比 GQA 带来约 4.5× 压缩；
7:1 的 hybrid 比例再额外给出约 8× 降低；
合起来大约是 36× 级别的 KV 内存节省。

这意味着：以前跨机房传 KV 是消防水带接家用水管；现在至少已经降到企业级千兆/百兆网可以认真算账的量级。

组件 3：Hybrid Prefix Cache Pool

作者强调，真正的线上系统不会只有一种 KVCache 形态。

混合模型里有两类状态：

线性注意力 / SWA 层的 recurrent state，是 request-level，大小固定，只有完全匹配才能复用；
full-attention 层的 KVCache，是 block-level，随长度增长，可以部分前缀命中。

因此他们设计了 hybrid prefix cache pool，把缓存又拆成两类：

prefix-cache blocks
- 用于集群内复用
- 必须块对齐并完全填满才可复用
transfer-cache blocks
- 专门服务跨集群传输
- 传完即丢，不长期占用缓存池

这个设计的妙处在于：它没有把“缓存复用”和“跨机房传输”混成一团，而是明确区分“长期资产”和“临时搬运箱”。这让系统既能吃到 prefix cache 的好处，又不至于被跨集群传输拖垮存储管理。

组件 4：长度阈值 + 双时间尺度调度

PrFaaS 不是把所有请求都送去远端，而是只挑那些值得送的长请求。

当未缓存长度 $l > t$ 时，请求被送往远端 PrFaaS 集群；否则留在本地 PD 集群。这里的核心不是“越多越好”，而是“只把网络预算花在最赚的请求上”。

短期调度（毫秒级）关注：

当前 PrFaaS 出口带宽是否接近阈值
某个请求的 prefix cache 命中在本地还是远端
是不是该优先命中缓存而不是重复 Prefill

长期调度（分钟级）关注：

Prefill 队列和 Decode 队列谁在变成瓶颈
是否要把 PD 集群中的部分节点从 Prefill 角色转去 Decode，或反向调整

这是论文最成熟的地方之一。很多系统论文只证明“某个结构在 steady state 下更优”，这篇论文连 bursty traffic、缓存分布不均、跨集群带宽波动都纳进来了。

训练/部署设定

这不是训练论文，但实验设定非常关键：

模型：内部 1T 参数 hybrid model
架构：对齐 Kimi Linear，KDA:MLA = 3:1
PrFaaS 集群：32 × H200 GPU，用于长上下文 Prefill
本地 PD 集群：64 × H20 GPU，用于 Decode + 短请求 Prefill
对照组：96 × H20 的同构 PD 集群
网络：跨集群约 100Gbps VPC 链路；集群内 800Gbps RDMA
请求长度分布：截断对数正态，均值约 27K tokens
输出长度：固定 1024 tokens
SLO：40 tokens/s

作者还给出了该 1T 模型的实测指标：

输入长度	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 计算增长速度超过了 KV 膨胀速度，使得“长请求反而更适合外包给远端 Prefill 集群”成为可能。

与现有方法的关键区别

维度	传统同构 PD	naive 异构 PD	本文 PrFaaS
Prefill / Decode 部署	同机房、同类硬件	异构硬件但粗暴全量分配	按请求长度选择性卸载
网络假设	RDMA 域内	仍可能被跨集群带宽卡住	明确围绕 commodity Ethernet 设计
缓存设计	单一前缀缓存视角	容易忽略 hybrid 状态差异	hybrid prefix cache + transfer cache
调度策略	角色配比优化为主	几乎无智能调度	带宽感知 + 缓存感知 + 双时间尺度
本质问题定义	如何把 PD 跑快	如何把异构硬件塞一起	如何让跨机房异构协作真正可运营

实验结果

主实验

方案	Mean / P90 TTFT	系统吞吐(req/s)	相对同构 PD
同构 PD（96×H20）	4.44 / 9.73 s	2.11	1.00×
naive 异构 PD	1.74 / 3.51 s	2.45	1.16×
PrFaaS-PD	2.22 / 3.51 s	3.24	1.54×

解读：

相对同构 PD，PrFaaS 把总吞吐从 2.11 req/s 拉到 3.24 req/s，提升 54%。
P90 TTFT 从 9.73s 降到 3.51s，下降 64%，这说明长请求不再挤爆本地 Prefill 队列。
naive 异构 PD 也能提速，但只有 16% 增益，证明“异构硬件本身”不够，调度才是决定性差异。

关键配置解

论文通过网格搜索找到最优点：

路由阈值： $t = 19.4K$
本地 PD 集群实例划分： $N_p = 3$ ， $N_d = 5$
大约 49.6% 的请求被送往 PrFaaS
被卸载请求的平均未缓存长度约 44K tokens

也就是说，作者没有选择“只卸载极长尾的 1% 请求”，而是大约把一半请求导向远端。这说明只要模型足够 KV-friendly，跨机房卸载已经不是 edge case，而是可以进入主路径。

带宽利用率

这是最关键的工程结果：

PrFaaS 集群平均出口带宽只有 13Gbps
只占 100Gbps 链路的 13%

这意味着什么？意味着这不是一个“理论上能跑、线上一上量就炸”的系统。它给系统留了非常大的带宽冗余。作者的核心论点并不是“我们榨满了 100Gbps”，而是“我们根本不需要榨满，已经够赚”。

消融与对比理解

虽然论文不是典型算法论文，没有传统 ablation 表，但系统层面的对照其实就是它的“消融”：

变体	吞吐	与完整方案差距	说明
完整 PrFaaS-PD	3.24	—	长度阈值、调度、异构协同都启用
同构 PD	2.11	-34.9%	没有异构 Prefill 集群，长请求挤占本地资源
naive 异构 PD	2.45	-24.4%	有异构硬件，但没有精细调度

这张表背后的真正结论是：

异构硬件能带来一部分收益；
但如果没有调度，收益会被 pipeline 失衡吃掉；
真正的价值来自“架构 + 调度 + KV 管理”的联合作用。

复现评估

维度	评分(1-5)	详细说明
数据可得性	⭐	线上请求分布、真实缓存命中和生产级流量不可得。
代码可得性	⭐⭐	论文无完整开源实现，但依赖的 Mooncake / vLLM hybrid KV 管理脉络可部分参考。
算力需求	⭐⭐⭐⭐⭐	需要 H200/H20 级别异构集群、VPC/专线、PD serving 系统，基本是头部实验室/云厂级工程。
工程复杂度	⭐⭐⭐⭐⭐	跨集群缓存一致性、调度、带宽治理、尾延迟控制都非常复杂。
预期收益	⭐⭐⭐⭐⭐	对长上下文、agentic coding、工具调用、RAG 长输入场景的 infra 成本结构影响很大。

复现建议：

第一阶段先在单云双集群环境里验证长度阈值策略，不要一上来做跨城市。
第二阶段把 hybrid KVCache 管理和 transfer-cache 分层做出来。
第三阶段再引入双时间尺度调度，监控带宽、队列与 prefix-hit 分布。

批判性分析

局限性

论文自己已经承认几个关键问题：

流量是 bursty 的，steady-state 优化未必能覆盖最坏尾部；
prefix cache 在不同集群分布不均，调度器必须实时修正；
inter-cluster bandwidth 会抖动，不能把理论可用带宽当成稳定常数。

我们额外看到的边界：

对模型架构强依赖。 这套系统不是所有模型都能用。只要你还是 dense GQA 路线，KV throughput 可能立刻把这套方案送回 RDMA 牢笼。
实验仍基于内部模型与内部流量设定。 论文给出的长上下文分布、输出长度固定 1024、SLO 40 tok/s，都是合理但偏特定的设置。换到更短输出、更高 prefix-hit、或多租户流量后，最优阈值可能明显变化。
成本结论没有完全展开。 论文证明了吞吐和延迟收益，但没把“跨机房网络费 + 缓存管理开销 + 调度复杂性”完整折成 TCO 模型。对云厂来说，这最后一公里很关键。
对失败模式讨论还不够。 如果远端 PrFaaS 集群瞬时失联、带宽骤降、或 transfer-cache 热点爆发，如何优雅降级到本地全流程路径，论文着墨不多。

改进方向

把 TCO 算清楚： 下一步最该补的是“每百万 token 成本 vs 带宽费用 vs 硬件资本开支”的统一模型。
把调度器和 prefix cache 结合得更深： 未来可能不只是按长度阈值，而是按“长度 × prefix-hit × 当前出口带宽 × 机房负载”联合决策。
与 KV 压缩/近似复用联动： 如果叠加 CacheGen、KIVI、CacheBlend 一类机制，跨机房带宽需求可能还能再降一截。
与 phase-specialized 芯片共设计： 一旦 Rubin CPX 一类 Prefill 芯片和 LPU/超高带宽 Decode 芯片成熟，PrFaaS 会从“系统技巧”变成“基础设施默认形态”。

独立观察

这篇论文其实在替 Kimi Linear 做 infra 侧“战略护航”。它不只是说模型长上下文更强，而是说：这种模型结构让部署方式本身都变了。
它和 Cerebras × AWS 的 disaggregated inference 是同一大方向，但更进一步：不是同一数据中心里做 Prefill/Decode 分工，而是把边界推到跨数据中心。
这篇工作的真正敌人不是 NVIDIA GPU，而是“单机房、单集群、固定角色配比”的旧部署范式。

对领域的影响

短期看，这篇论文会影响长上下文服务与 agent workload 的集群设计；中期看，它会推动模型团队在设计 attention 机制时，把“KV 可搬运性”当成一等目标；长期看，它可能让推理基础设施像存储分层一样，变成天然的多层异构系统：

本地低延迟集群负责短请求和高命中缓存；
远端高算力集群吞长上下文 Prefill；
Decode 落在最带宽友好的硬件上；
调度器按 token 长度、缓存位置和链路状态动态路由。

如果这条路线跑通，未来讨论“大模型推理架构”时，问题就不再是“用几张卡”，而是“哪些 token 该在哪个机房、哪类芯片、以什么缓存状态被处理”。

这就是 PrFaaS 真正的分量：它不是在优化一条流水线，而是在重画推理系统的地图。

速查卡
核心 Insight
为什么这个想法成立？
方法详解
整体架构
关键技术组件
训练/部署设定
与现有方法的关键区别
实验结果
主实验
关键配置解
带宽利用率
消融与对比理解
复现评估
批判性分析
局限性
改进方向
独立观察
对领域的影响