Seesaw：让预填充与解码使用不同的并行形态

日期： 2026-09-25
领域： 效率与系统（分布式推理、并行策略、KV cache）
核心论文： Seesaw: High-throughput LLM Inference via Model Re-sharding，MLSys 2025
作者： Qidong Su, Wei Zhao, Xin Li, Muralidhar Andoorveedu, Chenhao Jiang, Zhanda Zhu, Kevin Song, Christina Giannoula, Gennady Pekhimenko
证据口径： 下文所有论文内数字均来自实际读取的论文 PDF；“PDF p.x”按下载文件页码，“Fig./Table/§”按论文编号。没有数值标签的图不做像素估读。

0. 链接验证表与版本边界

全部链接于 2026-09-25 实际访问。核心论文的 OpenReview 页面触发浏览器验证，但 PDF 地址可访问；因此把“OpenReview”标成“入口受验证墙限制”，而不把它当作正文数值来源。未在论文、官方会议页、arXiv 或可检索仓库中找到 Seesaw 官方代码、数据/权重、项目页或视频，均明确记为“未公开/未找到”。

1. 候选池、排重与随机选择

运行日为周五，因此领域按规则轮转到“效率与系统”。先检查 ml-report-index.md：最近 14 天已经深度覆盖 Search Your Block Floating Point Scales!（低比特量化）、Ada-KV（KV cache 分配）以及稍早的 Lumos（训练性能建模）；这三篇与对应主题从候选中排除。候选由 MLSys 2025 proceedings 与 OSDI 2025 正式页面整理，并用 arXiv、OpenReview、Hugging Face Daily Papers、Papers with Code、Semantic Scholar 作交叉发现；其中部分聚合站没有新增的一手版本信息，最终链接统一回到会议正式入口。下列 23 个正式入口均实访返回可用页面：

1. Youmu: Efficient Columnar Data Pipeline for LLM Training — MLSys 2025
   
2. LeanAttention: Hardware-Aware Scalable Attention Mechanism for Decode — MLSys 2025
   
3. Rethinking Key-Value Cache Compression Techniques for LLM Serving — MLSys 2025
   
4. SampleAttention: Near-Lossless Long Context LLM Inference — MLSys 2025
   
5. ReaL: Efficient RLHF Training with Parameter Reallocation — MLSys 2025
   
6. APOLLO: SGD-like Memory, AdamW-level Performance — MLSys 2025
   
7. PipeFill: Using GPUs During Bubbles in Pipeline-parallel LLM Training — MLSys 2025
   
8. HyC-LoRA: Memory Efficient LoRA Fine-tuning with Hybrid Activation Compression — MLSys 2025
   
9. XGrammar: Flexible and Efficient Structured Generation Engine — MLSys 2025
   
10. FlexAttention: A Programming Model for Generating Fused Attention Variants — MLSys 2025
    
11. NEO: CPU Offloading for Online LLM Inference — MLSys 2025
    
12. Context Parallelism for Scalable Million-Token Inference — MLSys 2025
    
13. Marconi: Prefix Caching for the Era of Hybrid LLMs — MLSys 2025
    
14. FastTree: Attention Kernel and Runtime for Tree-Structured LLM Inference — MLSys 2025
    
15. Scaling Deep Learning Training with MPMD Pipeline Parallelism — MLSys 2025
    
16. Efficient LLM Inference using Dynamic Input Pruning and Cache-Aware Masking — MLSys 2025
    
17. Optimizing LLM Queries in Relational Data Analytics Workloads — MLSys 2025
    
18. SOLA: SLO Attainment with State-Aware Scheduling — MLSys 2025
    
19. ThunderServe: High-performance Cost-efficient LLM Serving in Clouds — MLSys 2025
    
20. Seesaw: High-throughput LLM Inference via Model Re-sharding — MLSys 2025
    
21. LServe: Efficient Long-sequence LLM Serving with Unified Sparse Attention — MLSys 2025
    
22. FlashInfer: Efficient and Customizable Attention Engine for LLM Inference Serving — MLSys 2025
    
