全球计算联盟：2026大语言模型系统级单位token能耗测评报告（18页）.pdf

核心结论速览： 选模型比选硬件更重要：Qwen3.5-397B与Llama4-Maverick在相同硬件、相同精度下能耗差距超过3倍——选错模型，再好的硬件也白搭。 换推理引擎是最快的“免费升级”：DeepSeek-V4从vLLM切换到SGLang，能耗降低78%、吞吐提升5.7倍——不换硬件、不改模型，仅换框架就能实现质的飞跃。 批处理大小是能效的“杠杆”：增大batch size可显著降低单位token能耗，合理配置并发的收益甚至超过模型选型本身。 MoE+FP8是当前最能“省电”的技术路线：gpt-oss-120B以0.37 J/token的文本能耗和0.53 J/token的代码能耗，证明“大模型不一定高能耗”。 代码场景是能耗“压力测试”：长提示词的密集预填充使代码场景GPU利用率最高，但也是能耗最高的场景——需要针对性优化。 高GPU利用率≠高能效：Mistral-Medium-3.5利用率高但能效差，gpt-oss-120B利用率低但能效好——能耗优化不能只看利用率。H2：技术负责人最关心的五个问题。问题一：如何用最少的硬件成本支撑大模型推理？核心答案：选对模型架构和推理引擎，比买更多GPU更重要。实证数据：在相同硬件（8×GPU）下，Gemma4-31B（31B Dense）文本能耗仅0.35 J/token，而Qwen3.5-397B（397B MoE）能耗达1.07 J/token——能耗差距超过3倍。更关键的是推理引擎：DeepSeek-V4在vLLM下能耗4.43 J/token，切换至SGLang后降至0.97 J/token——能耗降低78%，意味着在相同硬件上，仅换框架就能多支撑近4倍的推理请求。技术启示： 优先选择能效标杆模型（Gemma4-31B、gpt-oss-120B）。 评估推理引擎适配度（SGLang对部分模型有巨大优势）。 避免“参数崇拜”——大参数≠高能耗。问题二：如何通过配置优化降低推理成本？核心答案：增大batch size是性价比最高的优化手段。实证数据：能耗随batch size增大单调下降，合理配置并发对降低推理成本的收益超过模型选型本身。以Gemma4-31B文本场景为例，TP=2、BS=128是能耗、延迟、利用率三者最均衡的配置区间。TP=2是能效甜点，TP=4因通信开销抵消了计算收益，TP=1在大型batch size下出现能耗反弹——单卡计算能力已经饱和。技术启示： 优先优化batch size配置。 避免过度张量并行（TP=2往往是能效甜点）。 监控能耗反弹信号。问题三：MoE架构真的比Dense架构更省能吗？核心答案：MoE配合低比特量化，能效优势显著。实证数据：gpt-oss-120B（FP8 MoE）文本场景能耗仅0.37 J/token，代码场景0.53 J/token，是MoE+低比特路线的能效标杆。但并非所有MoE都省能——Qwen3.5-397B（FP8 MoE）文本能耗达1.07 J/token，代码场景高达2.18 J/token，跨任务能耗波动剧烈。技术启示： MoE架构省能的前提是“稀疏激活”+“低比特量化”组合。 不同MoE模型的能效差异极大，需实测验证。 Dense架构在中小规模（如31B）下可能更具能效优势。问题四：文本、代码、多模态三类场景的能效优化策略有何不同？场景能耗基线：文本 < 图像 < 代码。代码场景因长提示词的密集预填充，GPU利用率最高但能耗也最高。分场景优化策略：| 场景 | 能效最优模型 | 推荐配置 | J/tok | 优化要点 |||||||| 文本 | Gemma4-31B | TP=2 BS=128 | 0.348 | 小模型+适中并发 || 文本·吞吐 | gpt-oss-120B | TP=8 BS=128 | 0.373 | MoE+高吞吐 || 代码 | gpt-oss-120B | TP=8 BS=128 | 0.535 | 代码场景能效最优 || 代码·吞吐 | MiniMax-REAP | TP=8 BS=256 | 0.864 | 180 tok/s吞吐登顶 || 多模态 | Gemma4-31B | TP=2 BS=128 | 0.467 | 多模态能效最优 || 多模态·吞吐 | Llama4-Maverick | TP=8 | — | 3365 tok/s第一 |问题五：推理引擎如何选择？vLLM和SGLang哪个更好？核心答案：没有“更好”，只有“更适配”。实证数据：DeepSeek-V4在vLLM和SGLang上的表现差异说明了一切——同一模型、同一硬件，换引擎后的能效差距高达5.7倍吞吐、78%能耗。选择建议： 优先选择官方推荐或社区验证适配的引擎。 对主要使用的模型进行引擎对比测试。 关注引擎对MoE、量化等新特性的支持程度。H2：部署优化速查表。| 优化维度 | 关键参数 | 推荐值 | 预期收益 ||||||| 模型选型 | — | Gemma4-31B/gpt-oss-120B | 能耗降低3倍+ || 推理引擎 | — | 按模型适配选择 | 吞吐提升2-6倍 || 张量并行 | TP | 2-4（避免过大）| 能效甜点 || 批处理大小 | BS | 128-256 | 能耗持续下降 || 精度格式 | — | FP8（MoE优先）| 能效显著提升 |H2：与团队沟通的关键信息。关于选型决策：“传统思维是‘选最强的模型配最好的硬件’。但实测数据显示，在相同硬件下模型间能耗差距可达3倍以上——选对模型，每年可能节省数百万电费。”。关于推理引擎：“同样的模型、同样的硬件，换一个推理引擎能效差5.7倍。这是最容易实现、成本最低的优化——不需要采购新硬件，不需要重新训练模型，只需要升级框架。”。关于资源配置：“很多团队习惯把batch size设成默认值。但能耗随batch size增大单调下降，合理调整并发配置可能是投入产出比最高的优化手段——收益甚至超过模型选型本身。”。延伸阅读。以上为报告核心内容，如需获取完整评测数据、各模型详细配置及生产部署建议，请访问下载页下载完整PDF报告。FAQ。Q1：报告中的能耗数据是在什么硬件环境下测的？A1：所有测评在统一GPU环境下完成，具体硬件配置详见报告原文。Q2：J/token这个指标在实践中有多重要？A2：J/token是衡量推理能效的核心指标。每百万token推理电费可达1.4元，占API定价的7%-28%。在大规模部署中，J/token直接决定了运营成本和利润率。Q3：为什么代码场景能耗普遍高于文本场景？A3：代码场景的输入通常包含长提示词，需要密集的预填充计算（Prefill），使GPU得到更充分利用，因此能耗整体高于文本场景。Q4：多模态场景的能耗特征有什么特殊之处？A4：多模态场景存在视觉解码瓶颈，能耗普遍偏高。Mistral-Med-3.5在多模态场景能耗高达2.28 J/token，是三场景中能耗最高的。Q5：如何获取报告中的完整评测数据？A5：完整数据包含在《大语言模型系统级单位token能耗测评》完整PDF中，可访问下载页获取。数据来源说明。本页面所有数据均基于清华大学电机工程与应用电子技术系信息能源实验室、清华四川能源互联网研究院信息能源与绿色智算技术研究所联合编制的《大语言模型系统级单位token能耗测评》报告。