孪生调度：用服务系统的模型替代测量与静态启发式 #

1. 主题缘起 #

这个主题聚起来的原因不是某个新机制，而是一个共同的失败模式：服务系统的配置/放置空间已经大到无法用测量枚举，而静态启发式在这些空间里的失效点位置本身是负载相关的。 四篇工作分别在 framework、cluster、agent 三个类目里撞上同一堵墙，然后给出了同一种形状的答案——先造一个便宜的系统模型，再让这个模型去驱动一个部署或调度决策。

墙有三种具体形态。

第一种是标注成本。 多租户 LoRA 服务里"并发 adapter 数 × 静态 slot 数 × adapter 尺寸 × 到达率"的笛卡尔积，真机每个点要跑一小时，而训练网格是四重乘积——真机路线在时间上根本不成立；把单点成本压到 39 秒才让整条链条闭合 [2602.24044]。同一条流水线在单卡版本上的规模是 87,198 条合成样本对 882 条真机样本，即 99% 对 1% [2508.08343]。

第二种是决策对象上移。 引擎机制（分页显存、连续批处理、缓存结构）在这一代已经商品化，价值转移到"这些已固化的旋钮该怎么自动填"，而机制论文习惯性把配置留给用户 [2508.08343]。更极端的一步是把硬件目录本身变成决策变量：不再是"给定硬件优化软件"，而是"给定负载定型硬件" [2608.03741]。这两步都把问题推出了可测量的范围——前者的搜索空间是组合的，后者的目标器件根本还不存在。

第三种是时间尺度。 生产 AI coding 服务的 trace 回放显示 GPU 空闲被切成秒级碎片（p50 2551 ms），短于 p99 的碎片占总空闲时间的 95.6%，而容器编排的弹性机制端到端是分钟级 [2608.15762]。用分钟级机制填秒级洞无效，于是决策必须进入在线回路，而在线回路里唯一能承担"这个放置会不会更好"的东西就是一个可以在毫秒内跑完的仿真器。

分隔这四篇的轴是模型相对决策回路的位置：一端是彻底离线的设计空间探索与容量规划，另一端是把仿真塞进在线调度回路的每一轮。中文语境里这一族被叫作"孪生调度"。

（2026-08 增补）第四种形态：因变量下移到物理设施。 HPC 批调度侧的孪生传统给出了同一堵墙的另一面——问题不是"配置空间太大"，而是目标函数里的量在编排器里没有状态源。"把 FCFS 换成 priority+backfill 后机房的功率摆幅、PUE、冷却塔回水温度怎么变"这类问题，在调度模拟器一侧无功率无冷却、在数据中心孪生一侧只能回放不能重排，因此两个阵营各自都缺一半状态 [2508.20016]；连续体编排侧的同一句话是"编排面缺少描述能耗/碳强度/延迟的状态源"，所以第二个核心组件不是第二个调度器而是一个孪生 [2605.25292]。这一支进来之后，本主题多了一条与"模型距离决策回路"正交的第二条轴：被建模的因变量停在哪一层（SLO 与 GPU 利用率 / 功率与冷却 / 公平性与激励），见 §2.1。

2. 覆盖的 category 分布 #

model 一栏当前为空但仍写进 scope，因为 2608.03741 的五因子消融实际上是在变换模型架构而非硬件，并把收益归因到 kv_lora_rank 与 num_active_experts 这类纯架构参数上 [2608.03741]——下一篇从模型侧进来的工作会自然落入这个主题。

2.1 HPC 侧孪生 vs LLM serving 侧孪生（新增对比表） #

三篇 HPC/批作业调度侧的工作（2512.18894、2508.20016、2605.25292）与原有的 LLM serving 侧工作构成一条清晰的分野。这不是"同一方法在两个领域的复制"，八个维度里有六个取值相反。

关于"保真度的锚"这一行，必须写清两条例外，否则会把分野讲成一条不存在的规律。 第一，HPC 侧内部并不一致：S-RAPS 确实有五个真实系统数据集（Frontier、Marconi100、Fugaku、Lassen、Adastra）可回放亦可重排 [2508.20016]，而 SchedTwin 的真实 Polaris trace 只用于 motivate，§4 的评测完全没有用它，全部结论出自 150 作业的合成四阶段 trace，且该 trace 被作者自陈 "intentionally designed" 成让 SJF 有效的形状 [2512.18894] [2512.18894]；DECICE 则连一次与 vanilla Kubernetes 的端到端对比都没有 [2605.25292]。第二，两侧的薄弱处位置相反：HPC 侧有真实负载但缺物理量的 ground truth（PUE 只有一个脚注锚点，且承载全篇最有价值证据链的 Frontier 数据集不公开 [2508.20016]）；serving 侧有较硬的局部数值比对（算子级 TFLOPS、队列时序、19% 的 TTFT 误差）但负载多为合成或单一 trace，且模型本身是自建解析式而非从生产系统回放出来的 [2608.03741] [2608.15762]。因此可以明确写出的结论是：孪生保真度在两侧不是"强弱"关系而是"缺口位置不同"——HPC 侧缺被建模物理量的直接校验，serving 侧缺真实负载的覆盖。 一个把两侧长处拼起来的实验（真实 serving trace 回放 + 液冷链路的实测 PUE 对齐）目前不存在，见 §7 OC6。

3. 时间线 #

2508.08343 与 2602.24044 是同一条作者线的连续两步，可从三处独立确认：两者共享同一个孪生的资源画像（纯 CPU、单核、~200 MB、约 39 秒模拟一小时服务、90× 实时）[2508.08343] [2602.24044]；共享同一个"吞吐 ≥ 入流 token 速率 90%"的最优点操作化定义 [2508.08343] [2602.24044]；共享同一套四估计器分解与 curve_fit 标定路径 [2508.08343] [2602.24044]。差别在于前者只预测数量、不预测"放哪个"，并自陈这是 limitation [2508.08343]，而后者补上的正是放置。

时间线的起点因 HPC 一支的进入而前移了一层。 原表的起点 2508.08343（2025-08）与 S-RAPS（同月）实际上继承的是两条互不引用的传统：前者的祖先是 vLLM 主循环的代码级重实现，后者的祖先是 ExaDigiT/CQSim 世系——那一支的孪生传统比 LLM 服务早得多，且 SchedTwin 明确把 ExaDigiT 一线定位为"offline planning 导向、不提供 real-time feedback for dynamic operational control"，从而把"实时在环"标定为空缺 [2512.18894]。也就是说，本主题在 serving 侧发现的那条"模型距离决策回路"的轴，在 HPC 侧被独立地、以几乎相同的措辞发现了一次。

（2026-09 增补）serving 侧的起点又前移一层到 2503.08415（TokenSim, 2025-03）。 它比 2508.08343 早半年，且不属于"影子化某个具体引擎主循环"那一支，而是一个通用的服务运行时仿真器——它不为某个决策器服务，而是把整套运行时（动态到达、continuous batching、分页 KV、抢占/重算、跨 worker KV 迁移）建成一份可反复扫参的便宜副本 [2503.08415]。因此本主题现在有三个而非两个 serving 侧祖先：TokenSim 这样的通用仿真器本体、2508.08343 那样的引擎影子化、以及 2608.03741 那样的解析器件模型——前者的价值在被下游直接扩建（见 §8），而非产出某个具体调度结论。

4. Evolution timeline（技术谱系） #

三条独立的根，在"把成本拆成少数几个可分别拟合的估计器"这一点上汇合，然后按模型距离决策回路的远近分叉。（2026-08 增补）第四条根从 HPC 设施侧进来，它绕过了这个汇合点——这正是 §2.1 那张表的图形化表达。

