NEO — L3 Cross-Paper Synthesis #

§1 相关论文 #

NEO 是 CPU-GPU 异构在线推理的核心方法论贡献。FastDecode 首先提出 "compute near data on CPU" 的 insight [2403.11421]，但其 symmetric pipelining 将所有 decode attention 完全卸载到远程 CPU，导致 GPU 内存浪费和 CPU 瓶颈 [2411.01142]。APEX 进一步发现 NEO 的 batch-splitting 在 decode-heavy 场景仍有缺陷，提出 unified-batch + deferred sync [2506.03296]。KVDrive 从不同角度解决内存受限问题——通过 attention-aware caching 减少 GPU-CPU 传输而非 offloading 计算 [2605.18071]。

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

vs FastDecode #

NEO 对 FastDecode 的三项核心批判形成其设计动机 [2411.01142]：

1. GPU 内存利用率：FastDecode 将所有 KVCache 移至 CPU，GPU 仅保留模型权重和运行时 activation——这浪费了 GPU 内存中原本可用于 batch 的空间。NEO 引入 GPU-cache/CPU-cache 二分管理，优先使用 GPU 内存。
1. GPU-CPU 负载平衡：FastDecode 的 symmetric pipelining 将 batch 均分为两个相同子批次，但 linear stage（GPU）通常远短于 attention stage（CPU）。NEO 的 asymmetric pipelining 让两个子批次互补——batch-0 有长 linear stage（包含 prefill），batch-1 有长 CPU attention。
1. 成本效率：FastDecode 需要 8 台 32-core AMD EPYC 服务器处理单 A10G GPU 的 attention [2403.11421]。NEO 仅使用本机 CPU（"comes with the GPU as free"），部分卸载控制在 CPU 容量内。

FastDecode 的还击点：FastDecode 在 throughput-oriented 场景仍有优势——当延迟不敏感时，完全卸载可达 5.04× vLLM 吞吐 [2403.11421]。NEO 的 greedy fallback 保证 never-worse-than-baseline 但也意味着在 GPU 内存充足时完全回退到 GPU-only 模式，收益消失。

vs APEX #

APEX 发现 NEO 的 asymmetric pipelining 在 decode-heavy workload 下仍有三个问题 [2506.03296]：batch splitting 使 GPU linear ops 翻倍；CPU-GPU 性能差距（10-20×）使平衡约束不可行；pipeline 约束限制 CPU 请求分配导致 idle bubbles。APEX 的 deferred cross-iteration sync 将 CPU compute window 从单次 GPU attention 扩展到整个迭代周期——在 T4 上对比 NEO 提升 72% throughput。

NEO 的防线：NEO 的 greedy 原则保证数学上 never-worse-than-baseline（受 profiling 精度限制），而 APEX 未提供类似的理论保证。此外 NEO 的 PACPU kernel（ISPC 编译）有更好的跨平台 portability（AVX2/AVX512/Neon），APEX 使用 Llamafile kernel 在某些场景下可能有 compatibility 限制。

vs KVDrive #

KVDrive 和 NEO 面对相同的 GPU 内存瓶颈但走了截然不同的路径：NEO 将计算移至 CPU 以释放 GPU 内存给 batch size [2411.01142]；KVDrive 用 attention-aware caching 减少需要从 CPU/SSD 传输的 KVCache 量（cache hit rate ~80%），从而在 GPU 内存受限下仍保持高效 [2605.18071]。两者可能互补：KVDrive 的 cache 策略可用于 NEO 的 CPU-cache 管理，减少 CPU attention 的 memory footprint。

§3 可攻击面 #

