做智能体应用做了快两年被问到最多的问题往往不是“效果怎么样”而是“这到底要花多少钱”。以前我写文章讲成本基本只聊 token 单价。但最近几个月我们把 agent 系统从云端 API 迁到本地 GPU 服务器做私有化部署一个以前没人提的数字开始变得扎眼电费。智能体跑在自己的机房里你换来的是数据可控和长尾成本下降的潜力付出的则是每小时都在累计的功耗账单。别小看这一项——我见过不止一个团队买卡时豪气冲天月底看到电费单和散热账单后连夜写降耗方案。这篇文章把我做智能体耗电量估算的全过程整理出来电到底耗在哪些环节、怎么用一条公式算出单任务电费、需要实测哪些参数、如何把月度账单拆开看以及我用什么工具给一套生产环境的 agent 系统做了一次完整电费审计。适合正在自托管大模型、做智能体私有化部署或者正纠结“买卡还是调 API”的团队参考。1. 先拆清楚智能体的电耗到底发生在哪几个环节1.1 智能体不是一次对话而是一连串模型调用很多人以为智能体和普通聊天框没本质区别无非是多接了几个工具。但在耗电这件事上区别非常巨大。一个普通的单轮对话模型只被调用一次读入用户输入生成回复结束。而一个标准的智能体工作流里模型可能要连续被调用 5 到 20 次规划任务、决定调用哪个工具、解析工具返回结果、反思上一轮输出的质量、修正计划、生成最终答案每一步都可能触发一次独立的推理过程。于是出现了一个很反直觉的结论完成一个智能体任务的总 token 数往往是一个同长度纯对话任务的 5 倍以上。我在自己的项目里统计过一个“帮用户查订单并起草退款申请”的任务模型总共处理了约 4200 个 token其中输出约 1270 个、输入约 2900 个。而同样内容的一次人工代写回复1200 个 token 就能结束。token 数量决定了 GPU 的计算量计算量又基本决定了耗电量。所以做估算的第一步是彻底抛弃“一次对话算一单”的直觉建立起“一次任务等于多次推理调用”的认知。否则后面所有估算都会严重偏低偏低的幅度不是百分之几而是数倍。1.2 自托管和云端 API电费的计算逻辑完全不同这里要先划一条清晰的分界线。如果你用的是 ChatGPT、Claude 这类云端 API成本是按 token 计费的电费藏在对方的服务器账单里你无感也不需要自己算功耗。但如果你所在的企业因为数据合规要求或者长期使用成本考虑把智能体系统部署在自己的服务器、工作站甚至办公区一台高配 PC 上那么电费就成为一项直接、持续、可观的运营支出。行业里普遍有这样一个判断2026 年前后智能体会从概念演示走向工程化落地。这意味着大量团队会把 agent 从 demo 推进到生产环境而生产环境意味着 7×24 小时在线。一台 8 卡 H100 服务器满载功耗能到 6kW 以上按商业电价算一个月光 GPU 的电费就可能超过一台低配新车的月供。这个数字很多技术负责人是没提前算过账的。所以这篇讨论的“耗电量估算”默认前提就是你正在自托管模型、跑自己的 agent 服务或者正打算这么做。如果你还在用纯 API 方案这篇文章的价值更多在于帮你理解供应商定价背后的物理成本以及未来迁移自托管时的决策依据。1.3 三类容易被忽略的隐性耗电即使明确了自托管大多数人做估算时还是会漏掉三块。最典型的是待机功耗。GPU 空闲时并不是 0W——一张 RTX 4090 在模型常驻显存的状态下待机功耗大约 30W 到 60W加上 CPU 和风扇整机可能到 120W 到 180W。只要模型不卸载这个功耗就 24 小时存在。我见过有人只算“跑任务时”的电费结果真实账单比他的估算高出一倍多差额基本全是待机。其次是调度和框架开销。智能体系统不仅仅包含模型推理还包括向量检索、重排序、权限校验、日志落盘、监控采集。这些组件都跑在 CPU 和服务器的其余部件上。一台 GPU 服务器里CPU、内存、网卡、硬盘满载时的功耗能占整机的 15% 到 30%这部分不能假装不存在。第三是冷启动和切换损耗。如果你的服务用了 Serverless 推理或者经常卸载、重载模型那么模型加载、上下文重建、GPU 从深度降频拉满频率的过程都会产生短时功率尖峰持续时间可能从几秒到几十秒。单个任务里它占比不大但一天触发几百次积少成多。我的经验是这三大块隐性耗电加起来往往比“活跃推理”本身还多不拆开看永远不知道自己交了多少“存在费”。2. 核心估算方法从一条公式到一张月度账单2.1 先把单位换算玩明白做估算之前先得有统一的单位。功率用瓦W电能消耗用千瓦时kWh两者通过时间换算。记住一条1 kWh 1000W 持续 1 小时同时也是 3600 千焦kJ。后面手算任务能耗时会频繁用到焦耳提前建立这个换算关系能省不少事。GPU 厂商给的是 TDP热设计功耗比如 RTX 4090 标称 450WA100 标称 400W。但 TDP 不等于实时功耗。实际负载下GPU 功耗通常在 TDP 的 60% 到 90% 之间波动有些负载甚至只用到 10% 的功率。直接拿 TDP 乘运行时长属于“满负荷理论值”会把账单高估不少。正确做法是实测后文会讲。我平时用的单任务估算公式是这样的E_task (P_prefill × T_prefill P_generate × T_generate P_idle_gap × T_idle_gap) / 3,600,000解释一下每个符号P_prefill一次任务里处理输入prefill阶段整机功率单位 WT_prefillprefill 阶段总耗时单位秒P_generate逐 token 生成回复阶段整机功率单位 WT_generate生成阶段总耗时单位秒P_idle_gap两次模型调用之间的等待功耗单位 WT_idle_gap等待时间合计单位秒之所以除以 3,600,000是因为 W × 秒等于焦耳而 1 kWh 3,600,000 焦耳。这个公式看起来简单但每一步的参数都要求你对自己的系统有真实的测量数据这正是它和“拍脑袋估算法”的本质区别。2.2 用一个客服智能体任务走完整手算为了让公式落地我用一个真实场景完整算一遍。场景自托管 7B 模型单张 RTX 4090跑一个客服智能体任务目标是“查订单状态并起草退款申请”。这是我项目里的典型任务数据也是从日志里统计出来的。先看实测基础数字生成阶段整机功率约 420WGPU 约 330WCPU 加外设约 90Wprefill 阶段整机功率约 470W任务间等待功耗约 150W模型常驻显存再看一次任务中的耗时分布。这个任务平均触发 4 次模型调用总输出 token 数 1270 个总输入 2900 个。7B 模型 FP16 加载时生成速度约 85 token/sprefill 速度约 2000 token/s。于是生成时间 1270 / 85 ≈ 15 秒预处理时间 2900 / 2000 ≈ 1.5 秒任务内两次调用之间的间隔工具 API 等待、JSON 解析等合计约 3 秒代入公式E_task (470 × 1.5 420 × 15 150 × 3) / 3,600,000 (705 6300 450) / 3,600,000 7455 / 3,600,000 ≈ 0.00207 kWh按商业电价 1.2 元/kWh 算单次任务电费约 0.0025 元。听起来毫不起眼。但注意这只是“活跃”的部分。如果这个智能体一个月被调用 5 万次客服场景这个量级很正常任务总电耗 0.00207 × 50000 103.5 kWh电费约 124 元。同时服务器 24 小时在线待机功耗 150W一个月 720 小时待机电耗 150 × 720 / 1000 108 kWh电费约 130 元。两项加起来约 254 元/月。看明白了吗在一个实际运营的智能体服务里任务能耗和待机能耗几乎是五五开。如果调用量再小一些比如一个月只有 3000 次那待机占比会超过 80%。这就是为什么我反复强调估算智能体电费绝不能只算“跑起来”的账单。2.3 三个必须实测、不能拍脑袋的关键参数公式本身不复杂难的是参数从哪来。这里给出三个关键参数的实测做法和注意点。第一是功率。别直接用 GPU 的 TDP。正确做法是测整机交流输入功率用一个带功率统计的智能插座插在服务器电源前或者读服务器 BMC/IPMI 的功耗接口。软件层面可以用 nvidia-smi 读 GPU 瞬时功率但它不管 CPU、内存、风扇所以整机层面以插座或 BMC 为准GPU 层面用 nvidia-smi --query-gpupower.draw 准没错。第二是速度。模型生成速度 token/s 必须实测不要看官方 benchmark。同样是 7B 模型量化版本、上下文长度、并发数、推理引擎的差异会让速度差两三倍。测量方法很简单在服务日志里加 token 计数和时间戳或者直接读 vLLM 的 metrics 接口看 tps。建议同时记下峰值和均值峰值用于评估扩容均值用于算电费。第三是频次。任务级调用次数和 token 分布必须从自己的业务日志里统计别假设。我见过最离谱的估算是拿 benchmark 里“单次回答 500 token”的数字去套整个智能体系统结果实际 token 数差了 6 倍。正确做法是在 agent 框架的调用链路上打日志记录每次模型的输入/输出 token 数和用户请求的对应关系。统计一周你就能拿到非常可靠的均值。2.4 从单任务推广到月度账单把前面几节拼起来我平时用的月度估算公式是E_month P_idle × 720 / 1000 E_task_avg × N_tasks P_extra × T_extra / 1000其中 P_idle 是 24 小时待机整机功率W720 是一个月平均小时数E_task_avg 是单任务均值kWhN_tasks 是每月任务数P_extra × T_extra 是额外项比如每天一次的批量评估跑批功耗、每周一次的向量索引重建。别偷懒额外项单独列出来方便后面逐项优化。这个公式真正的价值在于敏感性分析。你可以快速回答“把待机功耗从 150W 降到 80W一个月省多少”“把生成速度从 85 提到 120 token/s单任务降多少”这类问题。一旦有了模型“如果怎样”就不再是猜而是几分钟内能算清楚的事。3. 实操记录给一套办公区 Agent 系统做电费审计3.1 我用的测量工具与接线方式工具与方法说清楚了接下来进入实操环节。我这次审计的对象是一台放在公司机房的 4 卡服务器4 张 RTX 4090 跑 vLLM上面同时跑着一个由 LangGraph 编排的多步智能体服务。我没有拆开机器量 12V 母线那太硬核也不安全我的方案是三层读数配合。第一层是机柜级机柜 PDU 上有功率显示直接读它能覆盖整柜所有设备包括交换机。第二层是服务器级这台主板支持 BMC我从 IPMI 的 SDR 传感器直接读到整机输入功率这个数字非常准相当于厂商出厂校准过的。没有 BMC 的机器就在服务器电源前插一个带功率记录功能的智能插座。第三层是 GPU 级用 nvidia-smi dmon -s p 循环记录每张卡的功耗和时间戳。软件层再补三个东西vLLM 的 Prometheus metrics 里直接有生成 token 数和请求数agent 服务的日志里加了调用链路 token 统计再用一个简单的 Python 脚本每 5 秒把 IPMI 功率、nvidia-smi 功耗、当前活跃请求数一起落库。nvidia-smi 的查询命令大概是这样的nvidia-smi --query-gpuindex,power.draw,utilization.gpu,temperature.gpu \ --formatcsv,noheader,nounits -l 5这样事后就能画出一张“功耗-请求数-阶段”的对齐图知道每个任务到底在哪个环节花了多少电。这一步对齐工作是整个审计里最值钱的投入比后面所有计算都重要。3.2 实测数据活跃、空闲、调度三种状态的功耗画像审计跑了整整 7 天覆盖工作日和周末。先把关键数据列出来再说结论。状态GPU功耗(W)整机功耗(W)说明深度空闲无请求模型常驻30 - 45140 - 165一天约 70% 时间处于此状态单请求推理低并发280 - 340430 - 500单用户测试场景常见8 - 16 并发推理350 - 420550 - 620vLLM 连续批处理下功率接近满载模型加载 / 重启400700 尖峰每次持续 10 - 20 秒“深度空闲”一栏特别扎眼一天 24 小时里这台服务器有大约 17 个小时处于无请求或极低请求状态但功耗始终在 150W 上下。一周下来这部分待机耗电占了总耗电的 63%。也就是说一大半电费买的是“随时待命”这个状态而不是实际干活。我还发现一个有意思的现象低并发下4 张 GPU 通常只有 1 张在忙。因为我们用的是每张卡一个模型副本的模式负载均衡器把请求派给其中一个副本其余 3 张保持低功耗待机。这意味着大部分并行能力在大多数时间是闲置的——这不能怪硬件是我们的业务量还没撑起来但它在电费上的代价是实实在在的。3.3 月度账单算出来比想象中更有价值基于一周数据外推一个月得到这样一张表项目月耗电(kWh)月电费(按1.2元/kWh)占比24小时待机108129.655.4%任务推理7286.436.9%评估跑批 / 索引重建10125.1%模型加载与启动562.6%合计195234100%看到这张表第一反应是一个月电费也就两百多块不贵嘛。但放到业务视角看就不一样了。这台服务器服务的是公司内部的客服智能体月任务量约 12000 次折算下来单任务电费约 0.02 元——是前面手算预估值的 10 倍。为什么差这么多因为预估值只算了“活跃推理”而真实账单里一半以上是待机、评估、加载这些支撑性开销。这个差异给了我两个结论。第一业务量还没起来时自托管小模型在电费上并不比云端 API 便宜因为 API 按调用付费自托管是按“存在”付费。第二一旦业务量往上走自托管的边际电费会迅速摊薄因为待机成本是固定的。按我的估算这个临界点大约在月调用 3 万到 5 万次之间跨过去之后自托管在成本上的优势才会真正兑现。3.4 优化前后的对比数据审计完不能白审。我根据数据做了三轮优化每轮都有明确的数据支撑。第一轮砍待机把模型加载改为按需深夜 23 点到次日早 7 点关闭跑批量评估的副卡只保留一张卡承载低峰请求。整机待机功耗从 150W 降到 85W。光这一项月省约 47 度电大约 56 元。第二轮提速度给 7B 模型换上了 INT8 量化版本生成速度从 85 token/s 提到 118 token/s单任务生成阶段耗时从 15 秒降到约 11 秒。任务推理能耗降了大约 25%月省约 18 度电。第三轮清尾账把每天固定时间跑的评估任务从中午挪到夜间与低峰期“共用”待机时段不额外产生峰值功率。省的不多约 8 度电/月但胜在零成本。三轮加起来月度电耗从 195 kWh 降到约 122 kWh降幅 37%。整个过程没有动硬件没有明显牺牲体验靠的就是把功耗数据当成一个普通性能指标持续观察。这也是我写这篇文章最想传达的一点电费优化不是一个环保口号它是一个可以像调接口延迟一样被量化、被优化的工程指标。4. 常见问题与排查技巧实录4.1 功耗异常排查速查表做功耗审计期间我整理了一个排查表遇到异常功耗可以直接对着查现象可能原因排查手段整机功耗长期偏高且无请求模型常驻显存未释放后台有 eval 进程监控采集频率过高IPMI 逐部件读功率ps 查进程检查 vLLM 引擎是否重复启动单任务功耗异常高上下文过长导致 prefill 占比大工具返回结果过大被反复注入日志里看 input token 分布对工具输出做截断或摘要CPU 功耗占比超过预期向量检索、重排序、日志序列化抢 CPUPython 代码存在低效循环top 按 CPU 排序用 py-spy 采样分析功耗波动剧烈、尖峰频繁请求突发加模型冷加载Serverless 频繁启停对齐请求时间线与功耗曲线调整扩缩容策略GPU 利用率高但功耗低内存带宽瓶颈或 batch 过小导致算力闲置测不同 batch 大小下的利用率与功耗关系这些坑我几乎都踩过。最典型的是第一条有段时间整机莫名其妙多出 30W 功耗查了一下午最后发现是监控采集脚本每 5 秒调用一次 GPU 查询接口反复把 GPU 从深度空闲状态唤醒。把采集间隔从 5 秒放宽到 30 秒后功耗立刻降下来了。监控也会烧电这个细节估计没几个人写进文档。4.2 降低单位任务耗电的五个有效方向从我的经验看想让智能体“少耗电多办事”优先级大概是这样的第一是压缩 token 总流量。智能体最大的能源浪费是反复把大段上下文塞给模型。做法包括对工具返回结果做摘要和截断、控制历史消息条数、把系统提示词写短、用缓存复用常见推理结果。token 少了计算量少了电自然省。这一招收益最高但最容易被当成“代码洁癖”。第二是选对模型和量化。能用 7B 解决问题的不要上 70B能接受精度影响的用 INT4/INT8 量化。模型规模差一级单 token 能耗可能差 5 倍以上。量化后生成速度上升、显存占用下降还给并发批处理留出空间是多个维度一起受益。第三是选对推理引擎。vLLM、SGLang 这类支持 continuous batching 的引擎比 naive 的一次只处理一个请求的写法吞吐高好几倍单 token 能耗直接下降。如果还在用 transformers 的 generate 函数裸接服务不夸张地说光换引擎这一项就能把 GPU 需求减半。第四是负载聚合。把零散请求攒成 batch 处理或者用 speculative decoding 加速生成减少 GPU 处于“半负载”的时间。GPU 在半负载和满载时的功耗差距不大干的活却差很多。尽量让 GPU 要么满载干活要么深度休眠别让它半梦半醒地耗电。第五是基础设施层面。能关的机器关掉能降频的降频模型改成按需加载评估任务挪到低峰。这类优化不性感但每一分都是从账单上直接扣下来的真金白银。4.3 估算工具的选型与使用注意最后说说工具。我日常用的是这样一组组合基本都不需要额外花钱整机功率优先用 BMC/IPMI 自带传感器没有的话用带计量功能的智能插座记录每小时平均功率。GPU 功率与利用率用 nvidia-smi dmon或 nvidia-smi --query-gpupower.draw --formatcsv -l 15配合落库脚本做时间对齐。任务耗电与 token 统计在 agent 框架的中间件里加 logging 钩子记录每次调用的 input_tokens、output_tokens、耗时。LangGraph、Dify 这类框架都有自己的回调接口别去改源码。长期记录用 node_exporter 加 Prometheus 加 Grafana 把 IPMI 和 nvidia-smi 指标统一收进来既能看到趋势又能和业务指标做关联分析。用这些工具有三个注意点。一是采样间隔不要太短否则监控本身会占用资源、抬高功耗稳态观测建议 15 到 30 秒。二是功率读数要分清交流AC和直流DC电源转换效率一般在 90% 上下如果 BMC 给的是 DC 功率换算到电费时要记得除以效率。三是任何估算都要保留原始日志不然出了偏差连复盘都无从谈起。最后分享一点我自己的体会。做了这次电费审计之后我最大的收获不是省了多少钱而是对“自托管到底意味着什么”有了更清醒的认识。以前评估方案时脑子里只有硬件采购价和 token 单价从来没有把“存在成本”这四个字放进去。现在我会在任何一个私有化部署方案里都加一栏功耗预算选型时会先用这里的公式跑一遍三年总成本再决定买几张卡、上什么量化、要不要做按需加载。如果你也正好在跑自己的智能体系统建议别等到月底电费单出来才吃惊。花一个下午把功率计插上把日志里的 token 数统计出来用上面的公式过一遍你会对自己系统的真实运行成本产生一个非常具体的感觉。这个数字不一定很大但它会让你在做“自托管还是 API”“买几张卡”“上不上量化”这些决策时心里踏实很多。
