部署本地大模型的朋友都有一个共同的痛点跑起来不难难的是怎么选硬件、怎么评估这台机器到底够不够用。看参数的时候TOPS、TFLOPS 一堆数字堆在那里等模型真跑起来该卡还是卡。最近斯坦福和 Together AI 联合提出的 Intelligence per Watt每瓦智能指标就是冲着这个痛点去的。这套度量方式把“本地 AI 能效”从纸面参数拉回到了真实任务场景对我来说它解决了一个困扰很久的困惑本地 AI 部署到底应该用什么标准来衡量性能。先说结论Intelligence per Watt 的核心思想不是看硬件能跑多少 T 算力而是看单位功耗下模型完成了多少有效智能输出。这个思路对于做本地 AI 部署、内网 AI Agent、边缘设备推理的朋友来说特别有价值它直接关系到硬件选型和成本评估。1. 为什么需要一套新的能效标尺1.1 本地 AI 部署的兴起带来的痛点这两年本地 AI 部署的热度明显上来了。从个人开发者在自己工作站上跑开源大模型到企业内部在内网搭建 AI 工作台再到边缘设备上做推理大家都在把 AI 能力往本地迁移。原因也不复杂数据隐私、延迟控制、长期成本这些诉求靠云端 API 很难完全满足。但本地部署有个绕不开的问题怎么衡量机器干得好不好。以前我们习惯了看云端 GPU 的规格表觉得显存越大、算力越高就越强。可真到了本地部署场景你会发现这套逻辑不太对。本地环境里功耗是有上限的散热是有限的尤其是工作站或者边缘设备不可能像数据中心那样无限堆硬件。这种情况下单纯算力高不代表体验好功耗、热量、性能之间的平衡才是关键。1.2 传统算力指标TOPS/TFLOPS的局限性传统上衡量 AI 硬件性能大家最常看的就是 TOPS每秒万亿次操作和 TFLOPS每秒万亿次浮点运算。笔记本厂商宣传 AI PC 的时候动不动就报一个 NPU 的 TOPS 数字看起来挺唬人。但实际部署过模型的人都知道这些数字和真实体验之间差距很大。问题出在哪儿呢TOPS 和 TFLOPS 都只是理论峰值算力它衡量的是硬件在理想条件下每秒钟能执行多少次运算。但真实跑模型的时候影响性能的因素太多了内存带宽够不够、显存容量撑不撑得住、算子优化好不好、量化策略合不合理。峰值算力再高只要有一个环节拖后腿实际速度就上不去。更关键的是这两个指标完全没考虑功耗。一块 300W 的显卡跑出 100 TOPS和一块 30W 的芯片跑出 20 TOPS从 TOPS 上看前者碾压后者但从能效上看后者的效率反而更高。1.3 从“跑分”到“干活”的转变斯坦福和 Together AI 提出 Intelligence per Watt本质上是在推动一个转变别再看“跑分”了来看看“干活”的能力。跑分衡量的是一种抽象的计算能力而干活关注的是实际完成的任务。对本地 AI 部署来说你真正关心的是这块硬件能跑多大的模型、每秒钟能处理多少 token、回答的质量怎么样、整体耗了多少电。Intelligence per Watt 的思路就是把“智能”和“功耗”结合起来看。它不再问“这块芯片算力有多强”而是问“每瓦特电能能换来多少智能输出”。这个视角特别适合本地部署场景因为功耗在本地环境里往往是硬约束。我还注意到这套指标在设计上其实是在向计算机体系结构领域的传统靠拢。多年前大家评价 CPU 就经历过从只看“频率越高越好”到“性能每瓦特”的演进。今天做 AI 推理芯片也走到了相似的路口。2. Intelligence per Watt 到底在衡量什么2.1 指标名字的拆分理解Intelligence per Watt字面意思就是“每瓦特智能”。拆开来看有两个部分Intelligence 代表智能也就是模型实际输出的有效信息量Watt 代表功耗也就是完成这些输出消耗的能量。把两者相除得到的比值就是这套指标的数值。关键是怎么理解 Intelligence 这个词。这里说的智能不是指硬件能力而是指模型在真实任务中的表现。它可能是回答问题的准确率、推理任务的完成质量、代码生成的正确性甚至是综合多种评估基准的综合得分。换句话说这个指标衡量的是单位耗电下你实际获得的“智慧成果”有多少。用生活化的类比来说以前评价一款车只看发动机最大马力。马力大的车就一定适合你吗未必。还要看它的油耗、百公里加速、实际载重能力。Intelligence per Watt 就相当于把驾驶体验和油耗结合起来算出一个“每升油能跑出多少实际驾驶乐趣”的指标。2.2 如何量化“智能输出”量化智能输出不是件容易的事。当前业界比较常见的做法是用一套综合评测基准的结果作为“智能得分”再除以推理过程中消耗的总能量。具体来说这个流程可以分为三步在目标硬件上运行一组标准评测任务比如 MMLU、HumanEval、GSM8K 这类常见基准记录整个推理过程中设备的实际功耗这里不是看 TDP热设计功耗而是要实测因为实际功耗和标称值往往差很多将评测得分与功耗相除得到 Intelligence per Watt 的数值。在实际实现上计算过程大致可以表示为IPW 基准评测得分 ÷ 总能耗。总能耗的单位是焦耳也就是平均功耗乘以运行时间。得出来的数值越高说明单位电能产生的智能价值越大。2.3 从评估视角看与能耗参数的结合我看了一些公开讨论这套指标的计算并不是简单粗暴地把一个单任务得分除以功耗。它更强调系统性评估考虑不同任务的差异和权重。比如一个模型在代码生成任务上表现很好但在数学推理上表现一般那它的“综合智能得分”应该把这些维度都包含进去。这样计算出来的 Intelligence per Watt 才是有参考价值的因为它反映的是实际使用中的综合表现而不是某一项特定能力。这里还需要注意一个细节Intel科学界对这个指标的共识是同一颗芯片跑不同模型的效率不一样同一个模型在不同硬件上的能效也不一样。所以 Intelligence per Watt 并不是一个只由硬件决定的固定属性它更像是硬件和模型共同作用的结果。这一点和我们做本地部署时的实际体验是一致的同一台机器跑经过量化的 4-bit 模型和跑全精度的原始模型能效表现完全不同。提示如果你要用这套指标来评估自己的部署环境不要把注意力全放在硬件规格上。模型量化、推理框架的优化程度、批处理设置这些软件层面的因素对最终能效的影响可能比硬件本身还要大。3. 面向本地 AI 场景的落地应用观察3.1 硬件选型时怎么用这个指标本地部署 AI 第一步就是选硬件。以前大家问的问题是“这块卡能跑多少 TOPS”以后值得换个问法“每瓦特能换多少智能输出”。举个例子你想在办公室部署一台本地 AI 工作站用于内部知识库问答和文档处理。如果只看 TOPS你可能会选一块功耗 300W 的专业显卡。但如果用 Intelligence per Watt 的思路来算一笔账这块 300W 的卡跑知识库问答任务每小时耗电 0.3 度全年 365 天不间断运行光电费就一千多块这还没算散热和空调的成本。而一块 100W 级别的芯片如果经过优化每瓦智能输出更高可能用四分之一的电就完成了大部分日常任务。虽然部分极端任务需要的时间长一点但综合能效反而是方案一的好几倍。3.2 提示词场景下的能效权衡仔细想一下本地 AI 的典型使用场景能效取舍会直接影响体验。我把常见场景按对 Intelligence per Watt 的敏感度做了一个分类场景典型负载能效敏感原因更好的衡量重点个人开发调试代码生成、解释开发机常开电费日积月累Token 数/瓦时企业内网知识库文档问答、检索增强生成并发请求多功耗直接影响成本高质量回答/瓦时边缘设备推理音频转文字、实时翻译设备散热和续航受限响应次数/瓦时数据敏感场景私有数据训练、微调长时间高负载需控制机柜功耗训练进度/瓦时以“内网本地 AI Agent 免费”这个热词为例很多人想在内网搭建一个完全本地运行的智能助手。这种场景下功耗往往是隐形成本。一个 Agent 会频繁调用模型做推理如果每瓦智能效率不高即使硬件本身免费长期的电费和散热管理成本也会让你头疼。3.3 模型选择与量化策略的调整Intelligence per Watt 这个指标其实也在倒逼我们在模型选择上做更精细的权衡。以前选模型只看“能不能跑得动”现在可以更理性地看“单位能耗下能获得多少智能”。实际操作下来我经验是先锁定任务类型和精度要求再去考察模型在这个硬件上的能效表现。比如同样是 7B 参数级别的模型有的模型在特定推理框架下做了算子融合和内存优化跑起来又快又省电有的模型虽然精度稍高但推理耗时翻倍能效往下掉了不少。量化策略对 Intelligence per Watt 的影响特别明显。4-bit 量化后的模型体积只有原版的四分之一左右推理时显存占用小、带宽需求低很多时候速度和能效都有显著提升。代价是精度上会有轻微损失但在知识库问答、文本分类这类任务上这种损失完全在可接受范围内。注意量化不是越低越好。我试过把模型压到 2-bit虽然显存需求进一步降低但有些场景下回答质量下降得厉害算出来的每瓦智能反而变低了。这个“拐点效应”很值得关注找到精度与功耗之间的最优平衡点就是实战中的核心功课。4. 实战视角怎样用每瓦智能指导本地部署4.1 自己动手做一次能效实测的完整过程说起“本地部署 AI”很多人的第一反应是装环境、下模型、跑 demo这些基础操作并不难难的是量化评估到底好不好用。基于 Intelligence per Watt 的思路我整理了一套自己实测本地 AI 能效的流程供大家参考确定基准任务集不要只测一个任务选 3 到 5 类典型任务比如文本摘要、知识问答、代码补全、内容分类。每类准备一组固定输入保证多次测试的输入完全一致。接入功耗测量工具有条件的话用带功耗监测的插座或者直接用系统级工具读取设备实时功耗。Intel 平台可以看 RAPL 接口的能耗数据NVIDIA 显卡可以用 nvidia-smi 的功耗字段来记录。跑通全套流程先做预热让设备进入稳定状态再跑测试集。记录每个任务从输入到输出完整生成的耗电量和耗时同时记录输出的质量评分。计算每瓦智能得分用质量评分可以自己定义评分规则比如回答正确率、语义相似度等除以总能耗得到该硬件加模型组合下的能效得分。在自己实测过程中我发现很多之前忽略的细节会影响结果比如 CPU 和 GPU 的协同调度、推理框架的线程数设置、甚至 BIOS 里的功耗策略。这些都说明能效是一个系统层面的属性单纯换个显卡或换个大模型可能都优化不了多少。4.2 推理框架和部署配置的影响推理框架的选型直接决定了 Intelligence per Watt 的最终表现。我用同一个模型、同一块硬件做过对比测试不同推理框架的每瓦智能输出差距相当显著。某些框架在算子融合、KV Cache 量化、连续批处理上做了大量优化推理速度和能效都明显领先。部署配置里批处理大小batch size是影响能效的关键参数之一。本地部署中很多人习惯一次只发一个请求也就是 batch size 为 1。这种模式延迟好看但硬件利用率很低。如果能把多个请求攒在一起做动态批处理显卡的计算单元能更充分地调度起来虽然单次响应时间可能略增但整体吞吐量和能效都会有明显提升。单请求模式延迟低、吞吐低、能效差适合交互式聊天场景动态批处理延迟略增、吞吐高、能效好适合内网知识库、批量文档处理这类高并发场景持续批处理延迟和吞吐兼顾能效最优但实现复杂度偏高。我之前给一个客户做内网 AI 工作台部署时就遇到过类似的问题。一开始所有请求都是直接发给模型显卡利用率徘徊在 20% 左右功耗却不低。后来在推理层做了请求排队和微批处理同样一块卡每天能处理的请求量翻了一番单位能耗降到了原来的六成。这就是每瓦智能思维在实际项目里的价值体现。4.3 内网环境下的能效优化注意事项在“内网 本地 AI Agent 免费”这类需求中很多人只关注功能实现忽略了一个实际问题长期运行的功耗成本。内网服务是 7×24 小时跑的一年下来电费消耗相当可观。用每瓦智能的思路来审视内网部署方案有几个值得关注的地方模型裁剪方面内网知识库问答场景通常不需要超大模型7B 或 13B 参数级别的模型经过量化后效果和速度往往是最平衡的点。再大的模型虽然理论上聪明一点但推理延迟和功耗都会上来性价比反而不高。推理缓存方面高频重复的问题没必要每次都走完整推理流程。在模型前面加一层语义缓存完全一样或高度相似的问题直接返回历史答案能省掉大量无效计算。硬件加速方面在预算允许的情况下加一块低功耗 NPU 会比长时间占用 GPU 更划算。某些设备上的 NPU 跑特定任务时每瓦性能比独立显卡高出好几倍。不过要注意NPU 的兼容性不如 GPU 灵活部署前要先确认模型和框架是否支持。我踩过的坑之前在内网部署本地 AI 时没有把“知识库检索 模型生成”这条链路做能耗拆分一直以为是模型本身太费电。后来逐个环节测功耗才发现知识库向量检索这一环节在并发高的时候也会吃掉不小的功耗。优化了嵌入模型的批处理策略之后整条链路的能效才真正上来。5. 关于 Intelligence per Watt 指标的使用策略与行业影响5.1 指标设计背后的生态博弈从行业层面来看Intelligence per Watt 的提出并非单纯的学术讨论背后是 AI 计算生态走向分化的信号。传统 GPU 巨头们在数据中心领域有绝对优势功耗高但算力绝对强。但在边缘计算和本地 AI 场景中功耗敏感度完全不同新的芯片玩家需要在功耗和智能输出之间找平衡。对芯片厂商来说这个指标体系会带来明显的产品导向变化。以后芯片设计的 KPI 可能会从“提升峰值算力”转向“优化单位功耗下的有效智能输出”。软件栈的优化也会从“跑得快”转向“在同等功耗下跑出更聪明的结果”。这种思路在 AI PC、边缘服务器、嵌入式设备这类场景中尤其重要。对模型开发者来说这就不是一个无所谓的信号了。以后评测模型时除了看精度和速度可能还要关注模型在常见硬件上的能效表现。模型压缩、蒸馏、量化技术的重要性会进一步提升因为这些技术直接影响每瓦智能的数值。5.2 已有测试平台与评估方法的参考业界已经有一些工具和协议在做类似的努力。MLCommons 的 MLPerf 推理基准测试就包含功耗测量部分它要求测试方在跑推理的同时记录系统总功耗。HEBench 这个项目专注于异构边缘计算的能效评估和 Intelligence per Watt 的出发点有不少重合。把这些已有的评估实践放在一起看会发现一个共同趋势大家都在从“性能优先”转向“性能和效率并重”。这不只是学术界在推动而是产业界在本地部署实践中碰到了成本瓶颈倒逼出来的需求。5.3 从指标到实践的落地建议说了这么多如果你正准备做一次本地 AI 部署我建议你从以下三个方面把 Intelligence per Watt 的思路真正落地先把评估体系建立起来。不做评估就开始部署方案就如同不看路就开车。定好任务的基准集选定功耗测量的工具在决定方案前做一轮详尽的能效摸底。把原有思路从“选最强硬件”转变到“选最合适组合”。智能时代的硬件选型不再只看芯片规格表而是看“硬件 模型 框架 量化策略”这个组合的最终能效。最强单卡不一定是最优选择一晚耗电的优雅组合可能才是答案。No matter 是什么规模的项目都有必要建立一个持续监控机制。本地部署不是一次性的模型会更新、数据会增长、使用模式会变化。通过持续记录功耗、延迟、吞吐和输出质量你能及时发现自己部署环境里的能效变化在问题恶化之前做出调整。6. 也谈谈这套指标的局限与完善方向6.1 智能量化的主观性很难回避Intelligence per Watt 虽然提供了更符合实际需求的评估方向但 Challenge 也真实存在。最大争议在于 “Intelligence” 的度量标准很难统一。不同任务对“智能”的定义不同代码生成看重正确性对话系统看重连贯性RAG 系统看重检索相关性。用一套固定基准让所有场景通用本身就有理想化色彩。实际的操作中我的经验是用一套主基准加一套场景定制基准的组合。主基准用于对比不同硬件方案之间的基础差距定制的场景基准用于验证自己的核心业务是否达标。两者结合比只用一个固定指标可靠得多。6.2 场景差异与“怎么用”的适配难度即使在同一台设备上Intelligence per Watt 也会因为使用方式不同而出现很大波动。连续对话的能耗和单次短问答完全不是一回事长文档处理的能耗和短文本生成也不在一个量级。在对指标做实测时如果场景定义不清晰数据就会失真。为了规避这个坑我的习惯是在评估方案时始终保持一致的测试流程同样的提示词列表、同样的并发模式、同样的模型配置、同样的样本数量。只有变量单一测出来的每瓦智能才有横向比较的价值。另外还有一个值得注意的倾向如果要拿 Intelligence per Watt 做产品宣传要尽量避免“这个数字越高越好”的说法。因为实际使用中不同任务对延迟和质量的敏感度不同单纯追求每瓦智能数值最大化不一定能带来最好的用户体验。作为工程实践的参考维度它很出色但作为唯一的决策指标还需要配合延迟、精度等传统指标一起看。6.3 未来评估框架的迭代方向从我观察到的情况看Intelligence per Watt 这类指标未来大概率会往更细的方向迭代。比如区分训练场景和推理场景、区分不同模态任务、区分交互延迟敏感型任务和吞吐敏感型任务。也可能出现专门针对 CPU 推理、NPU 推理的分支标准让不同硬件各有适合自己的能效参考体系。对我个人而言这套指标的更大价值不在于它给出了一个完美的数字而在于它提醒了所有做本地 AI 的人是时候用系统工程眼光来看待部署了。硬件、模型、框架、数据、功耗这些要素共同构成了真实的系统性能单看哪一块都是盲人摸象。这些年做各种本地部署项目的过程中我逐渐意识到能效评估从来都不只是学术问题它直接关系到方案的落地成本。早期部署本地 AI很多团队只看显存够不够大、推理速度快不快结果项目上线后才发现功耗超预期、散热跟不上、电费负担重。Intelligence per Watt 的思想如果能普及开来应该能帮不少人少走这些弯路。最后分享一个心得指标永远是为决策服务的不要因为一个新指标出来就全盘推翻以前的评估习惯。最好的方式是把每瓦智能和延迟、吞吐、精度这些维度放在一起看把多维度信息结合成一个整体框架来决策这样选出来的方案才是经得起折腾的方案。