LLM 推理的碳感知调度工程 2026:从电网碳强度到生产级闭环

一、问题的提出:推理服务的"碳足迹"正在成为新的 SLO

在过去两年,LLM 推理服务的 SLO 体系几乎是围绕延迟、吞吐、成本三者构建的。P99 延迟、首 token 时延(TTFT)、每千 token 美元成本、GPU 利用率、KV cache 命中率 —— 这些指标在过去 24 个月里被精雕细琢,形成了非常成熟的工程范式。但 2026 年开始,一个新的维度被加入 SLO 讨论:碳足迹(carbon footprint)。一个推理集群一年的碳排放,正在从"ESG 报告附录里的数字"变成"需要实时监控、按工作负载归因、纳入调度决策的核心工程指标"。

推动这一变化的不是口号,而是三股具体的工业力量。第一,欧盟 CSRD(企业可持续发展报告指令)在 2024-2026 年逐步落地,要求大型企业披露范围 1/2/3(scope 1/2/3)碳排放,而范围 3 中"购买的云计算服务"是 AI 公司不可避免的排放来源 —— 这意味着 Anthropic、OpenAI、欧洲的 Mistral 等公司的客户开始要求供应商提供推理服务的逐 token 碳报告。第二,Google Cloud 早在 2021 年就把其数据中心做到 24/7 碳感知,到 2025 年所有 Google Cloud 区域都暴露了 carbon-aware API;AWS 在 2024 年底推出 Customer Carbon Footprint Tool 的区域级碳报告;Azure 在 2025 年宣布所有新建区域默认碳感知。公有云的 API 层已经把这件事"民主化"了 —— 任何 AI 工程师都可以调一行 API 拿到当前区域电网的实时碳强度。第三,真正让 AI infra 团队开始投入工程资源的是大客户合同:在 2026 年的若干大型 B2B AI 合同里,"承诺的 gCO₂/千 token"已经成为采购方的硬性 SLA,违约有合同罚则。这意味着工程师必须把"碳"当成一种可调度、可配额、可观测的资源,而不是后置的环保姿态。

本文要回答的核心工程问题是:在保持 P99 延迟 SLO 和成本 SLO 不退化的前提下,如何把碳感知能力原生集成到 LLM 推理服务的调度层,使之成为一个可执行、可监控、可审计的闭环?我们将从电网碳强度数据源开始,经过推理服务的能量模型,再到调度器的时空可调度性决策,最后落到碳预算配额与生产闭环,试图给出一个在 2026 年的工程实践中可落地的范式。

二、形式化:碳感知调度的四元组

我们把碳感知调度问题形式化为一个四元组 (CI, E, L, B),其中:

• CI: 区域电网碳强度(region grid carbon intensity),单位 gCO₂/kWh。一个推理工作负载在不同区域运行时,会"乘上"所在电网的 CI。挪威的水电 CI 约 30 gCO₂/kWh,法国的核电约 50,中国的西部风光基地在白天可低于 100,而波兰的煤电、华北的燃气调峰时段可达 600-800。这一项的物理含义是"每一千瓦时电网电力对应的碳排放"。
• E: 推理工作负载的能量消耗(energy per workload),单位 kWh/request 或 J/token。一个标准的 70B 模型在 H100 上做一次 1024 token 输入、512 token 输出的推理,大致消耗 0.5-1.5 kWh,这取决于是否走 speculative decoding、是否使用 FlashAttention、是否启用了 PD 分离等。
• L: 延迟预算(latency budget),单位 ms。请求级别的 P99 上限,例如聊天场景 800ms,代码补全场景 200ms。
• B: 碳预算(carbon budget),单位 gCO₂/day 或 gCO₂/月。是配额层,例如某产品线每天被分配 500 kgCO₂ 配额,超出则触发降级或排队。

碳感知调度的目标函数可以写为:

minimize  Σ_i  CI(region_i) × E(workload_i)
subject to  P99_latency(workload_i) ≤ L_i
            Σ_i  CI(region_i) × E(workload_i) ≤ B
            total_throughput ≥ demand