23. WaferLLM: Large Language Model Inference at Wafer Scale — OSDI 2025

在原始 24 项清单中排除已覆盖的 Lumos（原编号 16），随后实际执行 printf '%s\n' {1..15} {17..24} | shuf -n 1，返回原编号 21，即 Seesaw。其正式 PDF 有完整模型、硬件、工作负载、端到端结果与敏感性分析，资料充足，故重抽次数为 0。

2. Motivation：静态并行为什么是结构性错配

问题不是“TP 还是 PP 谁总体更好”，而是两个阶段的主瓶颈交换了。Prefill 一次处理数百到数千输入 token，模型权重加载能被大量 token 摊薄，运行时主要被计算和 all-reduce 通信支配；decode 每一步每条序列只生成一个 token，算术强度低，逐层从 HBM 读取权重的占比高。TP 把线性层权重分摊到多卡，因此 decode 能并行加载权重，却需要在每层同步完整激活；PP 只跨 stage 传激活，prefill 通信轻，却把全局 batch 切成约 1/PP 的 micro-batch，使相同全局 batch 需要 PP 倍 forward pass，并重复加载权重。论文用 Fig. 3 明确给出这一方向相反的偏好（PDF pp.4–5）。

痛点有三组定量证据。第一，低带宽连接会把 TP 的每层 all-reduce 变成 prefill 税；实验中的 PCIe 4.0 ×8 仅 16 GiB/s，而对照 NVLink 为 600 GiB/s（§6.1，PDF p.8）。第二，空间拆分 prefill/decode 并不自动解决小集群问题：LLaMA2-70B 的 FP16 权重约 140 GiB，在 8×40 GiB GPU 上每阶段至少 4 卡，于是资源切分只能是 4/4；该配置的 prefill 吞吐比 decode 高 6×以上，而 4 卡 decode 吞吐仅为 8 卡 decode 的 15%（§3.2、Fig. 4，PDF p.6）。第三，实际 A100 对比显示连接决定收益：在 NVLink 上 Seesaw 对 70B ShareGPT 仍有 13% 提升，但 PCIe 上对 arxiv-summarization 和 ShareGPT 分别是 46% 与 30%（§6.4、Fig. 11，PDF p.9）。

因此论文的核心假设是：同一批物理 GPU 可以“时间复用”为不同的逻辑并行拓扑，只要重分片与 KV 迁移的开销能够被更大的阶段批次摊薄或异步隐藏。这个假设天然偏向 offline/high-throughput；如果系统要满足严格 TTFT/TPOT，积攒 CPU KV 缓冲直到满再切换会引入额外等待，作者在 §7.1（PDF p.10）也明确承认其以延迟换吞吐。

3. 故事线、形式化与关键权衡

3.1 平均每序列时间模型

论文在 §3.1（PDF p.5）把平均每序列时间写成：

$$T \approx \frac{T_{dm}^{linear}}{TP} + \frac{T_{dm}^{attn}+T_{comp}}{DP\cdot TP\cdot PP} + \frac{T_{comm}(TP)}{PP\cdot DP}.$$

其中 T_dm^linear 主要是线性层权重的数据移动，T_dm^attn 主要是 KV cache 数据移动，T_comp 是计算，T_comm(TP) 是通信且随 TP 单调增加。decode 中第一项占比大，增大 TP 有利；prefill 中第一项相对可忽略，第三项更关键，降低 TP、提高 PP/DP 更有利。这个模型的价值是把并行策略选择从经验规则变成三个资源项的权衡；它的局限是没有把切换、CPU 内存带宽、NUMA、PCIe 争用直接写入主式，而是由系统机制事后处理。

3.2 动态重分片流程

输入请求队列
   │
   ▼
选择 prefill 配置 c_p（常偏 PP，少 all-reduce）
   │  计算 prompt；GPU KV → pinned memory → shared CPU memory
   │  重复，直到 CPU KV 缓冲满
   ▼
