SchedMate：让调度器读懂代码、日志和历史作业

1. 现有调度器缺少哪些语义

生产 scheduler 通常只看用户名、作业名、GPU 数、提交时间等表层 metadata。论文把后果归纳为四类：profiling 对短作业过于昂贵；基于 metadata 的 duration estimate 不可靠，尤其生产中多达一半作业提前终止；框架和用户错误与硬件故障混在海量日志里，恢复慢；非侵入式调度器看不到 step time、loss、训练进度，侵入式改框架又难维护。LLaMA-3.1 预训练曾遇到 419 次故障、平均约每三小时一次，说明失败处理不是边角需求。

SchedMate 的 baseline 是缺少语义输入的 Lucid、Sia 等现有策略，而非另一个全新调度算法。增强过程保持非侵入：训练代码和 PyTorch 不变，系统只读 source code、stdout/stderr、历史作业与硬件指标；提取失败时回退原策略。

2. 三个组件分别补哪块信息

Scheduling Advisor

Advisor 从源码抽取能反映 workload 的语义，例如模型、数据、训练配置、循环与通信形态，形成 embedding fingerprint；再到 Redis 中检索相似历史作业。相似作业的平均 duration、SM utilization、吞吐和已有 performance model 可以直接供调度器估计 JCT、决定 packing，省掉重复 profiling。相比仅按作业名匹配，源码语义能识别“改了名字但训练逻辑相同”和“名字相近但模型/数据已变”的作业。

Metric Tracker

逐行把完整日志送 LLM 太慢。Tracker 先用 embedding 与预定义类别向量做轻量分类，只保留疑似进度指标的行；再从最新日志向前扫描，由较强 LLM 抽取 step、step time、loss 等结构化字段，获得足够数量 N 后停止并去异常值。没有进度日志时不猜，返回缺失，让 scheduler 回退。

Failure Handler

故障后常有数千条级联报错，但第一个真错误通常位于“正常日志→错误日志”的近似分界。Handler 用语义分类器在日志 chunk 上做二分定位，再把根因附近约 500 行交给 LLM，分类为基础设施、框架或用户脚本错误，并在基础设施类中定位 GPU、NVLink、节点等组件。确认硬件故障后可跑 nccltest、隔离节点、补节点并从 checkpoint 重启；代码 bug 则不做错误的自动重试。

3. 逐步数据流

1. 新作业到达，Advisor 读取其代码与配置，生成 workload fingerprint，在历史向量库检索 top-k 相似作业。
2. 有可靠匹配时复用历史 duration/utilization/performance model；没有匹配时保留原 scheduler 的 profiler 或 estimator。
3. 训练启动后，Tracker 持续过滤增量日志，更新 step time、throughput、loss 与进度。结构化指标用于检查 packing 干扰或 profile-as-you-go。
4. 退出异常时，Handler 二分寻找第一段错误，LLM 做细分类；只有基础设施故障进入自动诊断、隔离和重启。
5. 实际结束时间、资源曲线、日志与恢复结果回写历史库，供后续语义相似作业复用。

similar = VectorSearch(Embed(SourceCode + Config))
if |similar| > 0:
    duration_hat = mean(job.duration for job in similar)
    util_hat     = mean(job.utilization for job in similar)
else:
    fallback_to_original_scheduler()

日志：embedding filter -> recent relevant lines -> LLM parser -> metrics

4. 完整例子：Lucid 的一次错误 packing 如何被撤销

Job A 是 ViT 训练，新提交的 Job B 是 Stable Diffusion。Lucid 原本为每个作业做 100 秒 profiling，再按观测利用率把它们装到同一 GPU。若 A 的 100 秒正处 warmup，利用率会被低估，A+B 同卡后实际互相争抢。

接入 SchedMate 后，Advisor 先在历史库找到与 A 源码和配置近似的稳定运行，直接给出 steady-state 利用率并可跳过 profiling。若仍决定 packing，Tracker 在 B 放入前从 A 的日志得到吞吐 TP_before，等两个作业运行几十 step 后再得 TP_after。论文案例设置 slowdown threshold，若比值落到阈值以下（设计描述中举 35% slowdown，物理实验采用 0.5 threshold），就驱逐 B 回队列重新调度。为避免训练进度反复丢失，被驱逐作业不再参与 packing；无法追踪进度的 job pair 则跳过此检查。