这是一个带延迟约束和碳配额约束的多目标优化问题。在工程实践中,它通常被分解为两个子问题:路由决策(把请求路由到哪个区域)和时间决策(把工作负载调度到哪个时间窗)。前者是空间维度,后者是时间维度,两者共同构成"时空可调度性"(spatio-temporal schedulability)。

关键观察:大多数 LLM 推理请求并不是严格实时的。聊天补全有几百毫秒的容忍度,异步摘要、批量嵌入、训练数据合成、长文档 RAG 预处理这些场景可以容忍数秒甚至数分钟。这种"延迟容忍度"是碳感知调度可以存在的前提 —— 如果所有请求都是 50ms 的硬实时,碳感知调度无从谈起。

三、电网碳强度数据源与时空分布

碳感知调度的"空间维度"完全建立在电网碳强度的实时可观测性之上。在 2026 年的工程实践中,有四个主要数据源可以使用。

第一,WattTime(wattime.org)。这是非营利组织 WattTime 维护的 API,提供全球 200+ 区域的 5 分钟级别电网碳强度数据,数据来源是电网 EMS(能源管理系统)和卫星反演。API 返回值是 marginal carbon intensity(MOI),即"边际发电"的碳强度,而不是平均强度 —— 这对调度决策至关重要,因为我们要问的是"如果我现在多消耗 1 kWh,会触发哪种发电机上线",而不是"现在电网平均每 kWh 多清洁"。

第二,Electricity Maps(electricitymaps.com)。这是另一家商业 API,提供 hourly 级别的区域平均碳强度,以及"清洁度分数"(0-100),数据来源更全面(包含欧洲 ENTSO-E、美国 EIA、中国国家能源局公开数据),但延迟稍高(15 分钟到 1 小时)。Electricity Maps 的优势是覆盖中国区域,这是 WattTime 不擅长的。

第三,公有云原生 API。Google Cloud 的 carbon-footprint API、AWS 的 get-carbon-estimates API、Azure 的碳感知 SDK,都直接绑定到该云厂商的自有区域,延迟低、权威,但只能用于自家区域。

第四,国别级公开数据。欧洲 ENTSO-E 提供 24-48 小时预测,中国电力企业联合会发布日报。这些数据滞后 1 天,但适合做"碳预算月底结算"这类离线归因。

时空分布上,有三个工程上必须理解的特征:(a) 季节性强相关 —— 北欧水电在春汛期 CI < 20,冬季枯水期 CI 可达 200+;中国风光基地在春秋季白天 CI 可低于 50,夜间调峰时段升到 400+。(b) 昼夜双峰 —— 几乎所有电网都有"白天峰、夜晚谷"的碳强度模式,但不同电网峰谷差极大:德国风电主导,夜间低谷时 CI 可低于 50,而日间用气调峰时升到 300+;美国 PJM 电网在傍晚尖峰时段甚至会临时拉高到 600+。(c) 跨区域异质性 —— 同样跑一个 70B 模型,在挪威跑和在印度跑,每千 token 的碳排放可能差 10 倍以上。

工程上,我们把这四个数据源整合成"碳强度时序流",格式为 (region, timestamp, ci_g_per_kwh, source, confidence),每 5 分钟更新一次,落到时序数据库(TimescaleDB 或 InfluxDB),供调度器查询。

四、LLM 推理的能量模型

碳感知调度的"分子"是 E(workload),即每个推理工作负载消耗多少能量。这要求我们建立 token-level 的能量模型,把"硬件功耗 × 推理时延"换算成"每 token 焦耳"。

一个朴素的 token-level 能耗公式是:

E_per_token(w, h) = P_gpu(h) × T_per_token(w, h) / 1e6   # 单位 J/token
P_gpu(h) = P_idle(h) + P_active(h) × utilization(w, h)

其中 P_gpu(h) 是 GPU 在负载状态 h(是否在做 GEMM、是否在做 attention、是否空闲)下的平均功耗。H100 SXM 的 P_idle 约 70-100W,P_active 在 700W 满载;消费级 4090 的 P_idle 30W,P_active 450W。A100 80GB SXM4 的 P_idle 约 60W,P_active 400W。

但这个公式忽略了三个关键工程细节:

(1) Prefill vs Decode 的能耗差异巨大。在标准 Transformer 解码中,Prefill 阶段(处理输入 prompt)是大规模 GEMM,GPU 利用率 90%+,能耗主要在 GEMM;Decode 阶段(逐 token 生成)是 memory-bound,GPU 利用率往往只有 30-50%,能耗大量浪费在 memory bandwidth 等待。这意味着 Prefill 阶段每 token 的能耗远低于 Decode 阶段,比例大致是 1:5 到 1:10。如果不区分 Prefill/Decode,简单做平均,会让能耗模型严重失真。

(2) Speculative decoding 的能耗节省。投机解码(Speculative Decoding)用一个 draft model 生成候选 token,再用 target model 批量验证,平均接受率 60-80%。这意味着同样的输出 token 数,实际 GPU 调用次数降到 30-50%。能耗可节省 30-50%。但代价是引入了 draft model 的额外显存和复杂度。

(3) KV cache 命中与能效。如果一个请求的 prefix 命中了 cache(系统提示、few-shot 例子、上一轮对话),Prefill 阶段被跳过或大幅缩短,能耗可降低 40-70%。这与 id=495"Context Cache 工程"是同一现象的能源维度表现。

工程实践上,我们建立一个 energy-model 服务:

def estimate_joules_per_token(model_id, gpu_type, input_tokens, output_tokens,
                              cache_hit_rate, use_speculative):
    prefill_j = prefill_energy(input_tokens, gpu_type)
    decode_j = decode_energy(output_tokens, gpu_type,
                              acceleration=2.5 if use_speculative else 1.0)
    cache_saving = 1 - cache_hit_rate * 0.5
    total = (prefill_j + decode_j) * cache_saving
    return total  # 单位 J/token

这个模型不需要 100% 精确 —— 在调度决策中,精度 ±20% 即可,因为碳强度本身的波动也在 ±30%。重要的是:(a) 相对量级正确(Prefill < Decode),(b) 能区分 cache 命中与不命中,(c) 能反映 speculative decoding 的节省。

五、碳感知调度器与时空可调度性

有了 CI 和 E,我们就可以构建调度器。碳感知调度器的核心思想是:把"碳"作为一种"价格"信号,把"延迟容忍度"作为一种"弹性"信号,在时间-空间二维网格上做联合优化。

调度的输入是请求流,每个请求带:

• (region_preference, latency_budget, carbon_budget_per_request, workload_meta)

调度的输出是:

• (target_region, scheduled_time, routing_path)

调度器的核心决策循环大致如下:

class CarbonAwareScheduler:
    def __init__(self, regions, ci_stream, energy_model, latency_predictor):
        self.regions = regions
        self.ci = ci_stream  # (region, ts, ci) 时序流
        self.energy = energy_model
        self.lat = latency_predictor

    def decide(self, req):
        candidates = []
        for region in self.regions:
            # 当前区域碳强度
            ci_now = self.ci.current(region)
            # 该 region 的能耗估计
            e = self.energy.estimate(req.workload, region)
            # 该 region 的延迟估计(网络 + 排队 + GPU 时间)
            l = self.lat.predict(req.workload, region)
            # 如果延迟不满足 SLO, 跳过
            if l > req.latency_budget:
                continue
            # 碳成本 = CI × E
            carbon_cost = ci_now * e
            candidates.append((region, carbon_cost, l))

        # 选碳成本最低的 region
        candidates.sort(key=lambda x: x[1])
        return candidates[0]

    def decide_delayed(self, req, max_delay_seconds):
        """延迟容忍型请求: 在 max_delay 内找最低碳强度的窗口"""
        best_window = None
        best_ci = float('inf')
        for t_offset in range(0, max_delay_seconds, 300):  # 5 分钟粒度
            ci_forecast = self.ci.forecast(req.region_preference, t_offset)
            if ci_forecast < best_ci:
                best_ci = ci_forecast
                best_window = t_offset
        return best_window

关键设计决策:请求分桶。在线推理请求按延迟预算分桶:

• Real-time 桶(L < 200ms): 不做碳感知,走最近区域
• Interactive 桶(200ms ≤ L ≤ 2s): 做区域碳感知路由,选低 CI 区域但不延迟
• Batch 桶(L ≥ 2s 或显式 batched): 做时空碳感知,可延迟到低 CI 窗口

