Scope note: 任务给出的两个 id 是别名，已归一化到实际 KB 文件：2310.0724→ 2310.07240（CacheGen），2401.0967→ 2401.09670（DistServe）。 八个 peer 全部category: framework，但全部属于 LLM serving / training 世系， 而 target 属于 HPC 批调度 + 设施协同仿真 世系。这不是一个同题竞争簇， 而是一个"同类别、异领域"的对照簇——本篇 L3 的价值因此不在 metric 对拼， 而在于把两条互不引用的调度演化线放到同一张坐标系里，看它们在 调度粒度 / 抢占 / 未来信息 / 目标函数 四个轴上分别走到了哪。
八个 peer 按与 S-RAPS 的连接方式分成三层，连接强度递减。
第一层 — 同构方法论：仿真器驱动的策略/放置搜索。
它面对的问题同样是"配置空间太大、生产系统上不能试"，解法同样是
建一个被验证过保真度的仿真器，然后在仿真器里枚举配置：placement search
基于 $T_{Prefill}/T_{Decoding}$ 延迟模型，仿真器与真实系统的 SLO attainment
误差 <2% [2401.09670]。S-RAPS 做的是同一件事的重型版本——
它的"仿真器"不止覆盖调度与执行，还向下延伸到功率变换损耗、CDU、冷却塔回水温度
[2508.20016]。两者的分野是保真度的验证方式：DistServe 有
Table 2 的定量校验，S-RAPS 只有 Frontier 脚注里的真实 PUE 均值 ≈1.06 这一个锚点
第二层 — 同问题异领域：队列堆积、head-of-line blocking、碎片。
ShareGPT 在 load=0.9 时 98% 的延迟来自排队而非执行，因此优化 kernel 无用，
必须改调度学科。这与 S-RAPS 在 PM100 第 50 天观察到的"replay 利用率 ~80% 且队列在堆积"
[2508.20016] 是同一个现象的两个尺度版本。两篇的解法方向相反：
FastServe 用抢占式 skip-join MLFQ 把长任务踢开，S-RAPS 用非抢占的 backfill
把小作业塞进节点碎片 [2508.20016]。
（reserved slots、internal fragmentation、external fragmentation，有效利用率仅
20.4%–38.2%）与 HPC 的节点碎片是同一个装箱问题在不同分配单元上的投影。
vLLM 的解法是把分配单元切细到 16-token block；S-RAPS 的分配单元是整节点，
共享节点的作业在 PM100 上被直接过滤掉 [2508.20016]。
这个粒度差是本簇最大的结构性差异，§2 与 §5 都从它派生。
调度学科的形式化最优性证明（Theorem 3.1：longest-shared-prefix-first
≡ offline-optimal DFS），并把 greedy 与 optimal 的差距量化到 96%。这是衡量
S-RAPS 调度侧论证严谨度的天花板参照，见 §3 Attack 2。
第三层 — 目标函数与状态管理的对照。
"占用率高 ≠ 效率高"讲透了（decode 是 gemv，GPU 被占满但算力浪费），这直接
攻击 S-RAPS 把 ~100% 节点利用率当成功信号的做法（§2 矛盾 3）；二是它的
S-Part/R-Part 双侧流水线里 pipeline bubble 源于 temporal workload heterogeneity
[2403.11421]，与 S-RAPS 的 plugin 模式必须让
时间步仿真与事件驱动调度器各持一份系统状态副本 [2508.20016]
是同一类"两个异步子系统共享状态"的工程病。
调度器队列当作未来访问的 oracle 的系统（look-ahead window 驱动 prefetch 与
eviction，>99.6% 命中落在 DRAM）。S-RAPS 在这一点上走了完全相反的方向：它显式
禁止 clairvoyance，"pre-computing a schedule is not possible as the digital twin
observes the jobs as they are submitted" [2508.20016]。
两者构成"未来信息"轴的两个端点，§5 的方向 4 从这里生长。
唯一把"带宽/传输是被忽略的隐藏瓶颈"作为核心论点的论文，并给出了 break-even
的一阶估算（每月 >150 次复用则存储比重算便宜）[2310.07240]。
S-RAPS 的隐藏瓶颈是"设施侧物理量无人建模"，结构相同——发现一个被整个社区
当作外生变量的成本项，然后把它内生化。
连接点是静态放置的批判：它的设备分组与 placement ratio 在训练前确定、运行时不动，
"如果不同 stage 的 workload 随训练进度变化⋯⋯无法自适应调节"
[2312.11819]。S-RAPS 的
无抢占 / 无准入控制 / 无预留 [2508.20016] 属于同一类
"决策一次性下达"的设计约束。
八个 peer 的目标函数覆盖 throughput（vLLM [2309.06180]）、
JCT（FastServe [2305.05920]）、per-GPU goodput
（DistServe [2401.09670]）、TTFT + cost
（CachedAttention [2403.19708]、CacheGen
[2310.07240]）、samples/sec（FlexRLHF
[2312.11819]）——没有一篇报告瓦特。
即便是最接近成本语义的 CacheGen 与 CachedAttention，成本也是美元计价的存储/算力
账单，而不是功率摆幅、PUE 或冷却塔回水温度。S-RAPS 是唯一一篇把
"换调度策略 → 功率形状变化 → PUE 与回水温度变化"这条因果链端到端跑通的
[2508.20016]。这不是增量，是新的因变量。
accounts.json，赎回期五次运行从同一份账户历史派生优先级）
[2508.20016] 引入了一个社会-技术目标：
用户行为可以被计价机制塑形。八个 peer 里公平性最多以 starvation prevention
（FastServe 的 $\alpha$ 阈值 [2305.05920]）或
"无公平性保证"（SGLang 显式承认 greedy 会 starve
[2312.07104]）的形式出现，从来不是可设计的旋钮。
"仿真起点前已在跑的作业必须被放置到系统上"提升为正确性要求，并点名同行
忽略这一点会"distorting the results" [2508.20016]。
这是一个纯方法论贡献，见 §2.2 矛盾 1。
矛盾 1 — 冷启动是否会污染结论。
S-RAPS 断言忽略仿真起点前的作业会使调度模拟器"need time to fill up the queue
and system, distorting the results" [2508.20016]。但本簇的
LLM serving peer 全部从空系统起跑合成到达流并把结果当作有效：vLLM 用 Poisson
到达 [2309.06180]，DistServe 同样以 Poisson 到达喂三种
workload [2401.09670]，CachedAttention 明确写出
$\lambda=1.0$ [2403.19708]。没有一篇报告过预热状态的处理。
矛盾根源 — 作业时长与观测窗口的比值。 HPC 作业时长以小时计而仿真窗口是
一天到 15 天，起点前作业占据窗口的相当比例，且 PUE 与回水温度是积分量，
初值错误会累积 [2508.20016]；LLM 请求时长以秒计而 benchmark
窗口以分钟计，预热瞬态相对稳态可忽略，且 TTFT/TPOT 是瞬时量，不积分。
两边在各自时间尺度内都正确，但 S-RAPS 把它表述为对"scheduling simulators"的
普遍指控，越出了它的适用域。
矛盾 2 — "优先小作业"够不够。
S-RAPS 的 ML 打分函数梯度处处为负，最优解总在特征取值域边界，因此在高负载下
退化为"优先小作业"，论文自己承认这一点，并报告该策略取得最低 turnaround 与 EDP
[2508.20016] [2508.20016]。但 FastServe
的整篇论证就是"朴素的短任务优先不够"：naive MLFQ 的两个变体分别因抢占浪费已完成计算
和大任务堵在 $Q_1$ 而慢 24×–32×，必须用 skip-join 才能把已知的 prefill time
用对 [2305.05920]。
矛盾根源 — 抢占是否存在。 FastServe 的失败模式（抢占浪费已完成计算）在
S-RAPS 里结构上不可能发生：分配粒度是整节点、无抢占、run-to-completion
[2508.20016]。反过来，FastServe 的 3.6×–41× 收益也对
HPC 完全不可用。所以两者不是对立结论而是不同机制假设下的定理；真正可批评的是
S-RAPS 从未给出 ML 策略相对朴素 SJF 的定量差值——同一张 Fig. 10 里 SJF 就在旁边
矛盾 3 — "利用率 ~100%"是不是好消息。
S-RAPS 把 backfill 将 PM100 利用率从 ~80% 推到 ~100% 当作核心成功信号
[2508.20016]。FastDecode 则证明高占用率与高效率是两件事：
decode 阶段是 gemv，GPU 被占满但利用率极低，扩 batch 是唯一出路
[2403.11421]；vLLM 也指出当 KV 内存充裕、序列短时系统
转为 compute-bound，内存优化收益消失 [2309.06180]。
矛盾根源 — "utilization"是两个不同的量。 S-RAPS 的 utilization 是
按节点占用计的账目量 [2508.20016]，且共享节点作业被过滤掉
[2508.20016]；LLM 侧的 utilization 是 FLOP 或带宽的
达峰比例。一个被记为 100% 占用的节点完全可能在跑一个 memory-bound 作业、
只用到峰值算力的百分之几。S-RAPS 的度量在它自己的语义下无误，但
"利用率 80%→100%"不能被读成"算力浪费被消除"——恰恰因为它同时报告了
每作业平均功率 $-2\%$、作业规模 $-5\%$，这个组合更像是作业混合被改变，
而非同样的工作被更高效地做完。
FlexRLHF 的 Model Placement Ratio 抽象（用一个 0–1 比例值把复杂配置压成
可配项）[2312.11819]——都是把硬编码提升为配置面，
都因此付出"最优配置仍需手工调"的代价。
simulators at the cost of additional computational overhead"）
[2508.20016] 与 DistServe 在
segment-colocation 约束下权衡"通信本地性 vs 放置自由度"
[2401.09670] 是同一类决策；差别在 DistServe
把这个约束折进搜索并用 DistServe-Low vs DistServe-High 消融量化了它的代价
[2401.09670]，而 S-RAPS 只给出定性结论与一个顺序模式的
688× 数字，plugin 模式的速度从未报告 [2508.20016]。
Attack 1 — 头号结果的构造性偏差被承认但未被消除，而同簇有现成的消融范式。
Fig. 4 的 80%→100% 对比在构造上就对 replay 不利：PM100 过滤了共享节点作业，
且缺少 down/drained 节点信息使重排一侧占优——作者自己把 Frontier 的利用率优势
归因于后者而非策略优越 [2508.20016]。诚实值得肯定，但诚实
不等于证据。DistServe 面对同一类质疑（"收益到底来自 disaggregation 还是
并行度调优？"）的做法是构造 vLLM++ 这个"在 colocation 下做最优并行搜索"的中间基线，
证明它 ≈ 原始 vLLM，从而把因果钉死在 disaggregation 上
[2401.09670]。S-RAPS 完全可以做等价的事——例如人为注入
合成的 down/drained 节点掩码，或不过滤共享节点而按核数近似——但没有做。
结论是：backfill 的收益量级目前不可归因。
Attack 2 — 调度侧论证的严谨度低于同簇标准，而这恰是论文的主战场。
S-RAPS 的框架部分无形式化模型，仅实证 [2508.20016]。这在
framework 类别里不算孤例（vLLM [2309.06180]、FastServe
[2305.05920]、CacheGen [2310.07240]、
CachedAttention [2403.19708] 都没有统一解析模型）。但
S-RAPS 做了一个更强的声明：存在一个"低负载策略无关 / 高负载策略强相关"的
相变，两个区间由 Adastra 与 Fugaku 的 16% 请求节点利用率窗口 vs PM100/Frontier
高负载窗口划出 [2508.20016]。声明相变而不给相变边界的解析刻画
（哪怕只是到达率/服务率比与作业规模分布的两参数判据），是本篇最实质的方法论欠账
[2508.20016]。同簇有两个可效仿的先例：DistServe 用 M/D/1
排队模型预测出 intra-op 与 inter-op 的交叉点并解释它为何是内点最优
[2401.09670]；SGLang 证明 greedy 调度等价于离线最优 DFS 并给出
cache 容量 $\geq$ 最大请求长度这个明确的边界条件 [2312.07104]。
两者都说明：调度学科的相变边界是可以写出来的。
Attack 3 — ML 打分函数的自陈机制与其数学行为不符，且未与同图基线做定量对比。
L2 的六项检查已经指出：量纲不一致（时长/功率/内存混合取根号）、论文声称指数
"captures fine-grained differences" 但把 $X$ 从 100 增到 10000 只造成 $\sim0.1$
的分数差、$\alpha_j$ 与 $K$ 均未给出因此无法一阶回代
[2508.20016]。放在簇里看，这个欠账比表面更重：FastServe 的
可比部件（profiler 预测 prefill time 后决定入队层级）配了独立消融
（skip-join vs naive MLFQ 3.6×–41×）[2305.05920]，
SGLang 的每个组件都有 ablation 证明其 load-bearing（去掉树结构 / 去掉
cache-aware 调度 / 去掉 frontend hint 各自都退化）[2312.07104]。
S-RAPS 的 ML 策略与 SJF 同框出现却无差值，且"consistent trends across datasets"
的表述与两个子图都只标 Fugaku、附录确认只用 F-Data 相冲突
Attack 4 — 论文最需要的那个模式，性能从未被报告。
688× 实时来自顺序耦合（FastSim 排完再交给 RAPS）；而实时孪生必须走 plugin
模式，其速度全篇缺失，两份系统状态副本的一致性也只有一句
"requires both S-RAPS and FastSim to maintain separate copies of the system state"
[2508.20016]。附录披露的 ScheduleFlow 缺陷
（会排到不可用节点、"does not always occur"、根因未查明）正是这类状态漂移的
竞态实证 [2508.20016]。对照 FastDecode：它同样
存在两个异步子系统的 bubble 问题，但明确指出 bubble 源于
temporal workload heterogeneity 且 load-stabilizing schedule 只能部分缓解、
根本矛盾无法消除 [2403.11421]，并把最差区间
（短序列 8 sockets 效率退化到 37.6%，反而低于 4 sockets）报了出来
[2403.11421]。S-RAPS 对 plugin 模式既无量化也无失败区间刻画。
Attack 5 — 最有价值的那条证据链只在一台不公开的机器上成立。
PUE 与冷却塔回水温度的分叉（Fig. 6）是全篇唯一把调度决策传导到冷却塔的证据，
但它依赖 Frontier——唯一有经过验证冷却模型、也是唯一不公开数据集的系统
[2508.20016]；且"No open cooling model was available at the
time of writing, e.g. for PM100" [2508.20016]。再叠加
FastSim 闭源、代码托管在 code.ornl.gov 而非 GitHub
[2508.20016]，可复现性画像是：**框架可复现，
核心论点不可复现**。簇内对照鲜明——vLLM 是事实标准引擎
[2309.06180]、SGLang 的 radix cache 可定位到
radix_cache.py 行号 [2312.07104]、DistServe
[2401.09670] 与 CacheGen
[2310.07240] 均开源；而 FlexRLHF 未开源的后果
已有前车之鉴：核心思想被 OpenRLHF 等吸收，论文本身只作为 design reference
范式定位：它是"调度评估"这条线上唯一把因变量下移到物理层的一篇。
把本簇按"调度决策影响什么"排序，会看到一条清晰的下移轨迹：
vLLM 把决策影响限定在 KV 内存占用 [2309.06180] →
FastServe 下移到队列延迟分布 [2305.05920] →
SGLang 下移到跨请求的缓存命中结构 [2312.07104] →
DistServe 下移到 GPU 池的物理放置与互连拓扑 [2401.09670] →
CachedAttention / CacheGen 再下移到存储层级与网络链路
S-RAPS 落到配电与冷却。这条轨迹本身就是 framework 类别近年的主线，
S-RAPS 是目前的末端节点。它的生态位不是"更好的调度器"，而是
"调度器的物理后果可被离线观测"这一能力的第一个可用实现。
它明确选择不竞争。 论文对十余个既有调度模拟器的姿态是
"we do not compete but try to enable them, and provide example integration in
the source-code" [2508.20016]。这与 DistServe 式的
"替换你的引擎"或 vLLM 式的"成为默认引擎"是完全不同的采用模型：接入成本被压到
写一个 dataloader 插件，代价是强制下游接受两个约束（外部调度器必须能应答
"给定时间步的运行作业列表"；冷却侧必须有 Modelica 模型）
[2508.20016]。ScheduleFlow 正是在第一个约束上性能崩掉的
[2508.20016]——这说明"不竞争、只接入"的姿态并非零成本。
采用证据：机构强、公开弱。 强的一侧：作者横跨 ORNL / Texas State / NREL /
Colorado State / LLNL，数据来自 Frontier、Marconi100、Fugaku、Lassen、Adastra
五个 top-tier 系统，三个分支将合并回 ExaDigiT 基线仓库
[2508.20016]。这种"作者与数据的机构分布"本身就是采用面证据，
是任何 LLM serving peer 都不具备的资产。弱的一侧见 §3 Attack 5。
准入门槛极低也值得记一笔：依赖只有 Python 3.9+ 与常规科学栈，硬件要求是
"Laptop capable of running python 3.9+"，无 GPU 无集群，全部复现预算数小时
[2508.20016]——这与需要 16×A100
（FastServe [2305.05920]）或 128 GPU
（FlexRLHF [2312.11819]）的 peer 形成
量级差，是它作为"规划工具"而非"服务组件"的直接体现
适用下界是它自己交出来的。 Adastra 15 天低负载下所有重排曲线塌成一条线、
策略无关 [2508.20016]。这个空结果在簇内有精确的同类项：
FastServe 承认低负载下 MLFQ 退化为 FCFS、均匀 job size 分布下优势消失
[2305.05920]；SGLang 承认长输出多轮对话
"almost no speedup" [2312.07104]；vLLM 承认 OPT-175B/Alpaca
下优势缩小 [2309.06180]；CacheGen 承认短上下文与超高带宽下
回退 [2310.07240]。**所有调度/缓存类优化都有一个"资源充裕则
无效"的下界**，这是本簇最稳固的跨论文规律，也是 S-RAPS 的空结果不该被当作缺陷
而该被当作定位的理由。
这是本簇最直接、也最少人做的空白。DistServe 已经有一个被验证到 <2% 误差的
调度侧仿真器与解析延迟模型 $T_{Prefill}/T_{Decoding}$
[2401.09670]，正好是 S-RAPS 三段调度器契约所需要的那种
"能应答给定时间步运行作业列表"的组件 [2508.20016]；
而 S-RAPS 有功率模型与 Modelica 冷却链路。把两者对接，就能第一次回答
"把 prefill/decode 拆开后，机房的功率摆幅与 PUE 怎么变"。注意液冷是硬前提：
S-RAPS 的 PUE/回水温度只在液冷 CDU-冷却塔链路上有意义
[2508.20016]——而这恰好是现代 GPU 集群正在走的方向。
DistServe 的 goodput 定义是"每 GPU 每秒在 SLO 内完成的请求数"
[2401.09670]，分母是 GPU 数——一个静态成本代理。
S-RAPS 用 EDP / ED2P 作为调度侧指标 [2508.20016]，
即把能量显式写进目标。"每焦耳的 SLO 内请求数"这个目标函数目前没有任何
serving 系统在优化，而 DistServe 的 placement search 框架天然可以换目标函数。
§2.2 矛盾 3 指出的粒度差留下一个双向空白。正向：vLLM 证明把分配单元从
"按最大长度连续预留"切成 16-token block 可以把有效利用率从 20.4%–38.2%
拉到接近满 [2309.06180]，且 swap 与 recompute
两种恢复路径使抢占可行 [2309.06180]；而 S-RAPS
停在整节点、无抢占、且明确未实现 best-fit / conservative backfill
[2508.20016]——一个"可抢占 HPC 作业 + 检查点重算"
的策略族在孪生体里是可评估而未被评估的。反向：EASY backfill 的核心动作
（用小作业填节点碎片而不推迟队首作业的保留开始时间）在 KV 内存维度上
有精确对应——"在不违反排队请求的预留 KV 块的前提下放行小请求"，
而 SGLang 承认它的 greedy 顺序会 starve、没有公平性保证
[2312.07104]，正是 backfill 那套"保留 + 回填"纪律要解决的问题。
本簇在"未来信息"轴上有三个明确位置：S-RAPS 端点是零 clairvoyance
[2508.20016]；FastServe 位于中间——input length 已知、
output length 未知，因此 SRPT 不可用而 MLFQ 不够，skip-join 是对这个中间态的
最优利用 [2305.05920]；CachedAttention 位于另一端，
直接把调度器队列制造成 Belady oracle [2403.19708]。
S-RAPS 的 app-fingerprinting 流水线（K-means 聚类 → Random Forest 从提交前
特征预测簇 → 每簇一个回归模型预测运行时长/功率/内存）
[2508.20016] 实际上已经把 HPC 推到了 FastServe 的那个
中间态——请求节点数与用户历史已知、真实运行时长未知。但它把预测结果喂进了
一个静态打分函数，而不是喂进一个能容错的队列结构。用 skip-join MLFQ 的
思路重做（按预测时长跳入相应量子的队列、预测错了由降级机制吸收），
比继续调 $\alpha_j$ 更有希望，且天然回答了 §3 Attack 3 的"凭什么优于 SJF"。
§2.2 矛盾 1 的分析给出了一个可检验的推论：当 LLM 服务的会话生命周期从秒级
拉长到小时级——多轮对话与 agent 会话正在发生这件事，CachedAttention 的
idle 会话可以静默数分钟后重现 [2403.19708]——预热瞬态
相对观测窗口就不再可忽略，S-RAPS 的预填充要求就从 HPC 特有变成普遍必要。
目前没有任何 serving benchmark 报告"仿真起点已在运行的会话及其 KV 状态"。
这是一个纯方法学 gap，成本极低，影响面覆盖整簇。
S-RAPS 的四种赎回期优先级键（avg power / low avg power / EDP / Fugaku points）
都建立在同质硬件上 [2508.20016]。FlexRLHF 已证明异构放置
（推理放 V100、训练放 A100）在功能上可行 [2312.11819]。
在能耗剖面差异巨大的异构集群里，"按用户消耗的焦耳而非节点小时计价"会改变
作业向硬件的自选择——这是一个孪生体可以模拟、生产系统绝不敢直接上线的实验，
正好落在 S-RAPS 自我定义的用途上 [2508.20016]。