三个结构性事实值得单列。其一，分叉点在 2508.08343：它同时长出了"把代理模型推进在线回路"（被 2602.24044 接手）和"把孪生本身当作可进 CI 的容量回归工具"（无人接手）两个分支，后者的资源画像已经足够便宜，论文自己也在结论里提了一句但没展开 [2508.08343]。其二，根 B 与根 A/C 的分野不是精度而是可观测性：roofline 的输入是器件规格表，因此可以对一个尚不存在的器件目录求值，代价是它明确不建模排队、kernel launch、occupancy [2608.03741]；根 A/C 的输入是真机插桩指标，因此只能对已存在的系统求值。其三，汇合点是实质性的而非修辞性的：$Lat_{sched}=K_1B+K_2R_P+K_3R_P\frac{A_B}{A}$ 的三项一一对应调度器的三段循环 [2602.24044]，算子时间的 $\beta_1(bmnk)+\beta_2(bmk)+\beta_3(bkn)+\beta_4(bmn)+\beta_5$ 是一个 FLOP 项加三个搬运项加截距 [2608.15762]，roofline 的 $\max(\Phi/F,\beta/B)$ 是同一分解的两项极端形式 [2608.03741]——三者都是"手工设计特征基、让拟合自己决定哪项主导"，而不是黑盒回归。

（2026-08 增补）其四，根 D 绕过汇合点 M 是一个可解释的结构事实，不是遗漏。 HPC 侧不做成本分解的原因是它不需要——作业的资源需求由用户在提交时声明（节点数、walltime），执行时间不需要被建模而只需被"假设为用户填的值再做双向校正" [2512.18894]；真正需要建模的量在物理侧（功率变换损耗、CDU、冷却塔），而那一侧已经有 Modelica 这类现成的一等物理模型可挂 [2508.20016]。代价是开销结构完全不同：分解式的代理模型可以压到 113 ns [2602.24044]，而全排空 rollout 的成本随队列长度而非策略数增长，且这条曲线从未被测过、"a few seconds per scheduling cycle"没有任何测量支撑 [2512.18894]。其五，根 E 是 serving 侧对 M 的反向压缩：既然分解出来的估计器最终只是为了回答一个低维决策，那就干脆把决策本身离线打表（2603.13358）、或者只建总量不建结构（2604.15186）、或者换个代理量彻底不建（2603.17456）、或者换个调度单元让预测变得不必要（2606.01839）。这四步构成一条"模型复杂度递减而结论不退化"的路径，是本主题当前最值得警惕的一条演化——它的存在意味着"建更准的孪生"并非唯一进展方向。

（2026-09 增补）其六，根 A/C/E 的上游还站着一个更基础的层：通用服务运行时仿真器本体。 前述所有 serving 侧的孪生要么影子化某个具体引擎主循环（根 A/C），要么把决策离线打表（根 E），它们都默认"能把服务运行时仿真到 <1% 精度"这件事已经成立。TokenSim 正是把这件事本身做成一个可复用、可插拔 compute backend 的独立工具：离散事件引擎（SimPy）负责推进仿真时间，两级调度器与细粒度内存管理器负责运行时语义，算子级时间交给可换的 compute backend（如 GenZ）[2503.08415]。它对根 A/C/E 的关系不是分叉而是衬底——把"用便宜副本代替真机"从每篇各自重造一遍，抽象成一个共享的仿真基座（它自陈本簇里"唯一的模拟器/探索工具，其余全是被它模拟的真实系统" [2503.08415]）。这也是本主题里第一次出现"孪生本体被下游直接扩建而非仅被形似复现"的证据结构，直接催生 §5(k) 那条新轴。

5. 技术线交错 #

(a) framework 的实现遗留决定了 cluster 层能优化什么。 两篇 adapter 论文优化的核心旋钮——启动期静态指定的常驻 adapter 上限——是 vLLM 的实现选择而非物理约束：显存在初始化时静态切分，每个槽位按场景内最大 adapter 的尺寸统一分配，于是一个 rank-32 的 adapter 会把同卡上所有 rank-8 adapter 的槽位一起撑大 4 倍 [2602.24044]。这条依赖是双向的：没有这个静态切分就没有那个悬崖，也就没有 cluster 层的装箱问题 [2508.08343]。而论文自己的带宽核算已经拆掉了这个约束的物理基础——rank-8 adapter 的 PCIe Gen5 理论 DMA 约 0.34 ms，实测折算约 12 ms，高 30 倍以上，说明开销主要是框架路径成本而非链路成本 [2602.24044] [2602.24044]。

(b) 硬件目录的自由度决定了一个调度/切分想法有没有东西可切。 同一个模拟器、同一负载、同一模型集合，换 NPU 目录与商用 GPU 目录得到相反排名；机制在逐阶段分配里可见——NPU 下 decode-attention 与 decode-FFN 拿到相同存储档却相差 10–100 倍算力档，GPU 下 32 个阶段分配中 31 个是同一款 H100 [2608.03741]。这是一条 agent 类目产出、却直接约束 framework 类目设计的结论：软件侧之所以只能在时间维和缓存维找收益，部分是因为空间维在商用目录上已经退化 [2608.03741]。

(c) 仿真保真度的要求反过来锁死运行时的并发能力。 让全局映射图快照可无损重建集群运行态，要求执行器放弃几乎所有现代 GPU 运行时的性能手段：每队列一次只跑一个算子、依赖驱动而非发射顺序、跨卡传输必须先 Recv 后 Send 并由中心仲裁门控、shape 必须执行前可推断 [2608.15762]。代价是它无法叠加在任何依赖异步流水的高性能服务引擎之上，只能替换 [2608.15762]。这是本主题里最尖锐的一处交错：模型进入回路越深，它对被建模系统的行为限制就越强。 HPC 侧给出了这条规律的第二个实例，且更便宜：SchedTwin 的"虚拟未来只允许存在预测 end 事件、run 事件立即退出不重规划"这条不变量，隐含要求物理调度器不得自行启动作业，所有启动必须源自孪生的 qrun——这是把部署前提写成了优化，在 33 个容器的伪集群上不会暴露，在真实站点上会 [2512.18894]。两侧的形状完全一致：可重建性不是免费的，它总要向被建模系统索取一条行为约束。

(d) 排队目标是一个物理推论，不是可调参数。 "吞吐 ≥ 入流 token 速率 90%"这一定义等价于把系统钉在利用率 $\rho\approx0.9$；对 M/D/1，等待时间 $W=\frac{\rho}{2(1-\rho)}\tau=4.5\tau$，而 baseline 摊在 4 张卡上时 $\rho\approx0.45$、$W=0.41\tau$，约一个数量级的排队延迟差 [2602.24044]。也就是说 60% 的 GPU 节省是用 $1/(1-\rho)$ 的延迟放大买来的，ITL 的系统性劣化不是实现瑕疵而是目标函数的直接推论 [2602.24044]。同一个阈值在单卡版本上承担了全文所有 ground truth 标签的定义，且从未做过敏感性分析 [2508.08343]。HPC 侧的同型现象是"利用率 ~100% 是不是好消息"：S-RAPS 把 backfill 将 PM100 利用率从 ~80% 推到 ~100% 当作核心成功信号，但它同时报告每作业平均功率 −2%、作业规模 −5%，这个组合更像是作业混合被改变而非同样的工作被更高效地做完 [2508.20016]。两侧的教训相同：孪生优化的那个标量，其物理含义必须先被审计一遍。

