ASTRAEA：把公平写成一笔长期 GPU-time 账

ASTRAEA 处理长期公平，而不是逐秒平均分卡。深度学习作业必须成组拿卡，放置位置会影响速度，抢占也有代价；系统因此考察租户和作业在较长时间内获得的 GPU 服务。资源数量乘占用时间得到 GPU service time，租户和作业各自维护“实际所得／公平应得”比值，固定期限的 lease 再周期性重排执行权。

一、核心命题与系统边界

考虑一个由多个团队共享的 GPU 集群。团队在论文中称为 tenant，每个 tenant 对应一个虚拟集群（VC），有权重和由权重换算出的 GPU quota；团队成员只能向自己的 VC 提交训练作业。作业提交时声明固定 GPU demand，分布式作业遵守 gang scheduling：所需 GPU 要么同时全部获得，要么一块也不获得。ASTRAEA 的目标是在这种离散分配约束下，同时维持两层长期公平：

• tenant 层：不同团队获得的累计 GPU-time 应与各自权重、quota 和实际需求相称。一个团队暂时无活可跑时，其空闲份额可以被借走；它以后出现突发需求时应有机会追回。
• job 层：同一团队内部的并发作业也要按权重获得累计 GPU-time，不能让一个长作业永久占住整个 VC，也不能一味照顾短作业而饿死长作业。

这里的长期公平是历史窗口上的服务量公平，不是某一时刻的 GPU 数相等，也不是预测每项作业何时完成。ASTRAEA 不试图解决模型收敛质量、deadline 保证、弹性并行度或异构 GPU 定价。论文中的系统评估是 trace-driven simulator；lease、用户侧 checkpoint daemon、共享存储恢复和 coordinator 被具体设计出来，但没有给出生产集群原型的端到端实机评测。这条证据边界对理解实验结论很重要。

二、背景：为什么深度学习训练把公平问题变难

普通批处理系统可以把 CPU slot 或 task 细粒度拆分，再用 max-min fairness 在每个时刻调平份额。深度学习训练（DLT）不同。一次训练包含大量前向与反向迭代，可能持续数天；研究人员又会做超参数搜索和试错，根据中间结果提前取消表现差的任务。因此完成时间很难仅凭剩余迭代数可靠预测，作业最终状态也可能是完成、用户取消或程序／硬件故障。

三个约束直接击穿“立刻平均分”的思路。第一，gang scheduling 使资源不可连续切割。一个声明需要 8 GPU 的作业在传统框架中不能先拿 2 GPU 慢慢跑。第二，训练吞吐受拓扑影响。通信密集型 8-GPU 作业放在单台有 NVLink 的 8 卡服务器上，通常优于拆到两台机器；公平调度不能假定任意 GPU 都等价。第三，抢占要保存模型、优化器等状态，恢复时还有 cold start。为追求每秒钟的相等而频繁切换，公平度看似漂亮，JCT 却可能恶化。

混合负载还制造了相反的风险。FIFO 容易让长作业占满 VC，后到的短实验发生 head-of-line blocking；严格的短作业优先又会让长训练长期没有进展。一个可用的方案必须允许资源在较粗的时间尺度上轮转，记录过去谁多拿、谁少拿，并在可放置性允许时偿还欠账。ASTRAEA 因而选择 GPU 数乘运行时间作为统一账目，以 lease 作为最小纠偏周期。

三、Venus 生产 trace：问题规模和负载统计

论文首先分析 SenseTime 的生产集群 Venus，而不是从合成例子直接推出机制。Venus 有 133 台服务器，每台安装 8 块 NVIDIA Volta GPU，合计 1,064 GPU，服务器由 RDMA 网络连接。集群由 16 个 tenant 共享，每个 tenant 当时拥有静态 GPU 数；调度器是 Slurm。完整 trace 覆盖 6 个月、109,734 个 GPU 训练作业。

运行时累计分布进一步说明短长作业共存。Philly trace 中，运行时间小于 10 分钟、1 小时、6 小时、1 天、6 天的累计比例依次为 40.8%、71.6%、88.5%、94.1%、98.5%；Venus 对应为 67.3%、83.3%、90.6%、96.2%、99.6%。换句话说，Venus 约三分之二作业十分钟内结束，但仍有少量作业延伸到多日，单一的短作业优先或长作业保护都不够。