若之后 A 报 CUDA error: uncorrectable ECC error，Failure Handler 找到首个 ECC 报错而不是末尾的分布式级联异常，判断为 GPU 基础设施故障，跑诊断、隔离节点并从 checkpoint 重启。这个闭环把“预测错了怎么办”和“运行坏了怎么办”都补进非侵入式 scheduler。

5. 三种集成方式

Lucid+SchedMate：历史指标绕过不准的短 profile，语义相似历史增强 duration estimate，Tracker 在运行时取消有害 packing。Sia+SchedMate：Sia 原本要在多种 GPU 上 profile-as-you-go；相似作业可直接复用已有性能模型并立即训练，之后仍由 Sia 在线更新。Standalone：SchedMate 用 Advisor 给 SJF 提供预计时长，并用 Failure Handler 处理可恢复故障。论文由此说明这些组件是调度信息层，不绑定一种 policy。

6. 实验设置与准确数字

实现基于 Ray，约 5500 行代码；Qwen-2.5-7B-Instruct（GPTQ Int8）作为核心 LLM，BGE-m3 在 CPU 上做 embedding，Redis 存向量与历史 metadata。物理集群是 8 个节点，每节点 8 张 A800-80GB，共 128 GPU。工作负载覆盖 LLaMA-3 8B、Qwen-2.5 14B、ViT、BERT、Stable Diffusion、CLIP、DLRM、ResNet 等；trace 包括 1024-GPU Mars 训练集群的 500 个 LLM job、Acme、Philly、Helios、Sia trace，以及 20 个 GitHub 仓库生成的 100 个异构 job。

Advisor 平均查询延迟 9 秒，相比 100 秒 profiling 可接受；物理结果与 simulator 的平均 JCT、makespan 误差低于 3.7%。Acme 上改善最大，因为短作业和重负载让 duration 估计及错误 packing 更伤；这也是证据边界：trace 分布较集中、作业较轻时收益较小。

7. 贡献、限制及与其他调度器的关系

SchedMate 把源码和日志变成 scheduler 的正式输入，并用“embedding 粗筛 + LLM 精析”控制成本。LLM 不直接决定 GPU placement，只生成可核验的结构化事实；最后仍由确定性 scheduler 下发决策。即使 LLM 判断出错，影响范围也被限制在输入特征这一层。

局限：源码 embedding 对动态生成配置、外部数据分布和运行时网络状态未必敏感；历史相似不代表性能相似，软件或硬件版本变化会造成 concept drift。日志二分依赖第一个真错误引发后续级联的半排序假设，多故障或交错异步日志可能破坏它。自动恢复动作需要集群权限和可靠 checkpoint，误分类基础设施故障的代价高。系统还长期占用一张 GPU 部署 7B LLM，小集群未必划算。

合集关系：与 PromptTuner 都用语义复用减少调度成本，但 SchedMate 面向一般 DL 作业，从代码/日志抽取事实；PromptTuner 的语义对象是 prompt candidate 与 LLM runtime。与 Ymir、Titan、Lucid、Sia 等 scheduler 论文应连读：SchedMate 更像可叠加的观察层，而非替代它们的资源优化器。

8. Scheduling Advisor 的语义检索如何落到调度

Advisor 并不是让大模型直接预测“这个作业跑三小时”。它先从代码中生成结构化 workload metadata，再把描述编码成向量，与历史指纹做相似搜索。相似集返回后，持续时间和利用率使用历史观测的平均值。这个设计把难以验证的自由文本推理限制在信息抽取，把最终数值预测交给可追溯的历史样本。调度员可以回看命中了哪些作业，也能在相似集为空时明确回退，而不是接受一个没有证据的语言模型数字。

对 Lucid，利用率预测决定两个作业是否适合 packing，持续时间预测影响队列次序；对 Sia，历史记录不仅有一个标量，还可以带上不同 GPU 类型、placement 和 batch size 下的 throughput surface，新作业据此跳过启动前 profile，然后继续用真实运行结果修正。相同语义层由不同 scheduler 消费，说明 SchedMate 的接口是“给现有策略补特征”，而不是把所有调度统一成一种目标。

9. 日志两阶段设计为何必要

训练日志绝大多数是数据加载提示、重复进度、警告和框架噪声。若把每行都交给七十亿参数模型，日志产生速度可能超过解析速度，调度反馈总是落后。Embedding classifier 只需把行归到进度、性能、错误等粗类，吞吐远高于生成式解析；随后 LLM 只处理最近少量相关行，并在取得稳定的若干个样本后停止。逆序扫描意味着 scheduler 优先得到当前 step time，而不是先花时间处理启动阶段旧日志。