(e) 负载形状（agent 侧）能把部署结论整个翻过来。 PDAF 相对不解耦的收益在 $I/O=1$ 是 $0.48\times$、$I/O=10$ 是 $2.10\times$——4.4 倍摆幅压缩在一个十倍程内，此后并非单调，$I/O=1000$ 回落到 $1.27\times$ [2608.03741]。而上下文长度并不是外生给定的量：agent 质量研究正在压缩它，本篇赖以成立的长上下文恰是另一条线正在努力消除的东西 [2608.03741]。多轮/agentic 侧新进来的三篇把这条交错变得更具体：PPD 指出多轮下 99% 的 prefill 计算花在重算历史 KV 上 [2603.13358]，ConServe 指出同一负载在 turn 粒度上不规则而在 conversation 粒度上稳定（一次 compute-bound 的 turn-1 prefill + 一条长的 memory-bound 尾巴）[2606.01839]。这意味着 2608.03741 的 $I/O$ 比值不只是负载属性，还是"你在哪个粒度上统计它"的函数——同一条 trace 按 turn 统计与按 conversation 统计会给出不同的 $I/O$，因此会落在穿越点的不同侧。OC5 因此比原来更尖锐。

(f) 模型架构参数直接进入部署判据。 kv_lora_rank 从 128 扫到 4096 使 PDAF 收益上升 67%–147%（机制是 rank 太小时 decode-attention 由权重读主导、结构上与 decode-FFN 无法区分）；num_active_experts 增至 8× 使收益崩塌 60%–73%；降精度则分裂三个模型（+57% / −41% / −42%）[2608.03741]。这条把 model 类目直接接进了本主题的判据。

(g)（新增）目标函数下移到物理层之后，"孪生"这个词的所指发生了变化。 serving 侧的孪生建模的是同一个系统的更便宜的副本（影子化主循环、算子级映射图快照），因此它的误差可以对着被建模系统直接测量；HPC 设施侧的孪生建模的是一条跨层因果链：调度决策 → 节点占用 → 功率（含整流与变换损耗）→ CDU → 冷却塔回水温度 → PUE [2508.20016]。这条链上只有最后一环有一个真实锚点（Frontier 的 PUE 均值 ≈1.06 脚注），中间三环没有独立校验。后果不是"精度更差"，而是误差不可归因：Fig. 4 的 80%→100% 利用率对比在构造上就对 replay 不利（共享节点作业被过滤、缺 down/drained 节点信息），作者诚实承认并把 Frontier 的利用率优势归因于数据缺失而非策略优越，但诚实不等于证据——backfill 的收益量级目前不可归因 [2508.20016]。这与 §6.3 描述的 serving 侧"最优点邻域失真"是两种不同的失效：一种是精度在关键区域退化，另一种是精度无法被定位到某一环。

(h)（新增）保真度的验证方式分野，会直接决定一篇工作能对谁说话。 有真实系统 trace 可回放的一侧（S-RAPS 的五个 top-tier 系统数据集）可以做一件 serving 侧做不到的事：把"低负载下策略无关"这个空结果当作功率模型预测保真度的独立验证——Adastra 15 天所有重排曲线塌成一条线，而模拟功率与观测功率的升降时刻仍然对齐 [2508.20016] [2508.20016]。这是本主题里少有的"用负结果换取校验"的手法。反过来，自建解析模型的一侧可以做 HPC 侧做不到的事：对一个尚不存在的器件目录求值 [2608.03741]，或者把误差-决策质量的传导关系直接扫出来（30% 估计误差 → ≤1.5% 尾延迟退化 [2605.16637]）。两侧的可证伪性是互补而非可比的，这也是 §8 判定"证据门槛没有随论文数量抬高"时必须分两侧读的原因。

(i)（新增）调度单元的选择先于模型的选择。 本次进来的五篇 agent/多轮工作给出了同一条元结论：HexAGenT 把单元提到 workflow（在线揭示的 DAG + horizon $H_w(t)$）[2605.16637]，Scepsy 提到 workflow 的聚合份额（放弃控制流建模）[2604.15186]，ConServe 提到 conversation（于是预测变得不必要）[2606.01839]，HexGen-Flow 提到带阶段依赖的 agentic workflow [2505.05286]，而 DynaServe 反向把单元切到 token 边界以下 [2504.09285]。HPC 侧的两篇在这一维上完全不动——单元恒为作业、整节点、不可分割 [2512.18894]，因此 SchedTwin 只能在"策略池"这一维上找自适应性，其上界被池内成员逐周期最优组合锁死 [2512.18894]。这是 HPC-vs-serving 分野里最有行动含义的一条：serving 侧的主要自由度是重新定义调度原子，而 HPC 侧的主要自由度是重新定义目标函数（激励结构、EDP、公平性）。 两侧各自把对方的自由度当成了常量。

(j)（新增）"历史只追加"这个被普遍默认的前提正在被打破。 本主题所有前缀/adapter/KV 相关的模型都隐含假设上下文单调增长，因此缓存命中与显存占用可以按前缀树推理。Leyline 把 agent 的消息改写（删/替换/截断工具输出、压缩历史、插入 stub）显式提升为服务端指令，并用闭式 RoPE $\delta$-rotation 让 in-place 编辑后的下游缓存仍位置正确 [2606.01065] [2606.01065]。一旦这类原语被采纳，孪生里"KV 占用随轮次单调增长"与"前缀命中可由 trie 推出"两条都不再成立——这与 OC3 是同一类风险，但方向相反：OC3 担心被优化的悬崖被上游删掉，而这里是被建模的单调性被上游打破。

(k)（新增）孪生本体是什么、它的保真度锚在哪里——一条与"模型距离决策回路"正交的第三轴。 本主题此前两条轴分别是"模型距离决策回路"（§1）与"被建模的因变量停在哪一层"（§2.1）。TokenSim 逼出第三条：被建模的对象是什么，以及它的保真度用什么来校验。 三点值得钉住。其一，被建模的是服务运行时而非硬件。 旧的 LLM 推理仿真器（GenZ、LLMCompass）只吃单请求或单 batch、只报单条 test case 的延迟与内存，而真实 serving 面对成百上千并发请求、内存随请求进出动态变化 [2503.08415]；TokenSim 把 continuous batching、分页 KV 分配、抢占与重算、准入、KV 存取与跨 worker 迁移、排队全部建进离散事件回路——它仿的是运行时的行为，不是芯片的峰值。其二，调度策略与硬件时间模型被彻底解耦：算子级 breakpoint + 两级调度器让 disaggregation 这类跨 worker KV 迁移只需两行代码表达，同一引擎因此能覆盖 continuous batching / 分离 / 内存池三类结构迥异的优化而不改内核 [2503.08415]——这正是它的仿真结果可迁移到真实引擎的原因（调度语义与被仿引擎同构，而非另造一套）。其三，保真度的锚是与真实开源引擎的端到端对齐：对 vLLM v0.6.2（LLaMA2-7B / A100 / 2000 条 ShareGPT）throughput 几何平均误差 0.109%、P50/P99/max 延迟 <1%，延迟 CDF 与真机高度重合 [2503.08415]。这是本主题第三种保真度证据类型（区别于 §6.2 D6 的"真实 trace 回放"与"自建解析 + 局部数值比对"）：既非回放生产 trace、也非纯解析式，而是让一个通用仿真器在公开数据集上跑同一档负载、直接对齐一个活的开源引擎的端到端分布。它的软肋也随之明确——保真度只在被对齐过的机制上成立：抢占式调度（FastServe 式 skip-join MLFQ + proactive swap 的 7× 内存峰值）、可压缩/带宽自适应的 KV 传输（CacheGen 式）都在其未验证之列 [2503.08415]，因此"运行时全都仿得准"这句话对未被对齐的机制不能外推。

6. 共识与分歧 #

6.1 四篇一致的五条 #