tenant 的需求也随时间错峰。6 月 15 日，Tenant-B 的 GPU 利用率超过 90%，Tenant-A 的平均利用率低于 50%；6 月 21 日，Tenant-A 接近 100%，Tenant-B 只使用 60%。静态隔离会浪费一方的空闲资源，完全共享又可能让出借方在需求回来时拿不回 quota。ASTRAEA 的租户账本正是为“先借出、后追回”准备的。

四、公平究竟承诺什么：sharing incentive 与损失

论文用 sharing incentive 给公平一个可检验的参照系。对作业：若一个有 M 块 GPU 的集群由 N 个同权作业共享，每个作业在共享环境中的性能不应差于独占一个含 M/N 块 GPU 的小集群。对 tenant：若 T 个同权 tenant 共享 M 块 GPU，则在一段时间内，每个 tenant 至少应获得独占 M/T 块 GPU 时可得到的 GPU service time，而且承诺不应依赖其他 tenant 的负载。

GPU service time 的单位是“GPU × 时间”。8 GPU 跑 10 分钟产生 80 GPU·min，2 GPU 跑 40 分钟也产生 80 GPU·min。它把空间维度的卡数和时间维度的占用合到同一个可累加量中。LTGF 比值统一写成：

ρ = 统计窗口内实际获得的 GPU service time ÷ 同窗口内公平应得的 GPU service time

• ρ ≥ 1：实际所得至少达到公平基准，论文称满足长期公平或 sharing incentive。
• ρ < 1：实际所得低于基准，出现 sharing loss。实验中作业级还使用更严格的判定阈值 ρ_job < 0.95 来统计 sharing-loss jobs；tenant 级则统计 ρ_tenant < 1 的区间。
• ρ > 1 不是错误。它通常表示实体借用了别人的空闲 quota，或过去已经多得资源；后续 max-min 决策会优先照顾比值更低者。

sharing loss 不是丢失 checkpoint、吞吐下降百分比或 JCT 增量，而是“累计实际服务低于累计公平基准”的状态。一个作业可以 JCT 很短但曾有 ρ<1，也可能 JCT 很长却因本身需要大量计算而始终 ρ≥1。公平和效率因此要分开度量。

五、传统公平定义为何失败

瞬时资源分配公平

瞬时 max-min fairness 在时刻 t 为每个活跃作业分配 r_i(t)，目标是最大化所有作业中最小的即时份额；作业用不掉的资源再分给其他作业。在论文的 6-CPU 示例里，三个作业各拿 2 CPU 即可。DLT 却不能照搬：6-GPU 作业不能被切成三个 2-GPU 子份额；随意拆节点破坏通信拓扑；为了维持每一瞬间相等而高频抢占，还会反复 checkpoint 和 cold start。即时相等在物理上可能不可执行，在性能上也可能得不偿失。

长周期完成时间公平

Themis 的 long-term finish-time fairness 用 ρ_i(t)=T_i(t)/(T_i*(t)·N) 衡量作业：T_i(t) 是当前实际分配下的预计完成时间，T_i*(t) 是使用整个集群时的预计完成时间，调度器最小化最大的比值。它能配合 lease 处理 gang scheduling，却只把墙钟时间放进公平账，没有计入一次运行占几块 GPU，而且必须预测剩余时间和吞吐。

论文给出一个反例：6-GPU 集群中，Job1 请求 6 GPU，Job2、Job3 各请求 3 GPU；三个作业各需实际运行 40 分钟，调度轮次为 10 分钟。若按完成时间轮流让 Job1 独占一个轮次，再让 Job2 与 Job3 并行一个轮次，每 20 分钟里 Job1 得到 60 GPU·min，占总服务的 1/2；Job2、Job3 各得 30 GPU·min，各占 1/4。运行时间机会看似相同，GPU-time 并不相同，小作业失去 sharing incentive。

更糟的是，这种优先级给了虚报需求的动机：若多报 GPU 不会更快降低调度优先级，用户可能用更大的 demand 换取更多服务量。LTGF 对实际获得的 GPU 数逐时积分；大 demand 作业一旦运行，分子增长更快，其比值和“已经拿了多少”的反馈会立即变化。它不能验证作业真实需要多少 GPU，但至少移除了“相同运行机会下多报卡数白赚 GPU-time”的明显漏洞。

六、单租户中的作业级 LTGF：变量和公式完整展开

先看只有一个 tenant 的集群。统计窗口是 [t₁,t₂]，集群有 M 块 GPU，共 N 个作业。对作业 Jᵢ，论文定义以下变量：

