2026-09-02
UIUC 与 Azure 的 DynamoLLM 按请求长短分池，并动态改实例数、并行度和 GPU 频率；一周轨迹上相对固定高峰配置省 53% 电、38% 碳、61% 成本，延迟目标仍满足。
LLM 推理集群为了峰值延迟，通常按高峰配满 GPU，并且全程最高频率、最大张量并行。电费和空转都被峰值绑死。请求本身却很杂：预填充吃算力、解码吃显存，短问短答和长上下文不是同一种机器。Azure 两条一周轨迹里，Conversation 峰值是均值的 1.7 倍、低谷的 3.3 倍；Coding 分别是 2.8 倍和 34.6 倍。同一套最高性能配置，在夜里和周末是在烧空转。
传统机房节能管的是 CPU 作业。推理这边改一次配置很贵：拉起一台 8×H100 实例要 6 到 8 分钟；用 nvidia-smi 改频率平均 50 到 80 毫秒，而一次解码迭代只有 20 到 30 毫秒，每步都改频率会把吞吐打掉一截。需要能自动选配置、还得把切换开销藏起来的系统。
DynamoLLM 是 UIUC 与 Azure Research 做的推理集群能量管理框架，架在 vLLM 上，分层控制三件事：实例数量、张量并行（TP2/TP4/TP8）、GPU 频率（800 到 1980 MHz，200 MHz 一档）。HPCA 2025 正式发表。
上线前先给模型做能量-性能画像：不同长度、负载、并行、频率下的能耗和 TTFT/TBT。同一模型的画像可跨服务复用。请求按输入/输出长度分成 9 档，阈值来自 Conversation 轨迹的 33/66/100 分位。延迟目标定为空载单请求的 5 倍：短请求 TTFT 250 毫秒，中 400 毫秒，长 2000 毫秒，TBT 一律 100 毫秒。输出长度用 BERT 代理模型预测，输入长度是已知的。
控制分三层，时间尺度不同。集群管理器大约每 30 分钟按负载预测给各池分配节点，默认按最高性能（TP8 加 1980 MHz）算容量下限，并把碎片负载并到「更长请求」的池，避免每个池都为峰值多留一台。池管理器大约每 5 分钟在给定 GPU 数下选并行切分，切的时候把重分片开销表算进收益。实例管理器大约每 5 秒在仍满足延迟目标的频率里挑最省电的一档。
切换开销被单独打磨。新虚拟机用集群内权重缓存、引擎快照，以及在调度周期开始前预拉起。重分片用二分图最大权匹配尽量让权重留在原 GPU，剩下的走 NVLink；论文里 TP4 升 TP8 大约 50 毫秒（搬八分之一权重），降到 TP2 大约 100 毫秒。新旧实例在显存允许时重叠服务，避免同步那几百毫秒到几秒变成停机。频率调整把 nvidia-smi 常驻内存，控制器走特权模式，少一次用户态往返。
预测错了有退路。估短了导致排队，先重排快超时的请求，再拉到最高频率，再把没开跑的请求改派到池内其他实例；还不够就把等太久的请求掐掉，让前端换池或稍后重试。估长了只是跑在更贵的池里，延迟一般不受伤。
硬件是 8×H100 服务器，主结果用 Llama2-70B。对照 SinglePool：所有请求进一个池，TP8 最高频率，按峰值配 12 台。消融拆成只分池、只扩缩实例、只改并行、只改频率。
一小时公开 Conversation 轨迹上，相对 SinglePool：
| 系统 | 能耗变化 | 说明 |
| MultiPool | +20% | 分池但始终最高性能，资源更多 |
| ScaleInst | −4.1% | 只扩缩实例，拉起太慢拖尾延迟 |
| ScaleShard | −7% | 只改并行 |
| ScaleFreq | −19% | 只改频率 |
| DynamoLLM | −35% | 三档一起动 |
P99 TTFT / TBT 比 SinglePool 低 5.3% / 11.1%，P50 反而高 11.4% / 7.6%，因为有延迟余量时故意跑更省电的档。集群功率 P50 / P99 低 43% / 9%。
一天生产轨迹、11 台 H100，全天能耗低 42%。一周离散事件仿真里，Conversation 低 47%，Coding 低 56%。摘要里的 53% 是服务级总述，和这两条一周数字的量级一致，高于那一小时集群实验的 35%。
碳排放用 CAISO 一周碳强度映射：SinglePool 5 吨/周，DynamoLLM 3.1 吨/周，少 38%。GPU 服务器一周均值从 40 降到 24.6，按当时 GPU 虚拟机报价省 1362.7 美元/小时；电费最多少 56%，折合大约 4.4 美元/小时。客户总成本少 61%，大头是 GPU 租时。
输出长度预测错 40% 时，能耗高 13%，TTFT 高 7.3%。低/中/高负载下相对 SinglePool 分别省 51%、40%、23.4%。池子定 9 个；加到 12 或 16 会碎片化，减到 2 或 4 又调不细。
推理已经按峰值买 GPU 了，空转和最高频率是默认可浪费的两项。DynamoLLM 把分池、并行、调频合成一件平台能自动做的事，而且把分钟级扩容和毫秒级重分片的开销算进要不要切换。对正在跑 vLLM 集群的人，可搬走的部分是：按长度分池、低负载降频、切并行前先算 NVLink 搬权重划不划算。
61% 成本不要直接抄到自己的账单上。论文里电费节省相对 GPU 租金几乎可以忽略，省钱主要来自少租卡。碳也只计运行时，不含制造。
正文没有独立的局限节。评测主结果几乎都是 Llama2-70B，其他模型只说趋势相同。并行只做了单机张量并行，流水线并行被一笔带过。输出长度必须预测，紧急路径的最后一招是丢请求。频率控制要特权模式和常驻 nvidia-smi，云上租户集群不一定给。
53%、38%、61% 是摘要口径。能在真实 GPU 集群上直接读到的，是一小时降 35% 和一天降 42%。一周数字来自仿真。碳强度只展示了 CAISO。画像阶段要扫并行和频率网格，换模型或把延迟目标从 5 倍改成 10 倍、20 倍，都得重测。