从 CPU 重载目标 weight shards，并按 c_d 取回 KV shards
   │
   ▼
选择 decode 配置 c_d（常偏 TP，权重加载并行）
   │  prefetcher 异步 swap-in；continuous batching 解码
   │  重复，直到 CPU KV 缓冲空
   └───────────────────────────────↺ 回到 prefill

更接近实现的伪代码如下；它不是论文逐字代码，而是依据 §4–§5 的保真流程化表达：

while pending_requests or live_sequences:
    if cpu_kv_store.is_empty():
        reshard_weights(target=c_p)
        while not cpu_kv_store.is_full() and pending_requests:
            batch = schedule_prefill(pending_requests)
            kv = workers.prefill(batch, layout=HND)
            async_swap_out(kv, gpu_to_pinned=True, pinned_to_shared=True)
    else:
        reshard_weights(target=c_d)
        while not cpu_kv_store.is_empty():
            prefetcher.async_swap_in(free_gpu_kv_slots, shards_for=c_d)
            batch = schedule_decode(ready_sequences)
            workers.decode(batch)

关键权衡不是免费午餐。更少的阶段切换意味着更大批次和更好吞吐，却增加请求等待；CPU KV 缓冲扩展了 prefill 批次，却把 CPU 内存容量、NUMA 路径和 PCIe 带宽变成新约束；从 CPU 重载权重 shard 的开销近似与 batch 大小无关，可以摊薄，而 KV 搬运随 batch 增长，只能靠重叠隐藏（§5.2，PDF p.7）。

4. 关键机制与工程细节

论文不动态调整 DP，是一个重要设计边界。改变 DP 会改变模型副本占用与 KV 可用显存比例，要么提高复杂度，要么引入额外 CPU↔︎GPU 数据移动，因此作者只在 TP/PP 之间动态调整（§4.1，PDF p.6）。这既让实现可控，也意味着“动态并行”并非全空间自动搜索。

5. 数据集、模型、硬件与指标

作者没有纳入 SGLang 与 DeepSpeed-FastGen，理由是它们不支持 PP；也没有纳入 TensorRT-LLM，理由是其调度与 vLLM 类似且 vLLM 吞吐相当（§6.1，PDF p.8）。这解释了基线选择，却没有替代与 DistServe、Sarathi-Serve 或更新服务栈的 head-to-head。

6. 主结果：能从论文推出什么

6.1 完整可读的跨硬件汇总

相对提升的分母均为同硬件上的 vLLM。1.45× 既可表述为比 baseline 高 45%，也可表述为吞吐乘数 1.45；报告保留两种表达以避免“pp”和百分比混用。吞吐不是百分率，所以不写 percentage point。

6.2 A100 归一化矩阵：论文真正给出精确柱值的部分

Fig. 11 以“vLLM + NVLink = 1.00”为跨连接归一化基准。论文只有两个真实数据集，无法诚实补成“五基准×六方法”；下面给出可逐项读出的完整 2×4 矩阵，并保留缺失事实。

由柱值直接计算，PCIe 上 arxiv 的 0.89/0.61−1=45.90%，ShareGPT 的 0.82/0.62−1=32.26%；正文报告为 46% 与 30%，可能因为柱图值经两位小数取整。为了不制造精度，后续结论沿用正文 46% / 30%。同样，vLLM PCIe 约为 NVLink 的 60%，而 Seesaw 拉到 82%–89%，说明主要价值不是超越高速互连，而是在低带宽环境接近高速互连的吞吐（§6.4，PDF p.9）。

6.3 为什么没有五基准×六方法

论文只公开两个真实数据集、一个 vLLM baseline 和若干固定并行配置；Fig. 10 的各模型/数据集柱子没有印出精确数值，只给出汇总 speedup。若从图高估读并填满矩阵，会制造不存在的精度。因此此处明确：论文未报告可复核的五基准×六方法绝对吞吐矩阵，也未报告 tokens/s 或 requests/s 的完整表格；我们能确认系统在其目标场景中相对最佳固定配置占优，却不能计算单位 GPU 成本、能耗或集群 TCO。

