这次我们不看某个具体框架而是看一个评估 LLM 推理的新指标tok/s/MW。以前做推理性能测试大家习惯只盯 tok/s也就是每秒生成多少个 token。这个数字确实直观但它只回答了“跑得有多快”没有回答“为了跑这个速度付出了多少电力成本”。如果只是本地玩一玩多几十瓦少几十瓦无所谓。可一旦到了数据中心、长期服务、多卡集群电费、散热、机柜供电上限都是实打实的约束。tok/s/MW 这个指标把吞吐量和功率放到同一个公式里用来回答一个更实际的问题每消耗 1 兆瓦电力系统能稳定产出多少 token。这篇文章会把 tok/s/MW 从定义、计算、测量到优化完整过一遍。内容包括为什么传统 tok/s 不够用、tok/s/MW 和 tok/s/W、J/token 怎么换算、影响这个指标的关键因素有哪些、如何用框架日志加功率采集工具完成实测、以及一套可以直接套用的对比流程。如果你正在做 LLM 推理服务的容量规划、硬件选型或成本核算这个指标值得加入评估清单。1. 核心概念速览维度说明指标名称tok/s/MW指标类型LLM 推理能效指标核心公式推理吞吐量tok/s / 平均功率MW解决的问题只评估速度、忽略电力消耗导致的方案对比失真主要用途数据中心扩容、硬件选型、推理成本核算、绿色计算评估相近指标tok/s/W、tok/s/kWh、J/token、MFU测量工具推理框架自身日志、nvidia-smi dmon、整机功耗仪/PDU适用层级单机用 W 粒度数据中心与集群用 MW 粒度主要局限需要统一 workload、功率边界与 tokenizer不能替代延迟和准确率指标需要先说明一个概念层级MW 是兆瓦1 MW 1,000,000 W这个量级一般用于数据中心或推理集群。单机单卡测试时用 W 更自然所以很多资料里也会写成 tok/s/W。tok/s/MW 和 tok/s/W 本质是同一个东西只是把分母放大了一百万倍数值差别会很大。后面会给出完整换算逻辑。2. LLM 推理只测 tok/s 为什么不够先看一个常见场景。你手上有一张高端卡和一张中端卡高端卡生成速度明显更快tok/s 数字很好看。但如果高端卡的功率是中端卡的两倍多而吞吐量只提升了 30%那在长时间服务场景下高端卡单位电力的产出可能反而更低。这里的关键问题是你是在买“绝对速度”还是在买“单位电力成本下的产出能力”。对于一个小规模演示服务绝对速度更重要因为用户等不起卡数量也少电费占比不高。但到了推理集群阶段情况完全不同GPU 是长时间高负载运行功率不是瞬态值而是持续成本。数据中心的供电、散热、机柜密度都有上限。一个机柜能提供的功率是有限的能够部署多少卡取决于卡的功耗而不是卡的标价。在给定电力预算下能效更高的方案意味着可以部署更多算力或者生成更多 token。多个方案对比时tok/s 只能反映“快不快”无法反映“划不划算”。另一个容易被忽略的问题是散热成本。GPU 消耗的电能大部分会转化为热量散热系统又要额外耗电。数据中心通常用 PUEPower Usage Effectiveness来描述这个放大效应。PUE 1.3 表示 IT 设备每消耗 1W整站实际要消耗 1.3W。如果只看 GPU 卡本身的 tok/s不考虑站点级别的功耗放大做扩容规划时会出现偏差。所以 tok/s/MW 不是要取代 tok/s而是在 tok/s 之上增加一个功耗维度。它回答的核心问题是同样消耗 1MW 电力A 方案和 B 方案分别能产出多少 token。这个数据对容量规划、成本核算和硬件选型非常有用。3. tok/s/MW 的定义与计算方式3.1 指标公式tok/s/MW 的基础定义是tok/s/MW 推理吞吐量tok/s / 平均功率MW分子是系统在某个 workload 下稳定生成的 token 速率分母是这段时间内系统的平均功率。这里有两个需要特别注意的边界第一功率边界。分母可以只算 GPU 卡功耗也可以算整机功耗CPU、内存、主板、电源损耗还可以算数据中心站点功耗再乘 PUE。同一个测试因为分母边界不同tok/s/MW 可以差出好几倍。对比方案时必须先统一功率边界否则完全没有可比性。第二吞吐量的口径。tok/s 可以是单请求的生成速度也可以是并发场景下整个系统的端到端吞吐。对能效评估来说更推荐用并发场景下的端到端吞吐因为在线服务几乎不会有单请求独占一张卡的情况。3.2 单位换算与相关指标实际工作中单机单卡场景更常用的单位是 tok/s/W而数据中心级评估才用 tok/s/MW。两者关系如下1 MW 1,000,000 W tok/s/W 吞吐量(tok/s) / 功率(W) tok/s/MW 吞吐量(tok/s) / (功率(W) / 1,000,000)反过来也可以用 J/token 表示单 token 能耗单 token 能耗(J/token) 功率(W) / 吞吐量(tok/s) 1 W 1 J/s这组指标实际上是等价的。J/token 越小越好tok/s/W、tok/s/MW 越大越好。如果 A 方案在 600W 功率下能跑 100 tok/s那么tok/s/W 100 / 600 ≈ 0.1667tok/s/MW 100 / 0.0006 ≈ 166,667单 token 能耗 600 / 100 6 J/token这个计算是示意性的实际数值取决于模型、硬件、并发和推理框架但换算逻辑是通用的。容易出错的地方是单位换算用 MW 做分母时不要忘记把 W 除以一百万用 J/token 时要注意功率是平均功率而不是峰值功率。3.3 tokenizer 对指标的影响还有一个被忽视的变量token 本身不是一个绝对单位。不同 tokenizer 的分词粒度不同同一个中文句子模型 A 可能切成 30 个 token模型 B 可能切成 20 个 token英文单词也可能因为词表不同而出现不同切分。这意味着 tok/s 甚至 tok/s/MW 在不同模型之间直接比较时会有“单位不一致”的问题。如果要跨模型对比可以额外记录字符吞吐率或者用统一的 tokenizer 做归一化。如果只是同一个模型在不同硬件、不同量化方式、不同推理框架下的对比tok/s/MW 是可靠的因为 tokenizer 保持一致。4. 影响 tok/s/MW 的关键因素4.1 硬件平台GPU 的架构、显存带宽、算力、功耗都会直接影响 tok/s/MW。生成阶段 LLM 通常是访存密集型显存带宽越高token 生成速度越快。而 GPU 功耗又决定了一个机柜能部署多少卡。不同型号的 GPU 在相同模型上可能呈现完全不同的能效排名不能只看峰值算力。CPU 推理也有能效问题。虽然 CPU 绝对吞吐通常不如 GPU但在某些小模型、低并发场景下CPU 的功耗也不高tok/s/W 未必会差太多。关键还是要实测。4.2 模型规模与量化模型参数量越大单 token 生成需要的计算量和访存量越大。在相同硬件上大模型的 tok/s 明显低于小模型这意味着单 token 能耗更高。所以“能不能完成任务”的前提下尽量选择更小的模型是提升能效最直接的手段。量化是另一个有效手段。从 FP16 切到 INT8 或 INT4 后模型权重占用显存变小访存压力降低在支持低精度加速的硬件上吞吐量通常有明显提升。功耗未必同步增加于是 tok/s/MW 会改善。INT4 对能效的提升幅度取决于硬件对低精度计算的支持程度实际收益要以本机测试为准。4.3 批量大小与并发GPU 的功率相对固定但吞吐量会随并发上升。单请求跑一个模型时GPU 大量计算单元可能处于空闲状态tok/s 低tok/s/MW 也低。加入并发请求或启用动态 batching 后GPU 利用率提升在功率没有成倍增加的情况下吞吐量可能上涨数倍tok/s/MW 也就跟着上涨。不过并发不是越高越好。并发超过某个临界点后显存带宽和计算资源饱和吞吐增长放缓甚至因为排队导致延迟恶化。所以测量 tok/s/MW 时最好扫描一组并发参数找到该方案在实际 workload 下的能效高点。4.4 KV Cache 与上下文长度上下文长度对推理能效的影响经常被忽略。长上下文意味着更大的 KV Cache生成每个 token 时需要读写更多的 KV 数据访存压力显著上升。因此一个 2K 上下文的测试结果和一个 32K 上下文的测试结果不能直接对比。评估时应当贴近实际业务场景而不是用短上下文刷漂亮数字。4.5 推理框架与算子优化vLLM、TensorRT-LLM、SGLang、llama.cpp 等框架的调度策略、显存管理、算子实现差异都很大。同样的模型和硬件不同框架的 tok/s 可能差出不少。能效对比必须保持框架版本一致并且明确记录框架的配置参数。5. tok/s/MW 测量流程与功率采集5.1 测量前置条件为了让 tok/s/MW 有意义建议先确定以下条件固定模型文件和 tokenizer。固定量化方式、上下文长度、解码参数。固定测试数据集最好有固定的输入输出长度分布。固定并发数或请求速率。记录驱动版本、CUDA 版本、框架版本。任何一条不统一对比结果都可能失真。更稳妥的做法是专门维护一个标准的“能效测试配置”每次方案调整只改一个变量。5.2 采集吞吐量不同框架有不同的吞吐测试方式。llama.cpp 启动时开启 verbose日志里会输出平均 tok/s。vLLM 提供 benchmark 脚本可以在指定并发和请求数下测试端到端吞吐。无论用哪种方式都要注意区分“首 token 延迟”和“生成阶段吞吐”能效指标用的是平均生成吞吐不是首 token 延迟。一个通用思路固定一组 prompt固定输出 token 长度发送多个请求记录从开始到全部完成的总时间再计算总生成 token 数除以总时间。# 示例用 curl 对一个 OpenAI 兼容的推理服务并发发送请求 # 这里只是流程示意实际 URL、模型名、参数需要按部署环境调整 for i in $(seq 1 20) do curl -s http://127.0.0.1:8000/v1/completions \ -H Content-Type: application/json \ -d { model: your-model, prompt: 写一段关于大模型推理能效的短文。, max_tokens: 256 } done wait5.3 采集功率功率采集建议同时做 GPU 级和整机级两层。GPU 级可以用 NVIDIA DCGM 工具它比nvidia-smi更适合长期采样和批量记录# 每秒采样一次 GPU 功耗、利用率、显存等指标 nvidia-smi dmon -s pcu -d 1如果是整机功耗可以用机柜 PDU、UPS 或高精度功耗仪。采样时长建议覆盖整个吞吐测试过程并去掉预热阶段的数据。最终取平均功率而不是峰值功率。5.4 计算 tok/s/MW把吞吐量和平均功率放到一起就可以计算能效指标。下面是一段可以直接用的 Python 计算示例# 输入通过框架日志得到的吞吐量通过功耗采集得到的平均功率 throughput_tok_per_s 100.0 # 示例值替换为实际测试值 average_power_w 600.0 # 示例值替换为整机或 GPU 层平均功率 # 各能效指标换算 tok_per_w throughput_tok_per_s / average_power_w tok_per_mw throughput_tok_per_s / (average_power_w / 1_000_000) energy_per_token_j average_power_w / throughput_tok_per_s print(f吞吐量: {throughput_tok_per_s:.1f} tok/s) print(f平均功率: {average_power_w:.1f} W) print(f能效: {tok_per_w:.4f} tok/s/W) print(f能效: {tok_per_mw:.1f} tok/s/MW) print(f单 token 能耗: {energy_per_token_j:.2f} J/token)这里的数字只是示例实际值必须替换为真实测量结果。建议同一组测试至少跑 3 到 5 次取中位数或均值并把每次结果记录下来避免单次波动影响判断。5.5 记录对比结果对比方案时建议用表格记录完整环境信息和结果方案模型量化并发平均功率(W)吞吐(tok/s)tok/s/Wtok/s/MWJ/token方案A7BFP168待测待测待测待测待测方案B7BINT48待测待测待测待测待测先记录原始数据再做能效换算。这样发现问题时可以回到原始数据排查。6. 如何优化 LLM 推理能效6.1 先选对模型能效优化的第一步不是调框架参数而是选择合适规模的模型。把一个 70B 模型跑在有限显存上可能因为 offload 导致吞吐骤降能效非常差。换成可用的最小模型或 MoE 模型往往能带来最明显的收益。MoE 模型虽然总参数量大但推理时只激活部分专家单 token 计算量更小单位电力产出可能更高。6.2 合理使用量化在精度可接受的范围内优先尝试 INT8 或 INT4。量化能降低模型权重体积减少访存带宽压力这对生成阶段尤其有效。量化后要重新跑一遍能效测试不能只看模型文件变小就认定能效提升因为部分硬件在低精度计算时并不会降低功耗甚至可能因为额外转换操作导致收益有限。6.3 提升批量与并发尽可能让 GPU 处于高利用率状态。在线服务场景可以使用支持 continuous batching 的推理框架例如 vLLM、TensorRT-LLM、SGLang它们能在请求动态到达时自动拼 batch。在离线批处理场景可以预先组织好批次大小扫描不同 batch size 下的 tok/s/MW取能效最高的配置。6.4 使用编译优化和推理加速方法TensorRT-LLM 和 llama.cpp 等框架支持算子融合、图编译等优化方法可以提高 token 生成速度。在某些场景下这些编译优化还能降低显存占用间接降低整机功耗。部署前值得做一轮对比因为不同模型的优化收益差异很大。6.5 关注显存不足导致的 offload模型或 KV Cache 超过显存容量后推理框架会启用 CPU offload这时吞吐会断崖式下降tok/s/MW 会变差。解决思路包括选择更小模型、开启量化、限制最大上下文长度、使用能更高效管理 KV Cache 的框架。7. 工具生态与工程落地实际工程中tok/s/MW 不能靠手算一次就完事建议纳入监控体系。推理服务本身会暴露吞吐指标GPU 功耗可以通过 DCGM 或节点级 exporter 采集两者按时间对齐后就可以在监控面板中计算实时 tok/s/W 或 tok/s/MW。硬件功耗数据可以来自 NVIDIA DCGM整机功耗则要单独采集。大规模集群通常有带外管理接口或智能 PDU可以直接读取功率。小规模测试可以用nvidia-smi或nvidia-smi dmon临时采样但要意识到它只能覆盖 GPU 功耗不代表整机。这里有几个工程化建议测量脚本和结果记录要版本化方便复现。吞吐量指标和功率指标按相同时间窗口聚合。监控数据保留原始采样值不要只保留聚合后指标。对比方案时固定 PUE 假设并明确记录在报告中。8. 常见问题与排查方法问题现象可能原因排查方式解决方案同一方案多次测量 tok/s 波动很大并发请求不均匀、缓存未预热、测试时间太短增加测试次数去掉前几个请求的数据先预热再取多次运行的中位数功耗读数忽高忽低采样间隔太长没有覆盖完整测试周期缩短采样间隔与吞吐测试时间对齐使用 DCGM 每秒采样或延长测试时长不同框架 tok/s/MW 差距明显算子优化、batching 策略、KV Cache 管理不同检查框架日志和配置参数统一并发与输入长度后重新对比显存足够但吞吐很低上下文过长导致 KV Cache 访存压力大对比短上下文与长上下文测试结果限制上下文长度或升级显存带宽更高硬件计算出的 tok/s/MW 异常偏高或偏低单位换算错误、功率边界不一致核对 W/MW 换算确认功耗是卡级还是整机级统一单位与功耗口径后重新计算量化后吞吐反而下降硬件对低精度计算支持不佳或产生额外转换开销对比不同量化位数的实测结果换成更适合的量化格式或维持原精度并发增大后吞吐不再上升GPU 计算或访存已经饱和扫描不同并发下的吞吐曲线选择吞吐收益最高的并发区间避免队列堆积遇到问题时先回到原始数据吞吐量、平均功率、模型配置、环境版本。最忌讳的是只看最终能效数字却无法解释它为什么变化。9. 最佳实践与使用建议第一先定义清楚“对比口径”。tok/s/MW 只有在相同 workload、相同功率边界下才可比。建议至少在对比记录中写明模型、量化、并发、输入输出 token 长度、功率是 GPU 级还是整机级、PUE 假设。第二不要用单 token 生成速度直接代表系统吞吐。在线服务场景下并发请求的排队和调度会让单请求速度与系统吞吐脱节。能效评估应该用系统级端到端吞吐。第三把 tok/s/MW 和延迟、准确率一起看。能效高不代表体验好。如果方案为了能效牺牲了太多响应速度用户可能无法接受。同样如果量化让输出质量明显下降再高的能效也没有意义。第四真实业务数据要做脱敏。评测和监控过程中如果使用私有业务数据要注意数据安全和隐私保护避免未脱敏数据进入第三方工具或不可控环境。第五做扩容规划时把 PUE 和冷却成本也纳入计算。GPU 卡功耗只是起点数据中心的供电与散热损耗会放大最终成本。用 tok/s/MW 和 PUE 一起算才能得到接近真实情况的数据。第六保持测试脚本和配置文件的版本管理。每一次能效测试都对应一组软件版本和参数不记录版本信息的话后续复现会非常困难。10. 总结与下一步tok/s/MW 是一个把“速度”和“电力成本”放在一起评估的 LLM 推理指标适合用于推理集群的容量规划、硬件选型、量化方案对比和长期服务成本核算。它不替代 tok/s也不替代延迟、准确率指标而是在方案对比时补上“单位电力产出”这个视角。最值得先做的事就是搭建一套标准测试流程固定模型、量化、上下文长度和并发同时采集吞吐量与功率计算 tok/s/MW。最容易踩的坑是功率边界不统一、token 粒度不一致以及直接拿短上下文测试结果代表真实业务场景。后续可以继续扩展的方向包括把 tok/s/MW 接入监控面板实现实时能效观测做不同量化策略和推理框架的组合对比以及结合 PUE 推算数据中心层面的单位 token 成本。这个指标并不复杂但它能帮你把推理评估从“跑得快”推进到“单位电费下产出更多 token”。建议收藏备用下次做推理方案对比时直接套用这套流程。