AI智能体本地运行耗电实测：从功耗估算到降耗优化

如果你也在跑AI智能体，大概率被问过这样一句话：“你小子天天挂个模型，电费是不是爆炸了？”说实话，我第一次被问住的时候真答不上来。后来我花了几周时间把本地智能体耗电量这件事系统测了一遍，才发现网上主流回答几乎都简化过头：有人直接报显卡TDP，有人说7B模型一小时一度电，还有人说用API最省电因为电费在别人那里。这些说法要么没测到底，要么是错的。这篇文章放上我自己的实测数据，把AI智能体的耗电量拆开看：电从哪耗掉的、怎么在任务和待机之间分配、怎么用一台几十块钱的功耗仪估算出“跑一个任务多少度电、跑一天多少度电”，以及估算完怎么把电费压下来。适合正在跑Ollama、Dify、LangGraph这类智能体项目的人参考，也适合想评估“本地 vs API”哪个更划算的开发者。

1. 为什么智能体耗电不能只看显卡TDP

1.1 一个典型的误判场景

社区里经常有人问：“我准备在本地跑一个8B模型做Agent，需要多大电源？每天多少度电？”热心群众秒回：看显卡TDP，比如60W或者120W，然后乘以24小时。这个算法问题很大。显卡TDP是散热设计功耗，表示散热系统需要应对的极限能力，不是实际功率。实际跑推理时，显卡功耗通常在TDP的60%到90%浮动，而且智能体不是一直跑推理的。更关键的是，机器里又不是只有显卡在耗电——CPU、内存、主板、NVMe盘、散热风扇，甚至外接的USB设备，都在你的电表里。

我自己那台做智能体测试的机器，配置大概是一块中端显卡、32GB内存、8核CPU。待机功耗45W左右，光开机不上负载就比很多轻薄笔记本整机功耗高。加载一个7B量化模型后，空闲功耗涨到60到65W，这还什么都没跑。真正开始推理，整机瞬时功耗能冲到220W以上。如果按照显卡TDP 65W去估算，会说这机器跑一天才1.5度电，实际上整机一天的耗电随随便便2.5度起步。

1.2 智能体负载的特殊性：突发、等待、循环

智能体的耗电不能用“满载功耗×在线时长”来算，因为它的负载是突发型的。一个典型任务长这样：用户提问后，Agent要先调用LLM做规划，规划完调用搜索工具或数据库查询，等结果返回再让LLM总结，总结完可能还要写文件，写文件前又回头问一次LLM。这中间有大量等待、IO、上下文组装，LLM真正满负荷推理的时间可能只占任务时长的五分之一，甚至更少。

所以耗电要分两条线看：一条是推理电耗，也就是GPU/CPU高负载那几秒的额外功率；另一条是系统电耗，也就是Agent等待、解析日志、调用工具时整机的最低消耗。前者看tokens，后者看时长。忽略任意一条，估算结果都会偏得离谱。这个基本认知先立住，后面的公式才有意义。

1.3 多智能体编排带来的额外开销

如果你用的是Dify、LangGraph这类平台搭建多智能体，耗电特性和单模型聊天完全不同。多个子Agent互相传递上下文，每一轮传递都要做序列化、解析、重新拼Prompt，这些操作全部落在CPU和内存上。我用LangGraph跑过一个双Agent协作任务，结果发现CPU占用长期在40%以上，而这段时间里显卡几乎空载。也就是说，智能体项目里“看不见的调度开销”有时候比模型推理本身更耗电。这也是为什么我坚持用功耗仪测整机，而不是只盯GPU面板。

2. 估算前的三张底牌：硬件、负载、循环次数

在拿出公式之前，得先摸清三组数据。它们直接决定估算精度，缺一个后面全是空中楼阁。

2.1 硬件基线：先测出待机、空闲、峰值三组数

买一个带功率显示的智能插座，四五十块的就有，精度在±2%以内，家用足够。插上电脑，然后分三次读数：

• 待机功耗：正常开机，不加载模型，什么任务都不跑，等5分钟稳定后读数。
• 空闲功耗：加载完模型但没有任何请求，等显存和模型都就绪后读数。这一步很多人忽略，但模型驻留内存会让显存和CPU都保持一个较低的活跃状态。
• 峰值功耗：连续跑3到5次单轮推理，记录功耗仪上的最大值和平均值。