7. 逐层消融、敏感性与相变

7.1 机制级 breakdown

Fig. 12（PDF p.9）用 CodeLLaMA-34B、4×A10、arxiv-summarization 分解 prefill、decode 与 mixed batch：PP4 的 prefill 最快，TP4 的 decode 最快，Seesaw 用 P4→D4 同时接近两阶段的最佳值；最佳静态 vLLM 是带 chunked prefill 的 TP2PP2。作者把差距归因于两点：chunked prefill 仍会留下纯 decode step；TP2PP2 的 prefill 又慢于 PP4。但 Fig. 12 没有在柱上给出精确毫秒或吞吐数字，因此不能量化“重分片”“tiered KV”“异步搬运”各自贡献多少，也不能声称某一个组件贡献占比。

论文没有标准的逐组件 full → −async → −tiered → −reshard 消融表。能观察到的是系统路径对比，而非因果隔离。于是可以推出“联合系统优于最佳静态配置”，不能推出“tiered buffer 单独贡献 X%”或“异步管线隐藏 Y% 开销”。

7.2 输入/输出比的相变

Fig. 13（PDF pp.9–10）在 70B、8×A10 上固定输入 3,000 tokens 并改变输出长度。输出仅 1 token 时，PP8 与 Seesaw 相近，TP4PP2 因通信更慢；输出增长后，PP8 的 decode 权重重复加载代价迅速显现，最优固定配置先转为 TP2PP4，最后在 decode 主导时转为 TP4PP2。Seesaw 跨整个比例范围都高于固定策略。这里真正的相变是“prefill 通信主导 → 混合阶段 → decode 权重带宽主导”，不是某个魔法超参的单调收益。

图中没有给每个长度点印精确数值，故报告不估读转折发生在第几个输出 token；只能确认最优策略顺序和定性趋势。真实变长请求混在一批时，作者推断动态适配会更有利，但没有另设随机长度分布的显著性实验来证明该推断。

7.3 互连带宽敏感性

Fig. 14（PDF p.10）覆盖 PCIe 带宽的 0.1×–50×：低带宽时 PP 最好，高带宽时 TP 最好，Seesaw 在全范围优于固定策略。需要强调的是，这不是部署 0.1×、1×、50× 多套网络得到的实测；作者先在 34B、8×A10、arxiv workload 上测量并 trace all-reduce，再“mutate all-reduce time”投影吞吐。因此能推出模型对带宽变化的预期方向，不能把曲线当作真实多网络端到端证据。

7.4 超参与统计显著性

论文报告调优 vLLM 的 chunk size，但没有公开完整搜索网格、最终每个组合的 chunk size，也没有报告 CPU KV 缓冲阈值、prefetch 深度、pinned buffer 数量的敏感性。CPU KV 总量实际上影响切换频率与等待时延，却没有单独 sweep。

统计方面，论文未报告随机种子、重复次数、均值±标准差、置信区间、误差条或显著性检验。系统吞吐通常方差较小，但这不能替代报告；特别是 13% NVLink 增益是否稳健、云实例噪声是否改变排序，都无法从单点图判断。故 1.36× 是被观察到的实验汇总，不是带置信区间的总体效应估计。

8. 相关工作：问题来源与技术来源链

8.1 vLLM / PagedAttention：先把 KV 内存碎片问题变成分页问题

解决什么。 vLLM 通过 PagedAttention 把 KV cache 分成固定块，做到近零浪费并跨请求共享；论文摘要报告在相同延迟水平下相对 FasterTransformer/Orca 提升 2–4× 吞吐（vLLM PDF p.1）。它提供了 continuous batching 与高效 KV 管理这一“地基”，也是 Seesaw 的唯一主 baseline。

遗留缺口。 PagedAttention 解决“KV 放不下/碎片多”，却不解决同一静态 TP/PP 在 prefill 和 decode 的目标相反。更大 batch 仍会受到固定并行拓扑的通信与权重带宽权衡。