Batch 桶的延迟容忍度可以做得很激进:如果是离线摘要、批量嵌入、训练数据合成,延迟 10 分钟甚至 1 小时都可接受,这给碳感知调度打开了巨大的优化空间 —— 我们可以把这类工作负载全部调度到夜间风电大发时段、或调度到挪威水电季节。

工程上,调度器有两种实现路径:(a) 集中式调度器(类似 Borg / Kubernetes scheduler),所有请求经过中央决策器,适合自建集群;(b) 边缘代理 + 策略同步(类似 Envoy + RDS),每个推理节点本地有策略副本,中央定期推送 CI 预测,适合多云部署。我们更推荐后者 —— 因为推理服务的网络延迟本身就敏感,集中式调度器的决策延迟会成为瓶颈。

六、碳预算配额与生产级闭环

调度器解决"如何路由",配额系统解决"如何分配"。我们把碳预算设计成一个三级分配体系:

L1 - 组织级配额(Org-level): 每个产品线(对话、API、批量嵌入)按月分配总碳预算,例如对话产品线 50 吨 CO₂/月。这个配额来自公司 ESG 目标和合同 SLA。

L2 - 工作负载级配额(Workload-level): 每个工作负载类型(70B 对话、13B 补全、嵌入)在 L1 配额下进一步分配,例如 70B 对话每天 1.5 吨 CO₂。

L3 - 请求级配额(Per-request): 单个请求被分配的碳上限,例如 0.5 gCO₂/请求。这是调度器的硬约束 —— 如果一个请求在最低 CI 区域路由后仍超过 L3,该请求会被降级(换小模型)或拒绝。

生产闭环的关键是实时可观测性。我们建议暴露四个核心指标:

1. CI-weighted throughput(碳加权吞吐): Σ_throughput / Σ_carbon,即"每 kgCO₂ 服务了多少请求"。这是衡量碳效率的核心 KPI。
2. 碳预算消耗率(burn rate): 当前碳消耗速度 / 配额消耗速度。当 burn rate > 1.2 时触发告警。
3. 碳感知路由命中率: 多少比例的请求成功路由到低于平均 CI 的区域。
4. 延迟退化幅度: 碳感知路由相比最短路径路由的 P99 退化值。目标是 < 5%。

这四个指标进入 Grafana dashboard,接入 Prometheus,触发 Alertmanager 告警,并通过 OpenTelemetry 关联到 trace —— 每条 trace 都打上 region_id、ci_at_request_time、joules_estimated、carbon_grams 四个属性,使任何一条请求都能被回溯"它产生了多少碳"。

闭环的最后一步是碳报告与审计。每月自动生成 PDF/HTML 报告,内容包含:(a) 各产品线实际碳排放对比配额,(b) 碳效率(每 kgCO₂ 服务了多少请求)环比变化,(c) 区域间碳排放分布(用于评估跨区域负载均衡的合理性),(d) "可避免碳"估算 —— 如果走最短路径路由而非碳感知路由,会多排放多少。这个报告直接喂给 ESG 报告和客户合同 SLA。

七、对工程实践的推论

基于上述形式化和生产闭环,我们对正在搭建或运维 LLM 推理服务的工程团队提出以下五条可执行推论:

推论 1:不要在 P99 路径上做碳感知。任何 P99 < 500ms 的请求路径(首 token TTFT、代码补全、实时翻译)都应跳过碳感知逻辑,走最近区域。原因是这些请求的网络往返已经占用了 30-50% 的延迟预算,任何跨区域路由都会击穿 SLO。把碳感知能力集中在 Interactive(200ms-2s)和 Batch(> 2s)两类请求上。

推论 2:先做"碳感知观测",再谈"碳感知调度"。在 2026 年的工程实践中,我们强烈建议先实现"每条请求 trace 都带碳标签",并跑 4-6 周观测期,收集 (region, ci, latency, carbon_grams) 的真实分布数据。在没有数据的情况下做调度决策,几乎一定是优化错了的目标函数。观测期之后再上调度器,效果会显著更稳。

