TokenDance: Scaling Multi-Agent LLM Serving via Collective KV Cache Sharing

framework 2604.03143
multi-agent-servingkv-cache-sharingposition-independent-cachingllm-inferenceagent-systems
← Synthesis ← framework Survey Source ↗

TokenDance: Scaling Multi-Agent LLM Serving via Collective KV Cache Sharing #

Zhuohang Bian, Feiyang Wu, Chengrui Zhang, Hangcheng Dong, Yun Liang, Youwei Zhuo (Peking University, SJTU) | 2026-04 | arXiv:2604.03143 Category: framework | Tags: multi-agent-serving, kv-cache-sharing, position-independent-caching, llm-inference, agent-systems Read: 2026-04-18

Core Contribution #

把 multi-agent All-Gather round 当作 KV Cache 复用的第一类单位，将 N 个智能体在同一轮中的共享内容的 PIC 复用代价从 O(N) 摊销到 O(1)，并用 Master-Mirror 块稀疏 diff 将 per-agent 存储压缩 11–17×，使同一张 A100 可支撑最多 2.7× 的并发智能体数。

Summary #

Motivation：以 GenerativeAgents、AgentSociety 为代表的多智能体模拟系统按"同步轮"推进：中心调度器收集所有 agent 上一轮的输出 $\mathcal{O}^t = \{O_1^t, \ldots, O_N^t\}$，再把完整集合分发给每个 agent 作为新一轮输入。每个 agent 的提示形如 $P_i^{t+1} = H_i^t \,\|\, \Pi_i(\mathcal{O}^t)$：前缀是自己的私有历史 $H_i^t$，长度各异；后段是同一组共享输出块，但在不同 agent 里出现在不同的绝对位置。这种 All-Gather 通信结构导致：①prefix caching 一旦私有历史不同就彻底失效；②PIC（CacheBlend/EPIC 等）虽然能在任意 offset 复用，但必须对每个 agent 单独做一次 RoPE 旋转+重要位置选择，N 个 agent 就要跑 N 遍；③即便成功复用，最终 N 份 KV Cache 仍然是 91–97% 块级相同的密集副本，直接撑爆显存。

Method：TokenDance 把优化单位从"单请求"提升到"一整轮 All-Gather"。三大组件：(1) Round-Aware Prompt Interface 用保留分隔符 token 打标 logical block 边界，让运行时可以按 segment 做 content-based hashing，识别跨 agent 的共享块；(2) Collective KV Cache Reuse：KV Collector 把同一轮中 prompt 长度、cache span、slot mapping 兼容的请求组成一个 group，layer-wise 同步推进，在 check layer 上把 N 个请求的 Q/K 拼成一个大 batch 做一次 RoPE + 一次 key-difference 分析，选出的 important positions 集合直接复用到后面所有层；(3) Diff-Aware Storage + Fused Restore：一轮里挑出偏差最小的 Master 保留完整 cache，其余以 block-sparse K/V diff 表示，仅记录差异块索引和值；回读时用 ping-pong buffer 在 Master 传输路径中就近 merge diff 并做 RoPE recover，避免显式构造 dense Mirror。

Results：在 A100-80G 上用 Qwen2.5-7B/14B 评测 GenerativeAgents 与 AgentSociety：

Key Findings #

Key Figures #

Figure 1: All-Gather Prompt Structure #

Figure 1: All-Gather Prompt Structure

What it shows：三个 agent 在同一轮中的 prompt 组成——各自的私有历史 $H$（长度不一）加上同一组共享输出块 $O_1, O_2, O_3$，但因为 $\Pi_i$ 给每个 agent 的块顺序不同，同样的 $O_1$ 在不同 prompt 中出现在不同的绝对 offset。