为什么要测整机而不是只看显卡？因为智能体的工具调用、日志、网络请求这些活全在CPU上干。如果你只用一个软件看显卡功耗，会把一大半耗电漏掉。我的经验是，中端桌面平台跑本地模型时，CPU加内存加主板的待机功耗大约在40到60W，而推理时的增量功耗主要在显卡上。二者都得知道。

2.2 负载画像：一个任务里到底跑了几次模型

第二张底牌是“任务循环画像”。最直接的办法是在代码里给每次LLM调用打日志，至少记录三样：调用次数、每次耗时、每次token数。我用一个简单的Python装饰器做这件事，每次Agent调用模型时把耗时和token打到CSV里。跑几十个任务后，统计一个任务平均触发多少次LLM调用、每次多少token、模型生成速度是多少tok/s。

这一步结束，你就知道“一个小时跑多少个任务”和“每个任务总共消耗多少算力”。提取这些数据可能要改几行代码，但这是整个估算过程里最值得花的功夫。没有这些数，后面只能口算，误差奔着50%去。

2.3 循环次数：同样的问题，耗电能差出四倍

第三个变量是整个智能体耗电估算里最容易被低估的：循环次数。同一个任务“从这段文本里提取联系人并写成Excel”，我用两种方式跑过。一种让Agent自己不断拿工具试错，它来回重试了5次，每次都要生成几百token，最后才成功，整个过程耗电量为x；另一种我预先定义了工作流，第一步正则提取、第二步直接调LLM做格式修正，只用了一次LLM调用，总耗电量只有前者的四分之一左右。

所以谈到耗电估算，最该先优化的是流程设计。框架层面减少一次循环，省下的电比换一块低功耗显卡更明显。后面第5节我会专门讲降耗手段，这里的重点是：估算时要乘以真实的循环次数，不要想当然认为“一个问题等于一次LLM调用”。

3. 三步估算法：从功耗仪读数到单任务电耗

好，底牌齐了，我们开始算。

3.1 第一步：只测推理带来的功耗增量

一个人很难精确算出显卡在某次运算里用了多少焦耳，所以我的做法是测整机功耗的增量。选一个典型的单轮推理——比如“写一段200字的摘要”——执行期间，每秒记录一次功耗仪读数，取平均值P_infer。然后测一个完全不做推理但其他条件不变的场景，比如让Agent停在“等待工具返回”状态，每5秒记录一次，取平均值P_idle。

定义推理功耗增量 ΔP = P_infer - P_idle。为什么不用P_infer直接算？因为即便不推理，系统也要维持模型驻留和上下文，这部分电费已经由“空闲功耗”支付了。把增量单算，才能准确反映“多生成一个token额外吃掉多少电”。

举个实测示例。我测试时P_idle约65W，P_infer约190W，ΔP=125W。注意P_infer是多次单轮推理的平均值，不是瞬时峰值，瞬时峰值能到220W。平均值和峰值的差需要被扣掉，风扇狂转和供电余量都算在峰值里。

3.2 第二步：把增量折算成每token能耗

拿输出速度把瓦转成“瓦秒/token”。假设一次推理生成500 token，耗时10秒，那么速度就是50 tokens/s。每token功耗增量 = ΔP ÷ tokens/s。用上面的数字：125W ÷ 50 tok/s = 2.5瓦秒/token。换个角度想：推理1秒产生50个token，消耗125W，所以每个token消耗2.5瓦秒。

这个数值非常有用。它让你的耗电估算变成“按token数算钱”，跟API按token计费几乎映射上了。我把我在不同配置下见过的每token能耗整理了一下，基于常见量化模型，供参考：

表格里的数据都是近似值，硬件差异很大，但方向能说明问题：生成速度越慢的平台，单个token的能耗越高，CPU跑模型在这一项上尤其吃亏。

3.3 第三步：把推理电耗和非推理电耗加在一起

现在算单任务总耗电。公式：

单任务耗电(焦耳) ≈ ΔP × 推理总时长 + P_idle × 非推理总时长

其中推理总时长 = 任务内所有LLM调用的生成token总数 ÷ 生成速度。因为每次调用的生成token数和生成速度差不多，算一次总数即可。非推理总时长 = 任务总时长 - 推理总时长。

沿用之前数据：假设一个任务总共触发了4次LLM调用，每次平均生成500 token，共2000 token，生成速度50 tok/s，那么推理总时长 = 40秒。假设任务总时长是12分钟，非推理总时长是680秒。单任务耗电 = 125W × 40s + 65W × 680s = 5000 + 44200 = 49200焦耳，约0.0137度电。