C1 — 模型不是加速器，而是使问题在数据上可解的唯一环节。 这是本主题的立论共识：真机每点一小时、训练网格是四重笛卡尔积，真机路线在时间上不成立 [2602.24044]；87,198 次模拟对 882 次真机 [2508.08343]；四个子阶段 × 硬件 × 并行 × 副本数在共享预算下组合爆炸，真实集群上无法穷举 [2608.03741]；秒级窗口容不下分钟级的重调度，决策必须在毫秒内出 [2608.15762]。（增补）新进的十二篇里，最强的一条同型论据来自生产系统而非组合爆炸：在生产系统上把 FCFS 换成 priority+backfill 以观察机房功率响应，意味着可接受的服务中断，因此孪生是唯一的实验场 [2508.20016]；Scepsy 的版本是 2900 万条候选映射，搜索必须靠廉价预测器压到 ≤70 s [2604.15186]。但这条共识首次出现了明确的反例：ConServe 主张换调度单元即可让预测不必要（见 D5），MFS 主张用可直接测的代理量替代 laxity 估计 [2603.17456]。C1 因此应被降格为"当决策空间不可枚举且调度单元已固定时成立"。

C2 — 保真度来自结构分解，不来自一个全局公式。 见 §4 汇合点的三处方程比对 [2602.24044] [2608.15762] [2608.03741]，以及单卡版本把加载时延做成查表而非拟合式（因为对尺寸是分段离散的、disk/CPU 是两个截然不同的常数带）[2508.08343]。（增补）PPD 把这条推到端点：整个决策函数被离散化成一张离线 profiling 出的网格表，在线只做最近邻映射 [2603.13358]；Scepsy 则把分解粒度反向粗化到两个标量 $(n_m, p_m)$，依据是相对份额比绝对延迟稳定约 4× [2604.15186]。HPC 侧不共享这条共识：S-RAPS 与 SchedTwin 都不做成本分解，直接跑全量 DES 加物理模型，见 §4 第二汇合点。

C3 — 四篇全部没有最优性或鲁棒性界。 NP-hard 只是引用装箱文献的一句断言，贪心的近似质量完全靠实验 [2602.24044]；单卡版本连闭式吞吐模型都没有 [2508.08343]；两阶段搜索是贪心的，与全局最优的差距一个字都没说、top-$K$ 的 $K$ 也未给出 [2608.03741]；有完整仿真器却没有任何最优性论述，而离线穷举得 oracle 再度量在线贪心 gap 几乎零成本 [2608.15762]。（增补）这条在十六篇上依然成立，且 HPC 侧的形态更刺眼：SchedTwin 用"静态启发式的 one-step 决策 provide no guarantees of near-optimal performance"否定基线，而它自身是"one-step over policies"——无界 rollout 只用于打分、commit 仍只有一步，单调性/最优性检查不通过且未讨论 [2512.18894]，即用同一份论证标准施于自身则不成立 [2512.18894]。S-RAPS 更进一步：它声明了一个相变（低负载策略无关 / 高负载策略强相关）却不给相变边界的任何解析刻画，哪怕只是到达率-服务率比与作业规模分布的两参数判据 [2508.20016]。唯一的部分例外是 SPECTRE，它有闭式的临界 $r^*$，但那是模式切换的临界点而非调度质量的界 [2605.08151]。

C4 — 校准层级低于结论层级。 roofline 的唯一直接验证是算子级 TFLOPS，端到端行为论文自陈未验证 [2608.03741]；仿真精度证据取自 Llama3-8B 训练图、PP=2、2 张卡，与目标场景（多租户服务、8 卡）是不同的负载类别与规模 [2608.15762]；分布式 adapter 放置只测到 4 卡，贪心 first-fit 的决策质量随 GPU 数增长未被评估 [2602.24044]。唯一的例外是对抗性非平稳到达下的 running/waiting 队列时序验证，它证明的是瞬态耦合而非稳态均值 [2602.24044]。（增补）HPC 三篇把这条推到本主题的最低点：SchedTwin 的"a few seconds per scheduling cycle"是设计推断而非测量，全文无一个调度周期时延数字 [2512.18894]；S-RAPS 报告的 688× 实时来自顺序耦合，而实时孪生必须走的 plugin 模式速度从未被报告，两份系统状态副本的一致性只有一句话 [2508.20016]；DECICE 的"5000×5000 内 300 s"是模型训练+验证时间而非在线调度决策延迟，后者从未报告，且 300 s 的余量只有 0.7% [2605.25292]。三篇 HPC 工作的共同形态是：把开销当作可由架构推导的属性（并行 ⇒ $\max$ 而非 $\sum$），而 serving 侧把它当作必须测量的属性。

C5 — 版本绑定的重参数化是真实税负。 调度器时延项的函数形状是从具体调度循环里逆向出来的经验形状，作者自认"currently limited to vLLM"，换引擎或换大版本要重做形状发现而非重新拟合常数 [2508.08343]；加载时延常数是强框架版本依赖的，换 zero-copy 路径后整个孪生要重新参数化 [2602.24044]；每换一个 (模型, 硬件) 组合就要重标定一整套性能模型 [2508.08343]。（增补）HPC 侧的等价税负不在版本而在数据可得性：S-RAPS 自陈当前硬约束是"the current need of job traces, and power profiles"，且数据集里没有预留、作业依赖、down/drained 节点信息，这三项缺失就是当前的精度天花板 [2508.20016]；接入自家系统的成本被压到"写一个 dataloader 插件"，但冷却分析要求先有一个 Modelica 模型，而"No open cooling model was available at the time of writing, e.g. for PM100" [2508.20016]。这是一条比版本绑定更硬的税：版本绑定可以靠重标定解决，而开放冷却模型的缺失使 §2.1 那条最有价值的证据链目前只能在一台不公开的机器上成立。

6.2 四条真分歧 #

D1 — 该学还是该解析？根源是被建模量的性质不同，不是方法论优劣。 2608.03741 用纯解析 roofline，输入是器件规格表 [2608.03741]；两篇 adapter 工作必须学，因为要预测的是 $Max_{pack}$ 悬崖的位置，而这个拐点随 adapter 尺寸、到达率、静态上限剧烈漂移、越界即 OOM 或饿死，没有静态代理量可用 [2602.24044]。可迁移的判据在 2602.24044 里被明确写成一条规则：先判断被建模量是硬件静态量还是负载依赖量，再决定要不要学 [2602.24044]。SliceScheduler 落在中间——用线性回归但样本变异系数只有 0.62%/1.63%，是负载的确定性而非回归模型的精巧支撑了整个仿真器 [2608.15762]。（增补）这条分歧现在需要扩成三分：学 / 解析 / 都不建。 第三支由 MFS 代表：它面对的量（flow 的 laxity）既非硬件静态量也不便学习，于是改为构造两个可在交换机上直接算的代理量——MLU（最小链路利用率，决定 explicit-deadline flow 何时提权）与 RLI（相对层索引，决定 implicit-deadline flow 的相对紧迫度）[2603.17456]。DECICE 落在"想学但没给选择规则"的空档：它有策略池（AI / Heuristic / Gang）却没有任何阈值或决策树来决定何时用哪个，而它自己的 benchmark 里已经有现成的判别特征（依赖数：精确解算器 WF1→WF3 敏感度 8.4–23.5×，启发式仅 1.0–1.4×）[2605.25292]。判据可以更新为：先判断被建模量能否被一个可直接测量的代理量单调替代；能，则不必建模；不能，再问它是静态量还是负载依赖量。

