算电大统一 02：电力缺口如何变成计算损失

一台计算设备遇到两种供电限制：功率降低40%，持续5分钟；或者降低10%，持续20分钟。

如果原本的功率相同，两次少供的电量一样。任务受到的影响，也会一样吗？

我们的这轮仿真给出了一个具体反例。在同一段请求序列中，两种限制产生的p99请求总延迟分别为68.31秒和10.73秒。p99的意思是，按延迟从小到大排列，约99%的请求不超过这个位置；它用来观察排在后面的慢请求。

这个差别来自排队过程。电量只记录总数，任务还会记住供电变化发生在什么时候、积压了多少请求，以及工作进度是否来得及保存。

先交代证据范围：本文使用公开请求轨迹、公开训练静态测量和受控仿真，没有在本机做GPU限功率实验。请求到达时间和长度来自公开数据，下面的延迟是模型算出的，不是Azure线上系统的实测延迟。

为什么把计算响应单独做成一篇

第一篇回答电池在指定条件下能承诺多少功率；这个数字进入服务器以后，还不能直接变成请求成功率。中间至少有功率到处理速度、处理速度到队列，以及中断到恢复三道转换。如果同时把电池参数和计算机制都放进仿真，看到任务损失以后，很难判断它来自哪一层。

因此，本篇直接以计算入口可分配功率为输入，不让电池容量分布、温度或化学体系参与实验。我们只研究一个问题：已经给定供电变化时，计算模型需要保留什么信息，才能描述任务后果。

最初值得警惕的，是“画一张功率缺口—持续时间—损失曲面，就等于建立真实计算能力接口”的设想。曲面可以来自真实测量，也可以只是模型规则的可视化。两者的证据强度不同。研究需要先检查有没有真实动态功率响应，再决定能把结果称作什么。

本机环境审计能查询到GPU，但本轮没有配置可运行的训练框架，也没有实施限功率、任务训练或掉电恢复。公开资料同样没有恰好配齐本研究所需的全部动态测量。所以，本篇选择“公开输入驱动的机制仿真”，把缺少的测量显式留在假设一栏。

搜到的论文，各自解决了哪一段

资料	本轮实际取得与用途	不能替本文证明什么
You、Chung、Chowdhury的Zeus	开放全文及公开静态训练摘要；取固定配置的功率上限—epoch时间形状	动态限功率、掉电恢复或LLM推理速率已经标定
Patel等的POLCA	开放作者版；了解LLM功率模式、频率控制与功率cap的差异	本文已经复现生产级控制器或瞬时端口限制
Stojkovic等的DynamoLLM	开放作者版与官方请求轨迹；保留请求到达和长度结构	轨迹本身带有本文的真实延迟和GPU瓦数
Chung等的Perseus	开放全文；确认分布式训练关键路径与能量冗余已有研究	单一进度时钟等于多机训练实现
Kim等的阶段分离功率控制	2026开放预印本全文；对照阶段、模型和部署校准的必要性	特定系统的B200结果可以替代本文硬件标定
Daly的检查点研究	题录与出版社摘要，镜像全文未取得	本文实现了其最优间隔推导

上述资料均署名列在文末[1–6]。有全文与只有摘要的获取状态分开保留，没有用一个摘要句子推测整套算法。资料取舍也决定了本文的贡献范围：把总能量压缩何时会丢信息解释清楚，并提供可重复对照；不声称功率管理和检查点机制是新发现。

Kim等的预印本尤其提醒我们，同一个“功率控制”词语背后可能对应不同阶段、模型、硬件和控制手段。把任何一条外部曲线直接贴给本文的服务台，都会省掉最需要验证的那一步。

请求数据怎样选，留下了什么、没有留下什么

原始Azure发布文件覆盖一周，体积较大。本轮对Code和Conversation各流式读取前200000条数据，保留原始文件地址、字节数、行数和SHA256；没有把前缀称作全周。