Failure Handler 的二分搜索同样利用低成本分类器缩小范围。假设日志前半正常、真错误之后大多为错误，检查中间 chunk 就能反复砍半；用 chunk 而非单行，是为了容忍故障后仍穿插正常输出。定位后再给 LLM 约五百行上下文，避免单看一条 CUDA 报错误判。这个流程的安全边界在自动动作：只有基础设施类且定位到具体组件才隔离和替换；框架不兼容与用户脚本 bug 应报告而非无限重启。

10. 端到端收益不能等同抽取准确率

一个 metric parser 即便逐字段很准，若反馈延迟大于短作业寿命，也不会改善 JCT；一个 duration estimator 即便平均误差较低，若恰好把重作业误装到一起，也可能放大尾部。论文因此直接在物理集群运行二百四十一个作业，并用平均 JCT、排队时间验证信息是否真正改变 schedule。模拟结果再扩大到多条生产 trace，而不是用模拟替代物理闭环。

同理，Acme 上一倍以上的改善不能外推到所有集群。其作业短、分布偏斜、packing 干扰重，正好放大 Advisor 和 Tracker 的价值；Saturn、Philly 分布更集中、作业较轻，许多短作业甚至在 profiler 中已经完成，附加语义的收益自然变小。判断是否采用 SchedMate，应先量本地 profiling 占比、失败恢复时间、日志可观测性和重复作业比例，而不是只看最高一点九一倍。

11. 前置知识：JCT、packing、elastic 与 profiling

JCT 是 Job Completion Time，从提交到完成，等于排队时间与实际运行时间之和；makespan 是整批作业全部结束所需时间，p99 JCT 则刻画尾部。FIFO 只按到达顺序，SJF 要先预测时长再让短作业优先。Job packing 把多个资源互补的训练作业共置于同一 GPU，例如一个计算密集、一个内存或通信间歇性强，希望提高利用率；若利用率画像不准，两者争抢 SM、显存带宽或通信后反而一起变慢。Elastic scheduling 则在 GPU 类型、卡数和 placement 间动态迁移，需知道每种配置下的 throughput surface。

传统 scheduler 获取这些信息主要靠 profiling。Pre-profiling 在正式训练前让作业短跑，Lucid 的物理实验每个作业跑 100 秒并独占一个节点；profile-as-you-go 则像 Sia 那样，先在不同 GPU 类型上试跑，随后边训练边更新模型。这对长训练可摊销，对 Acme 中位时长仅两分钟的作业却可能几乎等于再跑一遍。基于配置的 step_time×total_steps 又默认训练跑完，但 Acme、Philly、Helios 按作业数统计，完成比例分别只有 49.7%、60.4%、62.4%，取消比例为 7.5%、9.0%、22.1%，失败比例为 42.9%、30.5%、15.5%；按 GPU time 统计，最终完成作业也只占 21.2%、32.1%、51.3%。

SchedMate 的关键架构原则是把 LLM 放在“信息抽取与分类”位置，不让它直接决定 placement。LLM 输出模型、数据、训练配置、step time、failure type、faulty component 等结构化事实，原 scheduler 仍以确定性政策消费这些字段。字段缺失时回退原 profiler、estimator 或 packing policy。这样一方面利用 LLM 跨框架理解代码与日志的能力，另一方面把幻觉半径限制在可检查的中间数据，不会让自由文本直接变成资源控制命令。

12. Scheduling Advisor 的数据结构与一次完整检索

新作业提交时，Metadata Extractor 收到 repository path、训练 command 与 launch config。ReAct agent 有两个只读工具：file_tree_tool 返回过滤后的项目树，file_read_tool 读取选中文件。它迭代寻找入口、配置、模型构造与数据加载代码，最终输出 JSON。必填 schema 包含 model name、model type/task、dataset、training iterations、iteration type、batch size 和硬件需求，还可带 d_model、layer 数、learning rate、worker 数等。论文示例从 python -m train experiment=pile/gpt 与源码中提取 GPT、NLP、d_model 768、12 层、80,000 step、batch 256、lr 0.001、Pile train/validation。