推论 3:用 batch 工作负载做"碳吸收"主力。如果你的推理集群中有批量嵌入、异步摘要、训练数据合成、离线评估这类工作负载,把它们的 carbon-aware 优先级拉到最高 —— 这些负载的延迟容忍度高(分钟级到小时级),碳优化空间最大(可以完全对齐电网低谷),且对用户体验零影响。一个有 30% batch 负载的推理集群,做碳感知调度后总碳排放可降低 15-25%,延迟几乎不退化。

推论 4:Speculative decoding 是碳效率的双倍器。投机解码不仅提升吞吐(2-3 倍),还降低每 token 能耗(30-50%)。两者叠加,碳效率(token/gCO₂)可提升 3-5 倍。如果模型架构允许(draft model 与 target model 兼容),强烈建议在生产推理中默认开启 speculative decoding,把它作为"碳效率"的核心工程杠杆,而不仅仅是"性能"优化。

推论 5:把碳预算纳入容量规划。在做下个季度容量规划时,把碳预算作为输入,与 GPU 数量、网络带宽、延迟 SLO 一起做多目标优化。一个常见的反模式是只按延迟/吞吐需求买 GPU,结果采购了高碳强度区域的 GPU,导致单位算力的碳成本高 2-3 倍。正确的做法是:碳预算约束下,优先采购水电/核电区域的算力(如北欧、加拿大魁北克、法国),并把这些区域分配给碳敏感的批量负载。

推论 6:把碳标签作为推理 API 的一等公民。当客户在选择推理供应商时,碳标签会成为差异化竞争点 —— 类似于当年的"绿色数据中心"。具体做法是:在 OpenAI 兼容 API 的 usage 字段中,除 prompt_tokens、completion_tokens 外,增加 carbon_grams 字段,每次响应都返回该次请求的碳排放。这要求每次请求都完成 joules_estimated × ci_at_request_time 的实时计算并写入响应。审计层面,提供月度 carbon_audit_<customer>.json,记录每个 API key 的累计碳排放,可被客户的 ESG 系统直接消费。

推论 7:避免"碳泄漏"陷阱。碳泄漏(carbon leakage)指本地优化碳排放时,把工作负载转移到另一个高碳区域,导致全球总排放不降反升。一个常见的反模式是:推理服务把欧洲的请求全部路由到挪威水电区域,导致挪威算力涨价,欧洲其他厂商被迫去波兰买高碳算力 —— 总碳排放反而上升。工程上的防御措施是:(a) 公开自己的碳感知路由策略,允许同行审计;(b) 在调度器中显式建模"如果我占用了低碳区域算力,其他厂商被迫使用的算力的预期 CI",并把这个社会成本计入自身碳足迹;(c) 长期看,推动行业级碳感知调度联盟,共同分配低碳区域算力,避免零和博弈。

八、讨论:与现有 SLO 体系的张力

碳感知调度不是免费的午餐,它与现有的 SLO 体系存在三类张力。

张力一:延迟 vs 碳。碳感知路由往往比最短路径路由多一跳网络(几十毫秒到上百毫秒),Interactive 桶的延迟退化通常在 1-5%,但极端情况下(如跨大洲路由)可达 10-20%。这要求延迟 SLO 留有 5% buffer 才能容纳碳路由。如果延迟 SLO 已经压到极限,碳路由必须给 P99 让路。

张力二:成本 vs 碳。低 CI 区域往往电价也低(挪威水电电价 < 0.05 €/kWh,德国煤电 > 0.15 €/kWh),所以碳-成本通常是协同的。但也有例外:某些低碳区域算力稀缺(冰岛),算力价格高;某些高碳区域算力便宜(印度)。这时需要权衡 —— 一个产品可以接受"低碳但高价"还是"高碳但低价"。这本质上是商业决策,不是工程决策,但工程上要支持两套调度策略。

张力三:负载均衡 vs 碳。跨区域负载均衡是延迟优化的传统手段,但它隐含"把请求分散到多个区域"。碳感知调度可能逆向集中负载到低 CI 区域,导致某些区域过载、另一些区域空闲。需要在调度器中显式建模"区域容量利用率"作为约束,避免碳优化压垮低 CI 区域的算力。