D2 — 误差的方向该不该被设计进去？这是一条直接冲突。 SliceScheduler 明确指出自己的仿真器高估（1.945 s 对实测 1.910 s）而对照系统低估，并论证高估是安全侧——预测偏悲观只会让调度更保守，不会把算子塞进实际装不下的洞里 [2608.15762]。2602.24044 的 starvation 分类器面对的是完全同型的问题、且两个方向的代价严重不对称（假阳性导致真实饿死，假阴性只是多用一张卡），却用了对称的 macro-F1；简化后 F1 降 0.025 恰好落在这个承载安全性的头上，实测确实产出了导致饿死的放置 [2602.24044]。两篇对"误差不对称是不是一等公民"给出了相反的工程答案。（增补）HexAGenT 提供了第三种答案：不设计误差方向，而是直接测量误差的传导。 它把估计器误差人为注入到 30% 并报告尾延迟只退化 ≤1.5% [2605.16637]。这条经验鲁棒性曲线不是界（见 C3），但它是本主题里目前唯一一份"误差 → 决策质量"的实测映射，比"高估即安全"的定性论证更强、比形式化界更弱。HPC 侧对这条分歧完全沉默：SchedTwin 的 Score 连量纲一致性与方向性两项最小检查都不通过（秒与无量纲 slowdown 等权相加、Score 越小越好而选择规则取 argmax），因此"误差方向"在它这里还谈不上是一个议题 [2512.18894]。

D3 — 仿真器该拥有运行时还是影子化运行时？ 影子化（两篇 adapter 工作）意味着不改一行 kernel、不改调度器、不是 fork，采纳动作只是改一个启动参数加接一组规则进部署脚本 [2508.08343]，代价是 C5 的版本绑定税，以及所有内部指标依赖未量化的插桩改动 [2602.24044]。拥有运行时（SliceScheduler）意味着快照精确、调度层开销 0.0%，代价是禁止多流并发、投机、动态 shape，迁移成本是"换掉整个后端"而非"换一个调度插件" [2608.15762]。两条路线在采纳成本上差两个数量级，且不可互相转化。（增补）HPC 三篇全部站在影子化一侧，且比 serving 侧的影子化更彻底：SchedTwin 是旁挂进程，事件经 Redis stream 下行、决策经 qrun 上行，约 1,000 行代码扩展 CQSim，零调度器内核改动 [2512.18894]；S-RAPS 的姿态被明确写成"we do not compete but try to enable them"，接入成本压到写一个 dataloader 插件 [2508.20016]。但影子化在 HPC 侧的代价被暴露得更清楚：外部调度器必须能应答"给定时间步的运行作业列表"，ScheduleFlow 正是在这个约束上性能崩掉的，而且它会把作业排到不可用节点上、根因未查明——这是两份状态副本漂移的竞态实证 [2508.20016]。结论可以更新为：影子化的真实代价不是版本绑定，而是状态对账层；这一层在 serving 侧表现为重参数化，在 HPC 侧表现为竞态。

D4 — 结论该是正面主张还是成立条件？ 三篇默认自己的机制永远有正收益，实验只回答"收益多大"；2608.03741 是唯一给出"什么时候收益为负"的——$I/O=1$ 时八个模型无一越线，AF 单独用在两个设计空间、所有比值、所有模型上从未超过不解耦基线 [2608.03741]，而这个否定结果比它的肯定结果更稀缺 [2608.03741]。这条分歧对本主题的整体可信度最关键：一个能被用来证伪自己的模型，和一个只被用来找赢点的模型，是两种不同的东西。（增补）HPC 侧在这条分歧上出人意料地站在 2608.03741 一边，且提供了本主题最干脆的两个空结果：S-RAPS 报告 Adastra 15 天低负载下所有重排曲线塌成一条线、策略无关，并把这个失败区当作定位而非缺陷 [2508.20016]；它还主动折扣自家最醒目的结果，把 Frontier 的利用率优势归因于缺失 down/drained 节点数据而非策略优越 [2508.20016]。反面是 DECICE：五页正文里无 limitations section、无负结果表，三个被点名的用例（cloud robotics / scientific computing / edge inference）零量化数据，其中 edge inference 连 owner partner 都未指定 [2605.25292]。因此判断标准（"它有没有报告自己什么时候会输"）在新一批里区分度依然最高，且与论文类型强相关：项目综述型论文系统性地不报负结果。

D5（新增）— 该建更好的模型，还是该换一个让模型变得不必要的调度单元？ ConServe 的核心主张不是机制而是一条元命题：对预测的依赖是调度单元的属性，不是负载的属性。同一条 agentic trace 在 turn 粒度上不规则（decode 长度、工具行为、KV 增长都在调度器动作时不可观测，因此必须预测，而任何预测器最终都会误路由），在 conversation 粒度上却塌回经典的两相结构，于是放置只需读两个可观测信号：离线 profiling 出的确定性 prefill 延迟曲线（按 turn-1 输入长度索引）与每 decoder 的活跃 KV 占用；不需要任何学出的 decode 成本模型 [2606.01839]。它还顺手指出一个本主题普遍存在的调度-价值错配：系统在优化 per-turn TTFT/TBT，而用户只读会话的最终有效输出，多数中间轮次发出的是没人看的工具调用 [2606.01839]。这与本主题前四篇的立场直接冲突——它们都把调度单元当作给定的，然后在这个单元上建模型。分歧根源是自由度的排序：如果调度单元可改，那么"先粗化单元、再看还需不需要模型"严格支配"在细单元上建更准的模型"，因为前者同时消掉了预测误差与误差传导（ConServe 的设计里放置一旦下达就永不重访 [2606.01839]）。而 HPC 侧的两篇恰好没有这个自由度：单元恒为作业、整节点、run-to-completion [2512.18894]，所以它们只能走"建模型/跑 rollout"这条路。可迁移的判据：先问调度单元能否上移到一个使关键量变为可观测的粒度；只有回答为否，才需要孪生。

D6（新增）— 孪生保真度该用真实 trace 回放证明，还是用自建解析模型 + 局部数值比对证明？ 这不是精度之争而是证据类型之争，且两侧目前都不承认对方的证据形式。真实 trace 回放一侧（S-RAPS）的优势是负载真实且覆盖五个 top-tier 系统、可回放亦可重排、并把"预填充"提升为正确性要求（仿真起点前已在跑的作业必须被放置，否则队列预热会污染结论，论文点名同行忽略这一点）[2508.20016]；劣势是被建模的物理量几乎没有 ground truth，整条"调度 → 功率 → PUE → 回水温度"链只有末端一个 ≈1.06 的脚注锚点，而这条最有价值的证据链依赖唯一不公开的数据集 [2508.20016]。自建解析模型一侧的优势是可以对不存在的系统求值、可以把误差-质量传导直接扫出来；劣势是负载多为合成或单条 trace，且校准层级系统性低于结论层级（C4）。两侧还各有一个自我背离的样本：SchedTwin 有真实 Polaris trace 却只用它 motivate、评测全用合成 trace [2512.18894]；SliceScheduler 有完整仿真器却把校准证据取自不同负载类别与规模（Llama3-8B 训练图、PP=2、2 卡）[2608.15762]。这条分歧的实际后果是可比性归零：两侧论文无法互相证伪，因为它们连"什么算作保真度证据"都不共享。§7 OC6 把它列为一个独立的根本性困难。（2026-09 增补）TokenSim 引入的是第三种证据形式，它落在这两侧之间：既非回放生产 trace、也非纯自建解析式，而是让一个通用仿真器在公开数据集（ShareGPT）上跑同一档负载、直接对齐一个活的开源引擎（vLLM v0.6.2）的端到端延迟分布，throughput 误差 0.109%、延迟 <1% [2503.08415]。它比自建解析式硬（对齐的是真机端到端 CDF 而非算子级 TFLOPS），又比生产 trace 回放易复现（负载来自公开数据集、纯 CPU/SimPy 可跑）。但它引入了自己的一处内部不一致——§III-C 报 <1% 而 Table II 的数值量级（2.7~13）随请求数单调增长、更像总耗时(秒)而非百分比误差，论文未调和 [2503.08415]——因此这第三种证据形式的可信度也仍需读者自行折扣。

