| Entity | 关系 | 关联维度 |
|---|---|---|
| DualPath (2602.21548) | 互补 — 同一瓶颈不同层 | 两者都解 agentic inference 的 KV-cache 瓶颈：Concur 在控制面限制 admission 防 thrashing，DualPath 在数据面增加加载带宽防 I/O stall。属于同一痛点的"减需求"与"增供给"两面。 |
| PPD (2603.13358) | 类似调度粒度、不同场景 | PPD 做 per-request routing（Turn 2+ 路由到 D 节点本地 append-prefill），Concur 做 per-agent admission。两者都在 request 层面之上引入新调度单元——PPD 用 turn-level decision，Concur 用 agent-level window。场景不同：PPD 面向在线多轮 chat，Concur 面向离线 batch agentic RL。 |
| MFS (2603.17456) | 正交——网络层 vs 调度层 | MFS 解 disaggregated MoE serving 中三阶段通信的网络争用（TTFT SLO），Concur 解单引擎内的 KV-cache 逻辑竞争（throughput）。MFS 的 Defer-and-Promote 思想与 Concur 的 AIMD 有结构性相似——都是"延迟给予资源直到真正紧急"。 |
| TensorHub (2604.09107) | 互补 — RL pipeline 不同阶段 | TensorHub 优化 trainer→rollout 的权重传输，Concur 优化 rollout 内部的 agent 推理调度。二者覆盖 agentic RL 循环的不同瓶颈环节，可组合部署。 |
| PrfaaS (2604.15039) | 部分交集 — 架构层冲突 | PrfaaS 假设 PD 分离且 prefill 可 offload 到远程集群；Concur 假设单 SGLang 引擎。Concur 的 agent-level 控制不感知 PD 分离，若引入 PD 架构需跨引擎聚合 feedback 信号。 |
| ZeRO-Prefill (2605.02960) | 正交 — 不同 workload 类型 | ZeRO-Prefill 针对 prefill-only 判别式工作负载（无 decode、无多轮），Concur 针对 agentic multi-step 工作负载（decode+tool call 交替）。重叠点在于两者都从 vLLM/SGLang 外引入新调度层来解构现有引擎的不匹配。 |
| TileRT (tilert-speed-scaling-law) | 远端正交 — 解码优化 vs 调度优化 | TileRT 优化 BS≈1 的 per-token decode 延迟（kernel-level persistent execution），Concur 优化高并发下的 batch-level 吞吐（admission-level congestion control）。两者分别攻击"单 token 太慢"和"太多 agent 互踩"两个维度。 |
| KVServe (kvserve) | 互补 — 压缩 vs 准入 | KVServe 压缩 PD 间 KV 传输减少带宽需求，Concur 限制同时活跃 agent 减少 KV 内存争用。在跨 DC 或带宽受限场景下二者可串联：Concur 控 admission → PrfaaS/DualPath 做 KV 传输 → KVServe 压缩 payload。 |
Concur 的根本创新是将 KV-cache 重新定义为共享有限资源（类比网络带宽），并在 agent 粒度而非 request 粒度做准入控制 [2601.22705]。这在框架类论文中是独特的——其他工作要么增加 KV 供给（DualPath 增带宽 [2602.21548]、KVServe 压缩体积），要么改变 KV 传输路径（PPD 走本地 [2603.13358]、PrfaaS 跨 DC [2604.15039]），要么根本不触碰 KV-cache 层（TensorHub 做权重传输 [2604.09107]、ZeRO-Prefill 做 expert 通信 [2605.02960]）。
| 维度 | Concur 的 delta |
|---|---|
| 调度粒度 | Agent > request > flow > token。PPD 按 turn 路由，MFS 按 flow 调度——Concur 在最高层级操作 |
| 信号设计 | 双信号（usage + hit-rate）合取检测 thrashing；MFS 用 MLU 单信号检测 flow urgency [2603.17456]；PPD 用 offline profiling 单维 scoring [2603.13358] |
| 部署侵入性 | 最低 — 纯中间件，不改引擎（vs DualPath 需改 H2D 路径 [2602.21548]；ZeRO-Prefill 需改 vLLM 执行栈 [2605.02960]） |
| Workload 假设 | 最窄——仅 offline batch agentic RL（vs PPD 覆盖 online chat、MFS 覆盖 online SLO-aware） |
Concur 声称 CPU offload（HiCache）在高并发下失败 [2601.22705]——HiCache 在 DeepSeek-V3 Batch-16 下比 SGLang 慢 3×。但 DualPath 的整个设计正是基于高效利用存储 I/O 带宽来替代 recomputation [2602.21548]。
矛盾根源：Concur 评测的 offload 是单节点 PCIe（共享带宽，竞争 GPU 通信），DualPath 的"offload"是经独立 SNIC 走 3FS 分布式存储且通过 InfiniBand VL QoS 隔离流量。两者在硬件约束和系统架构上完全不同——Concur 拒绝的是"naïve PCIe offload"，DualPath 的方案是"带 QoS 隔离的网络存储 offload"。在 DualPath 有 RDMA 双网隔离的部署中，offload 可能不再是瓶颈，Concur 的 admission control 仍有价值但 headroom 缩小。
Concur 的双信号合取 $U_t > U_{high} \wedge H_t < H_{thresh}$ 隐含假设：存在一个"健康 baseline hit rate"（论文中 warmup 末期 ~90%）[2601.22705]。若 workload 无共享 prefix（如每个 agent 处理独立 task），hit rate 天然很低——controller 无法区分"冷启动"和"thrashing"，可能永久卡在小窗口。论文自承此局限但未提供实验验证。
Concur 假设单一 SGLang 引擎暴露 usage 和 hit-rate 信号 [2601.22705]。在 PD 分离架构下（DualPath、PrfaaS、PPD 均假设 PD 分离），prefill 和 decode 运行在不同引擎上，KV-cache usage 语义不同（prefill 端短暂、decode 端长驻），hit-rate 信号需要跨引擎聚合。Concur 的 admit/pause/resume 原语无法直接映射到"KV 在 P 节点生成、传输到 D 节点"的生命周期。
单一 $W_t$ 窗口管理所有 agent，长 agent 和短 agent 共享同一准入队列。在 heterogeneous workload mix 下，AIMD 减半窗口时所有 pending agent 等概率受阻——长 agent（累积大量 KV）被 evict 后 recompute 成本远高于短 agent，但 controller 不区分。PPD 通过 session affinity 保证同一会话的 KV 不被打扰 [2603.13358]；MFS 通过 per-request deadline 驱动优先级 [2603.17456]；Concur 完全没有 per-agent 差异化。
Concur 代表 post-2025 agent-native 推理系统第一波——与 TokenCake、Continuum、Kairos 同期，标志着从"请求调度"到"agent 生命周期调度"的范式转折 [2601.22705]。
在框架类论文中，它占据一个独特的生态位：
Workload 复杂度
│
Agent lifecycle ────┤── Concur（AIMD admission）
│── TokenCake/Continuum（TTL-based eviction）
Multi-turn chat ───┤── PPD（per-turn routing）
│── MFS（per-flow network scheduling）
Single-request ───┤── DualPath（I/O path optimization）
│── KVServe（KV compression）
│── ZeRO-Prefill（MoE execution）
│── TileRT（kernel-level decode）
└────────────────────────────── System depth
Concur 的核心 insight（KV-cache 是共享资源、agent 是调度单元）是 durable 的。但 AIMD 具体实现会被后续工作超越——模型可预测 agent KV 增长曲线（从 workload characterization 中学习），ML-based admission 可能取代固定参数 AIMD。论文价值更多在于问题定义和现象命名（middle-phase thrashing、三阶段模式）而非算法本身。
当前 Concur 仅对单引擎有效。若系统采用 PD 分离（DualPath 或 PrfaaS 架构），可设计两级 AIMD：(a) 外层 agent-level admission 控制活跃 agent 数，(b) 内层 prefill-queue / decode-queue 分别控制各引擎 KV 压力。外层使用 aggregate hit-rate，内层使用 per-engine usage。这同时解决 Concur 的单引擎绑定和 DualPath 的无 admission-control 问题。
Hit-rate 是 lagging indicator。Agent workload 的 KV 增长曲线是可预测的——给定 system prompt、tool repertoire、平均 turn length 的先验，可以用简单 linear model 预测第 $k$ 步的 cumulative KV。将 predicted KV growth 作为 admission 信号（替代 reactive $H_t$），可解决 A1（无共享 prefix 场景下 hit-rate 失效）。ZeRO-Prefill 的物理量导出 $T$ [2605.02960] 提供了类似思路——从 workload 特征推导控制参数而非手动设定。
在 bandwidth-limited 场景下，KVServe 的 service-aware controller 决定压缩强度 [kvserve]，Concur 决定并发 agent 数。两个 controller 目前独立运行，但存在耦合：更高压缩比 → 有效 KV 占用更小 → 可容纳更多 agent → 可以放宽 $W_t$。联合优化可通过 shared signal（effective KV size after compression）连接两个 control loop。
Concur 优化 batch completion time 但不保证 agent-level fairness。在 multi-tenant 或 priority-differentiated 场景下，需要将 AIMD 扩展为 weighted fair queuing——每个 agent class 有独立窗口，总窗口 $W_t$ 在 class 间按 weight 分配。MFS 的 per-request deadline 驱动 [2603.17456] 和 PPD 的 SLO-weight 机制 [2603.13358] 可作为 fairness 维度的参考。
TileRT 将整个模型编译为 persistent kernel [tilert-speed-scaling-law]，消除 kernel launch overhead 但要求 batch 在 kernel 生命周期内稳定。Concur 的 admit/pause/resume 动态改变 active agent set，可能与 persistent kernel 的静态资源绑定冲突。探索方向：将 AIMD 窗口变化量化在 kernel-safe 边界上执行（如仅在 engine step boundary 改变 active set），或让 persistent kernel 接受动态 batch resize signal。