Seesaw 如何回应。 Seesaw 直接复用 vLLM 模型实现并扫其固定并行配置，然后把优化轴从“页式 KV”推进到“阶段级拓扑变化”。

设计如何传递。 vLLM 的 block 化、continuous batching 思想传到 Seesaw 的 GPU KV slot 管理；Seesaw 再把 KV 的归属从单一 GPU layout 扩展到 CPU shared-memory 中间态。

8.2 DistServe：把两阶段拆到不同 GPU，但面向 goodput/SLO

解决什么。 DistServe 空间拆分 prefill 与 decode，独立规划资源和并行策略，并以 TTFT/TPOT 约束下的 goodput 为目标；摘要报告可服务 7.4× 更多请求或把 SLO 收紧 12.6×，同时超过 90% 请求满足约束（DistServe PDF p.1）。

遗留缺口。 空间拆分需要每个阶段各自放下模型，资源粒度粗。Seesaw 的 70B 案例表明 8×40 GiB 只能 4/4，造成 prefill 比 decode 快 6×以上、4 卡 decode 仅为 8 卡的 15%。

Seesaw 如何回应。 它做时间拆分而非空间拆分：全部 GPU 先共同 prefill，再共同 decode；因此小集群没有永久的 4/4 资源锁定。

设计如何传递。 DistServe 把“阶段异质性”确立为系统边界；Seesaw把这个边界进一步变成可切换的模型 shard 布局。但两者目标不同：DistServe 优先 SLO，Seesaw优先 offline 吞吐。

8.3 Sarathi-Serve：不拆集群，而是把 prefill 切块塞进 decode

解决什么。 Sarathi-Serve 用 chunked prefill 与 stall-free batching 形成均匀迭代，降低 pipeline bubble；摘要报告 Mistral-7B 单 A100 serving capacity 2.6×、Yi-34B 双 A100 3.7×、Falcon-180B PP 场景最高 5.6×（Sarathi PDF p.1）。

遗留缺口。 chunk 太大时仍有 decode-only step，太小时 kernel 效率下降，而且固定 TP/PP 仍需同时服务两阶段。Seesaw 的 §7.1 明确指出 chunk size 的两难。

Seesaw 如何回应。 baseline 已启用并调优 chunked prefill；Seesaw 仍在纯 decode step 用 TP 配置、prefill 用 PP 配置。它不是绕开 Sarathi，而是在其仍遗留的固定拓扑上加一层阶段重分片。

设计如何传递。 Sarathi 的“把阶段调度问题显式化”传到 Seesaw 的 scheduler；未来最自然组合是 chunked prefill 负责细粒度 latency/throughput 平衡，resharding 负责剩余纯阶段的并行拓扑。

8.4 Mooncake：把 CPU/DRAM/SSD/NIC 变成全局 KVCache 池

解决什么。 Mooncake为空间分离的 prefill/decode 构建 KVCache-centric 全局缓存与调度器；arXiv v4 摘要报告仿真场景吞吐最高 +525%，真实 workload 可处理 75% 更多请求（Mooncake PDF p.1），FAST 正式页另报告真实 trace 容量提升 59%–498% 与数千节点部署。

遗留缺口。 它假设大规模服务集群、复杂存储/网络层和 SLO 调度，小型 commodity GPU 节点不一定能承担同样架构。

Seesaw 如何回应。 Seesaw 只用共享 CPU 内存作阶段切换中间态，面向单节点/小集群的有限 GPU 与慢连接；这牺牲在线延迟，却显著降低资源拆分粒度。

设计如何传递。 Mooncake 与 Seesaw共同表明 KV 不再只是 GPU 内部缓存，而是调度状态。Mooncake 将其变成跨节点存储对象，Seesaw将其变成跨并行布局的重分片媒介。

9. 非线性技术演进树与跨论文对标

                              ┌─ DistServe ── 空间拆 P/D、独立 SLO 规划
阶段异质性 ──────────────────┤
                              └─ Mooncake ─── 全局 KVCache 池、跨节点复用
                                      │
