数据中心里最容易被忽视的矛盾其实藏在集群的功耗墙里。模型推理速度从 30 tok/s 提到 60 tok/s看起来性能翻倍但如果你没有同时观察显卡功率很可能漏掉了真正的成本变化GPU 可能已经多吃了三四十瓦的电机柜的整体耗电预算也在快速逼近容量上限。过去大家聊 LLM 推理性能默认只看 tokens/s、首字延迟、TPOT 这些面向“快不快”的指标很少有人把“每秒吐出多少 token”和“为了让这一秒成立硬件消耗了多少电”放在一起算。最近讨论度上升的 tok/s/MW正好补上了这个缺口它把吞吐量和功耗放进同一个公式里衡量的是“每兆瓦电力能换来每秒多少 token 输出”。这个指标的价值短期看是选卡和调参长期看其实是判断一家公司或一个团队有没有真正为自己的推理服务做过规模化评估。因为在大模型大规模部署场景里电费不是后知后觉的成本而是第一天就要放进容量规划里的约束条件。接下来我会从问题背景、指标原理、测量方法、优化手段、常见误区和落地建议几个角度把这套思路拆开讲清楚。1. 为什么只看“每秒 token 数”不够1.1 速度和成本被割裂的两个视角先还原一个很常见的场景。你在一台 A 系列显卡上跑 7B 模型压测出来的吞吐量是 80 tok/s看起来不错。另一个同事换了另一种部署方式能到 120 tok/s于是结论很自然后者更快方案更优。但如果再往下一层看数据前者的整机功耗只有 420W后者直接冲到 650W那么每秒钟单位的电能换来的产出其实是下降的。对于一个要连跑一个月、每天处理上亿 token 的服务来说这种差距会直接反映到电费账单和散热需求上。传统指标为什么会掩盖这个问题因为延迟和吞吐量只描述了时间维度的表现完全没有物理消耗维度。用户在页面上看到“生成变快了”体验的确更好但基础设施负责人需要回答的问题从来不是“单纯有多快”而是“达到这个速度需要消耗多少资源”。这就像选车时只看百公里加速时间不关心百公里油耗和发动机热效率短途试驾没问题长期运营一定吃亏。1.2 延迟指标无法覆盖规模化约束继续拆一下常用指标。TTFTTime To First Token衡量用户从发起请求到收到第一个 token 的等待时间主要跟预填充阶段、排队状态、网络延迟有关。TPOTTime Per Output Token衡量生成阶段每个 token 的产出时间主要反映解码速度。吞吐量tokens/s衡量系统在单位时间内能产出多少个 token多数情况下指稳态批量生成速度。并发数影响队列深度也影响吞吐量和延迟之间的平衡。这些指标对于单次交互体验是有意义的但它们都建立在同一个假设上硬件资源可以无限供给。真实世界不是这样。一个机柜的供电上限、整个机房的总功率、冷却系统的散热能力都是硬约束。当推理规模大到一个集群级别新增一卡带来的吞吐提升必须和新增一卡带来的功耗提升一起看。否则可能出现一个非常尴尬的局面系统吞吐量确实上去了但机柜功率已经接近上限后续扩容被迫暂停问题从“跑不快”变成“根本没法继续加机器”。1.3 tok/s/MW 为什么能成为补位指标tok/s/MW 的意思非常直白分子是每秒产出的 token 数分母是兆瓦级的总功率两者相除得到“每兆瓦每秒能换到多少 token”。它把吞吐量和能耗放在同一张表里天然就比单独的“快”更接近规模化的运营视角。可以用一个更生活化的类比来理解。评价一个做饭的灶台效率不能只看“每分钟能炒多少道菜”还要看“烧掉一罐煤气能炒多少道菜”。前者衡量的是出餐速度后者衡量的是能源转换效率。实际开餐厅的人两者都得盯客人排队等餐时确实需要更快的灶台一个月算总账时又会发现“出餐速度”和“燃气成本”打架必须在中间找平衡。tok/s/MW 就是这套逻辑在 LLM 推理里的坐标。2. tok/s/MW 指标的构成和物理含义2.1 公式拆解分子是吞吐量分母是功率这个指标的表达通常是这样tok/s/MW (总生成 token 数 / 总耗时) / (平均总功耗 / 1,000,000)为了更清晰可以把计算拆成三步统计在测试窗口内一共产生了多少个 token。统计这个窗口的持续时长用 token 数除以时长得到 tok/s。统计同一窗口内的平均总功耗单位换算成兆瓦然后用 tok/s 除以功耗值。这里要注意分母的单位。单台服务器通常用瓦特或千瓦计量整套集群才更贴近兆瓦级。如果测试对象是单机 8 卡总功耗可能处于 3kW 到 8kW 之间用 kW 更直观得到的就是 tok/s/kW如果对象是整个机房再统一换算成 MW。不管用哪一级单位核心逻辑不变吞吐量除以功耗越高代表“电力换 token”的效率越好。2.2 分母应该是“总功耗”不只是显卡功耗很多人在计算这个指标时容易踩一个坑只统计 GPU 的功耗忽略 CPU、内存、主板、硬盘、交换机和散热设备的消耗。这在单机小范围评估时误差可能不大尤其是 GPU 功耗占大头的时候。但一旦到了集群级别网络设备和制冷系统的电耗会变得非常可观只数 GPU 就明显失真。正确的采集方式最好是从 PDU 或机柜级电表读取总功耗。条件不具备时退一步也要把“GPU 功耗 CPU 功耗 内存功耗 基础待机功耗”加进去做一个整机口径的平均估算。线上环境里如果有带功率采集的硬件平台能直接通过接口拿到整机功耗准确性会好很多。2.3 数据维度天然携带工程信息一个 tok/s/MW 数值背后其实隐含着好几层信息吞吐量高不高功耗高不高两者匹配度好不好。两个模型如果吞吐量完全一样一个用 300W 跑出 80 tok/s另一个用 500W 跑出同样的 80 tok/s前者的能效是后者的 1.67 倍。在容量规划时这个差距意味着同样的电力预算前者能支撑更多的服务实例或为其他业务留出余量。反过来也可能出现一个模型虽然单卡速度略慢但因为功耗低单位电力产出反而更高。这类对比如果不是放到 tok/s/MW 维度里看很容易被忽略。所以这个指标真正的工程价值不是替代原有指标而是把选型、调优、容量评估的讨论区间从“只看快慢”扩展成“综合考虑速度和电力”。3. 如何正确测量并计算 tok/s/MW3.1 准备一次基准压测测量前先定义好基准测试条件。最理想的基准是能代表真实业务的 prompt 长度分布和输出长度分布。举个例子如果业务场景是聊天助手prompt 可能几百到几千 token回复输出从几十到几百 token 不等如果场景是文档摘要输入可能上万 token输出可能只是几百 token。这两类场景的预填充阶段和解码阶段占比完全不同测出来的 tok/s 和功耗特点也会差异明显。推荐做法是构造一个和线上请求分布接近的测试集按比例采样一批真实 prompt固化成长度分布稳定的基准文件。每次测量都用同一份基准这样不同版本、不同配置之间才有可比性。测量步骤大致如下预热模型。先跑几轮请求让缓存、CUDA context、GPU 频率达到稳定状态。记录起始时间。用服务端日志或脚本记录请求发起时间。持续压测一段时间。时间不能太短建议至少覆盖几百个请求让吞吐量和功耗数据都进入稳态。统计总生成 token 数、总耗时、平均功耗。按公式计算 tok/s/MW。3.2 采集功耗和耗时的实践方法功耗采集有几个常见途径使用nvidia-smi查询 GPU 实时功率通过参数设置采样频率定时记录。使用 PyNVML 在 Python 里轮询 GPU 功耗适合和压测脚本整合在一起。如果机器支持 IPMI 或带外管理可以读取整机功率值。最准确的还是 PDU 或机柜级电表直接按时间段读取累计电耗再换算成平均功率。耗时统计方面建议使用请求发出的起点到最后一个 token 生成的终点来计算。不要忽略排队时间因为排队也在占用系统资源并且会拉低实际吞吐量。如果只测量 GPU kernel 时间得出的值偏理想化和真实用户体感相差很大。下面是一个简化版采集脚本示例结构import time import pynvml pynvml.nvmlInit() handle pynvml.nvmlDeviceGetHandleByIndex(0) power_samples [] start_time time.time() # 循环执行推理请求同时采集功率 while time.time() - start_time 120: # 执行一次推理或通过 HTTP 调用推理服务 result inference(prompt) total_tokens result[output_tokens] request_count 1 power pynvml.nvmlDeviceGetPowerUsage(handle) / 1000.0 # 转成瓦 power_samples.append(power) time.sleep(0.5) elapsed time.time() - start_time avg_power sum(power_samples) / len(power_samples) tps total_tokens / elapsed eff_kw tps / (avg_power / 1000.0) # 单位 tok/s/kW eff_mw tps / (avg_power / 1_000_000.0) # 单位 tok/s/MW注意这个脚本只是展示结构真实测量时还需要处理并发请求、动态批处理和账号权限等因素。如果目标是评估整个推理服务而不是单模型算子更建议通过服务层压测工具去发请求同时采集整机或 GPU 功耗。3.3 一个计算示例假设在基准压测中服务一共处理了 20000 个请求总生成 token 数为 500 万测试持续 1000 秒整机平均功耗为 1500W。吞吐量500 万 / 1000 秒 5000 tok/s平均功耗1500W 1.5kWtok/s/kW5000 / 1.5 ≈ 3333 tok/s/kW换算成 MW3333 × 1000 3333333 tok/s/MW如果换成另一套方案吞吐量还是 5000 tok/s但平均功耗降到 1200W那么 tok/s/kW 就是 4167相当于每度电产出的 token 数多了 13.5%。这种提升放到月度电费里就相当可观。注意比较两个方案的能效时必须保证基准请求集、并发数、输出长度约束尽量一致。否则分子分母都变了算出来的比值不能说明任何问题。4. 实际优化如何把单位电力的输出拉高4.1 先调吞吐量再谈功耗顺序不能反很多人拿到 tok/s/MW 之后第一反应是赶紧降功耗。这里要提醒一句降功耗不能以牺牲吞吐量为代价否则分子分母同时下降最终比值很可能并没有变好。正确的优化顺序是先找到一定功耗预算内提升吞吐量的可能性再看有没有办法在不明显降低吞吐量的情况下压低功耗。因为大模型中功耗和吞吐量不是简单线性关系比如通过增大 batch size 来提升吞吐量通常会带来 GPU 利用率上升总功耗也随之上升但吞吐量的增幅往往大于功耗增幅最终 tok/s/MW 反而提升。这说明一个关键原则能效优化不等于功耗最小化而是让每一瓦电换到更多输出。4.2 量化与精度策略量化是目前最直接影响 tok/s/MW 的手段之一因为它同时作用在分子和分母上。把 FP16 权重换成 INT8 或 FP8 精度后模型显存占用减少同一块显卡可能放下更大的 batch 或更长的上下文推理速度通常提升同时显存带宽压力降低部分硬件在低精度下单位功耗产出更高。于是分子变大分母下降或持平比值变好。但量化不是免费午餐低精度对某些模型和任务的准确率有明显影响尤其是涉及数学推理、代码生成和长文本知识提取的场景。INT4 可能带来更明显的质量下降部署前必须用业务测试集做质量回归。量化后的算子在不同 GPU 架构上支持情况不一样需要先做兼容性验证。所以不要抱着“量化等于节能”的简单想法去用。量化的实际效果和模型结构、任务类型、硬件架构强相关必须用同一份基准分别测 FP16、FP8、INT8 的 tok/s/MW 和质量指标再一起比较。4.3 动态批处理和 KV Cache 管理动态批处理或 Continuous Batching 对吞吐量的提升非常明显。它把不同请求的 decode 阶段合并到同一个批次里让 GPU 尽量处在满负荷状态而不是等单个请求串行跑。批处理带来的结果通常是吞吐量成倍增长功耗只是温和上升所以 tok/s/MW 会出现明显改善。KV Cache 的管理同样重要。如果每个请求都重复计算历史 token 的 KV 向量GPU 花在重复计算上的功耗就是浪费。引入 KV Cache 后相同 prompt 或前缀可以复用计算预填充阶段的开销降低有效吞吐量提高。配合 PagedAttention 这类显存管理策略可以把碎片显存也利用起来支持更大并发进一步推高分子。4.4 硬件选型和负载匹配同一个模型在不同的硬件上跑出的 tok/s/MW 可能差距很大。大卡的绝对吞吐量高但因为功耗高单位电力产出未必好。比如一张 700W 的卡跑出 100 tok/s一张 350W 的卡跑出 30 tok/s前者的绝对值是后者的 3.3 倍但能效只有后者的约 1.65 倍。如果你的业务延迟不敏感、并发不高把小卡组合起来可能总能耗更划算如果业务要支撑高并发低延迟大卡的高吞吐优势又会体现出来。这里给一个选型建议框架维度倾向于高吞吐大卡倾向于高效能小卡延迟要求低延迟需要更快的首字和生成延迟容忍度较高并发情况高并发同一时刻大量请求并发中等请求波峰不明显电力预算有明确功率上限有明确功耗和成本控制要求模型规模70B 级别或更大7B 到 14B 级别长期成本追求单次任务绝对速度追求单位电力产出的长期收益不要只看显卡型号还要看服务器整机功耗。有些服务器基础功耗很高卡的数量少时基础功耗会被稀释到每个 token 上导致能效偏低。4.5 调度策略和请求合并推理服务的调度策略也会影响 tok/s/MW。合理控制请求并发让系统稳定工作在最优吞吐区间能避免两种情况一是并发过低导致 GPU 利用率不足空转浪费电二是并发过高导致排队严重和显存溢出系统反复等待和重试反而降低吞吐量。可以通过压测找到自己的服务在不同并发下的吞吐量和功耗曲线一般会看到吞吐量先涨后平再跌的形状。选择“吞吐量接近峰值但功耗增长速度已经放缓”的区间作为常用工作点而不是盲目拉满并发。实践里最稳妥的路线是先固定模型版本和基准数据集跑完基线测试再逐项调整并发、batch size、量化级别、KV Cache 策略每项只变一个变量记录 tok/s/MW 绝对值和波动范围最后再组合最优项。5. 容易误用这个指标的几个坑5.1 把测试窗口截得太短模型刚启动时GPU 会进入最高频率运行预热性请求此时功耗可能处于一个不稳定的峰值上。如果只跑几十秒就统计很可能拿到一个偏高的平均功耗值。更麻烦的是有些推理框架会在前几个请求时做 JIT 编译或显存预分配这部分耗时不算在推理中却会占用 CPU 和内存如果日志统计又把这部分时间排除最终吞吐量会显得偏高能效数值失真。建议测试前先运行至少 1 到 2 轮预热把权重加载、显存分配、CUDA graph 编译这些一次性开销都稳定下来。正式测试窗口尽量保持在几分钟以上并多跑几次看波动范围而不是只报单次数值。5.2 忽略了空闲功耗和整机功耗还有一个常见误区是把“GPU 运行功耗”当成“系统总功耗”。如果只看 GPU 功耗分母偏小tok/s/MW 会显得虚高。等真的放到一个大型推理集群里发现冷却、网络、存储和管理节点也在耗电真实能效就会比单卡测量值低很多。尤其是机房里 GPU 利用率低、但机器仍然待机的情况空闲功耗对能效的影响会被严重低估。如果条件允许尽量从 PDU 或整机层采集功耗。临时没有条件时可以先把 CPU、主板、内存、风扇这些基础功耗估算进分母虽然不是特别精确但比只算 GPU 更接近实际运营视角。5.3 在不同负载之间硬比数值tok/s/MW 不是跨模型、跨场景通用的公平指标。你用同样的硬件跑 7B 模型和 70B 模型7B 模型的 tok/s/MW 几乎必然更高因为它的吞吐量更高、功耗更低。但你不能因此得出结论7B 一定比 70B 好。能力不上一个量级能效数字再好看也没有意义。同样短输出任务和长输出任务也不能直接比较。长输出任务里 decode 阶段占主导吞吐量可能偏低但预填充阶段的比例不同功耗特征也不一样。比较时要把模型规模、prompt 长度、输出长度、并发数、精度等条件对齐否则很容易得出误导性结论。5.4 只用 tok/s/MW 做决策忽略用户体验这个指标最终是给容量规划和能效优化用的不能完全替代用户体验指标。一个系统如果把能效调到最高通常意味着让 GPU 尽量跑满 batch这会让单请求在小并发下反而变慢。对实时对话场景来说首字延迟和生成速度才是用户直接感知的指标。如果为了能效把并发拉高导致首字延迟从 500ms 涨到 2 秒用户体感会迅速变差再高的每兆瓦产出也没有意义。正确的用法是先满足延迟和质量的硬性约束再在剩余空间内优化 tok/s/MW。它是一个成本效率指标不是一个端到端体验指标。6. 落到工程实践一套可复用的评估流程6.1 建立基线而不是拍脑袋不管你是刚接触 LLM 推理优化还是已经在做大规模部署第一步都应该是建立一套可复现的基线评估流程。流程至少包含三份材料固定的基准数据集包括代表性 prompt、输出长度分布、请求数量。固定的软硬件配置清单包括框架版本、CUDA 版本、量化策略、并发数。固定的计算脚本能自动输出吞吐量、平均功耗、延迟分位数、tok/s/MW。有了基线之后所有优化都变成同一基准上的对比实验。比如修改了 KV Cache 策略或者切换了新的推理框架直接在相同基准上重跑看 tok/s/MW 是上升还是下降波动范围如何。这样就不需要依赖直觉判断“新版感觉更快”这类模糊结论。6.2 从单机到集群的分层测量测量范围不同tok/s/MW 的数值含义也不同。建议像下面这样分层管理单卡/单机层用于快速验证模型版本、算子优化、量化效果。分母可以先统计 GPU 功耗也可以统计整机功耗但要固定口径。服务层在一个推理服务上压测考虑并发、排队、动态批处理。分母建议统计整个服务所在节点的平均总功耗。集群层面向真实容量规划考虑机柜、制冷、网络设备总功耗。分母必须使用机柜或机房级实际电耗。每一层的优化目标和测量口径不同。单机层性能高不代表集群层能效就高因为网络和散热会把大量非 GPU 功耗摊进分母。分层测量的价值是让你把关注点从“这张卡有多快”逐步提升到“这一兆瓦电能支持多少业务量”。6.3 用 SLO 和成本约束联合评判在实际生产环境里我建议把这样几类指标放在一起看而不是单独追求 tok/s/MW 最大化质量指标模型输出是否符合业务预期是否有明显降智。延迟指标TTFT 和 TPOT 是否满足用户可接受的阈值。成本指标单位 token 的电费、硬件折旧、运维成本。效率指标tok/s/MW判断电力-吞吐量的转化率是否变化。只有当质量、延迟都满足要求后tok/s/MW 才有讨论价值。否则一个模型输出质量不合格但速度飞快、功耗还特别低对生产没有任何意义。运营者和开发者需要达成一个共识所谓“最优”不是某个单一指标的最大值而是在多个约束条件都满足的前提下找到一个可持续运行的均衡点。6.4 定期重测防止性能回退软硬件环境会持续变化框架版本升级可能改变算子实现驱动更新可能影响 GPU 频率调度业务请求分布也可能随着时间漂移。如果几个月不重测当初很优秀的 tok/s/MW 可能已经悄悄下降。定期重测的节奏可以根据业务重要性来定重要服务每两周或每次框架升级后都值得跑一遍基线稳定的边缘服务至少每月一次。在重测时如果发现指标下滑可以沿着下面的链路排查看测试负载是否变化。确认请求长度分布、并发数是否和基线一致。看功放采集是否正常。检查 PDU 读数、nvidia-smi 数值是否有异常跳变。看 GPU 状态。温度是否过高、频率是否被压低、显存是否占用过多。看框架配置。量化、批处理、KV Cache 相关参数是否被某个配置项意外覆盖。看版本变更。最近是否升级了推理框架、CUDA、驱动或模型文件。这样从现象出发一层层排除比盲目翻日志更高效。就算最后没有找到明确原因重测本身也能帮你积累出更完整的系统画像。任何效率指标的长期价值都建立在持续跟踪和复盘的基础上。7. 回到最终判断这个指标会改变什么tok/s/MW 真正改变的不是测试方法而是整个推理系统在规模化场景下的决策方式。以前优化团队只盯着“怎么让生成更快”基础设施团队只盯着“怎么控制功耗”两个目标经常互相打架。现在通过同一个指标两边可以在同一张图上讨论问题。吞吐量和功耗不再是两个独立变量而是同时进入优化目标的输出表达式。放到更大范围看大模型推理正在从“跑通”走向“规模化运营”。当推理任务进入每天数亿 token、数千卡、持续数月运行的阶段电费会成为一张必须正视的运营账单。到那时候谁的单位电力产出更高谁就更有可能在同样预算内服务更多用户。tok/s/MW 不是用来替代延迟或吞吐量的指标而是给整个行业多一个更接近物理成本的视角。对于个人开发者和小团队我倒建议先从简单的测量脚本开始。不需要一开始就搭完整的集群级监控把你的单卡或单机功耗和吞吐量记录下来算出自己的基线数字然后逐项调整量化级别、batch size、并发策略看哪一步的能效提升最明显。这个动作做几轮以后你会发现自己对推理系统的理解已经比只看“跑得有多快”的人深了一层。