Why it matters：这张图直接解释了为什么 prefix caching 在 multi-agent 场景彻底失效——前缀 bit 对 bit 相同是 prefix caching 的先决条件，而 $H$ 长度不等就把对齐打破了。它也是 TokenDance "round-aware" 设计的出发点：内容相同但位置不同，就必须用 content-based segment hashing 而不是 position-based chunk hashing。

Detailed description：左侧列出 3 个 agent 的完整 prompt，每个 prompt 顶部是长度不一的 $H_i$ 块（浅色），底部是标注了 $O_1/O_2/O_3$ 的共享块（三种深色），图中用竖直虚线对齐同色块展示它们在 token 轴上的偏移差异。最右侧的标注强调"same content, different absolute positions"。

Figure 2: Motivation — Scaling Gap #

Figure 2a: Per-request latency under multi-agent vs independent loads

Figure 2b: Peak KV Cache usage comparison

What it shows：同样 250 个子请求，multi-agent workload（10 sessions × 25 rounds）与 250 个独立 request 在 A100-80G + Qwen2.5-14B 上的对比。左：latency-vs-request-index 曲线，multi-agent 从头就顶着 136 s 的 P99，而独立请求从低位逐渐爬到 125 s；右：peak KV Cache footprint，multi-agent 占 41.5 GiB（99.3% pool），独立请求只占 24.8 GiB（59.2%）。

Why it matters：用实测说明"即便总 workload 一样，只要 cache 需要跨轮 coexist 就会把内存池撑爆并触发 preempt/swap"。这是 TokenDance 把 storage 列为一等公民的经验证据——就算 prefill 再快，不砍每 agent 存储都救不了 scaling。

Detailed description：(a) 横轴是 request index (0-250)，纵轴是子请求 latency，两条曲线颜色区分 multi-agent vs independent；(b) 条形图展示两种 workload 的 peak KV Cache 占用，标注绝对值与百分比。

Figure 5: TokenDance Overview #

Figure 5: TokenDance overview — three components

What it shows：TokenDance 的三块组件并列：①round-aware prompt interface 保留块结构；②collective KV Cache reuse 把 N 个请求组成 group 做一次 RoPE+diff；③diff-aware storage + fused restore 把 per-agent cache 压成 Master + sparse diffs。

Why it matters：一图说清论文的"先暴露结构 → 共享计算 → 共享存储"三段式设计原则。它也明示了本文的 design rule："把 round structure 留给 runtime 看见"和"每个请求一份语义 cache，但共享所有真正公共的东西"。

Detailed description：顶部是 application 侧的多 agent prompts（带 separator token 标注分段），中部是 runtime 的 block-level scheduler 把 N 个兼容 request 汇入 KV Collector；底部是 storage 层，画出 Master 与 Mirror 的关系以及回读时的 fused restore 路径。各组件之间用带标注的箭头表示数据流（token → KV → diff）。

Figure 7: Collective KV Cache Reuse (核心创新) #

Figure 7: Collective KV Cache Reuse

What it shows：三种路径对比。T1：vLLM 从零算所有层；T2：per-request PIC，N 个 agent 各自 RoPE + diff + selective recompute；T3：TokenDance 把 N 个请求的 Q/K 拼成一个 batch 做一次 RoPE，在 check layer 做一次 important-position 选择，后续层直接用这个集合刷新每个请求的 K/V。

Why it matters：这是 compute 侧的核心 diagram。它展示了"从每请求摊销 → 每轮摊销"的粒度跃迁，也呼应了本文的"amortize group-wide work once per round"原则。Section 6.3 的 2.57× speedup 就是这个 diagram 的量化结果。

Detailed description：左侧画出 3 个 agent 的 prompt（共享块颜色相同，排列顺序不同）；右侧是三条 compute timeline：T1 横排 3 条独立 prefill；T2 横排 3 条 PIC reuse（RoPE + diff + recompute 被画成重复色块）；T3 把 3 个 agent 的操作合并，RoPE 和 diff 只画一遍（大色块），重算部分保留每请求独立。

Figure 8: Diff-Aware Storage (Master-Mirror) #

