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

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

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

先确定你要算哪一种成本

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

月度总成本公式

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

1
2
3
4
5
6

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

电费 = 实测整机平均功耗(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，并保持同一统计口径。

如何采集自己的数据

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

先用 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。