FastDecode — L3 Cross-Paper Synthesis #

§1 相关论文 #

FastDecode 是 CPU-GPU 异构 LLM serving 的先驱工作。其 S-Part/R-Part 分解和 "compute near data" insight 被 NEO [2411.01142] 和 APEX [2506.03296] 继承并改进。vLLM 作为 GPU-only baseline 在所有场景下被 FastDecode 大幅超越（1.88-5.04×），但 FastDecode 的高吞吐以显著延迟增长为代价 [2403.11421]。

§2 本篇 vs 相关论文的 delta #

vs NEO #

FastDecode 和 NEO 共享同一核心 insight：decode attention 是 memory-bandwidth-bounded，CPU 带宽差距远小于算力差距 [2403.11421] [2411.01142]。但两者在设计哲学上根本分歧：

FastDecode 的 激进设计 在 throughput-first 场景下仍有独特价值：完全移除 GPU KVCache 使 batch size 理论上可达百万级 [2403.11421]，这是 NEO 的部分卸载无法企及的。但 NEO 指出 FastDecode+ 在长输出时降至 baseline 的 <60% [2411.01142]——CPU 成为绝对瓶颈。

vs APEX #

APEX 验证了 FastDecode → NEO 演化路线的延续性，但也暗示 FastDecode 的全卸载路线有更深层的问题：即使 NEO 已改为部分卸载 + asymmetric pipelining，batch splitting 本身仍导致 GPU linear ops 翻倍 [2506.03296]。APEX 的 unified-batch + deferred sync 才彻底解决了这个问题——这使 FastDecode 的 S-Part/R-Part 分解在 decode-heavy 在线场景下基本过时。

FastDecode 仍有生存空间：在 offline batch inference（无延迟约束）场景下，FastDecode 的极大 batch size + 分布式 CPU 聚合带宽仍可提供最高吞吐。这一场景类似 FlexGen 的定位。

vs KVDrive #

FastDecode 和 KVDrive 代表了 GPU 内存瓶颈的两种极端解法：FastDecode 完全消除 GPU 上的 KVCache，KVDrive 精确管理 KVCache 在多层存储间的分布 [2605.18071]。KVDrive 的 attention-based cache 策略（cache hit ~80%）意味着大部分 KVCache 访问可在 GPU 本地完成——这使得 FastDecode 式的完全卸载变得不必要。但当 context length × batch size 极大（超出 DRAM 容量）时，FastDecode 的分布式方案仍有意义。

§3 可攻击面 #

1. 评估方法论弱点：实验使用减层模型并外推到原始模型——外推方法未详述 [2403.11421]。在非线性 scaling 行为下（如 pipeline bubble 随层数非线性增长），这种外推可能系统性高估性能。
1. 传输量缩减未定量：论文声称激活 tensor 比 KVCache "小数个数量级"，但未给出具体比值公式 [2403.11421]。实际上 $Q/O$ activation size $= O(B \times d)$ 而 KVCache $= O(B \times L_{seq} \times d)$，缩减倍数 $= L_{seq}$——对短序列（128 tokens）仅 128×，远非 "orders of magnitude"。
1. 短序列 scaling 反模式：8 sockets 在 128-token 序列上吞吐低于 4 sockets [2403.11421]。论文正确归因于 S-Worker 瓶颈，但未讨论经济影响——额外 4 台 CPU 服务器不仅无益反而有害，这使 FastDecode 在短上下文场景下的 TCO 比 GPU-only 方案更差。
1. Load-stabilizing schedule 贡献仅 20%：作为三大贡献之一，仅带来 20% throughput gain 且无独立消融验证 [2403.11421]。在学术贡献度上偏弱。
1. 未覆盖 prefill：FastDecode 完全忽略 prefill 阶段 [2403.11421]。在实际 serving 中 prefill 可能占主导（长 prompt 首轮），FastDecode 对这些请求无优化手段。

§4 生态位 #

FastDecode 是 GPU-CPU 异构推理的范式定义者——其 S-Part/R-Part 分解和 "compute near data on CPU" insight 构成了 NEO、APEX 等后续工作的思想基础。尽管其具体实现（远程 CPU 集群、symmetric pipelining）已被后续工作超越，但核心洞察——CPU 内存带宽与 GPU 的差距远小于算力差距——已成为该方向的公理。

时间线定位：FastDecode (2024-03) → NEO (2024-11) → APEX (2026-06)，三者形成了清晰的演化链。FastDecode 提出问题分解，NEO 解决部分卸载和在线延迟约束，APEX 消除 batch splitting 的最后残余问题。

当前适用性：FastDecode 的设计在以下场景仍有价值：(1) offline batch inference（FlexGen 替代方案），(2) 极大 batch + 长序列的 throughput-first 场景，(3) 作为教学工具展示 GPU-CPU 异构分解的原始思路。在 online serving 场景下，APEX 已全面取代 FastDecode 的方法论。

§5 未探索方向 #

1. S-Part/R-Part 分解的推广：FastDecode 将 attention 从 dense layers 分离。MoE 模型中，expert FFN 同样可按 compute intensity 分类——routing-conditional sparse experts 可能适合 CPU 执行（低 arithmetic intensity），而 shared experts 和 attention 留在 GPU。这种跨 MoE 维度的 S/R 分解未被探索。
1. R-Worker 与 KVDrive 的结合：FastDecode 的 R-Worker 持有完整 KVCache partition，KVDrive 的 attention-based eviction 可减少每个 R-Worker 需要保留的 KVCache 量 [2605.18071]，从而在相同 CPU 内存下服务更多序列或更长上下文。
1. Network-aware R-Worker placement：FastDecode 的性能模型假设均匀 InfiniBand 带宽，但在实际数据中心中 NUMA 拓扑和交换机层级导致非均匀延迟。根据 KVCache partition 的访问模式（temporal locality + spatial locality）优化 R-Worker 到物理 CPU socket 的映射可能进一步减少传输延迟。
1. APEX 的 deferred sync 应用于分布式 R-Worker：APEX 的核心 insight（跨迭代延迟同步）可推广到 FastDecode 的分布式场景——R-Worker 的 attention 结果延迟到下一次迭代消费，容忍更大的网络延迟波动。
1. 与 PD 分离的协同：在 Mooncake/DynaServe 的 decode 实例上部署 FastDecode 式的 CPU R-Worker——利用 decode 节点闲置的 CPU 资源执行部分 decode attention——可在不增加 GPU 的前提下扩大 decode batch size。