Figure 8: Master-Mirror Diff-Aware Storage

What it shows：左边 3 份近乎相同的 recovered KV Cache，仅在 10–20% 位置不同；右边是 TokenDance 的存储布局——Master 保留一份完整 cache，Diff 2 / Diff 3 只记录与 Master 不同的块的索引和 K/V correction。

Why it matters：这是 memory 侧的关键 figure。它直接对应 11–17× 的压缩比来源，也解释了为什么要和 collective reuse 共享同一个 reuse plan（reuse plan 里有 Master 选择和 important positions，直接被存储层消费）。

Detailed description：左侧 3 个 agent 的 cache 以同色/异色格子表示共享块/私有差异；右侧 Master 仍然是密集张量形状，Diff 2/3 缩成块稀疏结构（只有几个高亮块 + 索引列表）。箭头标注 "Diff = block-sparse (indices, values)"。

Figure 10: Main Scaling Result #

Figure 10: Scaling capacity — supported agents vs QPS

What it shows：2×2 布局（GenerativeAgents/AgentSociety × Qwen2.5-7B/14B）。每格左图是 round latency vs agent count（QPS=10，虚线 1500 ms SLO），右图是"最多能撑住 SLO 的 agent 数 vs QPS"。TokenDance（橙）在所有配置、QPS 全程都高于 vLLM、CacheBlend Ordinary Path、CacheBlend 三个 baseline。

Why it matters：论文最重要的一张图。它证明了本文的核心 claim："在同样 SLO 下能跑的 agent 更多"。特别突出了两个规律：①agent 多了 TokenDance 的优势更大（因为复用和去重都是 per-round 摊销）；②模型越大优势越明显（cache per agent 翻倍，去重绝对收益翻倍）。

Detailed description：4 个子图，每个含两条面板：左侧折线图（x=agent count 1–10, y=round latency, 4 条曲线），右侧折线图（x=QPS 1–16, y=max agents under SLO）。TokenDance 橙色曲线在所有子图都位于底部（latency）或顶部（capacity）；SLO 虚线横跨左面板。

Key Tables #

Table — Capacity Gains (从正文和 Figure 10 抽取) #

WorkloadModelMetricvLLM prefixCacheBlendTokenDance
GenerativeAgentsQwen2.5-7BMax agents @ QPS=16248
GenerativeAgentsQwen2.5-14BMax agents @ QPS>81≤24
AgentSocietyQwen2.5-7BMax agents @ QPS=4334
AgentSocietyQwen2.5-14BMax agents @ QPS=16<1<12

Takeaway：2.7× 并发 agent 数的提升来自 compute 摊销 × 存储压缩 两侧收益的乘积；14B 上优势更大，因为 per-agent KV footprint 翻倍。

Table — Storage Compression #

ModelCompression ratioAvg changed blocks per MirrorImplied capacity for N=10
Qwen2.5-7B11.2×53.2 / (500–700)1.8 caches (vs 10) — 5.6× ↓
Qwen2.5-14B17.5×59.6 / (500–700)1.5 caches (vs 10) — 6.7× ↓

Takeaway：Mirror 只需 Master 的 5.7–8.9%，模型越大压缩越狠（因为差异块数目近似不变，但 per-token cache 变大）。

Table — Accuracy #

WorkloadScenarios (ID)Δ rounds-to-first-divergence
GenerativeAgentsMeet and Greet (1), Valentine's Day (2)0.0%
GenerativeAgentsElection Discussions (3), Winning the Election (4)3.3–11.9%
AgentSocietyInformation Outbreak (5)0.0%
AgentSocietyPre-Landfall (6), Hurricane (7), Economic Stabilization (8)3.3–11.9%

Takeaway：所有偏离都是底层 CacheBlend PIC 选择性重算的数值扰动放大，TokenDance 的 collective grouping 只变执行顺序不变数值结果。

Limitations #

