消费级显卡跑 Agent 成本怎么算：电费、折旧与每任务成本

Sat, 11 Jul 2026 10:30:00 +0800

想知道一张消费级显卡跑本地 Agent 值不值，不能只看“显卡买了多少钱”，也不能只拿 API 的每百万 token 单价对比。Agent 会反复调用模型、工具和浏览器；长上下文、失败重试、空闲待机都会改变实际成本。

最实用的做法是把成本拆成四项：电费、硬件折旧、配套设备与人工维护，然后同时按“每个成功任务”和“每百万输出 token”核算。

先确定你要算哪一种成本

口径	适合回答的问题	容易漏掉的项目
增量成本	已有游戏主机，闲时跑 Agent 多花多少钱？	显卡本来就有，是否计入折旧
全成本	为本地 Agent 专门购买机器是否划算？	主机、内存、SSD、散热和折旧
单任务成本	自动处理一份文档、一次代码任务要多少钱？	失败、重试和人工复核
吞吐成本	自建推理服务每百万 token 的成本？	输入 token、KV cache 和闲置时间

如果显卡原本用于游戏或其他工作，先算增量成本更诚实；只有为了 Agent 新购整机时，才把整机折旧完整计入。

月度总成本公式

先用月度口径，数据最容易获得：

月度总成本 = 电费 + 硬件月折旧 + 配套服务费 + 人工维护成本

电费 = 实测整机平均功耗(kW) × 实际运行小时数 × 电价(元/kWh)
硬件月折旧 = (购入总价 - 预估残值) ÷ 使用月数
单次成功任务成本 = 月度总成本 ÷ 月成功任务数
每百万输出 token 成本 = 月度总成本 ÷ 月输出 token 数 × 1,000,000

“整机平均功耗”应尽量来自插座功率计或 UPS，而不是只看显卡标称 TBP。Agent 运行时还有 CPU、内存、SSD、风扇和显示器；只用 GPU 功耗会低估电费。反过来，机器待机但没有处理任务的时段，也不应混进纯推理成本，最好单独记录。

一个可替换参数的示例

假设一台机器在实际 Agent 工作负载下，插座实测平均功耗为 280W，每天运行 6 小时，每月运行 30 天；当地电价按 0.8 元/kWh 计算。专门为此购入的硬件按 7,000 元、36 个月、残值忽略来摊销。

1
2
3

电费 = 0.28 × 6 × 30 × 0.8 = 40.32 元/月
硬件折旧 = 7,000 ÷ 36 = 194.44 元/月
月度基础成本 = 234.76 元/月

若这个月完成了 600 个经过验收的任务，基础成本约为 0.39 元/任务。这里的“完成”不能只算模型返回；应该以脚本执行成功、工单关闭、人工抽检通过等业务结果为准。

这只是演算示例，不是通用价格。把功耗、使用时长、电价、购机金额和任务量替换成自己的数据，才有意义。

Agent 为什么比普通聊天更难估算

聊天模型常按 token 计费，而 Agent 的成本还受执行路径影响：

一次任务可能包含计划、检索、调用工具、读取结果和多轮修正。
上下文越长，KV cache 占用越多；显存不足时会降速、CPU/RAM 卸载，甚至触发重试。
浏览器自动化、代码测试和文件处理会拉长任务时间，即使 GPU 没有持续满载。
多 Agent 并行会提高吞吐，也可能让显存争用、排队和失败率上升。
为了降低首 token 延迟而常驻模型，会增加空闲功耗。

因此，不要用一次简短问答的 tokens/s 代表 Agent 成本。至少选一组真实任务，连续跑一周，记录输入/输出 token、成功率、重试次数、墙钟时间和整机耗电量。

两个必须同时看的单位

每个成功任务

这最贴近业务决策。适合比较“本地 Agent 自动处理 PR”“批量整理资料”“客服草稿生成”等固定流程。

`1`	`每个成功任务成本 = (本周期全部成本) ÷ 成功且验收通过的任务数`