两个前缀分别约覆盖2024年5月10日UTC 00:00—02:40，以及5月12日UTC 00:00—02:08。只取完整的1200秒窗口，不完整尾窗丢弃。开发和留出按时间位置划定：

窗口组	完整窗口数	请求数	用途
Code前4窗	4	102493	开发与规则检查
Code后4窗	4	97480	同服务留出
Conversation前6窗	6	187513	另一服务的留出
合计	14	387486	有限轨迹池

每行公开字段只有到达时间、输入token数、输出token数。没有原请求的实际延迟、模型身份、GPU功率、调度配置和生产SLO。我们可以保留突发到达和长短请求的关系，却无法从这些字段反推出真实服务器的完整服务能力。

工作量按“0.125×输入长度＋输出长度”构造，再把窗口总服务需求归一到指定负载率。0.125是公开写出的假设，不是从GPU测出的预填充成本；本轮也没有对该权重进行全面辨识。负载率0.8意味着总名义处理需求为窗口长度的80%，不意味着Azure原系统在那一刻有80%的实际利用率。

这个归一化方便比较请求结构，却改变了绝对吞吐的物理意义。本文即使输出每秒完成多少请求，也只能读作当前模型容量下的吞吐。Code与Conversation两个短前缀也不是跨天、跨硬件、跨模型的随机生产样本。

（P2-1）从长度构造工作量与名义服务时间：

$w_j=0.125L_{\mathrm{context},j}+L_{\mathrm{output},j},\qquad s_j=\rho H\frac{w_j}{\sum_{i=1}^{m}w_i}.$

这里 $m$ 是窗口请求总数，$H$ 是观察期，$\rho$ 是设定的归一化负载率，$s_j$ 是额定速率下的处理时间，满足 $\sum_j s_j=\rho H$。输入权重和容量归一化都是建模选择，不是对原部署速度的反推。

解析数据时还有一项必须留档的修正：时间戳混合了带小数秒和不带小数秒的合法ISO格式。程序统一按ISO8601解析，不能因一部分行格式不同就删掉它们。否则，被删掉的到达恰好可能改变拥塞。

电量相同，供电的时间结构可以很不相同

把额定功率记作一个单位，降低40%并持续300秒，少供的总量是“额定功率×120秒”；降低10%并持续1200秒，也是这个总量。

这里的120秒是“缺供能量除以额定功率”，不是实际停电120秒。由于我们没有给请求轨迹匹配真实服务器的入口瓦数，也不能把它直接换成千瓦时或电费。

（P2-2）事件的功率、时长与能量口径：

$x(t)=\frac{P(t)}{P_0},\qquad e=\frac{E_{\mathrm{short}}}{P_0}=\int_0^H[1-x(t)]\,dt=\delta(\tau+r).$

$P_0$ 是额定入口功率，$\delta$ 是缺口比例，$\tau$ 是平顶持续时间，$r$ 是每一侧斜坡时长；事件总长为 $\tau+2r$。最后一个等号要求整个梯形事件位于积分期内，无斜坡时退化为 $e=\delta\tau$。

在主例中，我们取首个按时间划出的Code留出窗口，把同一个20分钟序列重复一次，构造40分钟观察期。这样两次事件都能完整放入，还留有之后的请求。两种事件都从第180秒开始，工作负载、请求处理顺序和初始条件相同。

模型采用先到先服务。先到的请求没有完成，后面的就要等；功率下降时，处理速度按比例下降。请求总延迟超过2秒，记为超期。请求长度如何换成处理时间，以及功率如何换成速度，都是公开写出的情景假设，没有假装成硬件标定。

同一请求序列的情景	请求超期比例	p99总延迟
无供电扰动	8.62%	4.45秒
降低40%，持续300秒	31.80%	68.31秒
降低10%，持续1200秒	22.22%	10.73秒