Infrastructure Impact #

Deep Analysis (framework) #

0. 时代定位与设计约束（继承 Phase 2，补深） #

时代定位：2023–2025 年 LLM serving 的三波浪潮——PagedAttention（空间）、Continuous Batching（时间）、Chunked Prefill（P-D 交织）——已经把"单请求串行模型"里能砍的 overhead 几乎砍完。紧接着的是 disaggregated serving（Mooncake、Splitwise）和 PIC（CacheBlend、EPIC、KVLink、KVComm）这两个 2024–2025 的方向，但它们都停留在"单请求"视角。TokenDance 站在 2026 年回望这条时间线，指出下一个系统性红利来自"请求间结构"而不是"请求内结构"——把 All-Gather 作为第一类 schedule 单位。

为何不可 X（约束推导）：

替代方案在多 agent All-Gather 里是否可行？不可的根本原因
Prefix caching（vLLM/SGLang 默认）❌需要 prefix byte-aligned 相同；$H_i$ 长度各异后，$O_1$ 的绝对 offset 在不同 agent 里不同，token-0 对齐的 trie 直接 miss。
Per-request PIC（CacheBlend）⚠ 部分可行能匹配任意位置，但 RoPE 旋转 + diff 分析的复杂度与请求数成线性关系，N 个 agent 就是 N 次重复。
完全共享单份 KV❌$H_i$ 产生的 context 会污染后续 attention（跨 agent 信息泄漏）；而且 RoPE 作用后 K 的位置依赖不同，语义上就是不同的张量。
KV 去重 = CDN 式的内容寻址存储⚠ 粒度不对若按 token 级 content-hash 去重，metadata 爆炸且每 hit 需要跨表查询；按 block 级又不能直接发 attention（RoPE 位置不同）。
offload 到 CPU/SSD + prefetch（Mooncake/CacheGen）⚠ 单向优化对 idle cache 有效，但对"必须在线的 N 份 cache 同时进 attention"无帮助；且 round-to-round 的高重用率意味着 prefetch 也只是把重复数据搬来搬去。
更高级的 eviction/quant（H2O/KIVI）✅ 正交可与本文正交叠加，但不解决"N 份近乎相同的 cache 同时 alive"这个 root cause。

破局：一句话的"aha"——"N 个 agent 的 prompt 里，$O$ 块 bit-level 相同但 position 不同；位置差异可以通过一次 group-wide RoPE 校正，内容冗余可以用 block-sparse diff 压缩；所以 compute 和 storage 两侧都可以从 per-request 升级到 per-round"。

核心技术壁垒：Reuse plan 的跨组件流转。看似简单的"挑一个 Master + 其他人存 diff"，实际上要求：①collective reuse 在 check layer 的 important-position 集合必须精确反映每个 Mirror 相对 Master 的差异分布（否则 diff 里要么遗漏要么冗余）；②Diff backend 要在 write 时消费 plan、在 read 时按 block 产出 indices+values；③fused restore 的 ping-pong buffer 与 diff 元数据的对齐、与 attention tile 对齐、与 paged memory 的 slot 对齐——三个对齐同时满足。这套"plan → store → restore"的端到端一致性，比单独实现任一组件都要难，作者用 3K 行 Python + 500 行 CUDA 才把四个子系统粘起来。

设计绑定批判：本文 implicitly 绑定了 (i) All-Gather 通信模式（若实际是 DAG/chain-of-thought 会失效），(ii) RoPE 位置编码（方法强依赖 RoPE 的数学可逆性），(iii) CacheBlend 风格的 selective recompute（提供"位置集合→修正 K/V"的语义），(iv) LMCache + vLLM V1 的 paged KV 数据模型（block 对齐、slot mapping 可见）。任何一条松动都要重写一大块。

1. System Scope #

2. Architecture & Data Flow #

2a. End-to-End Data Flow #