D7（新增）— 孪生的目标函数该停在 SLO/利用率，还是继续下移到功率、公平性与激励？ serving 侧十三篇的因变量全部停在 SLO、goodput、TTFT/TPOT、GPU 张数；HPC 侧三篇把它下移到功率摆幅、PUE、冷却塔回水温度、EDP/ED2P，并且 S-RAPS 还把激励结构做成了调度输入——两阶段实验（replay 作收集期产出账户历史，赎回期五次运行从同一份历史派生优先级，含 Fugaku points 这类惩罚大功率作业的键）[2508.20016] [2508.20016]。DECICE 把能耗与碳强度提为一等调度输入，但全文没有一个焦耳或 gCO2 数字，架构完整而证据为空 [2605.25292]。分歧根源是液冷与计价口径：PUE 与回水温度只在液冷 CDU-冷却塔链路上有意义 [2508.20016]，而这恰是现代 GPU 集群正在走的方向；一旦 GPU 集群按焦耳而非卡时计价，serving 侧的目标函数就必须下移，而"每焦耳的 SLO 内请求数"这个目标目前没有任何 serving 系统在优化 [2508.20016]。这条分歧是本主题未来两年最可能被真实业务压力解决的一条，也是唯一一条两侧都承认对方目标合法、只是各自没有对方的状态源的分歧。

6.3 一处表面共识下的隐藏冲突 #

四篇都报告了各自的仿真器"够准"，但四篇都在同一个位置最不准——最优点邻域。孪生的 ITL 精度随 slot 数增大而恶化、TTFT 精度随到达率升高而恶化，即高负载 + 多 slot，正是最优配置所在的区域，而作者的 limitations 不提这条 [2508.08343]；TTFT 误差约 19% 且随 $\rho$ 增大而放大，与 $1/(1-\rho)$ 敏感性一致 [2602.24044]；点对点原语随规模收敛到 $1.00\times$ 而 EP all-to-all 反向发散到 $1.21\times$，两个原语共用一套带宽模型，而 MoE 的 decode-FFN 正是 EP 流量所在 [2608.03741]。这不是四个独立的实现缺陷，见 §7 OC1。

（增补）HPC 侧的同型现象出现在开销侧而非精度侧。 SchedTwin 的开销界 $\max_i$（而非 $\sum_i$）成立的前提是 $k$ 路 rollout 真并行；但终止条件是"跑到队列排空"，因此 $\max_i$ 随队列长度而非策略数增长——而队列长度恰恰在高到达率、长队列、即最需要自适应的区间里最大。这条曲线全文没有测过 [2512.18894]。形状与 serving 侧完全一致：模型最需要发挥作用的负载区间，正是它自身的保证最先失效的区间。 区别只在失效的是精度还是预算。

7. Open challenges（根本性困难） #

OC1 — 最优点与失真点在结构上重合 #

为什么难。 这不是"没人做"，而是目标函数把系统推到了模型假设最先失效的地方。所有四篇的最优解都定义在可行性边界上：吞吐达入流 90%（即 $\rho\approx0.9$）、slot 数取到显存墙前一格、batch 推到饱和区、功耗预算刚好用尽。而排队时延对 $\rho$ 的敏感性是 $1/(1-\rho)$，未建模效应（排队、抢占、CPU 争用、集合通信）的相对权重在这个区域按同样的形式放大。因此"把仿真器做得更准"不能收敛地解决问题——每提高一点精度，最优点就被推得更靠近下一层未建模效应的边界。

证据。 见 §6.3 的三处误差结构。以及一个直接后果：在 CPU 充裕（约 20:1 的核卡比）下拟合的调度器常数迁移到低配比节点后，starvation 分类器会系统性乐观，而整篇论文的安全性完全由这个分类器承载 [2602.24044]。（增补）第二个后果在 HPC 侧的开销侧：rollout 成本随队列长度增长而调度周期随到达率缩短，两者在高负载区同时朝坏的方向走 [2512.18894]。

需要哪些类目协作。 framework（导出运行时状态）+ cluster（把节点资源配比纳入特征）+ hardware。论文自己指出了硬件侧的缺口：如果运行时能暴露一个廉价的一致执行快照（当前算子 ID + 显存驻留集），整套重建论证就无需成立，多流并发也可以同时保留 [2608.15762]。这是一个跨越软硬件边界的接口需求，不是任何单篇能解决的。

已有的部分尝试为何不够。 对抗性非平稳到达下的队列时序验证是本主题里最强的保真度证据，但它验证的是累积吞吐动力学，而 TTFT 复现的是单请求准入时刻——后者误差 19%、且随负载升高而发散 [2602.24044]。也就是说现有的最好证据恰好不覆盖延迟 SLO 这一维。难度视界：3–5 年，因为它需要的是运行时可观测性接口的标准化，而不是更好的建模。

OC2 — 非对称代价下的可行性预测，且带界 #

为什么难。 可行性判据（会不会饿死 / 会不会 OOM）无法解析推导——加载时延与显存上界都只能查表 [2602.24044]，所以只能学；一旦学，就有假阳性，而假阳性的代价是服务崩坏、假阴性只是多用一张卡。更棘手的是误差不是逐决策独立的：oracle 误差通过回滚-重排队机制在 adapter 序列上传播，因此"当预测误差 < ε 时放置质量不超过最优解 k 倍"这类命题的证明比标准贪心分析困难得多 [2602.24044]。

已有的部分尝试为何不够。 代价敏感训练与保守侧置信阈值是现成的修复，但它只降低假阳性率、不给界；离线穷举得 oracle 再度量在线 gap 也是现成的（且几乎零成本）[2608.15762]，但它给的是经验 gap 而非误差到质量的传导界。（增补）HexAGenT 已经把"经验 gap"这一档做出来了：注入 30% 估计误差后尾延迟退化 ≤1.5% [2605.16637]，这是本主题目前最接近 OC2 的证据；但它测的是误差幅度而非误差方向，因此对"假阳性导致饿死"这一非对称结构依然无话可说。ConServe 从另一侧给出了一条绕过路径：把放置做成"提交一次、永不重访"，从而在结构上消掉误差传导 [2606.01839]——代价是失去了纠正错误放置的能力，与 HPC 侧无抢占的困境同型 [2512.18894]。需要 framework + cluster 协作（判据的物理来源在框架内部，代价结构在集群运营侧）。难度视界：1–2 年——这是本主题里最接近可解的一条。

OC3 — 被优化的悬崖可能是上游随时会删掉的 artifact #

为什么难。 这不是建模精度问题，而是投资判断问题：在为一个约束建一套完整的模型-数据-决策链条之前，必须先判断这个约束是物理的还是实现遗留的，而这个判断没有系统化方法。当前证据指向"实现遗留"：静态上限是启动期参数、不是物理约束，本主题的两篇 adapter 工作是在为一个可以被删掉的参数寻找最优值 [2508.08343]；如果 adapter 显存改成动态池，决策变量本身消失、悬崖被削平、整个优化对象蒸发 [2602.24044]。换一个为上千 adapter 设计的框架后，同一现象的幅度只剩 15–20% [2508.08343]——问题存在但被削弱了。

（增补）新进的两批工作各给了这条一个新实例，方向相反。 一是 ConServe 式的削平：整个"per-turn 是否解耦"的预测问题在换到 conversation 粒度后消失 [2606.01839]——即上游不必改代码，只要改调度单元的定义，下游一整套模型就贬值。二是 Leyline 式的打破：一旦 KV 编辑指令被采纳，"上下文单调增长"这条被所有前缀/占用模型默认的不变量就不再成立 [2606.01065]。因此 OC3 应被读成双向的：孪生既可能因为被建模的悬崖被削平而贬值，也可能因为被建模的不变量被打破而失效。

需要哪些类目协作。 framework 与 cluster 之间需要一个契约：哪些配置参数是长期稳定的接口、哪些是临时实现。目前没有这样的契约，于是每一代框架都会重新制造一批这样的旋钮，也重新制造一批为它们建模的工作 [2508.08343]。难度视界：不收敛——这是一个随框架代际周期性复发的结构性问题，而不是一个可以被解决一次的问题。