无扰动这一行很重要：这个窗口在2秒目标下原本就有超期，不能把表中所有超期都算成供电事件新增的损失。两种扰动后的结果也都没有满足2秒目标，不能把较小的10.73秒说成服务已经合格。

同能量事件的超期比例与p99对照见文末图1，虚线为同一请求序列的无扰动基线；图中延迟均为仿真结果。

为什么深而短的缺口在这个例子里更严重？可以把系统想成一个窗口。人来的节奏不变，窗口突然慢了很多，队伍就会迅速变长；恢复正常后，新来的人仍在进入，旧队伍需要慢慢消化。较浅的限制虽然持续更久，却可能没有在短时间内堆出同样长的队伍。

决定后果的是整段过程。只知道总共少处理了多少工作，无法还原每个请求到达时，前面已经排了多少。

先到先服务怎样变成可复查的计算

模型把所有请求放在一个变速服务台上，顺序不变、不丢弃，也不因为延迟太长就从评价队列中删除。它没有连续批处理和KV缓存，所以这是一项用于隔离排队机制的抽象。

额定功率下速率记为1，归一化功率为x，速率写成x的β次方。β分别取0.5、1、1.5，表示三种假设响应形状；β＝1只表示这一档采用线性响应，不能当成测得的物理定律。

（P2-3）假设的功率—服务速率关系：

$v_\beta(t)=x(t)^\beta,\qquad \beta\in\{0.5,1,1.5\},\qquad K(t)=\int_0^t v_\beta(u)\,du.$

$K(t)$ 是累计名义服务能力，单位为名义处理秒；不是电池容量，也不是实际服务器消耗的能量。

为了避免对几万条请求逐时间片逐条更新，程序使用累计服务时钟。它记录到某个时刻为止，服务台总共能提供多少名义处理时间：

（P2-4）变速FCFS的完成时刻：

$F_j=K^{-1}\!\left(\max\{K(a_j),K(F_{j-1})\}+s_j\right),\qquad F_0=0.$

$K^{-1}(y)=\inf\{t\geq0:K(t)\geq y\}.$

$a_j$ 是到达时刻，$F_j$ 是完成时刻；$K^{-1}$ 使用左广义逆，因此允许停电期间的平坦区。若令 $S_j=\sum_{i=1}^j s_i$、$S_0=0$，还可将递推写为用于向量化的形式：

$K(F_j)=S_j+\max_{1\leq i\leq j}\{K(a_i)-S_{i-1}\}.$

这只改变计算方式，没有改变先到先服务顺序；给定累计服务时钟后是同一个FCFS解。

这个表达说明了能量为什么可能不够。即使两个事件结束后的K总量相同，每个请求到达之前的K也可能不同，目标完成时刻就会不同。总量无法恢复所有“到这个时刻为止”的前缀信息。

实现中曾有一个容易让结果过于乐观的陷阱：停电时K不增长，曲线出现平坦区；若删除重复服务量再线性连接，就可能把这段停电时间缩短。正式运行保留平坦区，使用左广义逆，并加入包含真实平坦区的解析检查。这项修正处理的是程序如何忠实表达停电，不是看到结果以后改变成功定义。

评价也分不同账目。请求超期比例和p99看热身后到达的请求，并继续排空它们；窗口内吞吐只数观察期内实际完成的请求。一个请求在窗口结束后才完成，会影响完整延迟，但不会被算作窗口内完成量。两者不能在文字里互换。

（P2-5）超期比例、尾延迟与基线增量：

$D_j=F_j-a_j,\qquad M=\frac{1}{m_A}\sum_{j\in A}\mathbf{1}\{D_j>L\}.$

$D_{0.99}=D_{(\lceil0.99m_A\rceil)},\qquad \Delta M=M_{\mathrm{event}}-M_{\mathrm{baseline}}.$