1. SwiftLLM 基线偏弱：NEO 的 base system SwiftLLM 在 2-GPU 设置下比 vLLM 慢 8.8% [2411.01142]。论文声称 "leaving integrating Neo into vLLM as future work"——但这意味着报告的多 GPU 增益是在偏弱基线上测量的。如果集成到 vLLM，实际增益可能缩水。
1. H100 限制测试条件：HGX 测试台限制在单 NUMA 节点（1/4 总内存和带宽）进行 2-GPU 实验 [2411.01142]。这人为限制了 NEO 在高端 GPU 上的 CPU 容量。H100 的 14% 增益可能在完整 NUMA 配置下更高（或更低——因为 GPU 内存本身充足，offloading 需求减少）。
1. 短输出时的性能退化：NEO 在短 output length 时可能略差于 baseline（尝试 offload 的开销 > 收益）[2411.01142]。Greedy 原则理论上保证 never-worse，但 profiling 不精确导致实际中存在轻微违反。这在 agentic workload（大量短 tool call responses）中可能累积为显著开销。
1. Prefill 阶段处理不完整：NEO 将 prefill 集成到 GPU 子批次中，但未讨论长 prompt prefill 的处理。当 prefill 占主导时（长上下文首轮），CPU offloading 的收益归零，系统退化为 GPU-only。
1. CPU 带宽是不可控约束：NEO 的核心 insight（CPU 带宽差距 < 算力差距）在 GDDR/HBM4 时代可能逆转——未来 GPU 内存容量增长（如 B200 192GB HBM3e）可能使 batch size 瓶颈自然消失，而 CPU 带宽增长缓慢。

§4 生态位 #

NEO 定义了 "本地 CPU 作为免费加速器" 的 serving 范式——与 FastDecode 的 "远程 CPU 集群" 和 Mooncake 的 "PD 分离 + 分布式 KVCache 池" 形成三种异构方案的光谱。

范式坐标：

• 部署复杂度：NEO（单节点、无需额外硬件）< APEX（同上但需更新 kernel）< FastDecode（需 CPU 集群 + InfiniBand）< Mooncake（需 PD 分离基础设施）
• 最大吞吐增益：FastDecode（5×）> NEO-T4（7.5×）> APEX-T4（96%）> Mooncake-长上下文（525%）
• 适用场景：NEO/APEX 适合 GPU 内存受限的边缘/经济部署；FastDecode 适合 throughput-first 的 batch 场景；Mooncake 适合长上下文生产环境

采用证据：NEO 承诺开源但未给出 URL。APEX 已在 NEO 基础上进一步迭代，验证了 CPU offloading 作为研究方向的持续活力。CPU 带宽是绑定约束（而非算力）的 insight 已被多个后续工作验证。

§5 未探索方向 #

1. NEO + KVDrive 融合：NEO 的 CPU-cache 使用简单的 paged attention 管理。将 KVDrive 的 attention-based cache management（2D MCKP 优化 per-layer-per-head 窗口）[2605.18071] 应用于 NEO 的 CPU-cache 分区，可能显著减少 CPU attention 需要处理的 KVCache 量，从而在更弱的 CPU 上实现更大收益。
1. GPU 内存增长下的 offloading 价值重估：NEO 的 T4 7.5× 增益 vs H100 14% 增益呈现强烈的反相关——GPU 内存越大，offloading 收益越小 [2411.01142]。随着 B200（192GB）和 MI355X（288GB HBM3e）普及，需要重新评估 CPU offloading 在高端 GPU 上是否仍有价值——可能仅在 100K+ 长上下文或极大 batch 场景下保留意义。
1. APEX 的 deferred sync + NEO 的 PACPU kernel：APEX 使用 Llamafile kernel 替代 NEO 的 ISPC PACPU，但 PACPU 在某些场景下可能更优（跨平台 portability）。将 APEX 的调度策略与 NEO 的 kernel 实现结合可能产生最优方案。
1. 多租户 CPU 争用：NEO 假设 CPU 资源完全可用于 attention offloading，但在云环境中 CPU 同时运行 batch gathering、tokenization、scheduling 等任务 [2403.11421]。需要 CPU 资源隔离或优先级机制来防止 attention offloading 被其他任务干扰。
1. 与 PD 分离的结合：NEO 和 Mooncake 分别在节点内和节点间优化。在 Mooncake 的 decode 实例上部署 NEO 的 CPU offloading——利用 decode 节点闲置的 CPU 资源进一步扩大 decode batch size——是技术可行但未探索的方向。