结构化 metadata 仍不能直接做字符串等值匹配，因为模型别名、配置组合和代码组织会变化。系统用 BGE-m3 把整份 metadata 编成稠密向量，对 Redis 中历史向量算 cosine similarity；超过阈值 T_score 的才算 match，再取 top-k。若匹配集合为 S，新作业时长估计为 d_hat=(1/|S|)Σ_{j∈S}d_j，SM utilization 同样取历史均值；Sia 集成还可复用历史作业在不同 GPU type、placement、batch size 下的完整 performance model。standalone SJF 固定取三个最相似历史作业的平均 duration，再按估计值升序排队。

端到端例子：用户复制了一份 LLaMA-3 8B Alpaca fine-tuning 项目，改了作业名和输出目录，但模型、数据、batch 与 8-GPU 启动配置相同。表层 job-name 模型会视为新作业；Advisor 读取实际配置后仍会命中历史 LLaMA-3/Alpaca/SFT。若 top-3 历史时长为 3.1、3.3、3.2 小时，估计就是 3.2 小时；若三者 steady-state SM utilization 为 71%、74%、73%，预测为约 72.7%。这个算例只说明论文的聚合规则，不代表论文实测个案。若代码缺失、agent 失败或没有超过阈值的历史项，Lucid 回到 100 秒 profiling 与原 duration estimator，Sia 回到各 GPU 类型 profile，而不是生成一个无来源数字。

13. Metric Tracker 与 Failure Handler 的算法细节

Metric Tracker 的第一阶段不是生成式 LLM，而是 embedding classifier。系统预先把 init、progress、warning、info 等类别描述编码为 category vector；每条新日志也编码，按 cosine similarity 归类，只把 progress 类送到第二阶段。Metric Extractor 从最新日志逆序扫描，由 Qwen 解析 step index、step time、loss 等字段，收集到少量 N 条稳定样本就停止，再剔除 outlier。这种逆序、早停设计让 scheduler 先看到当前吞吐，不必从数万行启动日志顺序重放。日志不输出进度时组件返回缺失，integration 跳过干扰检查，保持原行为。

Failure Handler 假设第一个真实错误把日志从“大多正常”带到“大多错误”，后续会出现分布式级联异常。Failure Locator 对 chunk 而非单行做二分：检查中间 chunk 是否含 failure 类语句；若有，根因更可能在左半，否则在右半，反复缩小到最早错误附近。Chunk 能容忍故障后穿插正常输出。定位后，论文设计描述把约 500 行上下文交给 LLM，模块评测实际取定位点周围 200 行；LLM 先分 infrastructure、framework、user script，再为 infrastructure 标 GPU、NVLink、Node 等 faulty component，输出固定的 Error Type 与 Faulty Component 字段。

定位最早错误 chunk → 取局部上下文 → LLM 分类错误类型与故障组件
若是基础设施故障：诊断组件 → 隔离坏节点 → 补充节点 → 从 checkpoint 重启
若是框架或用户脚本错误：报告根因并停止自动重试

例如末尾只有 NCCL communicator aborted，但定位点附近先出现 CUDA error: uncorrectable ECC error，系统应诊断 GPU 基础设施故障：运行 nccltest 确认、在 cluster manager 隔离节点、补充节点并从最近 checkpoint 重启。若首错是 Python shape mismatch，则属于用户脚本，自动换节点只会重复浪费 GPU。自动恢复成立还要求 checkpoint 可用、诊断命令可信且 SchedMate 有节点隔离权限；论文给出动作链，不等于任何集群都能无审批执行。

14. 三种集成的伪代码与调度闭环

Lucid+SchedMate 同时改三个信息点。提交阶段若 k>0，用相似历史均值替代 Lucid profiler 与原时长模型；无匹配则回退。Packing 后，Metric Tracker 先记录 Job A 的 TP_before，等 Job B 共置并经过几十个 step 的稳态后再取 TP_after。论文把比值 TP_after/TP_before 与 threshold 比较；设计段用“35% slowdown”说明概念，物理实验实际 threshold=0.5。若低于阈值，驱逐后加入的 B 回队列，而且 B 不再参与 packing，以免 checkpoint 或训练进度反复损失；A 的日志无法解析时不执行此次撤销。

历史命中：profile = 历史硬件指标均值；duration = 历史时长均值
历史未命中：运行 Lucid 100 秒 profiler，并调用原时长估计器
pack(A,B) 后若可解析 A 的吞吐且 TP_after/TP_before 低于阈值：
驱逐 B，标记 B 不再参与 packing，并把 B 放回等待队列