OC4 — 模型主张的规模恰恰是不可验证的规模 #

为什么难。 建模的全部意义就是对建不出来的配置作推理，因此"在主张的规模上验证"与"使用模型的理由"在定义上冲突。当前的三个具体表现：$N\approx62$ 是从 8 卡单机推出的纯纸面外推，集中式 master 的反馈延迟、状态陈旧、真实执行偏离重建状态时的行为全部未建模也未测量 [2608.15762]；贪心装箱只测到 4 卡且跨节点后"请求路由免费"的假设会失效 [2602.24044]；面向一个尚不存在的器件目录，因此既无代码又无端到端真机结果，正确定位是设计空间探索报告而非采购依据 [2608.03741]。

（增补）HPC 三篇把这条表现得最直白。 SchedTwin 的"32 节点集群"实际是单台 48 核主机上的 33 个 Docker 容器构成的伪集群，而 $\max_i$ 开销界成立恰恰依赖核数充裕，$k$ 增大或队列变长后这个前提就不成立 [2512.18894]；DECICE 的 5000×5000 只测到一个点、余量 0.7%，而论文自己的 future work 要求"thousands of tasks 的生产 workload" [2605.25292]。唯一的正面样本也在 HPC 侧：S-RAPS 的复现预算是数小时、硬件要求是"Laptop capable of running python 3.9+"，无 GPU 无集群 [2508.20016]——它把外推问题转化为"接一个新 dataloader 即可在你自己的真实系统上重跑"，这是本主题里唯一一条不依赖外推的可信度路径。

已有的部分尝试为何不够。 目前唯一的替代是把扩展性写成解析式（如调度及时性 $t=(Nl+1)/(sg)$），但该式对全部四个变量严格单调、无内点极值，因此它只给出一条约束线而非最优点，且从未在变化的 $N$ 上被测量 [2608.15762]。难度视界：未知，因为它要求的是一种"模型外推可信度"的方法论，而这在系统研究里尚无公认范式。

OC5 — 负载形状被当作外生变量，但它正在被另一个社群主动优化 #

为什么难。 服务侧模型把负载形状当成给定的经验分布并据此定型硬件；质量侧研究把同一个量当成待优化的自由度。两者的目标函数不共享，且没有任何一篇同时优化 (成功率, tok/s) [2608.03741]。后果具体且已经可见：论文实测过的两个真实工作负载换算成它自己的 $I/O$ 定义分别约 7.6 与 3.2，都落在它自己的穿越点以下，即按本文自己的曲线读 PDAF 都不该赢 [2608.03741]。更结构化的问题是：真实部署的负载形状不是标量而是重尾分布，而在穿越点附近曲线强烈非线性，"对分布取期望收益"与"对期望取收益"不相等 [2608.03741]。

（增补）这条现在多了两层。 第一层是统计粒度：同一条 trace 按 turn 与按 conversation 统计会给出不同的 $I/O$（见 §5(e)），因此"负载形状"这个外生量连定义都依赖调度单元的选择 [2606.01839]。第二层是负载形状可被服务层自己改变：PPD 的 append-prefill 路由把 Turn 2+ 的 prefill 成本从"重算 99% 的历史"降到增量 [2603.13358]，Leyline 的编辑指令直接改写上下文长度 [2606.01065]。也就是说 $I/O$ 既被 agent 侧的上下文工程压缩，也被 serving 侧自己的缓存机制改写——它不是一个外生变量，而是一个被两侧同时作用的内生量。

需要哪些类目协作。 agent（上下文工程）+ model（架构参数）+ framework（前缀复用层）+ 本主题的 cluster 侧容量规划。一个复用层就足以把系统从穿越点右边推到左边 [2608.03741]。难度视界：2–3 年，主要障碍是服务侧论文普遍不测任务成功率，因此联合目标函数目前连测量口径都没有。

OC6（新增）— 两侧的保真度证据类型互不承认，因此不存在可比的孪生质量刻度 #

为什么难。 这不是"没人验证"，而是两侧对"什么算作保真度证据"的定义不相交（D6）。HPC 侧的证据是真实系统作业 trace 的回放/重排可对齐，且把"预填充"提升为正确性要求 [2508.20016]；serving 侧的证据是局部数值比对（算子级 TFLOPS、队列时序、19% 的 TTFT 误差、变异系数 0.62%/1.63%）与误差注入鲁棒性 [2608.15762] [2605.16637]。两类证据无法互相转化：真实 trace 回放不能验证一个不存在器件的 roofline，而误差注入实验不能验证 PUE 这类积分量的长程漂移。后果是本主题无法回答"这两个孪生哪个更可信"，而这恰是任何想复用别人孪生的团队要问的第一个问题。

为什么不是工程问题。 因为两侧的缺口位置由各自的可观测性天然决定，不是投入不足。HPC 侧缺物理量 ground truth 的根因是开放冷却模型不存在（"No open cooling model was available at the time of writing, e.g. for PM100"）且唯一有验证过冷却模型的系统数据集不公开 [2508.20016]；serving 侧缺真实负载覆盖的根因是生产 trace 的所有者不发布、且引擎版本绑定使旧 trace 迅速失效（C5）。两个根因都不在论文作者的控制范围内。

已有的部分尝试为何不够。 三个现成的锚点各自只覆盖一段：Frontier 的真实 PUE 均值 ≈1.06 是一个标量、不含动态 [2508.20016]；对抗性非平稳到达下的队列时序验证覆盖瞬态耦合但不覆盖延迟 SLO [2602.24044]；30% 误差注入覆盖幅度但不覆盖方向 [2605.16637]。最便宜的一步是明确的、且两侧都没做：把真实 serving trace 回放接进带液冷物理模型的孪生，用实测 PUE 与回水温度对齐——S-RAPS 的调度器契约只要求外部组件能应答"给定时间步的运行作业列表" [2508.20016]，而 serving 侧已有多个能应答这个问题的仿真器 [2508.20016]。需要 framework + cluster + hardware（液冷链路）协作。难度视界：2–3 年，其中技术部分约半年，其余是数据与模型开放的协调成本。

8. 成熟度判断 #

总体判定：research-frontier，其中恰好一个组件已具备生产形态。

证据一：开源与真机证据处在本主题最弱的一档。 四篇里只有 2508.08343 公开了代码仓库 [2508.08343]；2602.24044 的仓库承诺公开但截至抓取时无可引用内容，且三方对比中有两方是作者重实现 [2602.24044]；2608.03741 未公开且依赖三个外部组件才能复现，是同组里唯一既无代码又无端到端真机结果的一篇 [2608.03741]；2608.15762 无 artifact 声明、无仓库、无 LoC 统计，四个基线全部由作者自行实现 [2608.15762]。加上 2508.08343 与最接近的工作零头对头对比、论文主动承认并推给未来工作 [2508.08343]，本主题的横向可比性整体偏弱。（增补）新进的十二篇没有抬高这一档，而是把它分成了两种不同的弱。 serving 侧有实打实的开源与真机（HexGen-Flow 有 GitHub 仓库 [2505.05286]），但基线多为作者自建。HPC 侧则出现了本主题最严重的一类问题：SchedTwin 把"implementing SchedTwin as open-source software"列为三大贡献之二却全文无仓库 URL，唯一可定位的代码是被扩展的 CQSim，因此那三个策略选择百分比不可复现——"声称开源但等同未公开"比坦白未公开更糟 [2512.18894]；DECICE 只给出组织级入口而无仓库名/模块路径/commit，artifact 声明不可执行 [2605.25292]。S-RAPS 是反例且是本主题最干净的一份：代码在 code.ornl.gov/exadigit/raps 三个分支、复现预算数小时、依赖只有 Python 与常规科学栈，但核心论点（PUE/回水温度分叉）依赖不公开的 Frontier 数据集，画像是"框架可复现，核心论点不可复现" [2508.20016]。