$A$ 是评价请求集合，$m_A$ 为其大小，$L$ 是总延迟期限；$D_{(k)}$ 指将集合中的延迟从小到大排序后的第 $k$ 项。主P2评价热身后到达的请求，p99按这个最近秩定义取值；$\Delta M$ 才是同序列扰动新增的超期比例，乘100后为百分点。

事件和实验矩阵如何冻结

正式运行前保存了本地设计与固定配置，属于本地预分析记录，没有外部预注册。主要测试档位如下：

控制量	档位／规则
相对功率缺口	5%、10%、20%、30%、40%
平顶持续时间	1、10、30、60、300、900秒
每一侧斜坡时长	0、1、10秒
归一化推理负载率	0.6、0.8、0.95
功率—速率指数β	0.5、1、1.5
事件起点／推理热身	180秒／120秒
推理请求总延迟目标	2秒

5×6×3×3×3×14，共11340组推理主情景。每个窗口、负载和β另跑无扰动基线。主结果使用“扰动超期比例减同窗口基线”，而不是只展示扰动后的总超期。

斜坡的定义也影响能量。平顶时长为τ、两侧各r、幅度为d时，事件总长是τ＋2r，缺供能量／额定功率为d×(τ＋r)。改变r同时改变能量，不能从主矩阵直接宣称已经隔离了纯粹的斜坡因果效应。

同能量的两组配对固定无斜坡：40%×30秒对10%×120秒；40%×300秒对10%×1200秒。后者比原20分钟窗口长，因此把原窗口重复一次形成40分钟序列。这个接缝是人为构造，不应隐藏。训练同能量对照也统一用固定观察期内的有效进度，避免把作业完成以后的缺供算进这个作业的损失。

也不能反过来说，深而短一定更坏

这轮主实验回放了11340组推理情景，改变缺口幅度、持续时间、变化斜坡、负载和假设的功率响应。主数据由14个互不重叠的20分钟窗口组成：4个开发窗口，10个留出窗口。

在同能量实验的180组留出配对中，深而短造成更多超期的有140组，更少的有9组，相同的有31组。这些组合复用了有限的请求窗口，不能称为180次独立生产试验；“相同”也只是本次超期比例在数值容差内相同，不代表每个请求延迟都相同。

有的浅长限制持续压住系统，有的深短限制刚好避开繁忙时段。请求的到达节奏、长短分布、目标期限和处理能力都会改变比较。我们没有把一个好看的窗口总结成“深短总是更危险”。

同样不能把文末图1中的延迟当成某种GPU型号的购买依据。模型没有连续批处理、KV缓存、预填充与解码并行，也没有真实模型身份。公开数据保留了任务结构，却不足以识别完整的生产推理系统。

主矩阵还留下了比单个例子更完整的结果。在负载0.8、β＝1、无斜坡下，10个留出窗口的中位超期增量，跨缺口与时长档位从0到93.53个百分点。短小事件可以没有新增超期，大而长的事件可能把拥塞推到事件之后。这只是受限队列模型的响应表，不能称作生产LLM损失曲面的实测校准。

所有无扰动基线的超期比例范围为0至69.30%。也就是说，一些高负载或突发窗口在这个服务抽象中本来就不满足2秒目标。如果删掉基线，供电扰动会被错误地背上原有服务能力不足的责任。

180组同能量留出配对也不是全部结果的独立试验：它们从10个窗口、两对事件、三负载、三种β组合而来。更多、较少、相同只是各自模型条件中的数值方向；全体配对的超期差约在−1.99至34.28个百分点之间。负号与零差都保留，才能知道结论何时没有出现。

训练任务还会损失已经做过的工作

推理请求关心等多久，训练任务还关心工作保存在哪里。

设一个训练过程每计算120秒保存一次检查点，保存耗时3秒。发生中断时，未保存的部分需要重算；恢复供电后，另付30秒恢复开销。这些时间是本轮控制变量，不是从某家训练集群测得的平均值。