• Demandᵢ_job：作业声明的 GPU demand，运行期间固定。
• Allocᵢ_job(t)：时刻 t 实际分配的 GPU 数。gang scheduling 下，未运行为 0，运行时等于 Demandᵢ_job。
• Active(Jᵢ,t)：活跃指示量。pending 或 running 为 1，failed 或 completed 为 0。公平分母只在作业仍参与竞争时增长。
• Wᵢ_job：作业在其 tenant 内的分享权重；同权场景全部为 1。
• FairShareᵢ_job(t)：忽略 gang 离散性后，按活跃作业权重计算的瞬时理想份额。

实际累计服务是分配函数的积分：

Allocᵢ_job(t₁,t₂) = ∫[t₁,t₂] Allocᵢ_job(t) dt

Allocᵢ_job(t) = 0                    ，Jᵢ 未运行
              = Demandᵢ_job          ，Jᵢ 正在运行

权重份额是：

FairShareᵢ_job(t)
  = M × Wᵢ_job / Σⱼ(Active(Jⱼ,t) × Wⱼ_job)

作业无法使用超过自身 demand 的 GPU，所以公平累计服务还要逐时取上限：

FairShareᵢ_job(t₁,t₂)
  = ∫[t₁,t₂] min(Demandᵢ_job, FairShareᵢ_job(t)) dt

ρᵢ_job(t₁,t₂)
  = Allocᵢ_job(t₁,t₂) / FairShareᵢ_job(t₁,t₂)

min 很关键。假设 8-GPU 集群只有两个同权活跃作业，一个只需要 1 GPU，另一个需要 8 GPU。前者的理想权重份额虽是 4 GPU，公平分母每秒只记 1 GPU，因为多出来的 3 GPU 它根本用不了；否则一个永远无法消费其“应得份额”的小作业会被永久判欠账。空出的能力可以转给大作业，从而保持 work conservation。

论文据此把作业级目标写为 maximize minᵢ ρᵢ_job。这不是一次求出整个未来日程，而是在每轮选择当前比值最低的作业，使最差者得到改善。计算只依赖过去实际发生的分配，不要求预测取消、失败、剩余迭代或未来吞吐。

七、多租户中的 LTGF：quota、tenant 账本与 tenant 内作业账本

现在集群仍有 M 块 GPU，但由 T 个 tenant 共享。tenant j 的权重是 Wⱼ_tenant，其 quota 为：

Quotaⱼ = M × Wⱼ_tenant / Σₖ Wₖ_tenant

tenant j 有 Nⱼ 个作业，Jᵢ,ⱼ 表示其中第 i 个。其时刻需求与公平份额分别是：

Demandⱼ_tenant(t)
  = Σᵢ Active(Jᵢ,ⱼ,t) × Demandᵢ,ⱼ_job

FairShareⱼ_tenant(t)
  = min(Demandⱼ_tenant(t), Quotaⱼ)

Demandⱼ_tenant(t) 是该 tenant 所有 pending 与 running 作业的 demand 之和；完成和失败作业不再计入。理论定义中的 min 表示 tenant 没有足够工作时不为用不掉的 quota 累积欠账。实际占用是其所有作业实际分配量之和：

Allocⱼ_tenant(t) = Σᵢ Allocᵢ,ⱼ_job(t)

Allocⱼ_tenant(t₁,t₂) = ∫[t₁,t₂] Allocⱼ_tenant(t) dt
FairShareⱼ_tenant(t₁,t₂) = ∫[t₁,t₂] FairShareⱼ_tenant(t) dt

ρⱼ_tenant(t₁,t₂)
  = Allocⱼ_tenant(t₁,t₂) / FairShareⱼ_tenant(t₁,t₂)

Allocⱼ_tenant(t)<Quotaⱼ 可能来自工作不足或 GPU 碎片，Allocⱼ_tenant(t)>Quotaⱼ 则表示它借用了空闲份额。调度目标是 maximize minⱼ ρⱼ_tenant。论文没有把 tenant 比值和 job 比值加权合成一个总分，因为两者治理不同层级；合成还会让一个层级的好成绩掩盖另一个层级的严重欠账。

tenant 内作业的公平份额以 tenant 的公平份额为预算，再按活跃作业权重分：

FairShareᵢ,ⱼ_job(t)
  = FairShareⱼ_tenant(t) × Wᵢ,ⱼ_job
    / Σₗ(Active(Jₗ,ⱼ,t) × Wₗ,ⱼ_job)

FairShareᵢ,ⱼ_job(t₁,t₂)
  = ∫[t₁,t₂] min(Demandᵢ,ⱼ_job, FairShareᵢ,ⱼ_job(t)) dt

