PrefillShare (2602.12029) — L3 Per-Paper Synthesis #
Target: PrefillShare — 跨模型共享 prefill 模块 + cache-conditioned 微调，在 disaggregated serving 里做多模型 KV 复用。
Cluster: 8 framework peers spanning KV-management, disaggregation, CPU-offload decomposition, scheduling, 与 training-inference 分离范式。
1. 相关论文 #
这 8 篇 peer 落在四条互补的轴上，与 PrefillShare 的关系强弱不一。
A. 直接血缘：disaggregation + KV 复用底座（最强相关）
- Mooncake (2407.00079) — 与 PrefillShare 最贴近的 peer。同样是 KVCache-centric disaggregated 架构，同样把 prefill/decode 分池、用分布式 KVCache 池做 prefix 复用 [2407.00079]。区别在于 Mooncake 复用的是同一模型跨请求的 prefix，而 PrefillShare 攻的是 Mooncake 明确无法解决的跨模型（跨参数）复用——因为 KV 与参数强耦合，Mooncake 的 hash 去重在 $\theta_i\neq\theta_j$ 时命中率为零 [2602.12029]。
- vLLM / PagedAttention (2309.06180) — PrefillShare 的实现基座（在 vLLM disaggregated pipeline 上加 proxy 编排层）[2602.12029]。vLLM 用 block table + copy-on-write 做同模型内的 prefix / beam 共享 [2309.06180]，PrefillShare 的 "prefix cache hit ratio" 指标正是 vLLM 语义下的度量，其高并发 CPU staging 瓶颈也直接源自 vLLM 的 swap 机制 [2602.12029]。
B. 同构思想：把模型「拆成两半、按角色部署」（强相关，方法论同源）
- FastDecode (2403.11421) — 把 Transformer 拆成 S-Part（GPU 线性层）/ R-Part（CPU attention+KV）[2403.11421]。与 PrefillShare 的「prefill 模块 / decode 模块」拆分在结构手法上同源，但拆分轴正交：FastDecode 按算子类型（线性 vs attention）横切每一层，PrefillShare 按阶段角色（prefill vs decode）纵切并跨模型共享。
- NEO (2411.01142) — 同样按 attention/linear 拆分并 offload 到 CPU，用 asymmetric pipelining 隐藏 CPU 时间 [2411.01142]。与 PrefillShare 共享「decode attention 是瓶颈、KV 是绑定约束」的问题诊断。
- FlexRLHF (2312.11819) / HybridFlow (2409.19256) — 训练侧的「training-inference 运行时物理分离」范式。FlexRLHF 的 Disaggregated 策略引入 Shadow Actor 把训练/推理拆到不同设备组 [2312.11819]；HybridFlow 的 3D-HybridEngine 让同一 actor 在训练/生成用不同并行策略、zero-redundancy resharding [2409.19256]。PrefillShare 把这一「同一模型、不同阶段、不同部署」的思想搬到了 serving 侧的跨模型场景。
C. 弱相关：调度与训练系统对照（方法轴不同，仅提供对比参照）
- FastServe (2305.05920) — serving 调度层（skip-join MLFQ 消除 HoL blocking + proactive KV swap）[2305.05920]。与 PrefillShare 正交（一个管 request 优先级调度，一个管跨模型 KV 去重），但其 proactive KV swapping 与 PrefillShare 高并发下的 vLLM CPU staging 是同一类内存压力问题的不同应对。
- DeepSeek-V3 (2412.19437) — MoE 训练框架（DualPipe + FP8），主体是训练 [2412.19437]。相关性最弱，仅在「MLA 压缩 KV cache 以省显存」这点上与 PrefillShare「省 KV 存储」目标遥相呼应——但 MLA 是架构级压缩，PrefillShare 是跨模型去重，机制完全不同。
2. 本篇 vs 相关论文的 delta #
新颖点（PrefillShare 独有）
- 跨模型 KV 复用需要训练来使能，而非纯系统技巧。 这是与全部 8 篇 peer 的根本 delta。Mooncake、vLLM、FastServe 的所有 KV 复用都建立在「KV 与参数绑定」这个前提上，只能做同模型复用 [2309.06180][2407.00079]。PrefillShare 的 cache-conditioned fine-tuning 首次用训练打破这个前提——冻结 base、把 $C_{\text{base}}$ 当常量、只训 decode 去读别人的 KV [2602.12029]。Fig. 2 的 naive-sharing 崩塌曲线证明：没有这一步训练，共享根本不 work。
- 拆分轴是「阶段 × 模型」的二维复用。 FastDecode/NEO 沿算子类型拆一层 [2403.11421][2411.01142]，其复用维度是「同一请求跨设备」；PrefillShare 沿 prefill/decode 拆，复用维度是「同一 prefix 跨 N 个异构 decoder」——内存主导项从 $O(N(L_{\text{shared}}+L_{\text{unique}}))$ 降到 $O(L_{\text{shared}}+N L_{\text{unique}})$，当 $L_{\text{shared}}\gg L_{\text{unique}}$ 时对 $N$ 近似不敏感 [2602.12029]。这是 8 篇里唯一让「模型数」从内存主导项里消失的工作。
增量点（把已有思想搬到新场景）
- 「training-inference 分离」从训练侧搬到 serving 侧。 FlexRLHF/HybridFlow 已确立「同一模型在不同阶段用不同部署」[2312.11819][2409.19256]，但它们分离的是同一 actor 的训练态 vs 生成态。PrefillShare 分离的是冻结 base 的 prefill 态 vs 多个微调 decoder 的解码态——概念同源，但跨的是模型边界而非阶段边界。
- prefix-aware routing 是 Mooncake cache-aware scheduling 的窄化版。 PrefillShare 的「User ID 钉住 prefill worker」[2602.12029] 本质是 Mooncake KVCache-centric scheduling 的一个特例 [2407.00079]——Mooncake 做的是全局 TTFT 最小化 + 热点迁移，PrefillShare 只做局部 pin，简单但够用。
矛盾/张力点
- 「省 KV 存储」与 vLLM staging 的自我拆台。 PrefillShare 声称去重让内存对 $N$ 近似不敏感 [2602.12029]，但实测 ~110 并发后吞吐因 vLLM 把 KV stage 到 CPU 再 reload 而回落 [2602.12029]。这与 FastServe 的教训一致：抢占/高并发下 KV 内存压力最高可达 7× 而必须 swap [2305.05920]。根源分析：PrefillShare 的 Eq. 9 只算了 prefix 去重，没算 decode 侧每个 activation session 的瞬时 GPU-resident KV——高并发下后者才是绑定约束，正是 NEO 反复强调的「KVCache 导致的 batch size 瓶颈」[2411.01142]。两者不矛盾：Eq. 9 在稳态存储量上正确，但没建模瞬时 decode-side footprint。
3. 可攻击面 #
针对 PrefillShare 具体主张的对抗性反驳：
攻击 1 — 「精度追平甚至反超 Full-FT」被 regularization 解释掩盖了范围局限。
PrefillShare 把偶尔反超 Full-FT（Qwen3-8B HumanEval 83.5→86.6）归因于「只更新 decode = 严格正则化」[2602.12029]。但这是事后叙事，没有理论也没有消融来隔离「正则化收益」与「KV-mismatch 损失」。反例就在同一张表：LLaMA GSM+ 49.3<49.8、Qwen GSM8K 84.8<85.8、Multiple 91.0<92.0 [2602.12029]——恰恰是需要精确数值推理的任务上 PrefillShare 输，需要生成多样性的 coding 上赢。真实机制更可能是「冻结 prefill 损害了对 prompt 数字的精细编码」，而非普适正则化。作者自己的 L2 也承认这缺形式化 [2602.12029]。
攻击 2 — baseline 是「稻草人式」的 per-model disaggregation，比较不公平。
PrefillShare 的 baseline 给每个模型独占 prefill+decode GPU（4 模型 = 8 GPU，4 份完整 KV）[2602.12029]。但 Mooncake 早已证明：分布式 KVCache 池 + LRU + hash 去重可以让同模型 prefix 命中率达 50%+ [2407.00079]。一个装了 Mooncake 式共享 prefix 池的 baseline，其命中率不会是「~60% 峰值后骤降」而应更平稳。PrefillShare 的 4.5×/3.9× 是相对一个没有任何跨请求 KV 复用的 baseline 得来的，真实 delta 会显著缩小。这正是 FlexRLHF 被批评的同款问题——baseline 存在明显设计缺陷时「赢得太容易」[2312.11819]。
攻击 3 — 收益上界受 prefix 命中率天花板约束，论文回避了 $L_{\text{shared}}$ 不占优的场景。
所有大幅提升都发生在 $L_{\text{shared}}\gg L_{\text{unique}}$ 的四智能体长共享上下文 [2602.12029]。但 Mooncake 的真实 trace 数据显示 cache ratio 中位数只有 ~50%，ArXiv 类负载几乎为 0 [2407.00079]。当 agent 输出段变长（$L_{\text{unique}}$ 上升）或 agent 间上下文不真正共享时，Eq. 9 退化回 baseline。论文用固定 token 长度的 ReAct/Reflexion 合成负载 [2602.12029]，回避了真实 agent 输出长度方差。
攻击 4 — 每个专用模型都要单独做一次 cache-conditioned 微调，摊销成本没算。
PrefillShare 的部署路径要求「为每个专用模型做一次 cache-conditioned 微调」[2602.12029]。这是纯系统方案（vLLM、Mooncake、FastServe、NEO）都不需要的一次性训练开销 [2309.06180][2411.01142]。对于快速迭代、模型频繁更换的 agent pipeline，每次换 decoder 都要重训，实际 TCO 可能抵消 serving 收益——论文完全没有讨论 base 模型更新时全部 decoder 是否需要重训（这是 FlexRLHF Shadow 模型同步问题的 serving 版 [2312.11819]）。
4. 生态位 #
范式定位：从「系统级 KV 复用」到「训练-系统协同设计的 KV 复用」的跃迁。
这个 cluster 呈现清晰的三代演进：
- 第一代（同模型、纯系统）：vLLM 用分页做同模型 prefix/beam 共享 [2309.06180]；FastServe 用调度消除 HoL blocking [2305.05920]。
- 第二代（拆分部署、纯系统）：Mooncake 把 prefill/decode 分池做分布式 prefix 池 [2407.00079]；FastDecode/NEO 把算子拆到 CPU [2403.11421][2411.01142]；训练侧 FlexRLHF/HybridFlow 做 training-inference 分离 [2312.11819][2409.19256]。
- 第三代（跨模型、训练+系统协同）：PrefillShare 用训练打破 KV-参数耦合，实现纯系统方案做不到的跨模型复用 [2602.12029]。
PrefillShare 的独特生态位：它是这堆 framework 里唯一需要改训练目标才能成立的 serving 优化。vLLM/Mooncake/NEO 都是「拿现成模型直接部署」，PrefillShare 是「先训练对齐、再部署」——这既是它的护城河（复现需要训练 know-how [2602.12029]），也是它的采用障碍。
采用证据（弱）：PrefillShare 是 2026-02 的极新 NAVER Cloud 预印本，代码未公开、0 引用 [2602.12029]。对比 cluster 里的采用成熟度：vLLM 已是事实标准引擎 [2309.06180]、Mooncake 开源含 trace [2407.00079]、HybridFlow 开源为 veRL 且 EuroSys 2025 收录 [2409.19256]。PrefillShare 目前处于「思想新颖但零外部验证」阶段，与同为未开源的 FlexRLHF/DeepSeek-HAI-LLM 一样面临可复现性质疑 [2312.11819][2412.19437]。
5. 未探索方向 #
从这个 cluster 的组合空间里，几个技术上可做但没人做的杂交方向：
- PrefillShare × Mooncake 分布式 KVCache 池。 PrefillShare 的共享 $C_{\text{base}}$ 目前钉在单 prefill worker 上（局部 pin）[2602.12029]。把它放进 Mooncake 的分布式 CPU DRAM/SSD 池 + hash 去重 + 热点迁移 [2407.00079]，就能让「跨模型共享 base cache」进一步「跨节点、跨会话」复用，直接缓解 §3 攻击 3 的命中率天花板。
- PrefillShare × NEO/FastDecode CPU offload 解 staging 瓶颈。 PrefillShare 在 ~110 并发处因 vLLM CPU staging 见顶 [2602.12029]。NEO 的 asymmetric pipelining 恰好是为「隐藏 CPU-GPU KV 传输」设计的 [2411.01142]。把 decode 侧的 KV staging 换成 NEO 式主动 offload + load-aware 调度，可能把吞吐拐点从 110 推到更高并发——这是 PrefillShare 自己 L2 里 §7 提到的「future system optimization」的具体化 [2602.12029]。
- PrefillShare × FastServe 优先级调度。 目前 routing 只按 User ID pin，无请求优先级 [2602.12029]。引入 skip-join MLFQ [2305.05920] 让共享 prefill worker 上的多会话按 prefill time 分级调度，可在保 prefix 局部性的同时减少长会话对短会话的 HoL blocking。
- Adaptive 共享比例，而非全有全无。 Fig. 2 显示 naive 共享随比例崩塌、PrefillShare 在 100% 也稳 [2602.12029]，但没探索「按 layer / 按 token 位置自适应决定共享哪部分 KV」。DeepSeek 的 MLA 低秩压缩 [2412.19437] 提示一个混合方向：对精度敏感的前几层保留 per-model KV、对靠后层做共享——可能修复 §3 攻击 1 里数值推理任务掉点的问题。
- 训练-免除的跨模型对齐。 PrefillShare 最大采用障碍是每个 decoder 都要重训 [2602.12029]。借鉴 HybridFlow 的 zero-redundancy resharding「同一模型不同阶段权重互为子集」思路 [2409.19256]，能否设计一种约束让微调后的 decoder 的 KV 表示自动与 frozen base 兼容、免除显式 cache-conditioned 阶段？这是把「训练依赖」降级为「训练约束」的方向。
参考（drill links） #