证据二：真正成熟的不是决策器，是仿真器本身。 纯 CPU、≤1 核、~200 MB、90× 实时的资源画像，使它足以进 CI 做容量回归，用途远超生成训练数据；这是本主题被低估、也最可迁移的一块 [2508.08343]。它同时是唯一被真机验证过瞬态队列动力学的仿真器 [2602.24044]。若要给本主题挑一个"可以今天就用"的产物，是它，而不是任何一篇的调度算法。（增补）HPC 侧提供了第二个同型产物，且成熟度更高：S-RAPS 的 688× 实时（顺序耦合）、笔记本即可运行、五个真实系统的 dataloader 已就绪，接入自家系统只需写一个插件 [2508.20016]。两个产物的共同点值得记住：它们都是"便宜到可以每天跑一遍"的仿真器，而不是任何一篇的调度器。 本主题的可复用价值集中在孪生本体这一层，这个判断现在有两个独立来源支持。（2026-09 增补）TokenSim 是第三个、也是最直接的一个来源——它就是把"孪生本体"本身当作贡献的一篇。 它同样是纯 CPU/SimPy、无 GPU 即可运行、可插拔 compute backend [2503.08415]，开源于 github.com/pku-lemonade/TokenSim（论文自陈代码公开 [2503.08415]），但未声明 license——这对一个定位为"被下游直接扩建的共享仿真基座"的工具是一处实打实的采纳风险（法务不确定性会挡住企业内复用）。它与前两个产物的区别在于用途方向：2508.08343/S-RAPS 的仿真器是为各自的决策器服务的副产物，而 TokenSim 从设计上就是给别人当地基的通用工具，其价值恰恰体现在"被扩建而非被形似复现"（§5(k)、§4 其六）。三个独立来源共同把本主题的成熟点钉在同一层：可复用的不是调度算法，而是那个便宜到可以每天跑的运行时仿真器本体。

证据三：采纳成本在主题内跨两个数量级，且与价值密度反相关。 最低一端是改一个启动参数加接一组规则进部署脚本，无 kernel 改动、无调度器 patch、不是 fork [2508.08343]，但价值密度也最低（换来的是几个百分点的配置精度）[2508.08343]。最高一端是换掉整个后端且不能与现代服务引擎共存 [2608.15762]。中间一端（周期性重放置）声称 60% 的 GPU 削减，但那是跨场景均值而非任一具体场景的削减率，正文举的例子对应 50%/25% [2602.24044]。（增补）HPC 侧整体落在最低端：旁挂进程 + PBS hook + Redis + qrun，约 1,000 行代码，零调度器内核改动 [2512.18894]；或写一个 dataloader 插件 [2508.20016]。但价值密度与采纳成本的反相关关系在 HPC 侧被打破了：S-RAPS 的采纳成本最低而它回答的问题（换策略后的物理后果）没有任何替代手段，这是本主题里唯一一处"便宜且不可替代"的组合。

趋势方向：数量上加速，严谨度上分化（原判断为"持平"，需修订）。 七个月内进来三篇、跨三个类目，而且各自占据了"模型距离决策回路"这条轴上不同且互不重叠的位置，说明这条轴本身是真实的组织维度而非事后归纳。但最新的两篇恰好是真机验证最弱的两篇（一篇无端到端真机、一篇校准取自不同负载类别与规模），证据门槛没有随之抬高。（增补）扩到十六篇后，"持平"这个判断不再准确，正确的说法是分化： 一侧在变严（HexAGenT 报告误差注入鲁棒性、PPD 报告 27 个测试点的 per-metric winner counts、S-RAPS 主动折扣自家结果并保留 ScheduleFlow 的负面结果在正文 [2508.20016]），另一侧在变松（DECICE 五页无 limitations、三个用例零数据；SchedTwin 声称开源却无仓库、单一自造 trace）。分化与论文类型强相关，而不是与时间相关：机制论文在变严，项目综述论文在变松。 因此原来的单一判据需要加一条前置：先判断这是机制论文还是项目综述，再问"它有没有报告自己什么时候会输"。结论（保留并扩充）：作为方法论正在快速扩散，作为可部署系统尚未成熟；判断一篇新工作是否有增量，最有效的单一问题仍是"它有没有报告自己什么时候会输"，第二有效的是"它的保真度证据是真实 trace 还是自建模型，以及缺口在哪一环"。

9. 邻接 topic #

一处刻意留白（已被填上，此处保留原文并记录变化）。 原文写道：本主题目前完全没有覆盖高性能计算调度侧的同名方法族（那一支的孪生传统比 LLM 服务早得多，且以设施级能耗与冷却建模为主）；tag_filter 里保留了 digital-twin 与 simulation-guided-scheduling 两个足够宽的标签，scope_categories 预留了 model，因此那一支进来时可以直接并入 §4 的根 B 之外新增一条根，而不需要重写既有的四条结论；合并时唯一需要改写的是 §3 时间线的起点。2026-08 的这次增量正是该情形，且预案成立：新增了 §4 的根 D（并绕过汇合点 M、另立 M2），§3 时间线的起点前移了一层说明，既有的四条结论（C1–C5 中的 C2、以及 D1–D4）全部保留，只在其后追加了 HPC 侧的取值。新的留白：本主题仍未覆盖设施热流/冷却本体的建模一支（Modelica 冷却模型、autocsm 这类自动化工具只作为外部依赖出现 [2508.20016]），也未覆盖 GPU 集群的液冷侧实测——而 D7 与 OC6 都指向那里。tag_filter 已加入 power-cooling-cosimulation 与 energy-aware-scheduling 两个标签以便那一支进来时可被捕获。

10. 参考 #

按 §6 的分歧轴再钻一层：

• 该学还是该解析（现已三分：学 / 解析 / 不建模） → [2602.24044]（原判据）、[2608.03741]（纯解析一侧）、[2603.17456]（代理量替代模型）、[2605.25292]（有策略池但无选择规则的空档）
• 误差方向是否一等公民 → [2608.15762]（高估即安全侧）、[2602.24044]（对称损失的代价）、[2605.16637]（改为直接测量误差传导）、[2512.18894]（连量纲与方向性检查都不通过）
• 拥有运行时 vs 影子化运行时 → [2608.15762]（可重建性不变量的代价）、[2508.08343]（零改动接入的代价）、[2512.18894]（HPC 侧最彻底的影子化及其对账不变量）、[2508.20016]（影子化的真实代价是状态漂移的竞态）、[2503.08415]（第三种形态：既不拥有也不影子化真实运行时，而是把运行时语义抽象进独立仿真器、以真实引擎为对齐真值）
• 孪生本体建什么、保真度锚在哪（§5(k) 新轴） → [2503.08415]（建的是服务运行时而非硬件）、[2503.08415]（锚在与真实开源引擎的端到端对齐 <1%）、[2503.08415]（保真度只在被对齐过的机制上成立、且 Table II 的内部不一致）、[2503.08415]（元层定位：被下游消费/扩建）
• 最优点邻域失真 → [2508.08343]、[2602.24044]、[2608.03741]、[2512.18894]（同一形状出现在开销侧）
• 优化对象的非本质性 → [2508.08343]、[2602.24044]、[2606.01839]（换单元使问题消失）、[2606.01065]（打破不变量使模型失效）
• HPC 侧 vs serving 侧的分野（新增轴） → §2.1 对比表；保真度证据类型 [2508.20016] vs [2608.03741]；目标函数层级 [2508.20016] vs [2605.16637]；调度单元的可动性 [2512.18894] vs [2606.01839]