Sia+SchedMate 的差别是历史项提供多配置 performance model。原 Sia 让新作业依次在 GPU-A/B/C 上 profiling，再开始训练；命中语义历史后，作业直接用历史模型进入训练，之后仍以 profile-as-you-go 把真实 throughput 写回并修正。它不是永久相信历史，而是省掉冷启动探索。Standalone SchedMate 则采用 SJF：Advisor 取三个近邻平均时长排序，Failure Handler 对失败作业做恢复。三种案例分别验证语义层能增强非侵入式 packing、异构弹性与独立队列，不应把它误解为同一个新 scheduling objective。

15. 完整实验设置、逐项结果与模块消融

系统在 Ray scheduler 上约 5,500 行代码，LLM 由 vLLM 0.5.5 提供 API，FlagEmbedding 计算向量，Redis 存历史与做检索，NVIDIA Management Library 采硬件指标。默认 Qwen-2.5-7B-Instruct 使用 GPTQ Int8，部署一张 GPU；BGE-m3 跑 CPU。物理集群是 8 个 SLURM 节点，每节点 8 张 A800-80GB 和 2TB 内存，合计 128 GPU，软件为 Python 3.9、CUDA 12.2、PyTorch 2.4.0、Ray 2.6.3。Table 2 覆盖 15 种 workload：8B LLaMA-3、14B Qwen-2.5，以及 ViT、BERT、DeBERTa、Stable Diffusion、CLIP、DLRM、ResNet、Unet、EfficientNet、ConvNeXt、MobileNet、YOLO、T5，横跨 3.5M 到 14B 参数。

Trace 包括 1024-GPU Mars 的 500 个 7B–100B LLM job，完整代码库约 40K LoC；Acme、Philly、Helios 的 Saturn/Venus 与 Sia trace；另从 20 个 GitHub repo 生成 100 个 CV/NLP/audio 异构 job。物理实验从 Philly、Acme 抽 241 个作业，按原请求映射到大中小 workload，超过集群容量的请求封顶 128 GPU，重复三次。Lucid profiler 独占一节点跑 100 秒，SchedMate 占专用 GPU。Lucid+SchedMate 的平均 JCT/排队为 5.53/2.71 小时，Lucid 为 6.85/3.40 小时，JCT 降 23.2%；对应模拟为 5.64/2.60 与 6.79/3.32 小时，average JCT 与 makespan 的平均误差小于 3.7%。Advisor 平均延迟 9 秒。

Lucid 模拟在 Acme、Saturn、Philly、Venus 上相对原系统提升 1.23–1.91 倍，Acme 达最高值，因为负载更重、时长更偏斜、短作业与 packing interference 都多。Sia 结果可逐项核对：Philly 的 average/p99/makespan 从 0.74/10.60/14.7 小时变为 0.59/10.12/14.4；Helios 从 0.83/12.0/15.7 变为 0.72/10.7/14.8；Sia-trace 从 0.64/4.25/12.5 变为 0.53/4.12/12.4，平均 JCT 降 13.3%–20%。Standalone 相对 QSSF 平均 JCT 改善 25.7%，相对 Tiresias 改善 16%；加入 Failure Handler 又比不处理故障额外降约 12.5%。

模块级结果解释为什么端到端有效。Mars 上 duration estimate 相对误差低于 100%的比例，SchedMate 为 85.7%，Lucid ML estimator 仅 27.7%；SM utilization 平均相对误差则 SchedMate 28.1%、Lucid 的 100 秒 profiler 19.3%，显示语义历史更快但利用率并非更准。Failure Handler 在 300 个失败作业、其中 75 个 infrastructure failure 上，Qwen 7B/14B/32B 的 F1 为 67.7/65.1/68.2，precision 75.7/77.1/78.4，accuracy 90.1/90.0/90.7；去 Locator 后 7B F1 仅 11.1，RCACopilot 为 43.0，说明定位让小模型拿到正确上下文。

Metric Tracker 在 1,000 份合成日志、50%混入大量无关内容时，noisy success rate 84.3%、RMSRE 0.42，pure LLM 为 59.4%与 2.2；延迟分别 8.7 与 9.8 秒。对 partial information，把 slowdown detection rate 从 0 提高会持续降低 JCT，检测率 0.5 已有 12.5%改善，超过 0.6 后边际收益有限。模型扫描中 Qwen-2.5 0.5B、1.5B 无法完成 Advisor，7B 的 Advisor hit rate 73.0%、Metric Tracker success 91.6%、Failure Handler F1 66.7%；7B–14B 被作者视为效果与资源的较好平衡。