[Agent t outputs {O_1..O_N}] → [Scheduler: assemble prompts with separators]
    → [Round-Aware Interface: segment tokenization]
    → [KV Collector: group compatible requests]
    → [Layerwise collective prefill: shared RoPE + batched diff @ check layer]
    → [Per-request selective recompute at important positions]
    → [Reuse plan: Master + per-request diff metadata]
    → [Diff-Aware Storage: write Master dense + Mirrors as block-sparse]
    → [Decode phase: standard per-request autoregressive]
    → [Next round: fused restore (ping-pong buf) → attention → agent t+1 outputs]
StageInput → OutputLocationLatency scaleData format & size
ApplicationAgent outputs $\mathcal{O}^t$CPU< 1 msstring blocks
Prompt assembly$\mathcal{O}^t + H_i^t$ + separatorsCPU< 1 mstoken IDs, len $L_i$
Segment hashingtokens → segment IDsCPU<1 mshash table per segment
GroupingN requests → K compatible groupsCPU~ msgroup metadata
Collective prefillQ/K per layer → corrected K/VGPU HBM~100s ms$[N, L, H, D]$ batched
Reuse planper-request deviation scoresGPU→CPU< 1 msindex lists
Diff serializeMirror dense → (indices, K/V)GPU→CPU/Storage~mssparse blocks
Fused restoreMaster chunk + diff → paged KVGPU HBM0.1–0.6 ms/mirror/layerping-pong buffers
Attention + decodeKV → next tokenGPU HBMTPOT scalestandard

