LLM 推理服务的请求级能耗预算工程 2026：从 Token 功耗到绿色调度闭环

一句话摘要：把每一次大模型请求视为带有质量约束、延迟约束和能源约束的资源交易，才能将绿色推理从口号变成可观测、可优化、可回滚的生产工程。

一、为什么推理能耗已经成为服务质量的一部分

大模型推理系统过去主要围绕吞吐、首 token 延迟和每 token 延迟进行优化。这样的指标体系在模型规模较小、GPU 价格高于电力成本的阶段是合理的，但在长上下文、连续批处理、Agent 多轮调用和高峰自动扩容成为常态之后，能源消耗已经直接影响服务成本、容量规划、机房选址以及碳排放披露。一个看似只增加几百 token 的回答，可能触发更长的 KV cache、更低的批处理效率和更晚的 GPU 释放，从而形成远高于线性估计的边际能耗。

工程上最危险的做法，是把能耗当成离线统计项：月底读取电表，再除以总 token 数。这种平均数无法回答生产问题。某个租户是否因为超长 prompt 占用了不成比例的 HBM？某个路由策略是否把短请求送到了低利用率的大卡？某种 speculative decoding 是否降低了延迟，却因为草稿 token 被大量拒绝而增加了总 FLOPs？这些问题都要求能耗进入请求生命周期，而不是停留在财务报表里。

因此，推理服务的目标函数应从单一的性能最大化，转成带约束的多目标优化。可以把一次请求的结果抽象为四元组：质量 Q、延迟 L、金钱成本 C 和能耗 E。服务并不追求 E 越小越好，而是在 Q 不低于业务门槛、L 不超过 SLO 的前提下最小化 E 与 C。对于离线摘要、批量嵌入和夜间评估，延迟约束可以放宽；对于交互式客服和代码补全，首 token 延迟更重要。不同工作负载必须拥有不同的能源策略。

二、建立请求级能源计量模型

最小可用的能源模型并不要求一开始就给每个算子接独立电表。生产环境通常可以先采集 GPU 功率、显存占用、利用率、批大小、输入 token、输出 token、模型版本、精度和节点位置，再通过时间窗口聚合到请求。对请求 i，可用近似式表示：

[ E_i \approx \int_{t_0}^{t_1} P_{gpu}(t)+P_{cpu}(t)+P_{mem}(t)+P_{net}(t),dt ]

其中 GPU 功率通常是最大项，但 CPU、内存和网络不能永久忽略。尤其在量化模型和小批量请求中，GPU 计算部分下降后，数据搬运、采样、序列化以及容器空转的占比会上升。若只能取得节点级功率，可以把节点功率按请求占用的 GPU 时间、显存比例和批处理贡献进行分摊，并明确这只是估算值。

关键是保存估算的不确定性。推荐同时记录 energy_estimate、measurement_source、confidence 和 attribution_method 四个字段。直接读取硬件遥测的置信度较高，按节点平均分摊的置信度较低；共享批处理中的请求归因更应标注为近似。没有置信度的精确小数，往往比带误差区间的估计更容易误导决策。

计量系统还要避免把排队时间误算成模型计算时间。请求在队列里等待时，可能没有占用目标 GPU，但等待期间服务所在节点仍消耗基础功率。可以分别记录 waiting_energy、prefill_energy、decode_energy、postprocess_energy 和 idle_allocation。这样既能解释长 prompt 的 prefill 代价，也能识别低并发时的固定开销。对批量任务，可额外记录 batch_wait、batch_size 和 padding_ratio，因为 padding token 会制造没有业务价值的计算。

三、Prefill、Decode 与 KV cache 的能耗特征

Prefill 和 decode 是两个完全不同的能源问题。Prefill 对输入序列进行并行计算，通常计算密度高、瞬时功率大，适合大批量和高算力设备；decode 每次只生成少量 token，却要反复读取历史 KV，容易受到显存带宽和访存延迟限制。长输出会让 decode 阶段持续占用 GPU，即使瞬时功率不高，总能量仍然可观。

长上下文会同时放大两类成本。第一类是 prefill 的注意力和投影计算，输入 token 增长会使计算与通信增加；第二类是 KV cache 的容量与读写。PagedAttention 通过分页管理减少碎片和复制，通常能提升并发，但分页本身也有元数据、页表和换入换出成本。工程验证不能只看吞吐提升，还要观察每请求焦耳数、每有效输出 token 能耗以及缓存命中后的增量能耗。

缓存命中并不等于零能耗。命中前缀可以跳过一部分计算，但仍要进行调度、页映射、注意力读取和网络传输。跨节点 prefix cache 还可能因为传输代价抵消计算节省。实践中应记录 cache_hit、reused_tokens、transferred_bytes 和 avoided_flops，并以 avoided_energy 而不是命中率作为决策依据。一个命中率很高但跨机传输严重的方案，可能并不绿色。