ρᵢ,ⱼ_job(t₁,t₂)
  = Allocᵢ,ⱼ_job(t₁,t₂) / FairShareᵢ,ⱼ_job(t₁,t₂)

于是 Phase 1 能回答“哪一个 tenant 最欠”，Phase 2 再回答“这个 tenant 内哪一个 job 最欠”。只有一层 job 账本时，大量小作业的 tenant 可能挤压其他团队；只有 tenant 账本时，团队总量达标也可能由一个大作业独占。两级比值缺一不可。

八、理论度量到实现度量：式（16）的改动

模拟器在 tenant 选择时没有原样使用理论式 min(Demand,Quota)，而是把瞬时 tenant 公平份额改成：

FairShareⱼ_tenant(t) = Quotaⱼ(t)

这意味着即使 tenant 当时需求不足，其分母仍按 quota 增长，出借的空闲资源会形成一笔可见的历史差额。以后它出现 burst demand，较低的 tenant 比值可让它优先取得超过静态 quota 的资源，把先前出借的服务追回。论文给出的另一个理由是：原始 LTGF 是长窗口指标，tenant 曾经多拿资源后突然来一批新作业，较高比值可能在一段时间内压住这批作业；quota 版分母持续增长，能更快消化旧的“多拿”记录。

这项改动也改变了统计语义。理论式问“在有需求时是否得到应得服务”，实现式更接近“相对资源贡献，长期是否得到 quota 对应服务”。因此复现时必须明确自己使用式（8）还是论文模拟器的式（16），不能把两者结果混在一起。论文实验中的 tenant fairness 和两阶段选择基于这个调整版本。

Phase 2 还加入新提交作业优先。论文认为短作业在生产负载中占多数，提高新作业 reward 能让它们较快完成。算法章节另外说明三类可插入的优先因素：新作业、已经执行过很多 lease 的长作业、用户标记的紧急作业；但正式算法 2 只写了 reward=-ρ_job，实验实现明确采用的是新作业优先，论文没有公开附加 reward 的数值公式。复现者不能自行填一个系数后仍声称是原始配置。

九、两阶段算法：从欠账到一次可执行分配

每个调度轮开始时，ASTRAEA 暂时把所有运行中与排队作业都视为 pending，把全部 GPU 视为可用，再重新决定下一 lease 谁继续。统计窗口统一从 t_begin 到当前 t_now。算法反复执行，直到没有 demand 能被剩余 GPU 与 placement 同时满足的候选。

function ALLOCATE_ROUND(tenants, jobs, free_gpus, lease_length):
    为每个 tenant 计算 ρ_tenant(t_begin, t_now)
    为每个活跃 job 计算 ρ_job(t_begin, t_now)
    remaining_tenants = tenants 的副本

    while 存在 demand ≤ free_gpus 且可被放置的 pending job:
        # Phase 1：先偿还 tenant 欠账
        tenant = remaining_tenants 中 ρ_tenant 最小者
        if tenant 不存在:
            break

        # Phase 2：再偿还该 tenant 内的 job 欠账
        对 tenant.pending 中每个 job:
            job.reward = -job.ρ_job
            按实现策略叠加“新作业优先”等附加 reward
        job = reward 最大者

        placement = CONSOLIDATED_PLACE(free_gpus, job.demand)
        if placement 存在 且 job.demand ≤ free_gpus:
            授予 job 一个 lease 和完整 demand
            free_gpus -= job.demand
            从 tenant.pending 移除 job
            # 假定它将跑完整个 lease，立即更新本轮后续选择所见的账
            tenant.actual_service += job.demand × lease_length
            重算 tenant.ρ_tenant
        else:
            # 该 tenant 当前候选放不下，不阻塞其他 tenant
            从 remaining_tenants 移除 tenant

    return 本轮被选作业及其 placement

这段伪代码有三个容易误读之处。其一，最欠账 tenant 的某个作业放不下时，算法跳到其他 tenant，而不是让整个集群空等，因此仍然 work-conserving。其二，选择一个作业后会先按“完整运行一个 lease”预记 demand×lease_length，再挑下一项；否则同一个 tenant 会在本轮内被连续选中而看不到刚分出的资源。其三，正式算法没有规定比值相同的 tie-break，也没有给附加 reward 的精确函数。工程实现应选稳定规则，例如提交时间再加 job ID，并在结果中记录该偏差。

十、lease、checkpoint、续租和 placement 的完整数据流

lease 的作用。 长训练被切成固定期限的多个执行段。短于一个 lease 的作业完成后立即释放资源，不必等到租期末；长作业到期主动请求续租。固定边界让调度器只在有限频率上重排，避免瞬时公平造成的持续抖动。