KV 内存可管理 ─ vLLM/PagedAttention ──┼──────────────┐
                                      │              │
调度平滑化 ─ Sarathi-Serve ─ chunked prefill         │
                                      │              ▼
                                      └──────► Seesaw
                                         时间复用全部 GPU
                                  PP-prefill ⇄ TP-decode
                                      │
                                      ├─ tiered CPU KV
                                      ├─ async resharding
                                      └─ transition-minimizing schedule

演进动力有三次转折。第一，从“模型能不能放下”转向“KV cache 能否不浪费”，vLLM 让 batch 扩大。第二，从“统一请求流水线”转向“prefill/decode 资源异质”，DistServe/Mooncake 让阶段成为独立调度单元。第三，从“阶段必须占不同 GPU”转向“同一 GPU 集合可随时间改拓扑”，Seesaw 用切换成本换资源粒度。Sarathi 走的是另一条非线性分支：通过合并阶段减小干扰，而非分离阶段；Seesaw 证明即便用了 chunked prefill，固定拓扑仍有残余损失。

这些倍率不能横向判定谁“最好”，因为 baseline、模型、硬件、SLO 和指标不同；表格用于比较设计目标和证据形态，不用于做跨论文排行榜。

10. 真正贡献、可复用设计与迁移潜力

Seesaw 的真正贡献不是“CPU offload”本身，也不是再做一个并行搜索器，而是把并行布局纳入请求生命周期：拓扑不再是模型部署时一次决定的静态属性，而可以随阶段切换。这个抽象使“prefill 更怕通信、decode 更怕权重带宽”的事实能够被系统直接利用。

最可复用的三个设计是：其一，用完整 CPU KV image 作为不同 shard layout 之间的规范中间表示，避免 GPU 间复杂 all-to-all；其二，把 GPU→pinned 与 pinned→shared 分开，绕过 shared memory 无法 pinned 的限制；其三，用“CPU KV 满/空”把切换次数与 batch 大小绑定，使开销能被阶段批次摊薄。它们可以迁移到推理引擎、异构加速器和服务编排中。

迁移到量化模型时，权重体积变小会降低 decode 的权重带宽占比，也会改变 TP 的收益，必须重新选择 c_d；迁移到 MoE 时，expert routing 和 all-to-all 可能取代 all-reduce 成为主瓶颈，CPU 重载专家 shard 也更复杂；迁移到 speculative decoding 时，每次 decode 处理多个 draft token，decode 算术强度上升，prefill/decode 边界变弱；迁移到 prefix caching 时，CPU KV store 需要维护共享前缀引用与一致性。也就是说，Seesaw 的“阶段自适应”思想可迁移，但其论文中的具体 PP→TP 策略不能直接照搬。

11. 论文自述限制

1. 吞吐优先、延迟受损。 作者明确写出 chunked prefill 可同时服务吞吐与延迟，而 Seesaw “prioritizes throughput at the cost of increased latency”（§7.1，PDF p.10）。所以结论只覆盖 offline，不应外推到交互式聊天。
2. 低带宽/资源受限场景最有利。 A10 的平均 1.45× 高于 L4 的 1.29×，NVLink 上 ShareGPT 只剩 13%；作者据此把适用点放在 commodity GPU 与慢互连（§6.2、§6.4–6.5，PDF pp.8–10）。
3. 动态空间不含 DP。 因为改变 DP 会改变模型副本与 KV 内存份额并增加移动，系统只动态调 TP/PP（§4.1，PDF p.6）。因此“dynamic model resharding”并非任意并行维度的全局最优器。

12. 独立批判：证据—推论链