针对 decode，可采用 token 级早停、动态批处理、连续 batching 和合理的最大输出限制。早停不能粗暴地截断回答，而应结合置信度、结构完整性和用户意图判断。代码生成可以在测试通过时停止；检索问答可以在证据覆盖满足阈值时停止。把这些业务条件转成可观测的停止原因，才能区分真正节能与质量下降。

四、精度、量化与能源的联合选择

量化是降低能耗的常见手段，但“位宽越低越绿色”并不总成立。INT4 或 FP8 可能减少显存流量、提高并发，却也可能引入反量化、混合精度 fallback 和额外 kernel，最终在小批量场景中得不偿失。模型服务应按工作负载建立精度—质量—能源曲线，而不能直接套用离线困惑度结果。

一个实用的基准矩阵至少包含 FP16、BF16、FP8 和 INT4 四种配置，并在短问答、长上下文、代码生成、结构化输出和批量任务上分别测量。指标包括首 token 延迟、每输出 token 延迟、吞吐、峰值显存、质量得分、拒答率、重试率以及每请求能耗。重试率尤其重要：如果量化导致格式错误，应用层重试两次，初次节能很可能被完全吃掉。

精度路由可以把模型层级与能源预算绑定。高价值请求使用高精度模型，普通分类、改写和摘要使用量化模型；当节点温度或区域能源强度升高时，允许在质量差异经过验证的模型之间切换。路由器必须设置硬门槛：涉及法律、医疗、金融或代码执行的任务不得只按能源信号降级。能源优化是约束内优化，不是把风险转嫁给用户。

五、动态批处理与排队策略

连续 batching 常被视为纯性能技术，但它本质上也是能源调度器。批越大，矩阵计算越接近设备甜点区，固定开销被更多 token 分摊；批过大又会增加等待时间、padding 和尾部延迟。能耗最优点不是吞吐最高点，而是每个有效 token 的能耗最低点。这个点会随着输入长度、输出长度、模型精度和 GPU 型号变化。

可以为调度器定义一个简单的代价：

[ J = \alpha L_{p99}+\beta E/token+\gamma R_{quality}+\delta W_{waste} ]

其中 R_quality 表示质量风险，W_waste 表示 padding、拒绝草稿 token 和无效重试造成的浪费。调度器不必实时求解复杂优化问题，先使用分桶、优先级队列和滑动窗口估计就能取得收益。短请求进入低延迟桶，长上下文进入独立队列，离线任务只在能源和容量都允许时填充空隙。

排队策略还应考虑“等待换批”的能耗收益。若预计几十毫秒后可以形成更有效的 batch，那么短暂等待可能减少每 token 能耗；但对于已经接近 SLO 的请求，继续等待会造成尾部违约。推荐使用 deadline-aware batching：以请求 deadline 作为硬约束，以预测的 batch 增益作为软目标，并在日志中记录因 deadline 放弃合批的原因。

六、能源感知的多模型与多区域路由

当服务部署在多个区域时，路由器可以同时读取价格、碳强度、可再生能源比例、网络 RTT 和容量水位。这里的“绿色区域”不能只依据一个公开排名，因为实时电力结构会变化，且跨区域传输本身也有成本。所有能源信号都必须带时间戳和数据来源；如果数据过期，应退化到性能和可靠性优先，而不是继续使用旧信号。

路由策略可分为三层。第一层是硬约束过滤，淘汰不满足合规、模型可用性和延迟要求的区域。第二层是工作负载匹配，把长上下文送到拥有更大 HBM 的节点，把短请求送到可快速唤醒的共享池。第三层才是能源排序，在候选区域中比较预计每请求能耗和碳强度。这样可以避免为了低碳把请求发送到拥塞节点，导致排队时间和重试增加。

多区域路由必须设计回滚。能源数据异常、跨区链路抖动或某个区域的模型版本落后时，路由器应立即关闭能源优化开关，恢复到经过验证的默认策略。灰度发布时，能源路由只分配一小部分流量，并同时比较质量、SLO、能耗和用户投诉。没有回滚按钮的绿色优化，不属于生产工程。

七、把能源指标接入 OpenTelemetry 与 SRE 体系

能源指标需要进入现有的 trace、metric、log 和事件系统。每个请求 trace 可以挂载模型、版本、路由区域、输入输出 token、prefill/decode 时长、功率估计、缓存状态和质量评估结果。指标层聚合 p50、p95、p99 的 energy_per_request、energy_per_output_token、idle_power_ratio、padding_ratio 和 retry_energy。日志层保存异常归因，例如 GPU 遥测缺失、批处理超时、模型 fallback 或能源信号过期。

