Target: SliceScheduler — 把调度单元下沉到算子，用可克隆的全局映射图 (GMG) + 事件驱动仿真做 what-if 放置，回收多租户服务中秒级的 GPU 空闲片段。 与 8 篇 framework 论文对照。 注：任务单中的2310.0724/2401.0967在 KB 中的真实 id 为2310.07240(CacheGen) /2401.09670(DistServe)，本文按真实 id 引用。
这 8 篇按"与 SliceScheduler 争夺同一块资源的方式"分成三圈。
内圈 — 同样把"预测未来"做成调度基础设施
中圈 — 攻同一层（GPU 利用率 / 资源耦合）但用粗粒度手段
外圈 — 提供 SliceScheduler 缺失能力的参照系
lock_ref 引用计数把"缓存的中间结果"做成 first-class 且量化了收益（命中率 50–99%）[2312.07104]，而 SliceScheduler 的 GMG checkpoint 元数据具备同样的表达力却从未被测量 [2608.15762]。两者都承认"没有闭式 SLO 模型 → 用仿真器给候选放置打分"。真正的 delta 有三层。
粒度与频率：DistServe 枚举的是 (GPU 数 × 并行策略 × segment 布局) 的静态配置空间，搜索完成后运行时是朴素 FCFS + 最短队列分发 [2401.09670]。SliceScheduler 每轮从 unscheduled frontier 取一小批算子、对预定义 partition 并行 what-if、写回最优放置 [2608.15762]。前者一次决定"系统长什么样"，后者持续决定"下一个算子去哪"。
性能模型的形态截然不同，且这个差异是可攻击的。DistServe 有真正的解析模型：M/D/1 排队 + prefill/decode 延迟模型，且模型给出一个内点最优——低到达率时 intra-op 胜、高到达率时 inter-op 胜，交叉点在 (intra, inter) 平面内部，这正是"必须搜索"的解析理由 [2401.09670]。SliceScheduler 的 Eq 3 $t=(Nl+1)/(sg)$ 对全部四个变量严格单调，无内点极值——决策质量与调度及时性之间没有解析最优点，只有一条约束线，实践上只能把 $l$ 和 $g$ 往更粗推到边界 [2608.15762]。这不是缺陷本身，但它意味着 SliceScheduler 的"选粒度"是工程直觉（每 8 层融合，"empirically grouping"）而非模型推导。
仿真精度这条卖点被稀释。SliceScheduler 报端到端仿真误差 1.83%，并以 SimAI 的 20.58% 作对照 [2608.15762]。但 DistServe 用一个纯解析的延迟模型建的仿真器，就把 SLO attainment 误差压在 <2% [2401.09670]。两者不是同一量的误差（算子级时间 vs 请求级 SLO 达成），但足以说明"1.83%"并不构成方法论上的护城河——真正在起作用的是负载的确定性，SliceScheduler 自己测到算子样本变异系数只有 0.62%、传输 1.63% [2608.15762]。在这种 CoV 下，任何合理拟合都不会失败。
这是本篇最重要的一条 delta，也是一条真矛盾。
SliceScheduler 的显存安全完全前置：shape 在执行前可推断 → 显存占用在放置前可算 → 仿真出 OOM 的候选直接丢弃；没有 eviction、没有 swap、没有碎片整理，代价是"无法处理运行期意外增长" [2608.15762]。
vLLM 的整个立论恰好建立在相反的前提上：KV cache 动态增长、长度不可预知，按最大序列长度预分配导致有效利用率只有 20.4%–38.2%，故必须做运行期的分页、按需分配、抢占换出与重算恢复 [2309.06180][2309.06180]。
矛盾根源：两者调度的对象不同层。SliceScheduler 的调度单元是"融合 8 层的 LLM layer"这种权重与激活主导、shape 由输入决定的算子；它明确声明不改动批处理逻辑，坐在 continuous batching 下方 [2608.15762]。KV cache 随 decode 步逐 token 增长这件事，从未进入它的 GMG 节点语义。其离线负载被设成"输入 2048 token、固定输出 15 token" [2608.15762]——固定输出长度恰好抹掉了 vLLM 所攻击的那个不确定性。所以两者在各自范围内都正确，但 SliceScheduler 的"纯 admission-time 显存安全模型"若要覆盖真实 decode 负载，必须回答一个它没有回答的问题：谁来为 KV 的增量分配做准入。
SliceScheduler 报调度层运行时开销 0.0%（23.37 s vs Direct Execution 23.39 s），甚至名义上略负 [2608.15762]。它自己的解释很诚实：这套设计本来就不做重叠、不做投机，接管调度并未剥夺任何既有优化 [2608.15762]。
把这句话放到 FastDecode 旁边就能看清代价。FastDecode 的吞吐完全来自两个 mini-batch 的 S-Part/R-Part 交错流水，理想情况下 S 与 R 延迟匹配则无 bubble [2403.11421]；它的 load-stabilizing schedule 也只是为了让这条流水不出气泡。而 SliceScheduler 的可重建性不变量明令"每队列一次只跑一个算子、依赖驱动而非发射顺序、跨卡传输必须先 Recv 后 Send 并由中心仲裁门控" [2608.15762]。这两套机制不能共存：FastDecode 所依赖的一切并发结构，正是 SliceScheduler 为了让 GMG 快照唯一可重建而必须禁止的东西。
SGLang 提供了另一个刻度：它的 RadixAttention 在零复用场景下开销 <0.3%，而它保留了完整的 continuous batching 与 kernel 优化 [2312.07104]。所以 "<0.3% 且不牺牲并发" 与 "0.0% 但禁止并发" 是两种性质完全不同的低开销。
矛盾根源：基线不同。SliceScheduler 的 Direct Execution 基线本身就是非重叠的顺序执行，比较的是"加一层调度中介 vs 不加"，而不是"接管后的系统 vs 一个高性能 serving 引擎"。这也解释了它为什么选 AntMan/Orion 类共享系统而非 vLLM/SGLang 作基线——它不与后者竞争同一层，也不能直接叠加在后者之上 [2608.15762]。
FlexRLHF 是训练侧的对照：同样发现"某类模型在某个阶段大量 idle 却仍占着内存"，解法是 Interleaving / Disaggregated 两种离线确定的放置策略，用 Model Placement Ratio 配置 [2312.11819]。其 L2 的批判性评价直指要害：设备分组和比例在训练前确定，运行时不动态调整，若各 stage 的 workload 随进度变化则无法自适应 [2312.11819]。
SliceScheduler 正是这条批评的答案——把放置变成每轮重算的在线决策。但它只兑现了一半：候选放置来自预定义的 partition 集合，每个图模板到每个候选 partition 的算子映射也是预定义的 [2608.15762]。所以决策空间远小于"算子级调度"字面暗示的规模，本质上是"在一组 FlexRLHF 式的静态方案之间在线切换"，而非真正的自由放置。论文从未报告候选 partition 有多少个，而这个计数直接乘在 Eq 3 假定的每轮仿真工作量上。
CachedAttention 的实测结论是：HBM-only 缓存命中率约 0%（容量饥饿），HBM+DRAM 只有 1.7–19.1%，加上 SSD 才跳到 71–90%——绑定约束是容量而非带宽 [2403.19708]。SliceScheduler 完全没有分层：显存不够就在准入期丢弃候选放置。它的"显存吃紧时保安全但收益低"这一自我诊断 [2608.15762]，在 CachedAttention 的数据下有了明确的量化解释——这不是保守，这是把一个本可用 DRAM/SSD 层解决的容量问题当成了硬约束。
CacheGen 则补上第二跳：一旦跨出单机，传输就不是 Eq 1 那条按加速器对拟合的仿射直线所能概括的，带宽会剧烈波动，需要逐块自适应与降级回退，否则 SLO 违约率可达 81% [2310.07240]。SliceScheduler 的传输模型在单机 NVLink/PCIe 下 MAPE 0.92% [2608.15762]，但它对跨节点从未验证——而 Eq 3 恰恰把 $N\approx 62$ 当成主要卖点。
A1 — 核心定位（cluster-wide）与实验规模（单机 8 卡）之间存在结构性缺口。 Eq 3 推出的 $N\approx 62$ 是纯纸面外推，从未在变化的 $N$ 上被测量；集中式 master 的反馈延迟、状态陈旧、真实执行偏离仿真重建状态时的行为，全部未建模也未测量 [2608.15762]。对照 DistServe：它的 placement search 明确声明 model-size-independent 且在 OPT-13B/66B/175B 三个规模上跑通端到端 [2401.09670]；FastServe 也做了 6–16 GPU 的 scaling 曲线 [2305.05920]。SliceScheduler 唯一的 scaling 证据是一个未验证的公式。
A2 — 全文没有 ablation。 三个"涌现"性质（局部性、SLA 优先、负载均衡）中，只有 SLA 优先有 Fig 8(c) 支撑，负载均衡只有相对 Full-Share 的 +49% 这一处归因，局部性纯属设计论证 [2608.15762][2608.15762]。这在本组论文里是明显落后的：SGLang 逐一剥离 tree 结构 / cache-aware 调度 / frontend hint 并各自量化退化 [2312.07104]；DistServe 用 "vLLM++" 隔离出"并行策略调优本身不产生收益"这一反直觉结论 [2401.09670]；CachedAttention 把 scheduler-aware eviction 单独对 LRU/FIFO 打擂 [2403.19708]。没有 ablation，就无法排除"收益主要来自共享作用域变大"这个平凡解释——而 Fig 8 四个子图高度一致的排序（作用域越灵活越好）恰好支持这个平凡解释。
A3 — 论证链的承重点是全链唯一既无证明也无测量的一环。 "GMG 快照 ≡ 集群一致快照"这条可重建性不变量，论文只给了重建论证，无形式证明、无一致性测量；传输仲裁的无死锁性同样只是断言，冲突无关边集的选择算法未给出 [2608.15762][2608.15762]。对照 SGLang：它的对应难点（缓存与运行批次共享一个内存池、eviction 不得触碰在跑的节点）不但有 lock_ref 的具体实现锚点，还有 Theorem 3.1 给调度顺序托底 [2312.07104][2312.07104]。SliceScheduler 在"最难的那一步"上恰好最薄。
A4 — 绝对性能量级与同组论文差两个数量级。 整台 8 卡服务器只有 8.08–18.51 output tok/s [2608.15762]；FastDecode 在单张 A10 上 Llama-7B 达 2279 tok/s，其 vLLM 基线也有 452 tok/s [2403.11421]。硬件不同（A16 是面向推理/VDI 的 GDDR6 卡，而论文的论述框架却是 HBM 中心的 [2608.15762]）、负载不同（多实例多租户 vs 单实例吞吐压测），但差距之大足以质疑：在这个绝对量级上观测到的调度收益，是否会在一个高性能引擎（每卡数百 tok/s、连续批处理、异步流水）上依然存在？考虑到 SliceScheduler 的不变量禁止那些引擎赖以工作的并发结构，答案很可能是否定的。
A5 — 三个共享基线的 SLO 达成精确聚在 89.9%–90.7% 的 0.8 个百分点带内，在它们各自多背 1–2 个离线实例的情况下 [2608.15762]。加之 SLO 阈值被定义为 Static-Online 的 p90 TTFT，且四个基线全部由作者自行实现，这个"偏紧的巧合"需要 raw data 才能排除实现偏置。相较之下 DistServe 至少用了公开的 vLLM 与 DeepSpeed-MII 并公开自身代码 [2401.09670]。
A6 — 仿真速度对比不是同一件事。 176.8 vs 0.065 算子/ms 的对比中，SliceScheduler 弱化了流量调度，即它仿真的东西更少；SimAI 的算子数还是间接换算的 [2608.15762]。且该精度证据取自 Llama3-8B 训练图、PP=2、2 张卡，与目标场景（多租户服务、8 卡）是不同的负载类别与规模。此外论文两处把 2720× 写成"about four orders of magnitude"（实为约 3.4 个数量级）[2608.15762]。
A7 — 已有的机制没有被兑现成收益。 GMG 的 checkpoint 元数据本可表达多轮对话/前缀复用，但论文既未与前缀缓存的收益关联，也未测量其显存占用代价 [2608.15762]。这块空白在本组里成本很高：SGLang 报 50–99% 命中率、生产环境 52.4%/74.1%、首 token 延迟降 1.7× [2312.07104]；CachedAttention 报 TTFT 降 87%、prefill 吞吐 7.8× [2403.19708]。一个声称做多租户 LLM 服务调度的系统，把这条最大的收益源留作未测量的元数据字段，是论证上的重大遗漏。
A8 — 与生态不可组合，且未公开。 无 artifact 声明、无仓库、无 LoC 统计 [2608.15762]。同时它接管的是 PyTorch backend 层，"最小改动接入"的主张没有移植工作量数据，也未说明 Dynamo 捕获失败/graph break 时的退化路径——而 LLM 服务代码中 KV cache 管理与采样循环恰是最容易 break 的地方。
范式定位：它属于"把 GPU 集群当操作系统来管"这条线，而不是"把 LLM 服务引擎做快"这条线。 arXiv 主分类 cs.OS 不是偶然。本组另外七篇全部在引擎内部做优化——vLLM 改内存分配器、SGLang 改缓存与调度顺序、FastServe 改队列纪律、DistServe 改实例拓扑、FastDecode 改设备分工、CacheGen/CachedAttention 改 KV 的存储与传输。SliceScheduler 是唯一一篇把容器编排层的失败当作起点、把控制单元下沉到容器以下的：它的 Q1 不是"引擎不够快"，而是"空闲片段的所有权属于原容器，而用户应用不可修改" [2608.15762]。
它对 disaggregation 路线提出了一个值得记录的边界条件。 DistServe 与 FlexRLHF 都把静态分池当作答案 [2401.09670][2312.11819]。SliceScheduler 的一条测量直接限定了这类答案的适用范围：四实例回放显示跨 GPU 的空闲时间重叠不超过 20%，低优先级作业需要覆盖的 GPU 越多，这些 GPU 同时空闲的概率越低 [2608.15762]。这条数据说明：分池能解决"两类负载互相干扰"，但解决不了"每一池内部各自留下的秒级碎片"。这两个问题在文献里长期被混为一谈，本篇把它们分开了——这是它最结实的概念贡献，比系统本身更耐用。
采纳证据：目前为零，且结构上难以获得。 三重障碍。(i) 未开源 [2608.15762]，与 FlexRLHF、FastDecode、CachedAttention 同处闭源阵营 [2312.11819][2403.11421][2403.19708]，而 vLLM 已是事实标准、SGLang 的 radix cache 可逐行核对、DistServe 有公开仓库 [2309.06180][2312.07104][2401.09670]。(ii) 它要求接管执行层并禁止多流并发/投机/动态 shape，因此不能叠加在任何现代 serving 引擎之上，只能替换——迁移成本是"换掉整个后端"而非"换一个调度插件"。(iii) Eq 3 把适用规模钉在约 64 卡，而它面向的多租户集群场景通常更大。
因此它更可能作为思想被吸收，而非作为系统被部署：具体地，"算子级 what-if 仿真作为放置 oracle"与"跨 GPU 空闲重叠 ≤20% 因此碎片必须被细粒度分解"这两点，比 GMG 这套实现更可能进入后续系统。FlexRLHF 的历史轨迹是个好参照——系统未开源，但"训练-推理运行时分离"的理念成了后续框架的标配 [2312.11819]。
U1 — 用"让出"接口替代"接管"执行层（最高价值）。 当前设计的致命耦合是：为了让 GMG 快照可重建，必须禁止 FastDecode 式流水 [2403.11421] 与 SGLang/vLLM 式的连续批处理与异步 kernel。一条未被探索的中间路线是反转控制方向：不要求高优租户被调度器接管，只要求它导出两样东西——(a) 一个粗粒度的"未来 T 毫秒我不会用这张卡"承诺，(b) 一个显存水位上界。低优作业仍按算子级铺开，但仿真器只需重建低优侧的状态。这把论文自己指出的硬件缺口（缺少可被外部观测的、确定性的队列执行状态导出接口 [2608.15762]）从硬件需求降级为软件契约。
U2 — 准入期 OOM 硬过滤 + 运行期分层承接。 把 CachedAttention 的 DRAM/SSD 分层 [2403.19708] 接到 GMG 的 checkpoint 元数据之下：仿真出 OOM 的候选不再直接丢弃，而是标注"需要把某个 checkpoint tensor 下沉一层"并把下沉的传输代价直接计入仿真时间线（Eq 1 已经具备这个表达力，只需为 HBM↔DRAM 拟合一对系数）。这把"显存吃紧 → 保安全但收益低"这个已知弱区 [2608.15762] 变成一个可量化的连续 trade-off，而不是一道硬门。
U3 — 给仿真打分补一个最优性刻度。 SGLang 证明了在这类问题上贪心可以逼近离线最优并被证明 [2312.07104]。SliceScheduler 有一个更强的工具（完整仿真器）却没有任何最优性论述。一个直接可做的实验：用同一个仿真器离线穷举放置序列得到 oracle，度量在线贪心与之的 gap——SGLang 报的是"达到理论最优命中率的 96%"，SliceScheduler 完全可以报一个对应的数。这几乎零成本，且能把 A3 的批评转成卖点。
U4 — 把 checkpoint 元数据兑现为前缀复用，并量化其显存代价。 GMG 已经记录哪些中间结果被保留在哪张卡的 HBM 上 [2608.15762]，这与 SGLang 的 radix 节点、CachedAttention 的 session 粒度条目是同构的。缺的只是 (a) 一个匹配结构（哪些新图实例可挂接到哪些保留态）、(b) 一个 eviction 纪律、(c) 命中率与显存占用的联合测量。这是本篇性价比最高的未做工作。
U5 — 自适应算子粒度。 Eq 3 对 $g$ 严格单调且无内点极值，意味着粒度只能被推到约束边界，而当前取值（每 8 层融合，$g=10.575$ ms）是经验值且无敏感性分析 [2608.15762][2608.15762]。未被探索的是运行时按空闲片段长度分布自适应地选择融合深度：Fig 1 的片段 CDF（p50 2551 ms / p90 10888 ms / p99 17790 ms）本身就是一个粒度先验——短片段要求小 $g$，而小 $g$ 又压低 $N$ 上限。把这条张力显式建模，可能产生 Eq 3 目前缺失的那个内点最优。
U6 — 抢占。 论文全程无抢占，一旦低优算子被发射就跑到底；在近饱和区间它退化为 Static-Online 加调度开销 [2608.15762]。FastServe 的 skip-join MLFQ + starvation prevention 是现成的时间维答案，且它对内存的影响（抢占使 KV 开销最高涨 7×，需 proactive swapping 化解）也已被量化 [2305.05920]。算子级队列本应是比请求级更自然的抢占点（每个算子边界都是天然的抢占边界），但这个组合尚无人做。
U7 — 跨节点：借 DistServe 的 stage-colocation 约束打破 $N\approx 62$。 DistServe 的非显然洞察是"KV 传输只发生在对应的 inter-op stage 之间"，据此把匹配 stage 强制同节点，使传输始终走 NVLink [2401.09670]。SliceScheduler 的 Eq 3 瓶颈来自集中式 master 的仿真工作量随 $N$ 线性增长；同构的做法是按通信亲和性把 GMG 切成若干子图、每个子图一个局部 master、只在子图边界做全局仲裁。这同时需要 U1 的契约化接口来界定子图边界的状态可见性。
U8 — 把 ≤20% 空闲重叠这条测量搬到训练/RLHF 集群。 FlexRLHF 的 Disaggregated 策略把 Generation 占比从 93% 压到 56%，剩下的 44% 训练时间里推理设备组在做什么，论文没说 [2312.11819]。SliceScheduler 的方法论（trace 回放 + 空闲片段 CDF + 跨设备重叠率）是回答这个问题的现成工具，而 RLHF 的阶段结构是周期性且可预测的——这意味着重叠率可能远高于 20%，从而得出与 serving 场景相反的结论。这是本方法论最可能产出反直觉结果的迁移方向。
Inputs: L1+L2 of 2608.15762; L2 of 2305.05920, 2309.06180, 2310.07240, 2312.07104, 2312.11819, 2401.09670, 2403.11421, 2403.19708.