在V100静态曲线驱动的进度模型中，同样一次30秒中断，仅改变检查点计时的初始位置，作业完成时间就分别增加117、147和84秒。

同样中断30秒时，不同检查点相位的回滚与完成时间增加见文末图2；回滚进度已包含在总增加中，两者不能相加。

中断之前刚保存过，损失就小一些；离上一次保存已经很久，损失就大一些。额外完成时间还会受离线、恢复和后续检查点时机影响，不能简单把“断电时长＋回滚时长”当成全部账目。

这里的训练速度形状来自You、Chung和Chowdhury公开的Zeus制品：固定BERT-base、SQuAD、batch 32及优化器，比较不同功率上限下的静态epoch时间[1]。我们归一化后插值，把它接到训练进度模型。原制品不是本轮动态中断实测；每个配置的单次静态测量，也不能提供硬件响应的重复置信区间。

还要区分温和降速和中断。主矩阵的温和限制没有跌破所用曲线最低运行档，因此没有触发训练重启。若把每次限功率都当成一次任务失败，就会人为夸大供电波动的代价。

训练曲线与进度账目，还需要展开一层

Zeus目标配置在V100上有7档功率上限，在A40上有9档。本来计划使用P100作另一GPU曲线，预备解析却发现它没有相同batch 32配置；于是正式实验前改为A40，模型、数据集、batch和优化器保持一致。没有为了得到更明显的损失而按结果挑GPU，也没有悄悄换成另一个batch。

各GPU使用自己的最高power limit作速度归一化。对档位间线性插值，低于最低已覆盖档位时按无法正常训练处理；对可能的微小非单调用累积最大包络，本次主用V100和A40曲线没有需要实质修正的下降点。替换成A40是输入曲线替换检查，不是让一个V100拟合器准确预测未知A40。

功率cap和平均测量值必须分列。A40标称100 W档位的平均读数约105.93 W；我们没有测试其形成原因。这至少说明，不能把静态配置标签直接叫作每一瞬间都严格满足的服务器入口边界。

训练主矩阵共1692组，由两个GPU曲线、三个检查点周期、三个初始相位，以及90种温和事件和4种完全中断组合。检查点周期为60、120、300秒；目标工作量为1200个名义训练秒。周期按计算墙钟计时，写检查点和恢复不产生有效训练。

进度账分四类：降速少做的工作、写检查点占用的时间、未保存进度回滚，以及离线与恢复时间。一个短事件可能改变后续检查点的位置，所以完成时间增加不是某一段局部速度差的简单积分；所有账目都要按同一执行过程记录。

（P2-6）有效训练进度与完成时间：

$W_{\mathrm{gross}}(t)=\int_0^t f_{\mathrm{train}}(x(u))\,\chi_{\mathrm{calc}}(u)\,du.$

$W_{\mathrm{valid}}(t)=W_{\mathrm{gross}}(t)-W_{\mathrm{rollback}}(t),\qquad T_{\mathrm{job}}=\inf\{t:W_{\mathrm{valid}}(t)\geq W_{\mathrm{target}}\}.$

$f_{\mathrm{train}}$ 来自归一化静态训练曲线；只有正常计算时 $\chi_{\mathrm{calc}}=1$，写检查点、离线和恢复时为0。$W_{\mathrm{rollback}}$ 累计扣除已经执行但未保存、后来被中断丢弃的进度。进度可以因回滚下降，完成时间必须按实际执行过程找首次达到目标的时刻，而不是把额定时长直接除以平均功率。

前面的30秒中断可以展开成完整表：

检查点初始相位	回滚的名义进度	作业完成时间增加
0秒	57秒	117秒
30秒	87秒	147秒
90秒	24秒	84秒

不同相位改变的是事件发生时距离上一次成功保存的位置，不是在三种情况下修改中断时长。文末图2的蓝柱已经包含橙柱相应的回滚影响，两者不能相加。

