如果你也在跑AI智能体大概率被问过这样一句话“你小子天天挂个模型电费是不是爆炸了”说实话我第一次被问住的时候真答不上来。后来我花了几周时间把本地智能体耗电量这件事系统测了一遍才发现网上主流回答几乎都简化过头有人直接报显卡TDP有人说7B模型一小时一度电还有人说用API最省电因为电费在别人那里。这些说法要么没测到底要么是错的。这篇文章放上我自己的实测数据把AI智能体的耗电量拆开看电从哪耗掉的、怎么在任务和待机之间分配、怎么用一台几十块钱的功耗仪估算出“跑一个任务多少度电、跑一天多少度电”以及估算完怎么把电费压下来。适合正在跑Ollama、Dify、LangGraph这类智能体项目的人参考也适合想评估“本地 vs API”哪个更划算的开发者。1. 为什么智能体耗电不能只看显卡TDP1.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%去。字段说明单任务LLM调用次数决定推理总次数平均每次生成token数决定推理时长模型输出速度(tokens/s)用于换算推理时长单任务总时长用于计算非推理待机电耗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约65WP_infer约190WΔP125W。注意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能耗台式机中端独显7B Q450 tok/s125W2.5 瓦秒台式机高端独显13B Q480 tok/s250W3.1 瓦秒纯CPU内存7B Q410 tok/s80W8.0 瓦秒云GPU跑70B服务端等效估算100 tok/s1500W等效15 瓦秒表格里的数据都是近似值硬件差异很大但方向能说明问题生成速度越慢的平台单个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不读错误信息、再生成一轮、再报错。解决办法有三招第一在提示词里明确要求“如果工具返回错误直接终止并报告原因”第二给工具加上校验逻辑参数不对时返回结构化错误码引导模型少瞎试第三能用正则、脚本或传统代码解决的步骤就不要交给LLMLLM只做真正需要语义理解的部分。我实测过同样的“批量整理联系人”任务优化前平均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下次再优化时有据可依。哪怕你只是从“电费迷惑”开始这份账也值得算一算。