1. [比较公平性] 因为主实验只与 vLLM 0.5.4 比，DistServe、Sarathi-Serve、Mooncake 和 TensorRT-LLM 没有同硬件 head-to-head（§6.1，PDF p.8），所以 1.36× 只能解释为相对这版调优 vLLM 的收益，不能证明超过全部同期系统。
2. [可复现性] 因为截至核验日未找到 Seesaw 官方代码、配置文件或复现实验脚本，而论文又没有列出每个 workload 的最终 chunk size 与所有 c_p/c_d 选择，所以 独立研究者难以复核 1.06–1.78× 范围是否依赖隐藏调参。
3. [指标完整性] 因为论文以端到端 throughput 为唯一主指标，未报告绝对 requests/s、tokens/s、TTFT、TPOT、P50/P99 或 SLO attainment，所以 无法把 36% 平均相对增益转换为容量规划、用户体验或每美元收益。
4. [因果归因] 因为 Fig. 12 没有 −tiered buffer、−async pipeline、−transition minimization 的逐组件数值，只有整套系统与固定并行路径，所以 能确认联合设计有效，却不能知道重分片选择本身是否压倒了辅助机制。
5. [外部有效性] 因为评测只含 15B/34B/70B 的 FP16 dense GQA 模型，没有 MoE、量化、speculative decoding 或 prefix cache，而这些技术会改变权重带宽、KV 占比和通信形态，所以 不能假设 PP-prefill/TP-decode 的排序在现代推理栈中保持不变。
6. [资源会计] 因为实验为每张 GPU 配置 80 GiB CPU memory，8 卡节点就是 640 GiB 主机内存预算，却没有把 DRAM/NUMA/CPU copy 带宽与能耗计入成本，所以 “commodity GPU 更划算”的推论可能把代价转移到了主机侧。
7. [带宽敏感性] 因为 0.1×–50× PCIe 曲线通过修改 trace 中 all-reduce 时间投影，而不是在多种网络上运行，所以 该结果验证了模型内推，不等价于验证拥塞、NUMA、DMA 竞争下的端到端可移植性。
8. [统计可靠性] 因为论文没有重复次数、误差条或显著性检验，所以 尤其是 NVLink 上 13% 的中等增益无法与云实例抖动、热状态和调度噪声严格区分。

13. 可操作的开放挑战

13.1 理论

实验空白 T1：在线最优切换策略。 在相同到达序列与硬件上比较 (A) 满/空阈值 Seesaw、(B) 基于剩余 KV/预计输出长度的 MDP policy、(C) oracle 动态规划；横轴扫请求到达率和输出长度变异系数，统一报告 throughput、平均等待、P99 TTFT、切换次数与搬运字节。目标是估计 Seesaw 的阈值策略距 Pareto 前沿多远。

实验空白 T2：包含重分片成本的解析模型。 比较原式、加入 CPU 带宽/NUMA/reshard 项的新模型与实测；在 A10/L4/A100 上做 c_p×c_d×batch×CPU-KV-size 全因子实验，用 MAPE 和配置 top-1 命中率评估。若新模型不能更好选配置，就不能声称理论项解释了系统收益。

13.2 工程应用

实验空白 E1：公平的同栈对比。 在同版 vLLM backend、同 tokenizer、同 prompt/output trace、同 8 卡节点上比较 Seesaw、调优 vLLM chunked prefill、Sarathi-Serve、DistServe；同时报告 tokens/s、requests/s、P50/P99 TTFT/TPOT、GPU/CPU 内存、PCIe bytes、能耗和故障恢复。这样才能判断重分片相对空间拆分与阶段合并的净收益。

实验空白 E2：CPU 资源压力测试。 固定 GPU 与 workload，扫每 GPU CPU KV 预算 10/20/40/80/160 GiB、单/双 NUMA、PCIe ×4/×8/×16；比较 Seesaw 与“不用 CPU tier 的最佳静态配置”。若收益在 80 GiB 以下消失，部署建议必须显式把主机内存列为前置条件。

实验空白 E3：现代推理组合。 对 FP16、INT8、INT4、MoE、EAGLE speculative decoding 分别重跑 c_p/c_d 搜索，比较静态、Seesaw、Seesaw+chunked prefill。观察 decode 算术强度升高后切换是否仍有正收益，并把最优策略改变作为主要结果，而非只报总吞吐。

13.3 新兴方向