告警不要只设置“功率超过某值”。更有意义的是组合告警：吞吐不变但每 token 能耗连续上升，说明 kernel 或批处理退化；能耗下降但重试率上升，说明质量代价正在转移；低碳区域请求比例升高但 p99 超标，说明路由目标与 SLO 冲突。能源预算也可以像错误预算一样运营：月度消耗超过预算时，冻结非必要高精度任务，优先优化浪费最大的工作负载，而不是一刀切降低所有模型质量。

建议建立三类看板。运营看板展示实时功率、容量、排队和 SLO；工程看板展示模型版本、kernel、量化配置和缓存命中；治理看板展示租户分摊、区域碳强度、估算置信度和月度预算。每次优化都必须有前后对照实验，并保留原始遥测，防止聚合逻辑改变后无法复盘。

八、实施路线：从估算到闭环控制

第一阶段只做可见性。统一 token、GPU 时间和节点功率的采集格式，给请求增加 trace id，建立模型与版本维度。此阶段不要急于自动路由，先验证数据完整性和归因误差。第二阶段做离线基准，建立不同 batch、序列长度、精度和 GPU 型号的能耗曲线，并把质量评测接入同一实验平台。

第三阶段做低风险优化。优先处理 padding、重复 prompt、无效重试、过大的 max_tokens 和闲置节点，通常不会改变模型语义。第四阶段做策略灰度，包括能源感知路由、批处理等待、精度切换和离线任务迁移。每一个开关都要有白名单、最大流量、自动回滚阈值和审计记录。

第五阶段才考虑预测控制。根据流量预测、能源价格、碳强度和模型负载预热节点，安排批量任务，调整 warm pool 大小。预测模型本身也会出错，所以控制器需要不确定性边界：预测置信度下降时减少自动动作，回到保守策略。绿色推理的成熟标志不是控制器动作更多，而是系统能在不确定时少做错误动作。

九、常见误区与检查清单

第一，不能用平均能耗掩盖长尾请求。必须按租户、模型、区域、长度桶和请求类型分解。第二，不能把 GPU 利用率当作能源效率。高利用率可能来自大量 padding，也可能来自不必要重试。第三，不能单独优化首 token 延迟而忽略完整回答能耗。第四，不能把公开碳强度数据当作绝对真值，要保存来源、时间戳和置信度。第五，不能在能源优化灰度中跳过质量回归。

上线前至少回答以下问题：是否能区分 prefill 和 decode？是否记录了输入、输出和复用 token？是否知道功率数据缺失时如何降级？是否有每请求能源预算？是否能按租户解释账单？是否有高风险任务的精度下限？是否可以一键关闭能源路由？是否能从 trace 找到一次异常请求的完整资源路径？如果这些问题没有答案，系统还处在统计阶段，不应宣称已经实现绿色推理。

参考文献

1. Patterson et al., Carbon Emissions and Large Neural Network Training, 2021.
2. NVIDIA, DCGM Documentation: GPU Telemetry and Power Monitoring, accessed 2026.
3. Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention, SOSP 2023.
4. Yu et al., Orca: A Distributed Serving System for Transformer-Based Generative Models, OSDI 2022.
5. Dao et al., FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness, NeurIPS 2022.
6. Leviathan et al., Fast Inference from Transformers via Speculative Decoding, ICML 2023.
7. Frantar et al., GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers, 2023.
8. Lin et al., AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration, MLSys 2024.
9. OpenTelemetry, Semantic Conventions for Generative AI Systems, accessed 2026.
10. Google, Carbon Aware Computing for Data Center Workloads, technical report.
11. Microsoft, Sustainable Software Engineering Principles, accessed 2026.
12. Sze et al., Efficient Processing of Deep Neural Networks, Proceedings of the IEEE, 2017.
13. Dao, Flash-Decoding for Long-Context Inference, engineering notes, accessed 2026.
14. MLPerf, Inference Benchmark Rules and Power Measurement Methodology, accessed 2026.
15. Kubernetes SIG Autoscaling, Horizontal Pod Autoscaling Behavior, accessed 2026.
16. NVIDIA, TensorRT-LLM User Guide and Performance Best Practices, accessed 2026.
17. vLLM Project, Production Metrics and Distributed Serving Documentation, accessed 2026.
18. 未公开验证的猜想：在相同质量与延迟约束下，请求级能源预算可能成为比单纯 token 价格更稳定的跨模型路由信号。

十、从能源预算到容量规划的数学化落地

