全球首发！OAII社区甩出测评“硬指标”

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