有人会问，为什么不直接拿功耗仪测一次任务得到的累计电量？因为功耗仪反应慢，任务内功率波动太快，拿总时长算平均会丢掉“推理峰值和等待低功耗”的区别。上面的分项算法虽然不是实验室级精度，但对做工程决策已经足够——能把“电耗主要来自推理还是等待”分清楚，比一个总数字更有价值。

4. 一个完整案例：本地7B智能体跑一天到底用了多少度电

理论说完了，上实战。

4.1 测试环境与任务设计

为了不误导人，先说清楚测试机。配置中端独显（8GB显存）、32GB内存、8核CPU，本地用Ollama加载7B Q4模型，跑了两个智能体场景：一是LangGraph编排的双Agent问答，二是Dify里搭的一个自动整理网页信息的Agent。操作系统是常规桌面Linux，没有刻意做省电调优。任务类型都控制在“从网页或文档中提取信息并生成报告”，单任务目标时长约10到15分钟。

这个环境很典型——不是跑训练集群，不是云上高并发，就是一个人自己捣鼓智能体的场景。这类用户最需要知道“我这台机器天天挂着，一天下来到底几度电”。

4.2 实测数据与计算过程

实测数据记录如下：

• 待机（未加载模型）：45W
• 加载模型后空闲：65W
• 单轮推理平均功耗：190W（峰值218W）
• 推理功耗增量：125W
• 生成速度：约50 tok/s
• 单任务平均时长：12分钟 = 720秒
• 单任务平均LLM调用次数：4次
• 单任务平均生成token数：约2000 token

先算单任务。推理总时长 = 2000 / 50 = 40秒。非推理总时长 = 720 - 40 = 680秒。单任务耗电按第3节公式：125×40 + 65×680 = 5000 + 44200 = 49200焦耳，约0.0137度电。

然后算一天。假设每天跑50个这样的任务，分布在工作时间内。任务电耗合计约0.685度。但机器不可能正好任务一结束就关机。模型常驻内存，剩余时间都是“加载模型后空闲”状态。如果一天24小时，任务总共占用时间是50×720秒=10小时，剩下14小时机器挂着模型空闲。那么空闲期耗电 = 65W×14小时 = 910瓦时 = 0.91度。再加上任务期间的电耗0.685度，一共约1.6度电。如果完全不跑任务只挂机，一整天大约1.56度（65W×24h）。看，差距没有想象中那么大。

4.3 最反直觉的结论：待机电耗常常比推理电耗还高

上面计算暴露了一个特别扎心的事实：对我这种整天开着模型的用法，推理电耗（42%）和待机电耗（58%）几乎五五开，甚至待机更高。很多人的直观想法是“跑AI等于显卡猛转”，但实际上一个7B模型加载后即使不做事，显存也要保持数据、显存控制器要定时刷新，功耗比空载高出二三十瓦。一天挂下来，这部分电不少。

这引出两个结论。第一，如果在意电费，“不做任务时让模型退出、甚至让机器睡眠”比纠结用什么显卡更重要。第二，云端API看起来省电是因为本机只有客户端和网络开销，但服务端那部分电费绕了一圈还是体现在账单上。我算过一个70B模型的API请求，按每次回复的token数和服务器等效功耗折算，单次请求的服务端电耗比本地7B同一个任务高出5到10倍。这是绿色计算视角下的隐形电耗，可以纳入你的技术选型考虑。

5. 基于估算结果的降耗改造清单

算完这笔账，降耗方向就明确了：不是劝人不用AI，而是把每度电花在刀刃上。

5.1 先在框架层砍掉不必要的模型调用

第一优先级的操作是减少循环次数。智能体任务里最常见的浪费是“重试型循环”——工具返回错误、Agent不读错误信息、再生成一轮、再报错。解决办法有三招：第一，在提示词里明确要求“如果工具返回错误，直接终止并报告原因”；第二，给工具加上校验逻辑，参数不对时返回结构化错误码，引导模型少瞎试；第三，能用正则、脚本或传统代码解决的步骤就不要交给LLM，LLM只做真正需要语义理解的部分。

我实测过同样的“批量整理联系人”任务，优化前平均6次LLM调用（约3000 token），优化后降到2次（约800 token）。按前面每token能耗2.5瓦秒换算，单任务推理电耗从7500瓦秒降到2000瓦秒，省了73%。框架层的收益，比什么硬件降频都猛。