请求级能源预算只有进入容量规划，才会从监控指标变成工程约束。传统容量规划通常以每秒请求数、平均输入长度和峰值并发为输入，再根据模型显存估算 GPU 数量。能源预算要求新增一组维度：单位业务价值的能耗、不同长度桶的边际能耗、节点启动与待机能耗，以及能源价格和区域碳强度的时间变化。容量规划的对象不再只是“多少张卡”，而是“在什么时间、什么区域、以什么精度、为哪一类请求保留多少可用算力”。

可以把一天的流量拆成若干时间片 k，把每类工作负载 j 的请求量记为 D(j,k)，单位请求能耗记为 e(j,m,h)，其中 m 是模型和精度组合，h 是硬件类型。规划器需要满足容量、延迟、质量和合规约束，并最小化总能源成本。实际系统不必直接使用整数规划；先用离散候选方案、历史分位数和滚动预测，就能在不引入过度复杂性的前提下取得稳定收益。重要的是把假设写入配置，而不是藏在脚本里的魔法常数中。

节点生命周期也必须纳入模型。冷启动时，权重加载、编译 kernel 和缓存预热会产生一次性能源消耗；节点长期空闲时，待机功率会形成固定成本；频繁扩缩容则可能让系统不断重复加载模型。于是“少开机器”并不总是最优策略：如果 warm pool 让请求稳定进入高利用率批处理，额外的待机成本可能低于冷启动和排队造成的综合成本。优化目标应比较完整生命周期，而不是只看当前一分钟的功率曲线。

十一、实验设计与生产验收

能源优化最容易犯的错误，是只做一次 A/B 测试，然后把偶然结果写成结论。功率会受温度、时钟频率、后台任务、批次组成和网络状态影响，因此实验必须跨越足够长的时间窗口，并按输入长度、输出长度和请求类型分层。每组至少同时报告均值、p50、p95、p99、置信区间和异常比例。若只展示平均焦耳数，长尾退化可能被完全隐藏。

对照实验应至少包括默认策略、性能优先策略和能源优先策略。质量评测不能只用一个自动指标，还应加入格式正确率、任务完成率、人工抽检和业务转化指标。对于 Agent，还要计算工具调用数量、失败重试次数和上下文重复率。一个回答本身能耗下降，但因为工具调用失败导致全链路重试，不能算作成功优化。

生产验收可以采用四道门。第一道门是数据门：所有请求都能关联到模型、硬件和功率估计，缺失率低于预设阈值。第二道门是质量门：核心任务质量不低于基线，敏感任务不得自动降级。第三道门是可靠性门：SLO、错误率和重试率没有显著恶化。第四道门是回滚门：能源数据异常或策略异常时，可以在分钟级关闭优化，而不需要重新部署模型。四道门全部通过后，才允许扩大流量。

十二、组织与治理：谁为节能结果负责

能源指标跨越平台、模型、应用、财务和基础设施团队。如果没有明确的责任边界，平台团队可能只报告功率，模型团队只报告质量，业务团队只关注响应速度，最后没有任何团队对综合结果负责。建议为每个模型服务建立服务级能源档案，明确计量方法、质量基线、路由范围、预算负责人和例外审批人。

租户分摊也要保持可解释。共享批处理不能把所有固定功率平均摊给每个租户，否则小请求会被高估，大租户会被低估。可以把功率拆成固定基础项、批处理共享项和请求边际项，再按 GPU 时间、有效 token、显存驻留和批次占比组合分摊。分摊规则必须版本化，规则改变时保留旧账本，避免月度账单无法重算。

治理并不意味着让开发流程变慢。相反，能源预算可以成为 CI 和发布流程中的自动检查：新模型若在标准集上的每输出 token 能耗超过基线某个比例，就要求人工确认；新 kernel 若降低能耗但使质量或稳定性越过门槛，则不能上线；新区域若遥测缺失，则只允许进入实验流量。把规则自动化，才能让绿色目标成为工程默认值，而不是依赖个人倡议。

十三、结语：绿色推理是一种更完整的系统优化

推理能耗问题的核心，不是寻找一个“最省电的模型”，而是让系统知道什么请求值得使用多少计算、在什么时间运行、由哪类硬件承载，以及质量和延迟的边界在哪里。Token 数只是结果的一个表面代理，真正的能源效率取决于上下文复用、批处理形状、精度路径、节点生命周期、网络拓扑和应用层重试。

当能源被记录到 trace、纳入 SLO 预算、参与路由、进入容量规划并受到质量门禁约束时，绿色推理就不再是额外的公益项目，而会转化为更少的无效计算、更稳定的资源利用和更可解释的成本结构。短期看，这套方法帮助团队减少电费与容量浪费；长期看，它让大模型服务具备面对能源价格波动、硬件供给变化和碳披露要求的适应能力。真正成熟的系统，不是宣称每次请求都最低能耗，而是在不同约束下都能给出可解释、可验证、可回滚的选择。