2b. Data Movement Hotspots #

  1. Collective Q/K tensor concatenation（GPU HBM 内部）：把 N 个请求的 Q/K 拼成一个大 batch，每层一次；不跨 PCIe，但对 HBM bandwidth 敏感。
  2. Diff serialize 与回读（GPU ↔ CPU/LMCache 后端）：每 Mirror 每层一条 (indices, values) 记录，N-1 个 Mirror × L 层是写入端的高频数据移动；靠 block-sparse 把绝对体积从 dense 的 100% 压到 5–15%。
  3. Fused restore 的 ping-pong 传输（Storage → GPU scratch → paged KV）：是 online 关键路径。Algorithm 1 显式用两块 buffer 交替 load/compute 以隐藏 transfer-compute latency；作者特别提到这一步不 overlap 就会吃掉压缩红利。

    4. 3. Design Space & Constraint Analysis (framework 维度补深) #

    3a. Alternative Approaches #

    1. Per-request PIC（CacheBlend/EPIC） — 已经被采用，但 overhead 与 N 线性增长。
    2. Token-level content hashing — 理论上能识别任意位置共享，但 metadata 爆炸、hash 冲突处理复杂、无法与 paged memory 的 block 边界对齐。
    3. Agent-aware scheduling only（Parrot/Autellix/Tokencake） — 调度时间而不触碰 cache 内容；无法减少 compute 或 storage。
    4. KV quantization / eviction（KIVI/H2O） — 缩小单份 cache，不减少 cache 数目。
    5. Disaggregated cache pool（Mooncake） — 跨节点共享 pool，但同一轮 N 份 active cache 必须同时驻留 HBM 才能 run attention，pool 不解决"同一时刻 peak"。

      6. 3b. Feasibility Matrix #

      Alternative减少 compute?减少 storage?与 paged KV 兼容?精度损失?
      Per-request PIC❌ N 次重复❌✅轻微（本文承继）
      Token-level content hashing⚠ 有收益但 metadata 爆炸⚠ 随机访问代价大❌❌
      Agent-aware scheduler only❌❌✅❌
      KV quant/evict❌✅ 1.5–4×✅视方法而定
      Disaggregated pool❌⚠ pool 够大但 HBM peak 不变✅❌
      TokenDance (collective + Master-Mirror)✅ 1.2–2.57×✅ 11–17×✅同底层 PIC

      3c. Assumption Audit #

      • A1：同一轮中 $O$ 块占 prompt 大头 — 在 GenerativeAgents/AgentSociety 成立（作者 Figure 2、Figure 3 实测）；若 $H$ 远大于 $O$（长历史短 broadcast），Mirror diff 膨胀、压缩率下降。不确定处：作者 section 6.4 用 "requests diverge more strongly" 一笔带过，没给定量阈值。
      • A2：选个"与 group 结构最接近"的 Master 能使 diff 最稀疏 — 通过 deviation score 挑选；但作者没给该 heuristic 与 optimal Master 的 gap 评估。
      • A3：check layer 选出的 important positions 对所有后续层都适用 — 承继自 CacheBlend 的假设；section 4.2 显式"later layers reuse the important-position set ... without repeating the difference computation"。若某些 layer 的 K 分布与 check layer 偏差大，精度损失被放大。
      • A4：block_size 与 attention tile size 对齐 — 典型 page_size = 16/32 tokens 与 FlashAttention BLOCK_M/BLOCK_N 对齐。切换到 tensor-parallel 或 speculative decode 时对齐需要重调。

      3d. Core Technical Barrier（framework 维度下的再确认） #

      真正难复刻的是 Algorithm 1（Fused Diff Restore） 的在线链路：ping-pong buffer 切换 + 每层按 paged KV slot map 写回 + block 稀疏 merge + RoPE recover，同一条 transfer 里完成。如果任何一个 phase 错位（比如在 swap 前写回、diff indices 与 page boundary 未对齐、RoPE recover 被放在 attention 里而非 transfer 里），就会失去论文观察到的"dense materialization 零次"的关键 invariant，从而 restore latency 回到 dense 的 1.8–2×。这段逻辑藏在 500 行 CUDA/C++ 里，是 TokenDance 的核心壁垒。

      3e. Design Binding Critique #

      • 强绑 LMCache backend：diff backend 是在 LMCache 上 wrap 的，若 serving 栈是 SGLang RadixAttention / TRT-LLM 的 KV manager，Master-Mirror 语义需要在别的抽象下重新落地。
      • 强绑 vLLM V1 scheduler：依赖 V1 的"每 step scan requests"的节奏做 grouping；vLLM V2 的 continuous batching 语义下 group 成员可能在一轮中被 preempt 或 chunk 拆分。
      • 强绑 RoPE：KVLink/KVComm 其实也用 RoPE，但 ALiBi/PI/NTK 或 YaRN extension 下 "rotate + diff" 的数学保证需要重证。
      • 强绑 All-Gather 语义：tree-structured multi-agent 或 partial broadcast 会使 Master-Mirror 退化。

      4. Key Innovations #

      InnovationMechanismBenefitCost/Tradeoff
      Round-Aware Prompt InterfaceApplication 插入 reserved separator token；runtime 用 segment hash 取代 chunk hash让 runtime 识别共享 block需要 application 改 prompt 拼装（一行改动）；非 All-Gather workload 回退
      Collective KV Cache Reusegroup N requests → batched RoPE + batched important-position check → per-request refreshRoPE+diff cost 从 O(N) 摊销到 O(1)对 group 兼容性有约束；fallback path 必不可少
      Diff-Aware Storage (Master-Mirror)1 dense Master + block-sparse diff per Mirror；共享 reuse planper-agent storage −94%, compression 11–17×选 Master 的 heuristic；diff metadata 额外开销
      Fused Diff Restoreping-pong buffer + layerwise transfer + in-place sparse merge + RoPE recoverrestore latency 1.3–2.6× 优于 denseCUDA kernel 实现；对 paged-KV slot map 依赖

      5. Scheduling & Resource Management #

      • Batch formation：在 vLLM continuous batching 之上增加"按 round 结构聚合"的 pre-scheduler。Group 的形成依赖 runtime 每步扫描请求，满足 {same active prompt length, same cached span, disjoint slot mappings} 三约束才并入同组；否则 degrade to per-request。
      • Memory management：继承 paged attention；diff-aware backend 只在 LMCache 存储侧生效。Mirror 占 10–20% dense 空间，因此 KV pool 的有效容量被"放大"同比例。
      • GPU utilization：collective reuse 通过 batched RoPE 增加算术强度（更大 tensor → 更好 MMA 利用），间接帮助 HBM-bound kernel；但 attention 本身仍然是 per-request。
      • Multi-tenancy & priority：论文没深入；本质上和 vLLM 一样，但 round-level grouping 给了"优先保住关键 agent 的 Mirror"这种新的策略空间（未实现）。

      6. Target Scenarios & Workload Characterization #

      ScenarioWorkload patternSLO/GoalWhy baseline fails
      Social simulation (GenerativeAgents)10s agents × 10s rounds, 短私有历史1500ms round latency跨轮 cache 共存 + prefix 失效
      Agent society simulation100s agents × long history同上14B 模型里单 cache 就 ~50 MB，10 agents 直接撑爆
      Multi-agent coding (ChatDev/MetaGPT)少量 agent + 长共享代码库交互延迟本文未直接测，但模式符合 All-Gather（代码被 redistribute）
      RAG + multi-agent tool use外部知识 blocks 在 agents 间共享端到端 latency类似问题，但 retrieval context 可能更异构

      Primary bottleneck：memory-capacity-bound（N 份 cache 撑爆 HBM），次要 compute-bound（PIC 反复劳动）。TokenDance 同时攻两边。

      7. Performance Evaluation & Before-After Comparison #

      7a. Metrics Definition #

      MetricDefinitionUnitDirection
      Round latency完成一轮所有 agent 的端到端时间ms↓
      Max agents @ SLO在 1500ms round SLO 下最多支撑多少 agent—↑
      Compression ratiodense KV size / (Master + diffs) size×↑
      Restore latency / mirror / layer一个 Mirror 在一层上的回读时间ms↓
      Rounds-to-first-divergence与 vLLM 基线相比第几轮首次输出不同rounds↑ (closer to full trace = better)

      7b. Before-After Table #

      OptimizationMetricBaselineAfterGainConditions
      Collective reusePrefill speedup vs serial PIC1×2.57×2.57×10 agents, QPS=1, GenerativeAgents/Qwen2.5-7B
      Collective reusePrefill speedup @ high QPS1×1.3–1.5×—QPS=16
      Master-MirrorKV footprint compression1×11.2×11.2×Qwen2.5-7B
      Master-MirrorKV footprint compression1×17.5×17.5×Qwen2.5-14B
      Fused restorePer-mirror restore latency0.59 ms0.43 ms1.37×10 agents, QPS=1, 7B
      Fused restorePeak speedup vs dense1×2.6×2.6×3 agents, QPS=4, 7B
      End-to-endMax agents under SLO (14B)144×GenerativeAgents, QPS>8
      End-to-endLatency reduction vs vLLM1×up to 2.3×—跨 workload
      End-to-endKV storage reduction vs vLLM1×−94%~17×累积

      7c. Bottleneck Shift Analysis #

      
