Slasher: Power Flexibility for Cloud Datacenters
Liuzixuan Lin, Fiodar Kazhamiaka, Alok Gautam Kumbhare, Chaojie Zhang, Jaylen Wang, Hassan Khan, Rodrigo L. Assis, Mariana Rodrigues, Kyle Woolcock, Nithish Mahalingam, Brijesh Warrier, Rodrigo Fonseca, Ricardo Bianchini
cs.DC, cs.OS, eess.SY
2026-08-27
微软 Azure 的 Slasher 用电池、关停和期望缺口模型在生产机房削电；仿真里前 5% 靠空闲机，再削到 15% 时重算分数把高优服务影响压到接近零。
云数据中心过去默认合同功率上限之内可以随便用。AI 把这个前提打穿了：新园区在电网侧被推迟，爱尔兰等地已经把需求响应写进并网条件。冷却故障可能要在大约 30 分钟的热惯性窗口里把整个机厅削掉 10%，并维持 3 到 6 小时；多排同时故障则要几乎立刻在局部域削 5%，否则断路器连锁跳闸。
公开云更麻烦：一台机器上跑着互不相识的虚拟机，平台几乎看不见应用，「让作业自己让路」用不了。电池按小时级事件配会很贵，柴油机又受排放时长限制。
Slasher 是微软 Azure 的通用功率柔性系统。核心机制已经在生产里跑，部分手段和场景还在接入。事件被收成五个维度：发生频率、提前量、持续时长、削电幅度、爆炸半径。子秒级的并网电压穿越被明确排除，软件来不及。
架构分成两层。机厅控制器离线算好 playbook，把增量削电映射成动作序列和影响表；事件触发时多场景取最紧约束、查表执行。毫秒级响应交给机旁硬件做电池放电和处理器限频，软件再接上关停与迁移。区域编排器把削电额度分给伤得最少的机厅。
重叠事件记在配电树上，关重叠区里的一台机器能同时计入两件事。
怎么选关哪台机器，是这篇的算法核心。平台看不见服务等级目标，于是用「服务」（一组协同虚拟机）的历史 CPU 用量拟合负载分布，把关掉容量的风险写成金融里的期望缺口：超过剩余容量的那截负载按概率积分，再除以平均负载。服务优先级用平台能看见的属性相乘，外部客户 1000、现网内部 100、Spot 直接 0。贪心按单位瓦特的边际影响选机，每选一台就重算相关服务的边际成本，避免把同一条服务的缓冲吃穿。
配套的 Stratosim 按虚拟机粒度回放功率遥测，用来试控制策略。生产侧还有一次快速频率响应试点：电池先把电网侧功率压下去，软件再关内部机架，放电速率随 IT 功率下降而收，然后慢充并恢复。
杠杆量化来自微软 20 个数据中心、9 天的生产数据。
CPU 降频看起来便宜，账不算。Vault 在 3.7 GHz 还能在 p99 目标内撑 1300 请求/秒，2.5 GHz 只剩 600，峰值的 46%。十个请求型应用里，动态功率削 40% 时中位只剩 48% 服务容量，最差的 Go HTTP 只剩 7%。丢掉的吞吐通常比省下的瓦特更多。
拦住新部署更温和：中位轨迹两小时空闲机约 +2%、占用率约 −8%。热迁移理想情况下一小时多腾 3% 的机器。成熟集群空闲机通常不到 5%，所以空闲机关机很快见底。
控制策略在约 5000 台非空服务器、10000 个服务的轨迹上对比。前 5% 削电靠关多余空闲机，几乎无伤。再往上，按利用率从低到高关机的成本飙升：15% 削电的总代价，相当于一千多个面向外部用户的服务出现「缺口等于平均负载」级别的容量不足。按影响分数一次算完再关机，仍会把不少服务吃过缓冲；每步重算分数的策略在 15% 时总成本仍接近零，主要关 Spot 和缓冲充足的服务。单线程算一次分数 4.5 到 6 秒，重算再加 0.1 到 2 秒。
| 策略 | 15% 削电时的服务影响 | 备注 |
| 关多余空闲机 | 只覆盖前 5% | 受每集群最小空闲缓冲限制 |
| 按利用率从低到高关 | 很高，等价于超过 1000 个高优服务整段平均负载缺口 | 只看服务器利用率 |
| 影响分数只算一次 | 明显低于按利用率关，仍有服务被削穿缓冲 | 分数冻结在开头 |
| 每步重算影响分数 | 接近零 | 重叠服务持续更新边际成本 |
电网侧已经在把「偶尔能削」当成接电条件。对云厂商，这是能不能继续扩容的资格问题。Slasher 的判断很明确：公开云必须在平台层做，不能等租户配合；电池和柴油机盖不住所有场景，软件关停必须带着影响模型，否则 15% 这种不算极端的目标就会误伤现网。
GPU 与大模型专用调制被明确留作后续，那些手段要应用层可见性，平台层没有。这是一套能上生产的控制骨架加影响代理，不是新硬件。
作者写了：核心机制在生产，部分杠杆和场景仍在接入；GPU 与大模型工作负载不在讨论范围。评测里只认真做了「关已分配服务器」，降频和热迁移挤机被认定更适合有提前量的场景，没有同等对照。
影响模型假设负载会在剩余虚拟机上重分配，不包含请求改道路上的瞬时抖动。没有应用指标时，超量配置和「再加压就掉目标」分不清。现场试点只有时间线，没有削电百分比和租户侧数字。15% 近零影响是仿真里的期望缺口。