on-demand checkpoint 与 last store。 ASTRAEA 需要修改用户侧 DL library，并在作业启动时创建 daemon。每个训练迭代结束，作业更新模型和其他状态的内存 snapshot。调度器决定收回资源时发送 POSIX signal；daemon 立即把最近一个完整 snapshot 刷到磁盘，同时等待当前迭代结束。如果迭代能在抢占前结束，就再写一个更新 snapshot；来不及则放弃本迭代进度，将来从先前已刷盘版本恢复。这样资源回收不必无限等待一次很长的迭代。

renewal coordinator。 coordinator 触发续租、回收未续租作业资源，并恢复新获租期的作业。当前 lease 内的运行作业若再次被算法选中，就收到 successful renewal，继续占用原资源，不发生 cold start；未选中者暂停并释放。必须等所有被抢占资源释放后，才对新选 pending jobs 执行 placement，避免账面空闲与物理占用冲突。

placement。 论文不把 placement 算法列为贡献，采用 consolidated strategy：尽量把一个作业放到尽可能少的节点，减少跨节点通信并降低碎片。LTGF 只决定“谁应当先拿”，placement 决定“当前拓扑上能否拿到”。若最欠账作业无法满足拓扑，调度器允许越过它；因此短期执行次序不是纯粹按比值排序。

十一、数字化端到端例子：一轮怎样选 tenant、job、lease 与节点

下面是按论文公式构造的演算例，不是实验 trace 中额外报告的数据。设集群有 2 台服务器，每台 8 GPU，共 16 GPU；Tenant A 与 B 同权，各自 Quota=8 GPU。lease 长度取论文实验配置 900 秒。截至当前时刻，两者的公平累计服务分别都是 72,000 GPU·s；A 实际拿到 54,000，B 实际拿到 72,000，因此：

ρ_A_tenant = 54,000 / 72,000 = 0.75
ρ_B_tenant = 72,000 / 72,000 = 1.00

Phase 1 先选 A。A 队列有 A1（demand 8，ρ_job=0.50）和 A2（demand 4，ρ_job=0.80）；B 有 B1（demand 8，ρ_job=0.40）。虽然 B1 的作业比值全局最低，算法仍先维护 tenant 层，所以 Phase 2 只在 A 内比较，reward=-ρ_job 得 A1 为 −0.50、A2 为 −0.80，最大 reward 是 A1。consolidated placement 把 A1 的 8 GPU 全放到节点 1。

调度器立即给 A 的本轮账本预记 8×900=7,200 GPU·s。为简化演算，公平分母先保持本轮开始值，则 A 的临时比值变为 (54,000+7,200)/72,000=0.85。还剩 8 GPU，A 仍比 B 的 1.00 更低，于是再次选 A，候选只剩 A2。A2 要 4 GPU，可放在节点 2，预记 4×900=3,600 GPU·s 后 A 的临时比值约为 64,800/72,000=0.90。剩余 4 GPU 无法容纳 B1 的 8-GPU gang demand，本轮停止；不能把 B1 拆成 4 GPU。

900 秒后，A1、A2 到达租期边界。假设 A2 已完成，它立即释放节点 2 的 4 GPU，不请求续租。A1 尚未完成，daemon 已维护最新完整 snapshot，它与 B1 一起重新进入候选视图。此时 A 的实际累计服务上升，B 的公平分母也随时间增长而实际服务没有增长，下一轮 B 的 ρ_tenant 很可能变成更低者。若 B 被选，B1 可以整机放到已空闲节点；A1 若未续租，收到 signal，last store 刷盘并释放节点 1。coordinator 等回收完成后启动 B1。A1 将来再次获 lease 时从网络存储恢复。

这个例子串起了四类约束：tenant 比值决定跨团队顺序，job 比值决定团队内顺序，gang demand 决定 4 块剩余 GPU 不能给 8-GPU 作业，consolidated placement 决定整机落点，lease 和 checkpoint 则把下一轮的公平纠偏变成安全抢占。真实实现会在时间推进后同时更新实际积分与公平积分，示例中的“分母暂不变”只用于清楚展示论文算法第 14 行按完整 lease 预记分子的效果。

十二、系统与模拟器实现细节

