全球首发！OAII社区甩出测评“硬指标”
大模型终于要“算账”了！
7月3日，在全球计算联盟（GCC）指导，Open AI Infra社区主办、益企研究院协办的"超节点与 GW 级 AIDC 技术论坛暨 Open AI Infra 社区半年工作会议"在京举办，全球首发业内首份《大模型系统级单位Token能耗评测》报告。该成果首次实现了Token级焦耳能耗的精准测量，填补了大模型能效精细化评估的空白。
报告覆盖多类业务场景、主流大模型完成全维度推理能效实测，填补行业细粒度 AI 能耗评测空白，为产业科学选型、算力低碳部署提供标准化评测依据。
清华大学新型电力系统运行与控制全国重点实验室助理研究员 周杨林博士
本次测评报告由清华大学电机工程与应用电子技术系信息能源实验室、清华四川能源互联网研究院信息能源与绿色智算技术研究所、新型电力系统运行与控制全国重点实验室电化学储能高效集成与控制团队联合牵头编制，Linux基金会研究部门和SODA基金会提供开放协作生态系统支持。报告内容同步覆盖信息科技与能源系统两大研究方向，属于两大领域交叉融合类课题，报告聚焦大模型系统级单位Token能耗焦耳级能耗测评与能效评估。
AI 算力发展新趋势：竞争重心从能力模型转向算力能效
伴随大语言模型产业规模快速扩张，AI 算力能耗问题逐步成为行业核心关注焦点。大模型完整运行高度依赖电力配套基础设施，算力硬件性能持续迭代升级的背景下，AI算力能耗约束已成为限制 AI 产业规模化发展的关键瓶颈。
AI算力能耗指标现已成为大模型技术体系不可或缺的核心评估维度，未来人工智能行业的竞争，将不再局限于模型综合能力层面，模型运行能效、全生命周期可持续性将成为核心竞争赛道。
当前行业在大模型筛选、落地适配环节普遍存在三大核心痛点，构成产业选型三重困境：
2、榜单局限：当前主流大模型评测榜单仅面向模型输出能力开展评估，未纳入硬件适配能力、部署综合成本、能源可持续性等关键指标，可以说现有的榜单，只反映“能力上限”，不代表“部署效果”。
3、场景复杂：现有的通用综合性大模型，多模态模型适配场景覆盖范围广，但不同业务场景负载特征存在明显差异，对应最优软硬件组合方案互不相同，通用评测结果无法适配细分场景需求。
大模型推理能效系统整体定位
对比行业内已有大模型评测工具，本次研究评测维度包括硬件实测、能耗评测、B端选型、调度能力等维度，突破过去单一维度比较的局限，实现业务驱动的决策优化。
研究目标构建四层闭环结构，从模型评测的标准化，到大模型能效排行，到硬件场景匹配和智能调度，再反馈到算法/框架/硬件优化，不断地迭代优化和完善模型的评测体系，实现从“哪个模型能力最强”到“哪个组合最适合业务”。
大语言模型推理能效系统的评测方法论
本次评测体系构建了指标、场景和模型三大维度完整评测框架：
1、确定五项核心指标：每Token消耗焦耳量、硬件GPU利用率、TTFT（首Token延迟）、TPOT（解码速度）和 Throughput（系统整体吞吐）。
2、评测涵盖三类实际场景：通用文本聊天、代码补全、多模态图像问答。
3、评测涵盖八大主流模型：Gemma 4 31B，它适用于文本、代码、图像；千问 3.5 397B-A17B，Llama 4 Maverick，MiniMax-M2.7 Reap，DeepSeek-V4-Flash，MiMo-V2-Flash，Mistral-Medium-3.5-128B，以及 GPT-OSS-120B。
测试环境和规范测试流程如下：
1、硬件底座：在统一测试环境采用了8卡的英伟达硬件设施平台，
2、软件技术栈：软件协议栈采用ml-energy/benchmark 3.0 框架，vLLM 0.19.1 作为推理引擎，Zeus 0.13.1为能耗测量库，Prometheus+vLLM/metrics 作为运行时观测，Transformers 5.5.4 实现单Token 能耗数据可视化输出。
规范测试流程包括8个环节：下载模型+HF cache准备、启动 vLLM Docker容器、等待/health就绪、开启Zeus能耗监测平台、并发发送256/1024请求、Prometheus旁路采样、结果产出、回填元数据。
所有测试循环执行，取多次测试均值作为最终有效数据。
系统级单Token能耗评测总览
能效方面，
（1）Gemma4-31B是全局冠军（文本0.35 J/Token、代码0.47 J/Token 、多模态0.84 J/Token），三场景均衡稳定；
（2）gpt-oss-120B借助MoE+FP8将文本能耗压至0.37 J/Token，能效与吞吐兼顾；
（3）Qwen3.5-397B能耗高达1.07 J/Token和2.18 J/Token，波动剧烈，大MoE在不匹配场景下浪费严重；
（4）DeepSeek-V4换SGLang框架后吞吐提升5.7倍，代码能耗降至1.92 J/Token，证明软件优化价值；
（5）多模态方面Llama4-Maverick最优（0.86 J/Token），而Mistral-Med-3.5的2.28暴露视觉解码瓶颈。
总体而言，文本任务Gemma与gpt-oss领先；代码任务MiniMax-M2.7能耗0.86 J/Token但吞吐达4300 tok/s，适合速度优先场景；多模态Llama与Gemma接近。
场景负载决定能耗基线：文本 <图像> <代码；>
同一模型跨场景差异巨大：稳定型（Gemma/gpt-oss/Llama）三场景均衡，特长型（Qwen/Mistral）仅适配套餐场景。
选型速查：通用节能选Gemma4-31B；纯文本高吞吐选gpt-oss-120B；多模态选Llama4-Maverick；极速代码选MiniMax-M2.7；DeepSeek-V4适配SGLang后潜力可期。
热力图揭示能耗规律
热力图揭示了大模型推理能耗的三条核心规律。
第一，批处理大小是能效的第一驱动力。随着批处理从bs=8提升到bs=128，所有模型能耗均单调下降，gpt-oss降幅超过5倍。合理配置并发、攒批处理的收益，往往超过模型选型本身，这是最容易被忽视的"免费午餐"。
第二，同硬件条件下模型间能耗差距可达3倍以上。文本场景bs=128时，gpt-oss仅需0.37焦耳，而Qwen3.5-397B高达1.07焦耳，硬件相同、精度相同，能耗却相差近3倍。选对模型，同等投入下吞吐量可以翻倍。
第三，MoE加低比特量化是当前最优能效路线。gpt-oss-120B采用MoE架构配合低精度，三场景能耗均最低，甚至优于参数量更小的Mistral，证明稀疏激活加低比特在能效与吞吐之间取得了最佳平衡。
多模态场景数据有限，但Llama4与Mistral的能耗差距超过一倍，说明多模态能效优化空间依然巨大。
总结就三句话：攒批处理、选对模型、走MoE加低比特路线。
GPU 利用率与 TPOT：能耗之外的权衡
在能耗之外，发现GPU利用率与能效之间的三个反直觉规律。
第一，批处理大小对利用率影响有限。无论批处理从8涨到128，各模型利用率提升普遍只有5到15个百分点，远不如对能耗的影响显著。gpt-oss利用率始终卡在33%到42%，几乎是一条横线，说明计算单元根本喂不饱，推理实现卡在显存带宽上。
第二，场景对利用率影响更大。代码场景的GPU利用率普遍比文本高5到10个百分点，因为长提示词会产生密集的预填充计算，让GPU持续忙碌，而短文本更像"脉冲式"负载，频繁空闲等待。
第三，也是最反直觉的一条：高利用率≠高能效。gpt-oss利用率最低，仅40%出头，但能效却是全场最佳；Mistral利用率冲到80%以上，能效却最差。利用率高只说明硬件在跑，不代表跑得聪明。有的模型在高效计算，有的在大量空转。
总结就三句话：批处理提利用率效果有限，长文本更压榨GPU，但利用率高不等于节能，关键看计算效率。
聚焦TPOT，即每生成一个Token的延迟，直接决定用户体验。核心发现同样有三条。
第一，能耗与延迟天然对立。批处理从8增至128，所有模型TPOT均持续上升。gpt-oss从8毫秒涨到21毫秒，因为攒批省电的同时带来了资源争用。省电还是保体验，必须二选一。
第二，代码高并发是延迟试金石。低并发时各场景差异不大，但bs=128时，Qwen3.5-397B在代码场景飙至83毫秒，比文本同期的35毫秒恶化一倍多，说明长上下文任务在高并发下压力被急剧放大。
第三，框架成熟度决定延迟基线。DeepSeek-V4-Flash在bs=8时仅8毫秒，与gpt-oss并列最快，印证了SGLang的优化价值。而Qwen3.5-397B即使低并发也需11毫秒，bs=128时代码场景飙至83毫秒，从14到83暴涨近6倍，框架适配明显不足。
总结三句话：能耗和延迟不可兼得；代码高并发暴露模型短板；框架优化比模型本身更影响响应速度。选型速查：追求极致低延迟选DeepSeek-V4或gpt-oss；均衡吞吐与延迟选gpt-oss；Qwen3.5-397B除非对延迟完全不敏感，否则慎用。
Gemma深度分析：小模型的能效标杆
单独分析全局能效冠军Gemma4-31B的最优部署配置，核心结论就一条：TP=2是能效甜点，过度分卡适得其反。
能耗图上，TP=2在bs=64时仅需0.51焦耳，全场最低；TP=4不仅没更低，反而因通信开销能耗更高；TP=1在大批处理下能耗反弹，说明单卡算力已经饱和。
利用率图更直观，TP=2时GPU跑满99%到100%，TP=4时反而跌到33%左右。31B的小模型根本用不了那么多卡，分多了纯属浪费。
延迟图上，TP增加能降低延迟，批处理增大会推高延迟，两者作用相反，需要在中间找平衡。
部署建议很清晰：文本聊天场景下，TP取2或4，批处理取64或128，是能耗、延迟、利用率三者最均衡的配置区间。
总结一句话：小模型不需要大集群，TP=2就能喂饱GPU且能效最优，盲目加卡既不省电也不提速。
DeepSeek深度分析：推理引擎对能效的影响
分析得出推理引擎对大模型能效存在影响。
在相同DeepSeek模型下，我们仅将推理引擎由vLLM更换为SGLang，结果显示系统性能得到大幅提升。
左侧实验结果可以看到，随着 Batch Size 增大，SGLang始终保持更高吞吐、更低时延和更低能耗，在性能与能效之间实现了更优的 Pareto 最优。
右侧统计数据显示，在BS=128时，文本场景吞吐率提升5.7倍，单位Token能耗降低78%，TPOT降低85%；代码场景吞吐率提升2.5倍，能耗降低32%，TPOT降低87%。
这说明，同一模型，换一个推理引擎，就能获得完全不同的系统表现。推理框架对整体能效的影响，甚至可能超过模型架构本身。因此，大模型性能优化不能只关注模型算法，更要重视模型、推理框架与硬件平台的协同优化，实现系统级能效提升。
从评测到落地：电费映射+生产选型
将模型能效映射为可感知的运营成本，即单位 Token 电费 = 单位 Token 能耗 × 电价 × 数据中心 PUE，实现从技术指标到业务成本的直接转换。
基于这一指标，针对不同业务场景给出了生产环境的推荐方案。例如，文本和图像能效优先推荐 Gemma4-31B，单位能耗最低；文本和代码吞吐优先推荐 GPT-OSS-120B 和 MiniMax-REAP，在保证能效的同时实现更高吞吐。
最后，我们总结了生产部署的三个原则：第一，场景决定模型，避免盲目追求大模型；第二，配置决定效率，合理选择并行策略和 Batch Size；第三，框架决定最终表现，优先选择成熟稳定的推理框架。
核心观点是：能效评测的价值不仅在于比较模型，更在于指导生产选型，实现性能、成本和部署效率的综合最优。
技术前瞻：Token 级能耗测量体系
现有基于 NVML 等软件接口的能耗监测，受采样频率和系统延迟限制，难以捕获 Token 级瞬时能耗变化，也无法准确关联能耗与计算任务。
为此，我们设计了高精度硬件能耗测量平台，在芯片供电轨道进行侵入式测量，实现1 kHz 实时采样，结合时间标定提取Token 级能耗特征，并已在RK3588 边缘计算平台完成验证。
该硬件测试平台的核心目标是实现Token级能耗的精准定位，为模型优化、推理调度和系统能效分析提供更精细的数据支撑。
大语言模型推理能效系统的未来展望
未来，我们的长期目标为完善可持续算力基础设施体系，搭建算力精准供电架构，配套双向储能能量缓冲单元；在此基础上实现电力资源与算力资源协同调度，完成算子粒度的任务编排、算力动态分配，全面落地算电协同体系。欢迎Open AI Infra社区伙伴及产业界同仁加入，共同推动 AI 算力产业绿色可持续发展。