未解问题。当前业内对"碳足迹按 token 归因到最终用户"的方法论没有共识:是按生成 token 计费、还是按输入+输出 token 计费、还是按 GPU 时长按区域 CI 加权计费?碳信用(carbon credit)的抵消(off-set)是否计入工程碳足迹?这些问题在 2026 年仍在演进,我们的建议是:在工程上先把"暴露准确的每请求碳标签"做好,商业策略可以基于这个标签动态调整。

九、给 AI infra 团队的落地清单

如果你正在搭建一个生产级 LLM 推理服务,并希望在 2026 年内落地碳感知能力,以下是按优先级排序的 14 周落地清单:

第 1-2 周:碳强度数据接入。选一个数据源(WattTime 或 Electricity Maps),建时序表,接入 5 分钟级 CI 流,接入 4-6 个推理区域。这一步投入小、产出快,可立即在 Grafana 上看到区域 CI 差异。

第 3-4 周:能量模型。在你的 GPU 上跑一组 benchmark,测量不同模型(7B/13B/70B)、不同 batch size、不同 cache 命中率下的 J/token,拟合 energy-model 服务。

第 5-6 周:trace 标签。在推理服务的入口和出口给每条 trace 打 ci_at_request_time、joules_estimated、carbon_grams 三个属性,接入 Prometheus + Grafana。这一步只观测,不改路由。

第 7-8 周:分桶与配额。把请求按延迟预算分桶(Real-time / Interactive / Batch),把配额系统建起来(L1/L2/L3 三级)。

第 9-10 周:碳感知路由(只对 Interactive 桶)。在 Interactive 桶上启用区域碳感知路由,做 A/B 测试,观察延迟退化和碳效率提升。

第 11-12 周:时空调度(只对 Batch 桶)。在 Batch 桶上启用时空碳感知窗口调度,把批量嵌入、异步摘要调度到低 CI 窗口。

第 13-14 周:碳报告与合同 SLA。自动生成月度碳报告,接入 ESG 报告流水线,接入大客户的 SLA 监控。

长期:持续优化 energy-model 精度、扩展更多区域、接入 carbon credit 抵消流程、把碳感知能力抽象为可被外部租户使用的"碳感知推理 API"。

到 2026 年底,一个成熟的 LLM 推理服务应该具备的能力是:每条请求都知道自己产生了多少碳,每个产品线都有碳预算仪表盘,调度器自动在延迟和碳之间做权衡,碳报告能直接喂给合规和客户合同。这不是遥不可及的愿景,而是 Google、Anthropic、Mistral 等公司正在交付的能力。把这件事做扎实,就是 AI infra 团队在 2026 年最值得投入的方向之一。

一句话摘要:LLM 推理的碳感知调度不是环保姿态,而是电网碳强度数据、token 级能耗模型、时空调度器、碳预算配额四级工程体系,在保持 P99 延迟不退化的前提下,把每千 token 的 gCO₂ 降到 15-25% 的可执行闭环。

参考文献

1. Tom Corring, Google Data Centers, "Carbon-aware computing at Google", Google Research Blog, 2021.
2. Google Cloud Documentation, "Carbon Footprint API Reference", 2024.
3. AWS, "Customer Carbon Footprint Tool User Guide", 2024.
4. Microsoft Azure, "Carbon-aware SDK for Azure", 2025.
5. WattTime API Documentation, "Marginal Operating Emissions Rate (MOER) Data Product", 2024.
6. Electricity Maps, "Methodology: How we estimate the carbon intensity of electricity", 2024.
7. European Union, "Corporate Sustainability Reporting Directive (CSRD) ESRS E1", 2023.
8. Patterson et al., "Carbon Emissions and Large Neural Network Training", arXiv:2104.10350, 2021.
9. Strubell et al., "Energy and Policy Considerations for Deep Learning in NLP", ACL 2019.
10. Leviathan et al., "Fast Inference from Transformers via Speculative Decoding", ICML 2023.
11. Pope et al., "Efficiently Scaling Transformer Inference with Disaggregated Serving" (Disaggregated inference), OSDI 2023.
12. Kwon et al., "PagedAttention: Virtual Memory Management for LLM Serving", SOSP 2023.
13. Google, "24/7 Carbon-Free Energy by 2030: Progress Report", 2024.
14. Anthropic, "Responsible Scaling Policy and Emissions Reporting", 2024.