论文用 trace-driven simulator 实现 LTGF 和 ASTRAEA。输入事件至少包含提交时间、运行时长、GPU demand、tenant／VC 身份；模拟器按 10 秒调度间隔推进，维护作业状态、tenant 独立队列、节点可用 GPU、累计实际服务和公平服务。作业时长与 GPU demand 保持 trace 原值；论文说明即使提交时间做过归一化，这两项也不修改。集群初始时全部节点可用，每轮处理上一调度间隔内提交的作业。

Phase 1 使用式（16）的 quota 分母而非 demand-aware 式（8）；Phase 2 除 -ρ_job 外优先新提交作业。placement 固定为 consolidated。lease 是 900 秒，调度间隔是 10 秒，两者不是一个概念：调度器每 10 秒响应新提交，但运行作业只在 lease 边界接受是否续租的重排。论文称这些设置与现实 round-based scheduler 的默认设置兼容。

抢占开销被分成 checkpoint 和 cold start。每次 lease 到期都制作 checkpoint 以防未续租；只有续租失败并在以后恢复时才发生 cold start，而 cold start 是前人工作观察到的主要抢占成本。连续续租允许作业原地运行，从而避免这部分成本。论文没有给出 simulator 中单次 checkpoint、恢复、调度计算耗时、存储带宽的完整参数表，也没有给 on-demand checkpoint 的实机微基准。这些缺项限制了第三方对 0.8% 开销结论的逐项复算。

十三、实验设置：trace、规模、指标与负载处理

缩小规模是为了排除 Venus 中 CPU 作业和生产集群普遍低利用率的影响，让模拟负载更密集。Philly trace 没有 VC size，论文假设每个 VC 的大小与该 VC 所有作业请求 GPU 数的总和成正比。这个推定直接决定 tenant quota，因而也是公平结果的一项重要假设。

共同配置为 900 秒 lease、10 秒 scheduling interval、consolidated placement。cluster 初始化为所有节点可用。三类主指标如下：

• Fairness：每个 job 计算 ρ_job；每个 tenant 在多个固定区间计算 ρ_tenant 并观察分布。论文没有在文字中给出这些固定区间的具体长度。
• Average slowdown：(pending time + running time) / running time。它归一化等待，短作业等待同样时长时惩罚更大。
• Average JCT：用平均完成时间衡量集群调度效率，数值越低越好。

十四、六个基线各自在比较什么

前四个基线代表静态 quota、可借 quota、异构匹配与 least-attained-service 等不同常见目标；后两个分别是当时面向 job 公平和 tenant 公平的代表。比较覆盖面较广，但不是所有基线都与 ASTRAEA 优化同一目标，因此公平、slowdown 和 JCT 必须一起看。

十五、公平实验：作业和 tenant 两层的准确结果

作业级结果用 CDF 比较每个作业的 ρ_job。在 Venus 上，把 ρ_job<0.95 定义为 sharing-loss job，ASTRAEA 的比例是 7.1%；Themis 是 19.7%，为 ASTRAEA 的 2.8 倍；YARN-CS 是 73.6%，为 ASTRAEA 的 10.3 倍。论文称 ASTRAEA 在 Philly 的优势更大，原因是 Philly 的资源和作业在 tenant 之间更不均匀，但正文没有给 Philly 三项准确百分比，所以不从 CDF 估读。

tenant 级结果在多个时间区间计算每个 tenant 的 ρ_tenant，再统计 ρ_tenant<1 的区间比例。Venus 上 ASTRAEA 为 5.2%；Allox 为 6.9%；Gandiva_fair 为 8.0%；Tiresias-L 为 49.0%；YARN-CS 为 44.6%。相对这些基线，论文概括 ASTRAEA 改进为 1.3 倍至 9.42 倍。Philly 得出相似结论，正文同样未列逐基线百分比。

这里的“9.42 倍公平改进”具体来自 sharing-loss 区间比例的比值，而不是 ρ 本身乘了 9.42，也不是 JCT 加速 9.42 倍。类似地，“10.3 倍 job fairness”对应 YARN-CS 的 73.6% sharing-loss jobs 与 ASTRAEA 的 7.1% 之比。把倍数还原成原始指标，才能避免把少量坏事件的下降误读成所有作业吞吐提升。

十六、JCT、slowdown、开销、lease 与集群规模

slowdown。 图 12 的 CDF 显示 ASTRAEA 的等待开销在所比较调度器中最低，既能快速响应短作业，也能减少长作业等待。仍有极少数作业 slowdown 很大，因为其运行时间短到约 5 秒，而调度周期是 10 秒；仅等待一个周期就会使归一化 slowdown 显著上升。缩短调度周期可改善它们，却会提高调度器负载。论文没有为各方法报告一个精确的平均 slowdown 标量，不能从曲线位置编造。