再看固定40分钟、检查点周期120秒、初始相位0的同能量训练对照：

静态曲线	同能量事件对	深短有效进度	浅长有效进度
V100	40%×30秒／10%×120秒	2336.411	2340.170
V100	40%×300秒／10%×1200秒	2278.424	2314.699
A40	40%×30秒／10%×120秒	2337.177	2341.968
A40	40%×300秒／10%×1200秒	2285.932	2332.679

进度单位均为名义秒。数值来自静态曲线驱动的进度回放，既包含速度非线性，也包含检查点时间对齐，不能只归因于某一个机制。

全部GPU／检查点／相位组合中，深短减浅长的有效进度差约为−47.170至−3.173名义秒。训练侧这组对照方向一致，仍不足以推出任意模型、任意检查点策略也会如此；它是本次固定组合的结果。

有一种情况下，同能量确实等价

我们保留了一个刻意简单的对照：没有排队、没有检查点、没有中断恢复，训练速度又与功率严格成正比。

在相同观察期里，两次少供的电量相同，累计完成的工作就相同。程序也检查了这一点。

（P2-7）线性连续训练的负对照：

$W(H)=\int_0^H x(t)\,dt=H-e.$

这个等式要求速度与功率线性、全过程持续计算、没有检查点和回滚，并且两个事件都完整落在同一观察期。它是严格的模型极限，不是近似拟合。

这说明，不能把“同能量必然不同损失”换成新的口号。产生区别需要具体机制：服务速度的非线性、请求到达与排队、任务起止位置，或检查点和恢复。模型把这些机制写进去以后，才有理由讨论时间结构。

本轮9项核心测试通过；把服务时钟步长从0.25秒减到0.125秒，4个指定案例的p99变化最大约0.001秒。这支持数值实现的一致性，仍然不等于真实GPU行为已经验证。

研究过程中实际改了什么

记录	为什么要改	对结论的处理
时间字段解析	两类合法ISO精度混合	统一解析，未删行以凑齐格式
P100改A40	同一目标配置不可得	正式实验前登记，未根据扰动结果选择
服务时钟平坦区	去重插值可能缩短停电	修复左广义逆，加入解析对照后正式运行
同能量观察期	1200秒长事件及后续队列需要完整容纳	统一重复成2400秒，披露人工接缝
能量字段名称	归一化数值易被误读为焦耳	改为明确的E/P0、单位秒，绑定最终脚本

数值核查也分清了对象。独立标量FCFS循环与服务时钟在恒定速率下逐请求比较；零扰动、事件面积、真实平坦区、检查点账目和线性负对照都有检查。9项公共测试还包括第三篇使用的电池接头测试，不能把它们都叫作推理硬件测试。

四个指定积分细化案例中，p99最大变化约0.000949秒，请求超期比例最大变化约0.0001283，也就是0.01283个百分点。小数差支持这些案例的数值稳定，不是对全部情景的统一误差证明。服务时钟给定后的FCFS代数求解与功率速率积分的离散误差，也属于不同层次。

最终配置、源代码和原始输入均保存哈希，图直接读取派生表。没有为了让图更整齐而手工改数。修改实现的记录与正式结果一起保存，后续复查者才知道眼前的数值对应哪个版本。

供电和计算之间，还需要多说几句话

如果供电侧只交来“这次缺了多少电”，计算侧很难判断该怎么响应。至少还需要缺口幅度、持续时间、变化过程，以及能否恢复、恢复需多久。

计算侧也需要交代任务：请求何时到达、期限多紧、允许多少超期；训练何时保存、可否暂停、恢复后是否重算。同一份电力事件，接到不同任务上，损失可以完全不同。

已有系统研究已经在处理这些问题。Patel等的POLCA分析了LLM功率模式和控制方式；Stojkovic等的DynamoLLM研究了在服务目标下管理推理配置；Chung等的Perseus研究了分布式训练中的能量冗余与关键路径[2–4]。本文没有复现这些系统的控制器，而是把几个容易混淆的机制拆开，给出能回查的对照。

