§1 TL;DR #
FastDecode 将 Transformer 分解为 S-Part（GPU 密集线性层）和 R-Part（CPU 侧 attention+KVCache），彻底移除 GPU 内存中的 KVCache 以支持极大 batch size。使用分布式远程 CPU 的聚合带宽执行 attention，配合 load-stabilizing schedule 和性能模型，在 A10 GPU 上达到 vLLM 的 1.88×–5.04× 吞吐。
§2 痛点 / 方法 / 结果 #
Q1 痛点 #
LLM decode 阶段是 gemv 操作（矩阵×向量），GPU 利用率极低。扩大 batch size 是唯一可行的提升手段，但 KVCache 内存占用随 batch 和序列长度线性增长，很快超出 GPU 容量。直接将 KVCache offload 到 CPU 内存后仍需要每步 swap 回 GPU，PCIe 带宽成为瓶颈。
核心 insight（同 Neo）：GPU 和 CPU 在算力上差距巨大（~100×），但在内存带宽上差距远小（~3×）。decode attention 恰好是 memory-bandwidth-bounded——应该 compute near data on CPU 而非 move data to GPU。
Q2 方法 #
S-Part / R-Part 分解：
- S-Part（GPU）：所有线性层（QKV projection、FFN、output projection）——compute-bound，GPU 最优。
- R-Part（CPU）：attention 操作（$QK^\top$ + softmax + $PV$）——memory-bandwidth-bound，KVCache 留在 CPU 内存。
传输内容从 KVCache（$O(B \times L \times d)$ 每步）变为 activation tensor Q/O（$O(B \times d)$ 每步），量级缩小数十到数百倍。
分布式 R-Worker 架构：
- S-Worker（GPU 节点）：持有模型权重，执行 S-Part。产出 $Q_i, K_i, V_i$ 后发送到 R-Workers；接收 $O_i$ 继续后续层。
- R-Workers（多台远程 CPU 节点）：各自维护一份 KVCache partition，接收 QKV 后执行 attention 并返回 O。通过 InfiniBand 通信。
- Batch size 可达百万级（仅受分布式 CPU 内存总量限制）。
Load-stabilizing schedule：
R-Part 延迟随序列增长而增长（每步多读一行 KVCache），但 S-Part 延迟不变。简单 2-stage pipeline 会出现 R-Worker 成为瓶颈的 bubble。方案：控制新序列的注入时机，混合长短序列使 R-Worker 总序列长度稳定，减小延迟波动。带来最高 20% 吞吐提升。
Performance model-guided orchestration：
给定模型和 GPU 配置，通过微基准测试估算所需最小聚合 CPU 带宽，指导 R-Worker 数量选择。
核心技术壁垒：将 QKV activation 而非 KVCache 作为跨设备传输对象的设计选择。这使 GPU 内存完全释放给 batch，throughput 可随 batch size 线性增长直到 S-Part 饱和。代价是 R-Worker 的聚合带宽必须匹配 GPU 的处理速率。
Q3 结果 #
- Llama-7b：2279 tok/s（batch=1024）vs vLLM 452 tok/s → 5.04×
- Llama-13b：1441 tok/s（batch=1024）vs vLLM 350 tok/s → 4.12×
- Scaling efficiency（1024 token seq）：72.8%（7b）/ 84.1%（13b）at 8 sockets
- 短序列（128 token）scaling 退化：8 sockets 反而低于 4 sockets（S-Worker 成为瓶颈）
§3 架构 / 方法图 #
sequenceDiagram
participant SW as S-Worker (GPU)
participant R1 as R-Worker 1 (CPU)
participant R2 as R-Worker 2 (CPU)
participant R3 as R-Worker 3 (CPU)
Note over SW: Holds all model weights (S-Part)
Note over R1,R3: Each holds KVCache partition
loop Per layer l
SW->>SW: Compute QKV projections (S-Part)
par Send Q,K,V to R-Workers
SW->>R1: Q₁, K₁, V₁ (partition 1)
SW->>R2: Q₂, K₂, V₂ (partition 2)
SW->>R3: Q₃, K₃, V₃ (partition 3)
end
par R-Workers compute attention
R1->>R1: Append KV to cache, compute attention
R2->>R2: Append KV to cache, compute attention
R3->>R3: Append KV to cache, compute attention
end
par Return O
R1->>SW: O₁
R2->>SW: O₂
R3->>SW: O₃
end
SW->>SW: Continue S-Part (FFN, next QKV proj)
end
Pipeline 机制：S-Worker 维护两个 mini-batch A 和 B。S-Part(A) 执行期间，R-Workers 处理 R-Part(B)，反之亦然。理想情况 S-Part 和 R-Part 延迟匹配时无 bubble。
§4 作者证明 #
性能模型概述 #
论文提出 model-guided orchestration 但 workshop 版本未给出完整公式推导。核心逻辑：
- $T_S$ = S-Part 延迟（固定，与 batch size 成正比但与序列长度无关）
- $T_R$ = R-Part 延迟（与序列总长度成正比：$\sum_{i} \text{seq\_len}_i$）
- Pipeline throughput ≈ $\frac{\text{batch\_size}}{\max(T_S, T_R)}$
- 最小 R-Worker 数量 = 使 $T_R \leq T_S$ 的最少 CPU sockets
6 项检查 #
- S-Part/R-Part 分解正确：attention 是唯一依赖 KVCache 的操作，其余线性层仅需 activation——分解边界清晰。
- 传输量缩减：Q/O activation size $O(B \times d)$ vs KVCache $O(B \times L_{seq} \times d)$——论文声称 "orders of magnitude" 但未给出具体比值公式。
- Scaling efficiency 验证：Figure 7 展示 1→8 sockets scaling，13b-1024 达 84.1%。短序列退化（37.6%）符合 S-Worker 瓶颈预测。
- Layer reduction 的评估方法：评测使用减层模型并外推到原始模型——外推方法未详述，是方法论弱点。
- Load-stabilizing 贡献量化：声称最高 20% gain，但未单独消融。
- 无 prefill 处理：论文完全忽略 prefill 阶段，仅讨论 decode。实际 serving 中 prefill 仍需 GPU 执行。
无形式化解析模型 — workshop 版本仅描述性能模型框架，full arxiv 版本（15页）可能包含完整推导。
§5 实验与数据 #
吞吐对比（Fig 5） #
| System | Llama-7b (tok/s) | Llama-13b (tok/s) |
|---|
| vLLM | 452 | 350 |
| TensorRT-LLM | 233 | 204 |
| FastLLM | 175 | 143 |
| Vanilla | 194 | 103 |
| FastDecode (128) | 1052 | 660 |
| FastDecode (256) | 1542 | 1026 |
| FastDecode (512) | 2202 | 1363 |
| FastDecode (1024) | 2279 | 1441 |
Batch 128→1024（8×）仅带来 ~2× throughput——收益递减，因 R-Part 延迟线性增长。
Scaling efficiency（Fig 7） #
| # Sockets | 7b-1024 Efficiency | 13b-1024 Efficiency | 13b-128 Efficiency |
|---|
| 1 | 100% | 100% | 100% |
| 2 | ~85% | ~90% | ~80% |
| 4 | ~78% | ~88% | 75.9% |
| 8 | 72.8% | 84.1% | 37.6%* |
*8 sockets 低于 4 sockets throughput — S-Worker 瓶颈。
延迟（Fig 6） #
FastDecode(1024) 的平均 token 生成延迟约为 FastDecode(128) 的 3.5×——throughput-latency trade-off 明显。
§6 论证链 #
| Step | Claim | Evidence | Strength |
|---|
| 1 | KVCache 是 GPU batch size 的绑定约束 | Fig 1 (memory breakdown) | Strong — 定量清晰 |
| 2 | GPU-CPU 带宽差距远小于算力差距 | Fig 2 (hardware spec comparison) | Strong — 硬件事实 |
| 3 | S-Part/R-Part 分解将传输量从 KVCache 降至 activation | 定性论证 ("orders of magnitude") | Medium — 缺少具体比值 |
| 4 | 分布式 CPU 聚合带宽可饱和 GPU | Fig 7 scaling + performance model 框架 | Medium — 模型未完整给出 |
| 5 | Load-stabilizing schedule 提供额外 20% gain | 声称值，无消融图 | Weak — 未独立验证 |
| 6 | 端到端 1.88×–5.04× over vLLM | Fig 5, 6, 7 | Strong — 多模型验证 |
§7 实现 cross-reference #
- S-Worker：PyTorch，GPU 上执行
- R-Worker：C++ 实现，AVX-2 intrinsics 优化混合精度 attention
- 通信：InfiniBand 网络
- 评测硬件：A10 GPU (24GB) + 最多 4 节点 dual-socket AMD EPYC CPU
- 代码：
[实现未公开]（论文未给出开源链接）
关键实现细节：
- R-Worker 的 C++ attention kernel：使用 AVX-2 intrinsic 实现 paged attention 的变体，mixed-precision（FP16 KVCache + FP32 accumulator），contiguous memory access ordering 最大化 CPU cache line 利用率。
- Pipeline bubble 源于 temporal workload heterogeneity：S-Part 延迟固定但 R-Part 延迟随序列增长。Load-stabilizing schedule 通过混合长短序列保持 $\sum \text{seq\_len}$ 稳定，但只能部分缓解——根本矛盾无法消除。
框架特定分析 #
系统范围 #
- 阶段覆盖：仅 decode（prefill 未讨论）
- Serving 模式：offline-like throughput 优化（无 SLO 约束讨论）
- 并行维度：S-Worker 可用多 GPU TP；R-Worker 跨节点 data parallelism
- 部署模式：多节点异构（1 GPU node + N CPU nodes）
调度与资源管理 #
- 调度粒度：sequence-level（控制新序列注入时机）
- 抢占策略：无（batch 形成后不可抢占）
- 过载策略：未讨论
- KVCache 管理：完全驻留在 R-Worker CPU 内存，分 partition 到各 R-Worker
- Swap：无（KVCache 从不在 GPU 侧）
胜负场景 #
| Workload Regime | FastDecode | vLLM | Why |
|---|
| 长序列 (1024+)，高吞吐优先 | 5.04× | 基线 | GPU 完全释放给 batch，R-Worker 带宽充足 |
| 短序列 (128)，多 R-Workers | 比少 R-Workers 差 | 基线 | S-Worker 成为瓶颈，多余 CPU 浪费 |
| 延迟敏感在线场景 | 延迟 3.5× baseline | 低延迟 | 大 batch 必然增加延迟 |
| Prefill 密集负载 | 无方案 | 基线 | FastDecode 未处理 prefill 阶段 |
部署上下文 #
- Serving stage：仅 decode
- 硬件亲和性：需要 InfiniBand 连接的 CPU 节点集群，CPU 带宽是绑定约束
- 生态集成：独立系统，不是 vLLM 插件
- 迁移路径：需搭建 CPU 集群 + InfiniBand 网络 + 部署 R-Worker 进程