5.2 再在模型和硬件层压低单次推理功耗

如果已经砍不掉调用次数，那就降低每一次推理的成本。最常见的是模型量化：拿7B模型来说，FP16换成Q4_K_M，生成速度可能提升一倍，显存占用降低，推理功耗增量也能下降20%到30%。另外注意上下文长度。上下文越长，prefill阶段算得越久。很多Agent会把工具结果、历史对话全塞进去，导致每次请求的prefill token数巨大。我习惯在框架里做“上下文压缩”：超过一定长度后，先把旧对话用LLM总结成摘要，再继续任务。虽然多了半次调用，但整体token数通常能降一半以上。

硬件层还有两个容易忽略的点。一是保证推理用的核心频率稳定而不是疯狂Turbo，很多系统默认把功率拉满，收益曲线早就平了；二是如果机器平时只跑智能体，可以去BIOS里开启类似“节能模式”的电源策略，把CPU最大频率限制在70%附近，对生成速度影响不大，但整机功耗能低不少。注意别在需要实时响应时开这种模式，后台跑批任务很合适。

5.3 最后在调度层管理待机与空闲功耗

第4节的结论说过，待机是耗电大户。所以调度层的原则很简单：做完任务就让模型退出，让机器睡眠，而不是把模型挂在内存里美其名曰“随时待命”。如果你有定时任务，比如每晚跑一批网页抓取Agent，可以分成两步：先让机器在任务开始前1分钟用RTC唤醒或通过智能插座供电，然后执行脚本；任务结束再切到睡眠。对一天只跑2小时的任务，这个方法能省掉80%以上的空载电耗。

如果你用的是Dify、Coze这类平台，本质上是云端服务，本机耗电更少，但云端的电费也是成本。可以按照“每API调用等效电耗”做对比，决定要不要把高频简单任务放到本地小模型，低频复杂任务才调云端大模型。混合部署往往比单一选择更划算。

6. 边界条件与常见估算误区

最后聊几个容易翻车的细节。

6.1 不同编排框架的overhead差异

同样的模型和任务，在Dify、LangGraph、Coze上跑，耗电不完全一样。原因一是框架的调度策略不同，有些框架每个节点都要和LLM交互，有些可以并行；二是日志、追踪、可视化功能会占用CPU，像LangGraph的全链路追踪在调试模式下会显著增加非推理时段的功耗。我测下来，单任务总时长可能差20%到40%。估算耗电时，最好在你常用的框架里实际打日志，而不是直接套用别人的计算公式。多智能体框架还要注意子Agent之间上下文重复传输，会让token数翻倍，电耗随之翻倍。

6.2 测量与计算的坑：瞬时波动、电源转换效率

功耗仪直接显示的功率是墙插交流功率，包含了电源转换损失。而GPU软件读数（比如nvidia-smi的功耗）是部件直流功耗，两者差大约10%到15%。所以不要混着用：要么都用墙插总功耗做相对估算，要么都用部件读数做理论对比。我建议一律以功耗仪为准，因为电表算钱也是按墙插算的。

另外，功耗仪有刷新率限制，瞬时脉冲经常测不准。记录时尽量取1分钟以上的平均，或者在任务跑完后看电量计（kWh）的累计值。很多智能插座能看到“本次会话消耗了多少kWh”，这是相对靠谱的实测值，比手动记录瞬时功率稳得多。用电量累计值反推平均功耗，比盯着数字看容易得多。

6.3 记住：电耗只是决策维度之一

最后说句实话。省电不是智能体优化的唯一目标。一个任务重试5次可能就多花几十瓦秒，但换来的是流程鲁棒性；本地跑7B可能比调API每token电耗高一点，但省了拉取数据的网络等待和隐私风险。我做耗电估算，根本目的是把“看不见的浪费”变成“看得见的数字”，然后决定值不值得改。比如我发现某类任务因为提示词写得模糊，平均多触发3次工具调用，于是花20分钟改了提示词，单任务电耗降了30%——这才是我写这篇文章想带给大家的方法。

以后每跑一个新智能体项目，我都建议先花十分钟做一次基线记录：待机、空闲、峰值三个功耗，加一次典型任务的LLM调用次数。这四个数字一记，后面所有“哪个方案更省电”的争论都会瞬间落地。我现在的习惯是，把这些数据写进项目README，下次再优化时有据可依。哪怕你只是从“电费迷惑”开始，这份账也值得算一算。