要往真实部署前进一步，需要测到具体模型、批处理方式和硬件在动态限功率下的响应，也需要真实检查点与恢复记录。本文已经完成的是一套公开输入、代码、结果表和明确边界的机制实验。

因此，看到一次电力波动，除了问少供多少电，还应问：它发生时，计算任务正在做什么？

接下来该补哪类证据

如果目标是让接口真正用于具体LLM服务，首要工作是固定硬件、模型、量化方式和批处理配置，测量动态限功率时的服务响应。预填充、解码、TTFT和逐token间隔需要各自的测量口径，不能只留下一个总延迟数字。

如果目标是训练保障，则需要真实检查点写入时长、恢复时间、未保存进度和任务完成记录，并检查通信与慢节点。把同质进度时钟换成真实分布式训练之前，当前曲线应继续被称作机制情景。

新的验证还应把辨识与留出分开：用一组任务标定功率响应，再用未参与标定的事件检验预测，而不是在同一批事件上既拟合曲线又宣布精度。需要覆盖轻载、临界拥塞和恢复区间，因为全都轻松通过或全都拥塞，都会让比较缺少分辨力。

这些是后续计划，不是本轮已经完成的实验。本轮留档的成果包括输入范围、建模公式、完整参数矩阵、基线、反例、实现修正、图表和复现入口。它使后续硬件测量知道该补哪一段，也使读者能够辨认哪些规律来自真实请求结构，哪些来自模型定义。

资料与署名

[1] Jie You、Jae-Won Chung、Mosharaf Chowdhury，Zeus: Understanding and Optimizing GPU Energy Consumption of DNN Training，NSDI 2023，119–139。官方论文与制品。训练摘要数据来自作者仓库，许可Apache 2.0。

[2] Pratyush Patel等，POLCA: Power Oversubscription in LLM Cloud Providers，开放预印本，2023。原文。本文不将其原系统结果当成本轮实验收益。

[3] Jovan Stojkovic、Chaojie Zhang、Íñigo Goiri、Josep Torrellas、Esha Choukse，DynamoLLM: Designing LLM Inference Clusters for Performance and Energy Efficiency，HPCA 2025，DOI。Azure官方请求数据说明，CC BY 4.0。本轮仅下载Code、Conversation两份文件各前20万行，未使用完整一周数据。

[4] Jae-Won Chung等，Reducing Energy Bloat in Large Model Training（Perseus），SOSP 2024，DOI。

[5] John T. Daly，A higher order estimate of the optimum checkpoint interval for restart dumps，Future Generation Computer Systems，2006，22(3):303–312，DOI。本轮只取得题录和摘要，不声称复现其间隔优化。

[6] Jae Gon Kim、Donghoon Yoo、Hanyul Ryu、Sungho Ha、Juyeon Lee、Soojung Ryu，Phase-Decoupled, Model-Calibrated Power Control for Disaggregated LLM Serving，2026-09-10开放预印本，全文。本轮取得全文，未作为已核同行评审结果；其特定部署不能代替本文的硬件校准。

本文数字对应同目录研究稿与仓库P2派生表；检查点等具体设定属于本研究情景，不冒用外部文献背书。

文末图说明

配图集中列在文末，依图号顺序对应正文引用。

图1｜同能量事件的排队后果

同一窗口、同一请求序列、相同负载率。横轴12和120是缺供能量／额定功率，单位秒；虚线为同一序列的无扰动基线。左边看超期请求，右边看慢请求。图中延迟均为仿真结果。

图2｜中断与检查点位置

检查点周期120秒、写入3秒、恢复30秒，其余条件相同。蓝柱是完成时间增加，橙柱是其中回滚的名义进度；两柱不能相加。它们是模型输出，没有执行真实掉电恢复。