baseline vLLM:  memory-bound (KV pool saturation → preempt/swap)
 → after CacheBlend PIC: compute-bound (N 次 RoPE+diff)
 → after collective reuse: memory-bound again (N 份 dense cache)
 → after Master-Mirror: moderate both compute & memory
 → after fused restore: residual bottleneck = attention itself + scheduling overhead >10 agents

      作者在 Q2 末段明确指出"beyond 10 agents, scheduling overhead grows and partially offsets"——下一阶段瓶颈会回到调度层。

      7d. Baselines & Fairness #

      • 公平点：同 model、同硬件、同 workload trace、同 batch 配置；三 baseline 覆盖三种现有路线（prefix / PIC ordinary path / full PIC）。
      • 不足之一：没有加 KV quant（KIVI/H2O）等正交手段混合的 baseline，不能直接知道 TokenDance 与"极致压缩单 cache"对比的相对效果。
      • 不足之二：没有与 Mooncake/CacheGen 做对比（那些是 pool-level compress/offload）；虽然定位不同，但读者可能想看"cross-cache 去重 vs offload"。
      • 不足之三：QPS ≤ 16 已经把 baseline 压垮，但没展示 QPS 更高时 TokenDance 本身何时 saturate。

      8. API & Usability #

      • Application 接入：改 prompt 拼装插 ，一次性改动；非 All-Gather workload 自动走 fallback。
      • Runtime 部署：基于 vLLM V1 + LMCache；需要 CUDA extension 编译（paired block-sparse diff kernel）。
      • 配置复杂度：没展示具体 knobs，可预期包括 block_size、check_layer、group compatibility 阈值、fallback threshold 等几项。
      • 可观测性：论文未讨论。

      9. Infrastructure Impact Table（framework 维度） #

      LayerImpact
      Algorithm间接利好 multi-agent RL rollout 的 inference 阶段
      Kernel新增 paired block-sparse KV diff kernel；与 FlashAttention/FlashInfer 有对齐机会
      LLM对模型架构无要求，但当前绑 RoPE + 一阶 KV（未讨论 MLA）
      Agent给 multi-agent runtime 提供 round-aware 的一级接口，是本文最大的受益面
      Ops需要观察 group 形成率、fallback 率、diff 大小分布等新指标

      10. Comparison Matrix #

      FeatureTokenDancevLLM prefixCacheBlendEPIC/KVLinkTokencake
      Continuous batching✅ (承继 vLLM)✅✅✅✅
      Paged attention✅✅✅✅✅
      Position-independent reuse✅ (via backend)❌✅✅part
      Collective (round-level) reuse✅ unique❌❌❌❌
      Cross-agent KV dedup✅ unique❌❌❌❌
      Agent-aware schedulingpartial❌❌❌✅
      Multi-nodeunknown✅unknownunknown✅
      Quantizationorthogonal✅orthogonalorthogonalorthogonal

      11. Adoption, Maturity & Ecosystem Influence #

      • Status：arXiv preprint，没有提到 repo 链接（截至 2026-04）。建立在开源 LMCache + vLLM 之上，如果作者开源，兼容性路径清晰。
      • 上游依赖：LMCache、vLLM V1、CacheBlend；意味着可以随着这些项目一起迭代。
      • 下游影响（预测）：(i) vLLM/LMCache 可能吸收 round-aware segment hashing 作为 multi-agent API；(ii) AgentSociety、OpenClaw 这些 agent framework 很可能把 "insert separator" 作为标准用法；(iii) 后续 paper（2026 中后期）会把 round-level 优化扩展到 DAG-pattern 多 agent。
      • 生态链：TokenDance 可视为 CacheBlend → Tokencake → TokenDance 这条 peking-group 线的延续——从 cache-centric 到 scheduler-aware 到 round-aware，每一篇都向"更大的优化单位"推进一步。

      Open Questions #

      • All-Gather 以外的通信模式（tree/DAG/partial broadcast）下，collective reuse 与 Master-Mirror 的退化曲线具体长什么样？是否能定义"结构 similarity 阈值"预测收益？
      • Master 选择 heuristic 是否存在 pathological case（例如 $O$ 块高度异构时）？有没有 optimal Master 的近似算法？
      • 与 KIVI/H2O 等 per-cache 压缩叠加后的 compounding gain 是多少？是否存在互相抵消（Mirror diff 被量化后重算代价上升）？
      • MLA / GQA / MoE 模型上这套流程需要多少改造？特别是 MoE 路由的"per-token expert assignment" 作为 per-agent 差异源会把 Mirror 撑多大？
      • Fused restore 的 attention-tile-inside fusion 的实际加速上限是多少？是否值得一个后续论文专门做？