失败任务不能从分子中删掉。它们消耗的电力、推理时间和人工排障，正是本地系统真实的运营成本。

每百万 token

这适合对比本地推理服务和云端 API，但要区分输入与输出。很多 Agent 的输入包含长工具日志和历史上下文，输入 token 远多于输出 token；若只除以输出 token，数字会偏高。更稳妥的做法是同时记录输入、输出和总 token，并保持同一统计口径。

如何采集自己的数据

不需要一开始就搭建复杂的监控系统。先建立一个表格，每次运行记录以下字段：

字段	记录方式
开始与结束时间	Agent 日志或任务队列
整机耗电量	智能插座、功率计或 UPS
输入/输出 token	推理服务日志或客户端统计
成功、失败、重试	任务状态与错误日志
人工复核时间	工单、PR 或抽检记录
模型与量化版本	避免不同模型混在同一组数据里

先用 20 到 50 个有代表性的任务做基线。随后分别测试短上下文、长上下文、工具调用多和重试多的任务，才能看出显存和模型选择对成本的影响。显存规划可结合本地模型量化与显存选择一起判断。

折旧该怎么算才不会误导自己

折旧没有唯一答案，但必须先把假设写下来。

已有显卡：可以只算电费和额外维护，作为增量成本；也可以给显卡设一个机会成本，作为更保守的全成本。
新购设备：显卡、主机、内存、SSD 和散热器应一起纳入；不要只摊显卡价格。
使用寿命：用 24、36 或 48 个月都可以，关键是用同一假设比较本地与云端。
残值：预计设备能转卖时，可从购入价中扣除预估残值；不确定就设为 0，结论更保守。

NAS 或小主机通常功耗较低，但显存、散热和扩展能力也会限制模型与并发。若考虑这条路线，可先看NAS 部署 Ollama 的性能判断。

与云端 API 比较时，不要只比单价

可以把云端侧也换算成每任务成本：

`1`	`云端每任务成本 = 模型 API 费用 + 工具/API 费用 + 必要的存储与网络费用 + 人工复核成本`

本地通常更适合这些情况：

每天有稳定、可预测的任务量，机器利用率较高。
数据不能或不希望发往外部服务。
已经拥有可用 GPU，增量成本主要是电费。
可接受自行维护模型、驱动、服务和故障恢复。

云端通常更适合这些情况：

负载是偶发的，机器大部分时间会闲置。
任务需要远超本地显存的大模型、超长上下文或峰值并发。
团队不愿承担驱动、模型升级、监控和故障排查。
任务结果价值高，优先需要最强模型或多模态能力。

本地部署也不是只能二选一。稳定、隐私敏感的步骤放本地；复杂、低频或需要更强模型的步骤调用云端，往往更容易控制总成本。

一个实用的决策线

把本地每月固定成本记为 F，每个任务的可变电力与维护成本记为 v，云端每任务成本记为 c。当 c > v 时，本地达到收支平衡的大致任务量为：

`1`	`每月盈亏平衡任务数 = F ÷ (c - v)`

如果 c 小于或接近 v，本地不会因为规模而明显更省钱；此时应更多考虑隐私、延迟、可控性和离线能力。这个公式只是财务筛选，仍要加入失败率和人工复核时间。

常见误区

只看显卡功耗：整机电力、待机和散热同样要付费。
把标称 tokens/s 当吞吐：真实 Agent 会被上下文、工具、网络和测试步骤拖慢。
忽略失败任务：重试最频繁的流程，往往才是成本黑洞。
只计算模型费用：浏览器、搜索、向量库、存储和人工审核也可能收费。
混用不同模型的数据：量化版本、上下文长度和并发不同，结果无法横向比较。

总结

消费级显卡跑 Agent 的成本，不应只回答“每小时几度电”。先用实测整机功耗算电费，再按自己的折旧假设加入硬件成本，最后用成功任务数和 token 量分摊。连续记录一段真实工作负载后，你就能清楚判断：是继续本地运行、扩容显存，还是把部分步骤交给云端 API。

消费级显卡 on KnightLi的博客