LLM推理服务如何利用Prefill与Decode功耗不对称性降低电费成本-北京尧图网络

1. 从电费账单说起为什么LLM推理服务需要看电网脸色第一次看到这个标题的时候我脑子里冒出来的第一个疑问是一个做LLM推理服务优化的论文为什么标题里会出现Demand Response这种电力系统里的术语后来把整篇论文的脉络捋了一遍才明白这背后其实是一个非常现实的成本问题。大规模LLM推理服务的成本结构里电费占比远比大多数人想象的要高。一个中等规模的推理集群GPU满载运行时的功耗动辄几十千瓦起步如果算上散热和配电损耗实际用电量还要再往上浮一截。而在很多地区的电价体系里工业用电并不是一个固定价格——它存在分时电价和需求响应机制。简单说就是电网在高负荷时段电价高在低负荷时段电价低同时电网运营方还会在某些时段发出削峰信号鼓励大用户主动降低用电功率作为回报给予电价补偿或费用减免。这就引出了一个很自然的想法既然电价是波动的那LLM推理服务能不能在电价高的时候少用点电、在电价低的时候多用点电听起来简单但真正做起来会遇到一个核心矛盾——推理请求是有延迟要求的。你不能因为电价高就把用户的请求晾在那里不处理等电价降下来再算。用户等不了SLA也不允许。所以这篇论文要解决的核心问题就是在满足推理延迟约束的前提下如何让LLM服务的功耗跟随电价信号动态调整从而降低整体用电成本。关键词里的Phase Asymmetry相位不对称就是他们找到的突破口——LLM推理的prefill阶段和decode阶段在功耗特性上存在显著的不对称性而这种不对称性恰好可以被用来做功耗调节。这篇文章适合谁看如果你在做LLM推理服务的部署和优化关心推理成本控制或者对GPU集群的功耗管理感兴趣那这篇论文的思路值得仔细拆一拆。如果你只是刚接触LLM推理也没关系我会把里面涉及的基础概念都铺开讲清楚。2. Prefill和Decode到底哪里不对称要理解这篇论文的核心洞察得先把LLM推理的两个阶段掰开来看。很多人知道prefill和decode在计算特性上不同但具体到功耗层面差异到底有多大、差在哪里可能并没有仔细想过。2.1 两个阶段的计算模式差异LLM推理的prefill阶段处理的是用户输入的prompt所有token是并行计算的。这意味着GPU在这一阶段的计算密度极高矩阵乘法规模大Tensor Core利用率高显存带宽主要消耗在加载模型权重和写入KV Cache上。用大白话说prefill阶段GPU是满负荷运转的状态功耗自然就高。Decode阶段就不一样了。每生成一个tokenGPU只需要计算一个位置的注意力矩阵乘法的规模急剧缩小。虽然现代推理框架会做batch合并来提高利用率但decode阶段的算术强度Arithmetic Intensity天然就比prefill低得多。GPU的计算单元大量空闲瓶颈从计算转移到了显存带宽上——每生成一个token都要把整个KV Cache读一遍。这个差异直接反映在功耗上。论文里给出的实测数据显示在相同硬件上prefill阶段的GPU功耗可以比decode阶段高出30%到50%。而且这个差距不是线性的——不是说你把batch size调大就能抹平的因为两个阶段的瓶颈资源根本不同。2.2 功耗不对称带来的调度空间这个功耗差异意味着什么意味着如果你能把一部分计算从高电价时段搬到低电价时段你搬动的重量是不一样的。Prefill阶段的计算是重的搬一个prefill请求省下来的电费可能相当于搬好几个decode请求。但这里有个陷阱prefill和decode不是独立的任务它们有严格的依赖关系。一个请求必须先prefill完才能进入decode。你不能说我现在只做decode不做prefill因为那样新请求永远进不来。反过来你也不能只做prefill不做decode因为那样用户永远拿不到完整的输出。论文的巧妙之处在于他们发现虽然两个阶段有依赖但在调度层面存在灵活空间。具体来说Prefill的时机可以调整——请求到达后你可以选择立即prefill也可以稍微等一等攒一批一起prefill。Decode的速率可以调整——你可以选择每个step生成更多token如果框架支持也可以选择在低电价时段加快decode。两个阶段的资源分配比例可以调整——在电价高的时候把更多GPU资源分配给必须完成的decode把prefill尽量推迟在电价低的时候集中资源做prefill。这种调整之所以可行是因为prefill和decode对延迟的敏感度不同。Prefill的延迟主要影响首token时间TTFT而decode的延迟影响的是每token生成时间TPOT。用户对TTFT的容忍度通常比TPOT高——等首token等个一两秒可以接受但每个token都慢就很难受了。2.3 为什么叫相位不对称Phase Asymmetry这个说法我理解是在强调两个阶段在功耗-延迟权衡曲线上的不对称。对于prefill你稍微增加一点延迟比如把batch攒大一点功耗效率会显著提升对于decode你增加延迟带来的功耗节省就没那么明显因为decode本身就是带宽瓶颈batch大了功耗增加也有限。这种不对称性意味着功耗调节的杠杆主要应该加在prefill阶段。论文的调度策略本质上就是在做这件事在电价高的时候把prefill的优先级压低让decode优先跑在电价低的时候把prefill的优先级拉高集中处理积压的请求。这里有个容易误解的点压低prefill优先级不等于不处理prefill。如果一直不处理请求队列会无限增长最终TTFT会突破SLA。所以论文里一定有一个队列长度或等待时间的约束超过阈值就必须强制prefill。这个约束的设计是整篇论文工程价值最高的部分之一。3. 调度策略拆解怎么在SLA边缘反复横跳理解了不对称性之后接下来的问题就是具体怎么调度论文里提出的方案不是简单的电价高就少做prefill而是一套带反馈的动态调节机制。我把它拆成几个关键组件来讲。3.1 电价信号的获取与预测Demand Response的前提是你能拿到电价信号。在实际部署中电价信号通常有两种来源一种是电网运营方提前发布的分时电价表这个是可以提前知道的另一种是实时需求响应事件这个是突发的可能提前几分钟到几十分钟通知。论文里假设系统能够获取这两类信号。对于分时电价系统可以提前规划对于突发需求响应事件系统需要快速响应。这里有个工程细节电价信号的粒度通常是15分钟或1小时而推理请求的调度粒度是毫秒级的。所以系统需要把粗粒度的电价信号翻译成细粒度的调度决策。论文采用的方式是设置一个目标功耗曲线。根据当前电价和预测的未来电价系统计算出一个目标功耗值然后调度器尽量让实际功耗跟踪这个目标值。电价高的时候目标功耗低电价低的时候目标功耗高。3.2 请求队列的双优先级设计这是整个调度策略的核心。论文把请求队列分成了两个优先级高优先级队列存放已经完成prefill、正在decode的请求。这些请求必须尽快处理因为用户已经在等输出了。低优先级队列存放等待prefill的新请求。这些请求可以适当延迟只要TTFT不超过SLA。调度器在每个决策时刻做两件事第一决定给decode分配多少GPU资源第二决定是否从低优先级队列取请求做prefill。当电价高时调度器倾向于把资源都给decodeprefill能拖就拖当电价低时调度器会主动从低优先级队列取请求做prefill甚至提前prefill一些还没到截止时间的请求。这个设计的精妙之处在于它把功耗调节转化成了队列管理问题。功耗高是因为prefill在跑那我就控制prefill的启动时机。而decode的功耗相对稳定因为它必须持续跑。3.3 延迟约束的硬边界前面说了prefill不能无限推迟。论文里设置了一个最大等待时间参数我把它叫做max_prefill_delay。如果一个请求在低优先级队列里等待的时间超过了这个值调度器就必须强制把它取出来做prefill不管当前电价多高。这个参数的设置很关键。设得太小功耗调节的空间就小省不了多少电费设得太大TTFT会经常触达SLA上限用户体验变差。论文里给出的经验值是max_prefill_delay应该设置为TTFT SLA的60%到70%。比如你的TTFT SLA是2秒那最大等待时间就设在1.2到1.4秒左右。这样留出足够的余量给实际的prefill计算。除了等待时间还有一个约束是队列长度。如果低优先级队列积压太多即使每个请求的等待时间还没到上限也应该开始prefill了否则后面来的请求会等更久。论文里用了一个简单的阈值策略当队列长度超过某个值时提高prefill的优先级。3.4 功耗跟踪的反馈控制目标功耗曲线和实际功耗之间会有偏差因为请求的到达是随机的每个请求的计算量也不一样。论文用了一个比例控制器来调节。简单说就是如果实际功耗高于目标就进一步压低prefill的优先级如果实际功耗低于目标就适当提高prefill的优先级。这个反馈控制器的参数需要调。比例系数太大系统会震荡——一会儿疯狂prefill一会儿完全不做prefill比例系数太小响应太慢电价高峰都过去了功耗还没降下来。论文里建议用一个较小的比例系数配合一个低通滤波器来平滑功耗测量值。实操中有一个坑GPU功耗的测量本身有噪声而且不同型号的GPU功耗响应速度不同。如果你直接用瞬时功耗做反馈控制器很容易被噪声带偏。建议用滑动窗口平均后的功耗值窗口大小设置在1到5秒之间。4. 实测数据背后的工程真相论文里给了一组实验结果我挑几个关键数据来说顺便聊聊这些数据在实际部署中意味着什么。4.1 省电效果与SLA的权衡曲线论文的核心实验结果显示在典型的电价曲线下采用Phase Asymmetry调度策略可以降低**15%到25%**的用电成本同时TTFT的P99值增加不超过20%。这个数字看起来不算特别惊艳但考虑到LLM推理服务的电费基数很大15%到25%的成本节省已经相当可观了。更重要的是这个节省不是靠牺牲用户体验换来的。P99 TTFT增加20%意味着如果你的SLA是2秒那P99从1.5秒变成1.8秒还在SLA范围内。当然这是在论文设定的负载条件下。如果你的负载本身就接近系统容量上限那调节空间会小很多。4.2 不同负载下的调节空间差异论文里做了一个负载扫描实验从低负载到高负载分别测试。结果发现负载水平GPU利用率成本节省TTFT P99增幅低负载30%25%5%中负载60%18%12%高负载85%8%20%接近饱和95%3%35%这个表格很说明问题。负载越低功耗调节的空间越大。因为低负载时系统有大量空闲资源你可以从容地把prefill挪来挪去。高负载时系统本身就在满负荷跑你能做的只是拆东墙补西墙调节空间自然就小。这给实际部署的启示是Phase Asymmetry调度最适合中等负载的场景。如果你的集群长期跑在90%以上的利用率那这套方案帮不了你太多你更需要的是扩容或者做请求优先级管理。如果你的集群利用率只有30%那这套方案能帮你省不少电费。4.3 与基线方案的对比论文对比了几个基线方案无调节所有请求按FCFS处理不做任何功耗管理。静态阈值电价高于某个阈值时暂停prefill低于阈值时恢复。Phase Asymmetry论文提出的动态调度方案。结果显示静态阈值方案在高电价时段确实能省电但电价降下来之后会有大量积压请求集中prefill导致功耗尖峰而且TTFT的波动很大。Phase Asymmetry方案通过动态调节把积压请求更平滑地分散到低电价时段避免了功耗尖峰TTFT也更稳定。这个对比说明了一个道理功耗管理不是简单的开关控制而是需要精细的流量整形。就像交通管理一样你不能简单地封路而是要通过信号灯配时来平滑车流。5. 落地这套方案需要想清楚的几件事论文读完了思路也理解了但真要把它落地到自己的推理服务里还有几个工程问题需要想清楚。5.1 你的推理框架支持细粒度调度吗Phase Asymmetry调度的前提是你能独立控制prefill和decode的调度。但很多现成的推理框架比如一些早期的推理引擎是把prefill和decode混在一起调度的你没法单独控制prefill的启动时机。如果你用的是vLLM这类支持continuous batching的框架那恭喜你它天然就把prefill和decode分开了你可以在调度层做文章。如果你用的是更传统的框架可能需要先做一轮改造把prefill和decode的调度逻辑拆开。具体来说你需要能在调度器里做这几件事维护两个独立的请求队列等待prefill的和正在decode的。在每个调度step能独立决定是否从等待队列取请求做prefill。能控制prefill的batch size避免一次prefill太多请求导致功耗尖峰。5.2 电价信号的接入成本Demand Response的前提是你能拿到电价信号。如果你是在自建机房跑推理服务那电价信号可能来自你的配电系统或者电网的公开接口。如果你用的是云服务那云厂商通常有预留实例和按需实例的价格差异但实时的电价信号可能拿不到。论文里假设系统能获取实时电价这在学术环境下是合理的但在实际部署中可能需要额外的对接工作。一个折中方案是用历史电价数据训练一个简单的预测模型提前预测未来几小时的电价曲线然后基于预测做调度。预测误差可以通过反馈控制来补偿。5.3 多租户场景下的公平性如果你的推理服务是多租户的那功耗调节会带来公平性问题。电价高的时候低优先级队列里的请求会被延迟如果这些请求恰好来自某个特定租户那这个租户的体验就会变差。论文里没有深入讨论这个问题但在实际部署中必须考虑。一个可能的方案是在租户层面做轮转确保每个租户的请求被延迟的概率是均等的。或者给不同租户设置不同的优先级高优先级租户的请求不参与功耗调节。5.4 硬件异构性的影响论文的实验是在同构GPU集群上做的。如果你的集群里有不同型号的GPU那功耗特性会不一样。比如A型号的GPU在prefill和decode之间的功耗差异是40%B型号只有25%那调度策略需要针对不同型号做适配。一个实用的做法是在系统启动时对每种GPU型号做一次功耗标定测量prefill和decode阶段的典型功耗值然后把这些参数喂给调度器。这样调度器就能根据当前可用的GPU型号来调整调节策略。6. 从这篇论文延伸出去的几个想法读完这篇论文我脑子里还冒出了几个相关的方向不一定成熟但值得想一想。第一个想法是能不能把功耗调节和请求的优先级结合起来比如对于延迟不敏感的请求比如离线批处理任务可以完全跟着电价走电价低的时候集中跑电价高的时候完全暂停。对于延迟敏感的在线请求则用Phase Asymmetry的方式做精细调节。这样可以把两类请求的调度策略分开各自优化。第二个想法是功耗调节的粒度能不能更细论文是在GPU级别做调节的但现代GPU支持更细粒度的功耗管理比如可以限制GPU的功率上限power cap。如果在电价高的时候不仅减少prefill还适当降低GPU的功率上限可能会进一步省电。当然降低功率上限会影响计算速度需要权衡。第三个想法是这套思路能不能用到其他类型的推理服务上比如图像生成、语音识别这些服务也有类似的计算阶段划分也可能存在功耗不对称性。如果能把Phase Asymmetry的思路推广到更多类型的推理服务那价值就更大了。最后分享一个我在实际调优中的小经验做功耗调节的时候不要只盯着GPU功耗。CPU、内存、网络设备的功耗加起来也不是小数目。特别是在高负载场景下CPU的功耗可能占到总功耗的20%以上。如果你的调度策略只优化GPU可能会忽略掉其他组件的功耗变化。建议在功耗测量时把整个节点的功耗都纳入进来这样优化目标更准确。另外功耗调节的效果和你的请求模式强相关。如果你的请求到达非常均匀那调节空间主要来自prefill时机的微调如果你的请求有明显的波峰波谷那调节空间会大很多因为你可以把波峰时段的prefill挪到波谷时段。所以在部署之前先分析一下你的请求到达模式评估一下理论上的调节上限再决定要不要投入精力做这套调度。

LLM推理服务如何利用Prefill与Decode功耗不对称性降低电费成本

相关推荐

零幻觉AI客服技术解析：RAG检索增强与置信度阈值实践

论文解读与源码复现｜NegBench：视觉语言模型其实不懂“否定“（CVPR 2025）

手写持久化B树KV存储引擎：从原理到工程实现

更多资讯

软考高项案例分析：成本管理与挣值计算公式详解

AI编程助手Context Mode详解：上下文视野如何决定代码质量

从「一人公司」到「AI 员工取代同事」：Paperclip 正在改写中国创客叙事

Manus手势SDK如何被AI大厂重构为手部语义管道

MiniCPM-V 4.7-35B-A3B-FP8的10个实战场景：OCR识别、PDF解析与视觉定位完全指南

学生党省钱用AI全攻略：从免费工具到本地部署的按需付费方案

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？