当前位置:首页 > 软件工具 > 正文

Agent 的算力账单:一个任务跑到 1333 步,整月订阅就没了

约 3664 字 · 预计阅读 10 分钟
一句话总结:Grok Bot 开始限每周额度,马斯克说成本"难以为继"。我按 computer use 的典型消耗算了一笔账:每步 1600 token、上下文截断在 50K,跑到 1333 步成本就是 200 美元,正好等于一个月订阅费。而 1500 步的自动化任务,一小时就能跑完。

Grok Bot 出问题了。

马斯克的说法是,这个智能体最终可能消耗掉大部分超级智能算力,服务成本已经高到"难以为继"。产品侧的动作更直接:限制每周使用额度,引起了用户不满。

我第一反应是这不合理——一个每月 200 美元的产品,限什么额度。

算完账发现,问题是真的大。

一、先把这笔 Agent 算力账单算出来

先说明:下面的单价和消耗量都是假设值,用来看量级,不是任何厂商的真实报价。

设定一个 computer use 类任务:每走一步截一张图、给一个动作。每步新增约 1,600 token。

关键在上下文。这类任务的每一步都要把之前所有步骤带上——它得知道自己走到哪了。所以第 n 步的请求体不是 1,600 token,是 1,600 × n。

实际产品不会让它无限涨,一定会截断,比如卡在 50K。我按这个来。

单价按输入 3 美元/百万 token、输出 15 美元/百万 token。

Agent 的算力账单:一个任务跑到 1333 步,整月订阅就没了

图 1:成本随步数线性上升,没有规模效应,跑得越久越贵

跑出来的结果:

步数 总输入 token 成本
1088,000$0.28
501,743,600$5.32
1004,243,600$12.91
30014,243,600$43.27
60029,243,600$88.81
100049,243,600$149.53
150074,243,600$225.43

50 步的短任务 5 块 3,一个月能跑 37 次。看着还行。

1500 步的长任务 225 美元,比整月订阅还贵。

交点算出来是 1333 步。

二、为什么成本随步数线性涨

这是 Agent 和普通对话最不一样的地方。

普通对话,一次请求的成本是固定的——你说一句,它答一句,5 块钱用一个月能问几千次。

Agent 不一样。它每一步都要重新读一遍自己走过的路。第 100 步的请求里,前 99 步的内容一个字不少(除非截断)。所以总成本不是"步数 × 单价",是"步数 × 累积上下文 × 单价"。

上下文截断之后,单步成本封顶了,但步数还在涨,所以还是线性。

这意味着 Agent 没有规模效应。 一个跑 10 步的任务和跑 100 步的任务,成本差 10 倍,没有任何折扣。

脚本模式那篇算过另一种解法:把多步操作压成一次脚本执行,20 步的 token 消耗能差 27 倍。那本质上也是"别让模型一步步走"。

三、1333 步那个交点意味着什么

一个自动化任务跑 1333 步,大概要多久?

computer use 每步包括截图、推理、执行,快的话 2 到 3 秒。1333 步 × 2.5 秒 ≈ 55 分钟。

也就是说,一小时的高强度自动化,就能吃掉整月订阅。

这就解释了为什么要限每周额度。一周 168 小时,如果重用户每周跑 20 小时的高强度任务,成本远超 200 美元。

反过来算:一个月 200 美元,能跑 37 个 50 步的短任务。这个配额对轻度用户够用,对重度用户远远不够。

四、Grok Bot 限额度不是小气

公开数据里有一条:Grok Bot 付费周活已经 80 万。

假设这 80 万人平均每人每月跑 5 个中等任务(假设 200 步,约 29 美元),光推理成本就是 1.16 亿美元/月。而 200 美元 × 80 万 = 1.6 亿美元月收入。

毛利不到 30%,还没算研发、带宽、服务器折旧。

这个账撑不住,不是因为用户用得多,是因为单次任务的边际成本太高。SaaS 产品多一个用户成本接近零,Agent 产品多一个用户就要多烧一份 GPU。

五、做 Agent 产品的人该怎么算

三条,都是我踩过或算过的。

第一,先算单任务成本,再定价格。 不要按"用户数 × 月费"想收入,要按"任务数 × 步数 × 单价"想成本。这两个数不匹配的时候,越增长亏得越快。

第二,把上下文压缩当成核心功能,不是优化项。 不截断的话,1500 步要 18 亿 token,成本 5,404 美元。任何产品都撑不住。所以压缩策略(丢早期步骤、总结历史、只留关键状态)直接决定单位经济成不成立。

第三,能脚本化的别逐步跑。 同一个任务,让模型生成脚本一次执行,和让它一步步点,成本能差一个量级。message threads解决的是传输重复,脚本模式解决的是推理重复,两件事都在砍同一类浪费。

六、常见问题

这些成本数字准吗?

不准。单价是我假设的,消耗量也是估算。真实的数字取决于具体模型、具体实现、有没有缓存。这里只用来看量级和趋势。

为什么不用更便宜的模型?

便宜模型单价低,但步数会更多(能力差,要试更多次)。总成本不一定更低,得实测。

普通用户会被涨价吗?

短期不会。更可能的做法是限额、降速、把长任务拆成需要确认的步骤。这些都比直接涨价温和。

自家部署会不会更省?

看规模。GPU 固定成本摊到足够多的请求上才划算,小团队自建通常比 API 贵。

结语

这次的事说到底是一个老问题:把边际成本很高的东西做成订阅制。

SaaS 时代这个模式能成立,是因为多一个用户的成本几乎为零。Agent 不是——它多干一步就要多付一次钱,而且这一步的钱是实打实烧掉的。

所以"每月 200 美元随便用"这种定价,在 Agent 上早晚要出事。先出事的会是那些免费额度给得最大的产品。

参考资料

目录导航
  • 一、先把这笔 Agent 算力账单算出来
  • 二、为什么成本随步数线性涨
  • 三、1333 步那个交点意味着什么
  • 四、Grok Bot 限额度不是小气
  • 五、做 Agent 产品的人该怎么算
  • 六、常见问题
  • 结语
    • 参考资料
  • 相关文章:

  • 上下文压缩三种策略实测:省到 100 token,就得接受会漏
  • 腾讯混元 Hyra 2.0:三层 Agent 做科研,从解题变成造工具
  • DeepSeek 的 Creator Mode:说一句话,生成一个能用的插件
  • Agent 开始有身份了:内容站该怎么声明谁能来、能干什么
  • Anthropic message threads:20 轮少传 96%
  • Kimi 连干 20 小时,SlopCodeBench 无一通过:验收口径不同
  • 过度封装的下场:一个检查代码的活拆成六个组件,改需求改了两天
  • 让 Agent 操作桌面应用:走无障碍树比截图省 5 倍,但省的不是最关键的
  • 发表评论

    ◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。