16. 规模开销、部署限制和复现清单

Scheduling Advisor 是三个模块里最重的。作者从 Mars 取 200 个共用 40K LoC 项目的大作业，用每 GPU 一个 Qwen-1.5-14B-Int8 测规模。每批请求少于 4 个 job 时，单 GPU 平均延迟低于 20 秒，多卡收益不明显；请求强度达到 8 后，单卡延迟快速上升。单 GPU 吞吐约稳定在 480 job/hour；2 GPU 在强度 16 时超过基线 2 倍，4 GPU 在每批 32 job 时达约 2,000 job/hour、相对基线 4.6 倍。作者据此建议对 PAI 一类 300–1200 job/hour 周期流量低峰用一张、峰值用四张或更多，而不是始终预留最大 LLM 服务。

语义相似的主要风险是 concept drift：相同代码在不同数据规模、GPU 型号、网络拓扑、框架版本、编译选项或外部 checkpoint 下可能性能不同；平均 top-k 还会掩盖多峰分布。生产库应把硬件/软件版本、数据规模与实测置信区间写进 fingerprint，对历史加时间衰减，低相似度或高方差时回退 profiling。源码 agent 还接触用户代码，应只读、限制工具根目录与输出 schema，防止代码中的提示注入把 agent 引向无关文件或泄露凭据。

日志侧风险包括异步多进程输出破坏“正常后错误”的半排序结构、多个并发根因、首错被截断，以及错误分类后自动隔离健康节点。故障恢复必须设置置信阈值、诊断二次确认、隔离配额、人工审计和重试上限；framework/user bug 不能自动循环。Metric Tracker 依赖用户打印 step time；partial information 实验证明半数检测已有收益，却不证明缺日志时仍能纠正某一具体 packing。7B LLM 持续占一张 GPU，对小集群可能比省下的 profiling 更贵，需把顾问服务的 GPU-hour 计入总体成本。

复现应保存四类原始输入：提交 metadata、完整源码快照与 command、stdout/stderr、硬件时间序列，并确保历史库只含测试作业提交前可见的数据，防止未来泄漏。Advisor 需报告 top-k 命中、duration/SM error、每请求延迟与 fallback 比例；Tracker 报 success、RMSRE、过滤前后 token 数、延迟及 partial detection 曲线；Handler 报 infrastructure 类的 F1、precision、accuracy，单独做无 Locator 与 last-500-lines 对照。端到端必须同时跑 Lucid、Sia 与 standalone 的原策略，报告 average/p99 JCT、queue、makespan、额外 GPU-hour，并保留物理集群和 simulator 误差。只有把模块准确性、信息缺失、额外服务成本与最终 schedule 都列出，才能证明提升来自语义信息，而不是模拟器或更多硬件。

17. 一项语义事实怎样改变三类调度决定

以“新作业与三个历史作业语义相似”为例，Lucid 消费的是历史平均时长和平均硬件利用率：前者改变队列优先级，后者决定是否 packing；Sia 消费的是完整性能模型：不同 GPU 类型、卡数、placement 和 batch 下的吞吐会改变弹性配置；standalone SJF 只消费平均时长。相同检索结果不能不经转换直接塞给三个 scheduler，因为它们的决策变量不同。论文所谓 plug-and-play 是模块接口可复用，不是所有策略使用同一组数值。

再以 step time 为例。Metric Tracker 抽出若干稳态 step 后，Lucid 计算 packing 前后吞吐比并决定撤销；Sia 原本已有 profile-as-you-go，论文案例主要用 Advisor 跳过初始 profile，没有宣称 Tracker 替换 Sia 的在线模型；standalone 案例也没有用 step time 动态抢占。把论文组件全量接到每个案例会变成新的系统，不能拿原实验数字支撑。正确复现应严格保持各案例的消费路径，再另做扩展实验。

失败类型同样不是直接等于“重启”。Infrastructure 类还需定位组件并通过诊断；框架错误可能来自 CUDA、PyTorch、NCCL 版本不兼容，需要环境修复；用户脚本错误需要开发者改代码。论文自动动作只覆盖可恢复基础设施故障。若错误发生前没有 checkpoint，换节点后也可能从头训练，JCT 收益远小于有频繁 checkpoint 的作业。standalone 模拟中 Failure Handler 带来约百分之十二点五的额外平均 JCT 降低，是基于 trace 中可识别的 resumed failed jobs，不是所有失败都能得到相同收益。

