大模型落地这两年我被问得最多的问题从“效果怎么调”慢慢变成了“这一套跑下来电费多少、碳排放怎么算”。绿色计算这个概念以前更多出现在数据中心运维的报告里现在做算法的、做推理服务的、做基础设施的都开始被拉进同一个会议里对账。所谓面向可持续发展的大模型优化与能效评估说白了就两件事一是把每一度电换来的有效计算尽量做多二是把这笔账算清楚、算得可复现让别人也能核对你到底省在哪。这篇内容适合三类人看。第一类是正在做模型压缩、推理加速的算法同学你可能已经把延迟降下来了但还说不清能耗降没降第二类是做推理平台和集群调度的工程同学你需要一套能落地的采集方案而不是拍脑袋估算第三类是负责技术选型和成本核算的角色你要的是指标定义、边界划分和一张能拿去汇报的对照表。我会把指标怎么选、数据怎么采、模型侧和系统侧怎么优化、踩过的坑怎么排查按我实际做项目的顺序摊开讲参数和计算过程都给到能直接抄的程度。1. 先把账算明白大模型能耗到底花在哪里在动手优化之前我坚持先做一件事把能耗拆到能归因的粒度。很多人一上来就谈量化、谈蒸馏结果跑完发现整机功耗几乎没动白折腾两周。原因往往不是优化无效而是能耗大头根本不在他优化的那一层。1.1 训练与推理是两本完全不同的账训练侧的特点是“短时高强度”。一次几百亿参数级别的预训练动辄上千张加速卡满载跑几周功率曲线几乎是平的峰值功率长期贴着机柜上限。推理侧恰恰相反它是“长时中低强度”单次请求的功耗不高但架不住 7×24 小时不停地跑累计电量往往在半年内就超过当初训练那一笔。我一般用两个粗略的比值来判断该往哪边投入。第一是推理累计能耗与训练能耗的比值业内常见经验是一个模型上线服务一年以上推理侧累计能耗很容易追平甚至超过训练侧具体倍数取决于请求量和模型规模没有普适数字但方向非常稳定。第二是空闲能耗占比也就是加速卡分配出去了但实际计算单元利用率很低的那部分时间这部分在推理服务里能占到两三成是性价比最高的优化目标因为它不需要改模型只需要改调度。这里有个我吃过亏的细节只看加速卡功耗会严重低估。一台八卡整机加速卡满载可能占整机功耗的七成左右剩下三成是 CPU、内存、风扇、电源转换损耗。如果你的优化只把加速卡功耗降了 10%整机层面可能只有 7% 的改善再乘上机房 PUE最终到“市电”层面的改善更小。所以从第一天起我就要求所有对比实验都以整机输入功率为准芯片级读数只用来做归因分析。1.2 算力效率、能源效率、碳效率别混着说这三个词在汇报里经常被混用但它们衡量的东西完全不同混着说就一定会得出错误结论。概念关注点典型度量容易被误用的场景算力效率硬件理论峰值被用出了多少MFU、算力利用率拿 MFU 提升直接等同于省电能源效率每焦耳能量产出多少有效工作J/token、J/样本、EDP忽略 PUE 直接对外披露碳效率每单位有效工作的碳排放gCO2e/token、gCO2e/千次请求用平均电网因子掩盖时段差异MFU 提升不等于省电这个逻辑漏洞我见过太多次。举例来说把批次调大能让 MFU 从 30% 涨到 45%但如果批次大到内存交换频繁、风扇转速拉满整机功率可能从 6.2 kW 涨到 7.1 kW吞吐涨了 1.5 倍能耗只降了约 24%远没有 MFU 那个涨幅好看。反过来某些场景下 MFU 没变但因为把计算挪到了能效比更高的硬件上J/token 直接砍半。结论就是优化目标必须直接写成能源效率指标MFU 只能当过程指标看。1.3 为什么“绿色”这件事必须落到可核算的口径上可持续发展这个说法很容易变成口号一旦要对外披露或者对内立项就必须回答三个问题边界在哪、因子取什么、能不能复现。边界指的是只算加速卡、算整机、还是算到机房市电入口因子指的是用电的碳排放系数取年度平均还是分时复现指的是别人拿同样的模型和配置能不能得出同一个量级的结果。我的做法是把口径写死在实验模板里每次实验必须填三个数字整机输入功率均值、有效吞吐、以及核算时使用的 PUE 与碳排放因子。这三个数字一变结论的可比性就没了。下面这节讲具体怎么采、怎么算。2. 能效评估体系怎么搭指标选型与数据采集评估体系这块我的原则是“宁可用简单指标算准也不用复杂指标算歪”。见过太多团队搭了一套花哨的模型最后因为采集口径不统一跨版本对比全是噪声。2.1 指标怎么选J/token 比 tokens/s 更接近真相吞吐tokens/s是工程上最常用的指标因为它直接对应延迟和成本但它在能效维度上是有误导性的。两个配置A 吞吐 1000 tokens/s 功耗 6 kWB 吞吐 1400 tokens/s 功耗 9 kWA 是 6 J/tokenB 是 6.4 J/tokenB 更快但更费电。如果你的目标是最低成本选 B 可能对如果目标是能效选 A。这两个结论不冲突但必须先明确你要哪个。我常用的指标组合是这几个J/token推理单次生成一个输出 token 消耗的焦耳数最直观适合跨模型、跨硬件横向对比。J/有效样本训练一次训练迭代分摊到每个有效训练样本上的能耗比单纯看总电量更能反映数据效率。EDP能耗延迟乘积焦耳数乘以延迟用来防止“为了省电把延迟拖到不可接受”这种自欺欺人的优化。单位有效工作碳排放把 J/token 换算成 gCO2e用于对外沟通和内部碳账本。注意J/token 一定要标注输入输出长度、批次大小和并发数。同一模型在 batch1 和 batch32 下J/token 能差出三四倍不标条件的数字没有意义。2.2 采集方案从整机功率计到芯片级读数采集方案分三档按精度和成本排列我一般建议至少做到第二档。第一档是芯片级读数通过厂商提供的管理接口读单卡功耗。优点是粒度细、能归因到具体任务缺点是它只反映芯片自身不含电源转换损耗和风扇通常会低估整机功耗一到两成。这档数据我只用来做相对比较比如“量化前后芯片功耗变化了多少”不用于对外披露。第二档是整机 PDU 级功率计在机柜配电单元或者服务器电源输入端串一个带数据记录功能的功率计采样间隔 1 秒。这一档的数值就是我说的“整机输入功率”是核算的基准。成本不高一台几百块到一两千的智能电表就能满足关键是采样间隔要够密因为推理负载波动大采样太稀会严重失真。第三档是机房级计量用来算 PUE。这个通常由运维提供自己做的话成本较高。如果拿不到实测 PUE我建议在报告里明确标注“采用行业参考值 1.2~1.4 区间估算”不要把估算值写成实测值这是最容易在评审时被挑出来的问题。采样频率这块有个经验推理场景建议 1 秒一次训练场景可以放宽到 5 秒一次。原因是 GPU 功率在推理时会在毫秒级剧烈抖动1 秒一次已经是在做平均了再稀就抓不到峰值。另外一定要记录空闲基线也就是服务启动但不接请求时的整机功率这个数字在算“净能耗增量”时非常关键。2.3 一套可复现的测量流程与计算示例下面是我实际用的一套流程四步每一步都要求留痕。第一步预热。服务起来后先跑 5 分钟空载等风扇转速和温度稳定记录空闲功率基线。跳过这一步是新手最常见的错误冷机启动时功率曲线是爬坡的直接开始测会把平均值拉低。第二步固定负载压测。用固定输入长度和固定输出长度比如输入 512、输出 256固定并发数跑满 10 分钟前 2 分钟丢弃后 8 分钟取功率均值和吞吐均值。丢弃前段是为了排除缓存预热和队列堆积的影响。第三步换算。以一台八卡整机为例实测整机输入功率均值 6.5 kW压测吞吐稳定在 1200 tokens/s那么单 token 能耗 6500 W ÷ 1200 tokens/s ≈5.42 J/token若机房 PUE 取 1.3则市电侧 5.42 × 1.3 ≈7.05 J/token换算电量7.05 J ÷ 3.6×10⁶ J/kWh ≈1.96×10⁻⁶ kWh/token碳排放因子按 0.58 kgCO2e/kWh 估算1.96×10⁻⁶ × 0.58 ≈1.14×10⁻⁶ kgCO2e/token也就是每百万 token 约 1.14 kgCO2e这个量级读者可以拿去对照数量级对了说明你的口径大致没问题如果算出来每百万 token 只有几克或者几十公斤大概率是漏乘了单位或者把 PUE 用反了。第四步训练侧同理但要换公式。训练能耗的估算我用的是“总算力需求 ÷ 有效算力 × 整机功率 × 卡数”的思路。举个具体例子一个 70 亿参数模型训练数据量 1 万亿 token前向加反向的近似计算量按 6×参数量×token 数估算总算力 ≈ 6 × 7×10⁹ × 1×10¹² 4.2×10²² FLOPs假设所用加速卡的实测有效算力注意是实测不是标称为单卡 4×10¹⁴ FLOPs/s用 2048 张卡并行纯计算时间 ≈ 4.2×10²² ÷ (2048 × 4×10¹⁴) ≈5.1×10⁴ 秒约 14 小时再按实际工程经验乘一个 1.3~1.5 的系数通信等待、检查点保存、数据加载停顿取 1.4实际约 20 小时整机功率按每 8 卡 8 kW 计256 台整机 2048 kW20 小时耗电约41 MWh乘 PUE 1.25 得市电侧约51 MWh碳排放约29.6 吨 CO2e这组数字的目的是让你对量级有感觉。实际项目里我建议把这个模板做成表格每次训练填一次跑三个月就能看出哪些环节在漏电。3. 模型侧优化在不掉点的前提下把能耗压下来模型侧优化的诱惑在于“改几行配置就能省”但坑也最多。我的判断标准很朴素优化之后整机功率下降的幅度必须大于精度下降带来的重跑成本。如果量化之后准确率掉了一个点需要多训一轮来补那这一轮的电早就把省下来的抵消了。3.1 量化收益最大但边界要说清楚低精度推理是当前性价比最高的一档优化没有之一。把权重和激活从 16 位降到 8 位理论上显存占用减半、访存带宽压力减半而大模型推理在解码阶段往往是访存瓶颈所以收益非常直接。我实测过的场景里整机吞吐提升 1.4 到 1.8 倍是常见区间J/token 相应下降三到四成。但边界在哪很多人没搞清楚。第一量化对预填充阶段和解码阶段的收益不一样。预填充阶段计算密集量化主要省访存解码阶段访存密集量化收益更大。所以长短输出比例不同的业务量化收益差别很大短输入长输出的场景收益最明显。第二4 位量化的收益不是线性的。8 位到 4 位显存确实又减半了但反量化开销和精度补偿策略会吃掉一部分收益我见过不少场景 4 位相比 8 位只多省了 10% 到 15% 的能耗精度却明显下滑不划算。操作上我的建议是分阶段验证不要一步到位先在离线集上做 8 位量化记录任务指标变化控制在可接受范围内通常要求相对下降不超过 1%再上在线灰度压测吞吐和整机功率算出 J/token 的实际变化只有当前两步都确认收益为正才考虑更激进的方案。提示量化后一定要重新测功率不要用“吞吐提升比例”直接推算能耗下降比例。因为吞吐上去了计算单元利用率也上去了整机功率往往会跟着涨一点实际能耗下降幅度小于吞吐提升幅度。这个误差通常在 5 到 10 个百分点做汇报时被问到会很尴尬。3.2 剪枝与蒸馏适合的场景比想象中窄结构化剪枝在视觉模型上很成熟搬到大模型上就会遇到麻烦注意力头和中间层的冗余度不像卷积通道那么明显剪完之后往往需要一段不短的恢复训练而这段恢复训练本身的能耗就要算进总账。我自己的经验是除非你有明确的推理成本压力且能接受两周以上的恢复训练否则结构化剪枝的投入产出比不如量化。蒸馏更适合“有明确小模型形态”的场景。比如你有一个能力很强的教师模型但线上只需要处理固定几类任务那就蒸馏一个参数量小一个量级的学生模型推理能耗直接按参数量比例下降而且不需要在线上做复杂的运行时优化。这条路的关键在于任务收敛度任务越窄蒸馏越有效任务越泛学生模型越难逼近最后为了保效果不得不加长输出或者加多次采样能耗优势就没了。无训练的结构化稀疏比如按固定模式跳层或跳注意力值得关注它的好处是不需要恢复训练代价是精度损失不可控需要用评测集筛。我一般把它当作“最后一档备用手段”在算力极度受限的边缘部署场景才会用。3.3 结构与调度层面MoE、注意力与批处理混合专家结构在能效上是个双刃剑。稀疏激活确实让每个 token 只走部分参数单 token 计算量下来了但它的显存占用并没有按比例下降因为所有专家都得常驻或者频繁换入换出而且路由不均会导致部分设备忙、部分设备闲整机功率并不会按计算量比例下降。我见过一个案例MoE 模型单 token FLOPs 只有稠密模型的三分之一但整机功耗只降了不到两成原因就是负载不均衡加显存带宽打满。注意力层面的优化收益主要集中在长上下文场景。标准注意力的计算和显存开销随序列长度平方增长一旦上下文拉到几万 token这部分就成了能耗主导项。分块计算、稀疏注意力这类手段能把它压到接近线性长文本业务的 J/token 改善非常明显。短上下文业务做这个优化基本看不出差别别浪费工时。批处理是另一个高频误区。批次调大能提升吞吐、摊薄单 token 的固定开销但存在一个拐点超过拐点之后延迟上升、显存压力增大、可能触发换页能耗反而变差。我通常的做法是做一次批次扫描从 1 扫到硬件能承受的上限每个档位记录吞吐和整机功率画出 J/token 曲线取曲线最低点对应的批次作为默认配置。这个扫描一次两三个小时但能长期受益非常值。4. 系统侧优化从单机能效到集群碳账本模型侧的天花板大概就在那里想再往下压就得动系统。这块的收益往往比模型侧更大但也更容易被忽视因为它不属于算法同学的舒适区。4.1 硬件与机房PUE 那一刀砍在哪里PUE 是机房总能耗与 IT 设备能耗的比值1.3 意味着 IT 设备每用 1 度电机房额外还要花 0.3 度在制冷和配电损耗上。这个系数看着不起眼但它把所有的模型侧优化成果都乘了一遍。你把 J/token 从 5.4 降到 4.0改善 26%如果同时把 PUE 从 1.5 降到 1.25市电侧的实际改善会从 26% 放大到接近 38%。降低 PUE 的手段主要是制冷方式和气流组织这些属于基础设施范畴普通研发团队插不上手。但有一件事研发团队能做提高设备的实际负载率。机房最浪费的状态不是满载而是低负载——一台服务器闲着也要耗电风扇要转、内存要供电、电源有转换损耗。把零散的小任务集中调度到少数机器上让其余机器进入低功耗状态这个动作在混合负载集群里往往能省出 10% 以上的电而且完全不需要改代码。硬件选型上我的建议是不要只看峰值算力要看目标负载下的能效曲线。同一张卡跑小批次和大批次时的能效比可能差两倍。选型时应该拿你自己的真实负载去跑基准而不是看厂商在理想条件下的数字。这件事我在两个项目里都吃过教训一次是选了峰值高但小批次能效差的卡结果线上批次上不去实际能耗比另一套方案还高。4.2 调度策略把任务挪到更“绿”的时段电网的碳排放因子是随时间变化的中午光伏出力高的时候因子低傍晚用电高峰时因子高两者差出一倍是常有的事。这意味着同样的电量在不同时段消耗碳账本上的数字完全不同。对训练任务来说这是最容易吃到的一块红利。训练任务通常对完成时间有弹性比如要求 48 小时内完成即可完全可以做成“碳感知调度”把任务排到预测因子较低的时段启动或者在中途因子升高时降速、因子降低时提速。实现方式不复杂成本模型里把“当前时段碳因子”作为一个权重项加进去就行。对在线推理来说弹性小得多但也不是完全没空间。可做的是非实时任务的迁移批量的离线推理、日志分析、数据预处理这类任务完全可以挪到深夜或者绿电充裕的时段。我一般建议把这类任务单独排一个队列和实时请求做资源隔离避免互相干扰。注意碳感知调度必须配套一个“完成时限”约束否则优化器会无限期推迟任务来等最绿的时段。我在第一版里就漏了这个约束结果一批离线任务排了三天没启动业务方直接找上门。4.3 碳足迹核算的边界与几个必踩的坑核算这块我列几条实际踩过的坑都是那种“不算不知道、一算全是错”的类型。第一个坑是边界不一致。A 方案只算加速卡B 方案算了整机两个数字放在一起比结论一定是错的。团队内部必须先统一到“整机输入功率 × PUE”这一层对外披露时再单独说明边界。第二个坑是碳排放因子的取值。用全国年度平均值最简单但会掩盖时段差异和地域差异。如果不做碳感知调度用年度平均值可以接受如果做了就必须用分时因子否则你省下的那些碳在账本上根本体现不出来。第三个坑是忽略隐含碳。硬件制造、运输、报废这些环节的碳排放虽然不在电费单上但在完整的生命周期评估里占相当比重。我的做法是在内部核算里把这一项列为“参考项”不并入运营碳但在选型决策时作为考量因素之一——毕竟一台能效高但三年就要换的机器全生命周期未必更绿。第四个坑是缓存和重试的能耗没算。推理服务里的语义缓存命中率提升能直接减少计算量但很多团队的能耗核算只统计“实际执行了推理的请求”把缓存省下来的部分当成不存在。这会导致缓存优化的价值被严重低估。5. 常见问题与排查实录这一节是我这几年攒下来的速查表基本覆盖了大部分“优化了但没效果”和“数据对不上”的场景。5.1 测量失真排查表现象最可能的原因排查动作整机功率远低于芯片读数之和采样点在错误的配电层级或功率计精度不足核对采样位置换用带真有效值测量的功率计多次测量结果波动超过 20%采样间隔太稀或压测时长太短采样提到 1 秒压测延长到 10 分钟以上丢弃前段吞吐涨了但 J/token 没降功率随利用率同步上涨净收益被抵消计算净能耗增量对比空闲基线不同版本结果无法对比输入输出长度、并发数或 PUE 口径变了固化实验模板把这三个参数写进配置训练能耗估算比实际低一半只算了纯计算时间漏了通信和检查点开销乘 1.3~1.5 的工程系数或直接用实测总电量5.2 优化后能耗不降反升的几种典型情况第一种是量化后为了保精度加了采样次数。为了让量化模型的输出质量追平原模型有些方案会用多次采样加投票结果 token 生成量翻倍能耗直接反超。这个坑很隐蔽因为它是在业务层做的补偿只看单次推理的数据看不出来。第二种是批次调大触发了显存换页。批次从 8 调到 32吞吐涨了 2.5 倍但显存超了开始走主机内存交换整机功率从 6 kW 涨到 7.5 kWJ/token 反而变差。这个现象在长上下文场景特别容易出现因为 KV 缓存占用随批次线性增长。第三种是并发调高导致 CPU 侧成为瓶颈。加速卡在等数据功率没降但吞吐不涨等于是拿满功率干半份活。排查方法是看加速卡利用率和 CPU 利用率的比值如果卡利用率上不去而 CPU 打满问题就在数据预处理或者请求编排上不在模型上。第四种是过度追求低延迟。为了把首 token 延迟压下来把并发限制得很低卡长期处于低负载运行单 token 分摊的固定开销极高。这种情况下延迟指标很好看能效指标很难看。我的建议是同时看延迟分位数和 J/token两个指标一起定验收线任何一项不达标都不算完成。5.3 几条不太好写进文档的经验第一条优化顺序比优化力度重要。我的一般顺序是先修调度和空闲浪费改配置就行收益立竿见影再做量化收益大、风险可控然后做批处理扫描最后才考虑剪枝蒸馏这类需要训练的方案。反过来做往往在前两步就把时间耗光了。第二条每个优化动作都要留一份“回滚配置”。能耗优化经常伴随精度或延迟的轻微退化业务方不一定接受。我习惯把每组配置和对应的三项指标精度、延迟 P99、J/token记录成表一旦线上出问题能立刻定位到是哪次变更引起的。第三条别在测试环境得出最终结论。测试环境的负载模式和生产差太远我在测试环境测出的最优批次上线后因为请求长度分布不同最优值直接偏移了一个档位。正确做法是测试环境筛出候选生产环境灰度验证。最后分享一个我觉得最实用的小习惯给每个模型版本维护一张“能效身份证”记录参数量、量化位宽、典型批次、实测 J/token、对应 PUE 和碳因子口径。这张表攒上半年你会发现它能回答很多临时被问到的问题也能让你在做下一个项目时对“大概能省多少”有一个靠谱的预判而不是每次都从零开始试。