实验空白 N1：跨请求 prefix/KV 复用。 比较 Seesaw-HND full copy、copy-on-write shared prefix、Mooncake-like global KV object，使用前缀共享率 0%/25%/50%/75% 的 trace；指标包括搬运字节、命中率、吞吐、首 token 时延和一致性错误。它检验 CPU 完整 KV image 是否会重复搬运共享前缀。

实验空白 N2：多租户与弹性 GPU。 在抢占、GPU 故障与动态租户负载下比较静态 vLLM、Seesaw、DistServe；测重分片恢复时间、KV 丢失率、尾延迟和有效吞吐。Seesaw 的 CPU 中间态可能成为恢复锚点，也可能成为单机故障域，必须以故障注入区分。

14. 近期工作雷达

1. ThunderServe（MLSys 2025）：从单节点重分片扩展到云上异构实例与成本感知调度；适合与 Seesaw 比较“节点内拓扑适配”和“节点间资源适配”能否联合。
2. LServe（MLSys 2025）：以 unified sparse attention 降低长序列 KV/计算压力；若 attention 项缩小，Seesaw 解析模型中的阶段平衡会重新移动。
3. FlashInfer（MLSys 2025）：把可组合 attention kernel 与调度原语交给服务栈；它可能降低固定配置的 kernel 损失，是更强 backend 对照。
4. NEO（MLSys 2025）：在线推理的 CPU offloading，与 Seesaw“CPU 只作中间态”的选择形成直接对照；可检验 CPU 算力利用是否优于纯搬运。
5. SOLA（MLSys 2025）：以 state-aware scheduling 追求 SLO attainment；它代表 Seesaw 若要从 offline 走向在线必须补上的状态和尾延迟控制。
6. WaferLLM（OSDI 2025）：在 wafer-scale 互连上研究 LLM 推理；当通信带宽极高时，Seesaw 预测 TP 占优，这篇工作提供完全不同硬件点的参照。
7. Context Parallelism for Scalable Million-Token Inference（MLSys 2025）：长上下文把 KV/attention 项推到主导位置，可能需要把 CP 纳入 Seesaw 目前只有 TP/PP 的动态空间。

15. 结论

Seesaw 值得看的地方，是它把“并行策略选择”从部署参数提升成推理阶段状态：在低带宽小集群上，prefill 用通信友好的 PP，decode 用权重带宽友好的 TP，再用 CPU KV tier 和异步 copy 把切换成本藏起来。论文在 A10 上给出 1.45× 几何平均、1.78× 最高，A10+L4 总体平均 1.36×；A100 PCIe 上把 vLLM 相对 NVLink 的约 60% 吞吐拉到 82%–89%（Fig. 10–11，PDF pp.8–9）。

但最稳妥的结论应当窄一些：这是一套针对 offline、throughput-first、低带宽互连 的有效联合设计，不是在线服务的全面替代。没有代码、绝对吞吐、延迟/SLO、逐组件消融、现代模型组合和统计区间，使 1.36× 还不能直接转化为生产容量承诺；最关键的后续实验，是让它与 DistServe、Sarathi-Serve 和现代 vLLM 在同一栈、同一 trace、同一延迟约束下正面对比。

索引状态： 已更新 ml-report-index.md，追加本报告日期、领域、标题、venue 与一句话结论。
资料说明： MLSys 正式页与 arXiv 均写作 Wei Zhao；下载 PDF 的字体抽取将其误识别为 “Wei hao”，本报告采用正式元数据。所有无法核实的代码、数据、项目页与核心论文视频均明确标注，未以第三方镜像替代官方入口。
视觉核验说明： 已实际调用 Playwright，但本机 /usr/bin/chromium、/opt/pw-browsers 及 Playwright 缓存均无 Chromium 可执行文件；遵照“不运行 playwright install”约束，没有联网安装浏览器，因此无法完成真实的浅色/深色/移动端截图检查。已改用 Warm Editorial 确定性验证器（0 warning）、HTML 语义检查与响应式 CSS 静态审查；这不能完全替代浏览器像素级核验。