平均 JCT。 图 13 显示 ASTRAEA 的平均 JCT 小于所有基线。论文把原因归于短作业的 work conservation、长作业等待减少，以及 tenant quota 可灵活借出与追回。正文没有列出图 13 每根柱的准确值，因此可以确认排序，不能声称具体缩短百分比。“不牺牲平均 JCT”是有图形比较支持的定性结论，不等于论文给出了每个 trace 上统一的加速倍数。

抢占开销。 每次 lease 到期都会 checkpoint，续租失败才导致以后恢复的 cold start。续租成功可原地继续，避免主导抢占成本的 cold start。Venus trace、900 秒 lease 下，论文报告 checkpoint 与 cold-start 合计只给平均 JCT 带来约 0.8% 额外开销。

lease 敏感性。 lease 变长时，checkpoint 和切换频率先下降，更多作业可在一租期内完成，JCT 因而先下降；继续加长则重排机会过少，JCT 又上升，公平也随纠偏频率下降而变差。历史 trace 上 1,200 秒是文中所称最有效率的长度，900 秒有相近 JCT、但公平更好，所以后续实验选 900 秒。图 9 还测试了其他长度，但正文没有逐点列出 JCT、preemption overhead 和公平值，本页不猜测图中坐标。

集群规模敏感性。 图 14 比较 ASTRAEA 与此前实验中表现较强的 Tiresias-L，指标是平均 JCT 和 ρ_job<0.95 的 sharing-loss job 比例。论文结论是在所测节点规模上，ASTRAEA 始终同时优于 Tiresias-L；集群越大，两者的 JCT 与公平表现都改善，因为更多空闲资源能容纳更多 gang jobs、减少等待并偿还公平欠账。正文没有列出所扫节点数及每个点的准确坐标，故只能保留这一趋势与排序。

十七、结果为何成立，以及局限和不适用场景

各机制怎样作用于结果

• GPU-time 同时计入空间和时间。 大作业运行一分钟时分子增长更快，不再与小作业运行一分钟被视为同等服务。这直接修复完成时间公平的需求虚报激励，也解释 job sharing-loss 比例为何下降。
• tenant → job 两级选择。 Phase 1 防止一个团队用作业数量压过别的团队；Phase 2 防止团队内部由单个大作业垄断。它对应实验里 tenant 与 job 两类改进，而非用单一指标碰巧兼顾。
• quota 分母形成出借凭证。 低负载 tenant 出借 GPU 后，比值相对下降；burst 到来时能优先追回。资源不必为静态隔离而空置，因此公平改进没有以更高平均 JCT 为代价。
• lease 把抢占频率封顶。 900 秒给调度器周期性纠偏机会，连续入选者又能原地续租。公平靠有限重排实现，0.8% 开销则来自避免不必要 cold start。
• 可放置性跳过保持利用率。 最欠账作业因 gang size 或拓扑放不下时，其他作业仍可运行。这牺牲瞬时严格次序，换取 work conservation 和较低 JCT。

论文证据没有覆盖的部分

• 只有 trace-driven simulation，没有生产部署、控制面扩展性、scheduler 决策延迟、网络存储拥塞或故障恢复实测。checkpoint 数据流的可行性描述不能替代完整原型证据。
• 评测节点统一为 8 GPU，账本只核算 GPU。异构 GPU 的速度／价格差异、CPU、RAM、网络带宽、多资源主导份额都没有进入 LTGF；Gandiva_fair 的异构交易机制也被明确排除。
• 算法假定固定 demand 和 gang scheduling。弹性训练可在运行中改变 GPU 数，GPU-time 增长与训练 goodput 未必成比例，直接套用会把“卡时相等”误当“有效训练进度相等”。
• on-demand checkpoint 要改用户侧 DL library、运行 daemon 并依赖网络附加存储。无法一致性保存模型与优化器状态、单次迭代极长或 checkpoint 巨大的作业，会有更高丢进度和 I/O 成本。
• LTGF 是回顾性账本，不提供 deadline 保证。论文只说可给紧急作业增加 reward，没有给约束求解、可行性判断或违约界限。
• sharing incentive 的独立小集群参照在 M/N 小于 gang demand 时并不能真的启动作业；公式用 min(Demand,FairShare) 处理服务量上限，但“性能不差于独立集群”的字面语义在该边界并不充分。更稳妥的理解是长期 GPU service-time 基准。
• 式（16）会让无需求 tenant 的 quota 分母继续增长。它有利于未来追回，但也意味着统计的“欠账”包含主动闲置，而不全是调度器造成的拒绝；长期保留多少历史、tenant 消失或权重变化时如何重置，论文没有说明。