完整闭环应把实际结束时长、资源曲线、最终状态、源码指纹、日志解析结果和恢复动作写回历史库。下次相似作业才能复用这次性能，同时 operator 也能审计预测来自哪些样本。写回还必须区分正常完成、用户取消、代码失败和基础设施失败；否则把提前失败的短时长当成正常 duration，会把 SJF 预测系统性拉低。论文正是因为生产作业大量提前终止才反对只用 step_time×total_steps，历史库若不保留终止语义，也会重犯同一错误。

18. 结果归因、失败场景与生产运行手册

Acme 上 Lucid+SchedMate 提升最大，不应简单归因于“LLM 更懂作业”。这个 trace 同时满足三个放大条件：时长分布高度偏斜，短作业让一百秒 profile 比例很高，重 workload 共置后干扰明显。因此 duration retrieval、跳过 profile、运行期撤销 packing 三项一起产生一点九一倍上界。Saturn 与 Philly 时长更集中、任务更轻，许多短作业在 profiling 期间已经完成，packing interference 也小，所以提升只有一点二三到一点二六倍。收益随本地 workload 结构变化，先量 profiling GPU-hour、重复作业率与干扰分布比直接复制架构更重要。

Advisor 的 duration 结果也存在一个容易误读的指标：相对误差低于百分之百的比例从 Lucid 的百分之二十七点七升到百分之八十五点七，不等于平均误差只有百分之十四点三；图中作者因为真实值很小时相对误差敏感，还截断了曲线。SM utilization 上 Advisor 平均误差百分之二十八点一，反而差于 profiler 的百分之十九点三，优势在于少于十秒、单 GPU、无需占用每个训练作业的一百秒 profile。调度器选择的不是“所有字段最准确”的模块，而是在准确性、等待和 GPU 占用之间换取更低端到端 JCT。

故障模块同样要同时看 F1、precision 与 accuracy。三百个失败里只有七十五个基础设施故障，类别不均衡使 accuracy 九成可能掩盖漏报；precision 约百分之七十六到七十八意味着自动隔离前仍需诊断确认。Locator 对七十亿模型尤其关键：去掉后 F1 从六十七点七掉到十一点一，而三百二十亿模型在末尾日志 baseline 上仍可到六十九，说明大模型有时能从噪声推回根因，但成本更高且不稳定。正确系统设计是先缩小证据，再用适中模型，而不是靠扩大参数吞下整份日志。

生产运行可分为提交、运行、退出三条异步通道。提交通道对源码做只读快照和语义提取，设超时后立即 fallback，不能阻塞整个队列；运行通道按固定间隔增量读取日志，只保留 progress 候选并为每个作业维护最近稳态窗口；退出通道只在异常状态触发二分定位、分类和诊断。三条通道共享作业标识与版本化历史库，但各自限流：Advisor 按提交峰值扩 GPU，Tracker 以 embedding 为主要吞吐，Handler 按故障事件突发扩容。这样才能把论文模块从离线演示变成不会反过来拖慢 scheduler 控制面的服务。

最小上线门槛包括：所有源码工具只读且限定仓库根目录；JSON schema 校验失败即回退；相似样本必须显示来源、硬件与软件版本；packing 撤销设冷却和禁止重复共置；故障隔离要求诊断通过、配额允许且保留人工审计；历史写回标记结束原因；控制面记录顾问 GPU-hour、解析延迟和 fallback 率。论文证明语义信息能改善调度，但这些保护决定它在真实多租户集群中是否可控。

灰度阶段应把语义组件先设为只建议、不执行：Advisor 同时输出预测与原 profiler 结果，Tracker 只标记应撤销的 packing，Handler 只生成故障报告。积累一段时间后按真实完成时长、实际 slowdown 和人工根因计算误报、漏报与节省的 GPU 时间，再逐项开放自动动作。这样能把检索错误、日志抽取错误和调度政策错误分开；若一开始就同时启用跳过 profile、自动驱逐与节点隔离，JCT 变化无法归因，错误动作也可能互相放大。论文的三项案例本来就是分开验证，部署也应保持同样的可观测边界。