本地小模型答对 88.7% 真实提问,斯坦福用「每瓦智能」立标尺

Intelligence per Watt: Measuring Intelligence Efficiency of Local AI

Jon Saad-Falcon, Avanika Narayan, Hakki Orhun Akengin, J. Wes Griffin, Herumb Shandilya, Adrian Gamarra Lafuente, Medhya Goel, Rebecca Joseph, Shlok Natarajan, Etash Kumar Guha, Shang Zhu, Ben Athiwaratkun, John Hennessy, Azalia Mirhoseini, Christopher Ré

cs.DC, cs.AI, cs.CL, cs.LG

2025-11-11

提指标「每瓦智能」(准确率÷功耗),测 20+ 小模型×8 硬件×100 万真实提问:本地答对 88.7%,两年能效涨 5.3 倍。

这篇在解决什么

LLM 的提问几乎全交给云端的前沿大模型处理,而需求增长比云厂商扩容的速度更快。OpenAI 的 Stargate 这类超大规模数据中心,就是这种压力的产物。

作者认为另一条路正在打开:20B 激活参数以下的小模型(Qwen3、GPT-OSS、Gemma 3)在很多任务上已经能和前沿模型打平,Apple M4 Max、AMD Ryzen AI 这类本地加速器的显存和算力也够把它们跑到交互延迟内。问题随之变成:本地推理能不能从云端手里分走一部分需求?

要回答这个问题,得同时量两样东西:本地模型答得准不准,本地硬件把电变成有用计算的本事有多大。在此之前的「Green AI」类工作主要在云端 GPU 上测固定任务,没人系统地在本地加速器上、用真实提问分布把这件事测清楚,更没把进步拆成「模型贡献了多少、硬件贡献了多少」。这篇要补的就是这个缺口,顺带给出一个能持续追踪这场迁移的指标。

方法

核心指标很直白:每瓦智能(Intelligence per Watt,IPW)= 任务准确率 ÷ 功率(瓦)。功率这个分母逼着你同时关心「答得对」和「少耗电」,这正是本地推理受功率约束时的核心矛盾。

围绕它定义了一组互补的度量:

为什么要分瓦和焦耳:新硬件既降功耗又降延迟,所以每焦耳的提升往往比每瓦更猛,论文里前者涨到 18 倍,后者 5.3 倍。热约束场景看每瓦,算总账看每焦耳。

几个关键设计选择:

规模:20 多个本地小模型、8 块加速器(A100、H200、GH200、B200、RTX 6000 系列、MI300X、M4 Max、SambaNova SN40L,另加 iPhone 16 Pro 的 A18 Pro)、100 万条真实提问(WildChat 50 万、Natural Reasoning 50 万、MMLU Pro 1.2 万、SuperGPQA 2.65 万)。

结果

把每条 query 路由给最合适的本地模型(best-of-local),本地小模型能答对 88.7% 的单轮聊天和推理提问。单模型则随规模爬升:Qwen3-4B 平均 49.6%,Qwen3-8B 57.5%,Qwen3-14B 60.0%,GPT-OSS-120B 到 71.4%。

维度结果
本地 best-of-local 覆盖率WildChat 97.8% / Natural Reasoning 88.3% / SuperGPQA 77.0% / MMLU Pro 92.4%(其中 3 项超过 best-of-cloud)
聊天 vs 推理聊天 88.9%,推理 64.9%,差 24 个百分点
每瓦智能两年涨幅5.3 倍(模型贡献 3.1 倍,硬件 1.7 倍)
每焦耳涨幅18 倍(模型 3.1 倍,硬件 5.9 倍)
云端单条 query 仍领先B200 比 M4 Max 高 1.40 倍 IPW;SambaNova SN40L 高 1.78 倍 IPW、6.5 到 7.4 倍 IPJ

纵向看:2023 年 Mixtral-8x7B 跑在 Quadro RTX 6000 上,每瓦智能 7.92×10⁻⁴,可解查询 23.2%;2024 年 Llama-3.1-8B 加 RTX 6000 Ada 涨到 1.80×10⁻³(同比 2.27 倍),覆盖率 48.7%;2025 年 GPT-OSS-120B 加 Apple M4 Max 到 4.18×10⁻³(同比 2.32 倍),覆盖率 71.3%。两年的进步是模型和硬件一起堆出来的。

最锋利的反转在路由那一节。本地硬件单条 query 不如云端,但用 80% 准确率的路由器把简单 query 留给本地小模型、难的甩给云端,在 24 小时 8020 万条 query 的模拟里能省下 64.3% 的能耗、61.8% 的算力、59.0% 的成本;完美路由(oracle)的上界是 80.4% / 77.3% / 73.8%。系统级省电不靠本地硬件追上云端,靠的是跨两端路由。

为什么重要

对从业者,该问的不是「本地够不够和云端一样强」,而是「有多大比例的 query 本地能扛」。答案是:用一组多样的小模型加路由,能扛近九成。路由器准确率做到 80% 就能拿到约 80% 的潜在收益,再往上不如去扩本地模型池的多样性,而不是死磕路由精度。

几条可直接拿去用的结论:内存富余的本地设备上 MoE 架构的 IPW 最高;先把模型做大、再激进量化到 FP4(FP16 到 FP4 省 3 到 3.5 倍能耗,每降一档精度掉约 2.5 个百分点),通常比用更小模型保 FP16 更划算;iPhone 这类手机 NPU 在约 12W 下能达到工作站 GPU 约 7 倍的 IPW,轻量 query 是条独立赛道。

要诚实:这是一篇度量与框架论文。88.7% 是从 20 多个模型里挑最好的「best-of-N」上界,不是单个能直接部署的模型(单模型天花板目前是 GPT-OSS-120B 的 71.4%)。真要复现这个覆盖率,得真的跑起一个多模型路由。

局限与存疑

作者自己点了几条:功耗是软件级遥测(NVML、powermetrics、ROCm SMI),误差 10 到 15%,绝对值别太当真;只测了单轮,多轮 agent、工具调用、长上下文没全覆盖(GAIA、TerminalBenchV2 上的扩展说定性结论成立);聊天的对错靠 Qwen3-235B 当 judge,会继承这个裁判模型的偏见;快照停在 2025 年 10 月。

读下来还有两处更该存疑。第一,云端用 bs=1 做对照是保守做法(论文承认 B200 上 bs=64 的 IPJ 高 11 到 20 倍),所以「云端只领先 1.4 倍」其实低估了云端在真实服务场景下的效率,云端的真实优势被压低了。第二,88.7% 这个数把「平局」也算本地答对,而开放式聊天的裁判和参考答案都来自 Qwen3-235B,对和它风格相近的模型有主场优待,真实场景里这个数可能要打折。

术语

原文与代码

社区讨论

相关论文

全部论文解读