不适用或需要重定义的环境

ASTRAEA 不适合直接用于低延迟在线推理、不可抢占／不可 checkpoint 的训练、严格物理隔离集群、GPU 型号差异决定价值的混合集群、资源需求频繁弹性变化的训练，以及以 deadline、成本、能耗或 goodput 为首要目标的环境。若 tenant 之间共享 CPU、内存和网络也会成为瓶颈，只公平核算 GPU-time 仍可能产生总体不公平。此时可以借用“两级历史账本＋周期性执行”的结构，但分母、服务单位和 placement 约束必须重定义。

十八、复现清单：怎样得到可核对而非相似的结果

1. 锁定 trace 口径。 Venus 使用两周快照、11,304 jobs、16 tenants；Philly 使用两周快照、44,329 jobs、15 VCs。保留原始 duration 和 GPU demand，记录提交时间是否归一化。完整六个月 Venus 统计用于动机分析，不要误当评测输入。
2. 重建资源规模。 Venus 配 100×8=800 GPU，Philly 配 210×8=1,680 GPU，初始全部可用。Philly VC quota 按各 VC 全部作业请求 GPU 总量的比例推算；保存推算表以便审计。
3. 统一时间与服务单位。 选秒或分钟作为唯一时间单位，实际服务始终计算为 allocated GPU × elapsed time。调度周期 10 秒，lease 900 秒；短作业完成即刻释放，不补记到 900 秒。
4. 实现状态积分。 pending/running 的 Active=1，failed/completed 为 0；每个事件区间分别累计实际分子与公平分母。验证 demand 上限的 min，并分别实现理论式（8）和实验式（16），正式对比用后者。
5. 实现两阶段选择。 每轮先最小 ρ_tenant，再在其队列最大 reward；基础 reward 为 -ρ_job。选中后按完整 lease 预记 tenant 服务，再继续挑选。记录论文未规定的 tie-break 和新作业 reward 细节。
6. 实现物理约束。 demand 必须全给或不给，consolidated placement 尽量少跨节点。候选放不下时移除当前 tenant、继续其他 tenant；不能把“GPU 总数够但拓扑不够”误判为可运行。
7. 实现续租状态机。 每轮视图包含 running 与 pending jobs；running 再次入选则保持 placement，未入选则 checkpoint、释放，所有释放完成后再启动新作业。模拟 cold start 时单独记账，避免把成功续租也算一次恢复。
8. 对齐六个基线。 实现 YARN-CS、HiveD、Allox、Tiresias-L、Themis、Gandiva_fair 的论文口径。特别标注 Themis 预测误差率和附加优先级，因为 ASTRAEA 论文没有给出这两个参数的准确数值；Gandiva_fair 不含自动交易机制。
9. 先做小例子单元测试。 检查 6-GPU、一个 6-GPU job 加两个 3-GPU jobs 的反例：20 分钟的完成时间轮转会产生 60、30、30 GPU·min；LTGF 目标下一个 10 分钟大作业轮次对应两个 10 分钟小作业并行轮次，三者在 30 分钟窗口各得 60 GPU·min。
10. 复算公开的锚点。 Venus 应得到作业 sharing-loss 比例 7.1%（ASTRAEA）、19.7%（Themis）、73.6%（YARN-CS），tenant sharing-loss 区间 5.2%、6.9%、8.0%、49.0%、44.6%，以及 900 秒 lease 下约 0.8% 平均 JCT 开销。若这些锚点不符，先检查积分窗口、式（16）、完成即释放和 lease 预记。
11. 分离可复现与不可精确复算项。 论文未在正文提供图 12 CDF 坐标、图 13 柱值、图 14 各规模坐标、checkpoint/cold-start 完整参数、Themis 误差率和固定 tenant 统计区间。没有作者 artifact 时，应报告趋势复现和参数敏感性，不宣称像素估读出的数值与原论文完全一致。

最终判断：ASTRAEA 的主要价值是把共享 GPU 集群中的公平拆成两个可审计账本，并设计 lease 执行器周期性偿还欠账。它最适合固定 gang demand、作业可 checkpoint、tenant 权重明确且 GPU 同质的训练集群。实验有力支持“在两条生产 trace 的模拟中显著减少 sharing loss，且平均 JCT 不恶化”，但不支持把结论无条件推广到异构、多资源、弹性或 deadline 场景。