当 Token 越来越便宜，账单为什么越来越贵？- VPSSpark

2023 年，GPT-4 API 每百万输入 Token 要价 $30。2024 年底，同等智力水平的模型已跌到 $3 以下。2025 年，Claude Haiku 级别的模型每百万 Token 不到 $1。如果你只看「单价」，应该感到高兴——AI 正在大幅降价。

但如果你打开上个月的账单，很可能会皱眉：怎么比去年贵了？

这不是你的错觉，也不是哪家厂商在坑你。这是一条已有 160 年历史的经济学定律在 AI 时代的最新重演——它叫 Jevons 悖论（Jevons Paradox）。

核心结论

Token 单价每跌一半，你的用量通常会涨 3—5 倍。单价下降带来的「节省」被更大的用量完全抵消，账单不降反升。

−97%

GPT-4 级模型
单价 2023→2026

10×

同期平均
Token 用量增幅

3×

开发者 AI 月账单
同期平均增幅

Jevons 悖论：越便宜，用越多

1865 年，英国经济学家 William Stanley Jevons 在研究煤炭时发现了一个反直觉的现象：蒸汽机的效率每提升一次，煤炭的总消耗量不降反升。原因是效率提升降低了使用成本，反而催生了更多的应用场景——原来用不起蒸汽机的工厂用起来了，原来只开一条线的工厂开了三条线。

「节约了每单位的消耗」并不等于「节约了总消耗」。这就是 Jevons 悖论：当一种资源变得更高效（或更便宜），对它的总需求往往会增加，而非减少。

Token 的故事完全相同。单价每跌一个数量级，就有一批原本被「太贵了」这道门槛挡在外面的用例被解锁：

单价 $30/M 时，你只用 AI 写周报摘要。
单价 $3/M 时，你开始用 AI 做代码 Review。
单价 $0.3/M 时，你开始让 AI 跑后台 Agent、处理客服工单、每小时扫一次日志。
单价 $0.03/M 时，你把整个工作流都喂给它，并且忘了关闭。

每一次降价都不是让你「省钱」，而是让你「敢用更多」。账单的绝对值于是在单价不断下降的同时，悄悄向上爬。

账单膨胀的三个真实推手

Jevons 悖论解释了「为什么」，但要控制账单，你需要知道钱究竟烧在哪里。在 AI API 账单里，有三个结构性的膨胀源。

推手一：用量膨胀——从「偶发询问」到「常驻后台」

两年前，典型的 AI 用量是「我有问题时才问」。今天，随着 Cursor、OpenClaw 这类 Agent 工具普及，AI 已经从「被动应答」变成了「主动执行」：它在你睡觉时跑 CI 分析，在你开会时整理代码仓库，在你吃饭时处理用户反馈。

这一转变意味着调用频率从「一天几十次」膨胀到了「一天几千次」。即使每次调用的单价只有原来的十分之一，几千次的总量仍然让账单轻松翻倍。

用法阶段	典型调用频率	每次 Token 量	月度 Token 总量
问答辅助（2023）	30 次/天	~500 tokens	~450K tokens
代码 Review（2024）	200 次/天	~3,000 tokens	~18M tokens
后台 Agent 常驻（2025+）	2,000 次/天	~8,000 tokens	~480M tokens

注意最后一行：用量从 450K 跳到 480M，是一千倍的增长。即使 Token 单价同期跌了 90%，账单仍然会是 2023 年的 100 倍。

推手二：上下文暴涨——每次请求的 Token 数不可同日而语

更隐蔽的账单杀手不是「调用次数」，而是「每次调用的体积」。

2023 年，GPT-3.5 的上下文窗口只有 4K tokens。一次对话撑死传几百字的问题加几轮历史记录。今天，Claude Sonnet 支持 200K context，Gemini 2.5 Pro 直接开放 1M context。开发者不再小心翼翼地「裁剪上下文」，而是直接把整个代码库、整份 PDF 文档、完整的对话历史塞进去——毕竟「反正现在模型能看」。

上下文的隐性成本

把一个 500KB 的代码文件塞进 prompt，大约等于 125,000 tokens——比 2023 年一整个月的典型用量还多。如果你的 Agent 每次请求都携带完整上下文，账单会呈指数级膨胀，而不是线性增长。

更棘手的是「extended thinking」（深度推理）模式。Claude 3.7 Sonnet 的 thinking 模式在生成最终答案之前，会先产生大量内部推理 tokens——这些 thinking tokens 同样计费，而且往往比最终输出还多。一次「深度分析」的实际消耗可能是你以为的 5—10 倍。

推手三：Agent 乘数——Token 不是加法，是乘法

这是账单膨胀最猛、最难预见的来源。

在「问答」模式下，一次请求就是一次请求，Token 消耗是线性叠加的。但在 Agentic 工作流里，一个用户请求会触发一整条调用链：

图 1 · 一个「简单」Agent 请求的内部调用链

用户发送一条指令「帮我审查这个 PR 并给出修改建议」

Orchestrator Agent规划子任务，分配给多个子 Agent → 1 次 LLM 调用

子 Agent ×4读取代码、搜索文档、检查测试、生成评论 → 4 次 LLM 调用（每次含完整上下文）

汇总 + 重试Orchestrator 整合结果，如遇错误自动重试 → 2-3 次 LLM 调用

用户发出了 1 条指令，实际消耗了 7—8 次 LLM 调用，每次调用都携带大量上下文。这就是「乘数效应」——你以为你按了一次按钮，账单上记了八行。

更危险的是无限循环的 Agent：当 Agent 遇到错误时会自动重试，当任务没有明确终止条件时会持续执行，当两个 Agent 互相等待对方时会死锁并同时占用算力。一个写错了 termination condition 的 Agent，一觉醒来可能给你留下一张几百美元的账单。

真实踩坑

某开发者在 CI 流水线里接了一个「自动修复失败测试」的 Agent，忘记设置最大重试次数。一次偶发的 flaky test 触发了 Agent 循环，8 小时内产生了 2,300 次 LLM 调用，账单 $340。模型价格已经非常便宜，但乘数够大时，任何价格都能打出大数字。

把账单拆开看：一道让人清醒的算术

假设你今天的 AI 使用场景是：每天跑 10 个 Agent 任务，每个任务平均触发 8 次 LLM 调用，每次调用平均 10,000 tokens（含上下文）。

参数	数值
每天 Agent 任务数	10
每任务 LLM 调用次数（乘数）	8
每次调用 Token 量	10,000
每月总 Token 量	10 × 8 × 10,000 × 30 = 24M tokens
单价（Claude Sonnet 级，$3/M）	24M × $3/M = $72/月
若用更贵模型（$15/M）	24M × $15/M = $360/月

$72—$360/月，只是一个开发者的日常工作流。如果团队有 10 人，或者 Agent 任务数翻倍，数字会直接乘过去。账单的大小不再由「我有没有用 AI」决定，而是由「乘数链有多长」决定。

让账单可控：不是少用，而是有意识地用

Jevons 悖论的教训不是「别用」，而是「用对结构」。煤炭用量增加本身不是坏事，带来了工业革命；Token 用量增加本身也不是坏事，带来了效率革命。问题是：这些账单有没有产生对等的价值？

以下是三个可以立刻实施的控制手段，按实施成本由低到高排列：

方法一：分层路由——用便宜的模型做大量工作

不是所有任务都需要最强的模型。「判断这段代码有没有语法错误」和「设计整个系统架构」对智力的要求差了一个数量级，但如果你对两者都用 Claude Sonnet，账单也差了一个数量级。

建议按任务复杂度分三档：

格式化、摘要、简单分类：用 Haiku / GPT-4o-mini 级别，单价约 $0.15—$0.3/M，速度也最快。
代码生成、多步推理、文档撰写：用 Sonnet / GPT-4o 级别，单价约 $3—$5/M，性价比最高。
架构设计、复杂调试、需要 extended thinking：用 Opus / o3 级别，按需调用，不作为默认。

实施方式：在 LiteLLM 这类 Gateway 里定义模型别名（fast / smart / deep），客户端按任务类型路由，主密钥和路由逻辑放在云 Mac 的 Gateway 上统一管理——可参考 Cloud Mac + OpenRouter 保姆级实战里的三层路由方案。

方法二：预算熔断——在 Token 烧光之前拉闸

分层路由解决的是「用对模型」，预算熔断解决的是「用量失控」。Agent 循环、意外重试、无终止条件的长任务——这些不是理论风险，是每个认真使用 Agent 的开发者迟早会踩的坑。

最低限度需要两层保护：

上游 credit cap：在 OpenRouter、Anthropic 控制台直接设置月度硬限额，超出后 API 直接拒绝请求，不会默默扣费。
Virtual Key 级 spend cap：在 LiteLLM 这类自托管 Gateway 里，给每个客户端（Cursor、OpenClaw、脚本）各发一把 Virtual Key，分别设独立的月预算。某个工具失控时，只烧自己的配额，不影响其他工具。

LiteLLM Virtual Key 创建示例（API）

curl -X POST http://127.0.0.1:4000/key/generate \
                  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
                  -H "Content-Type: application/json" \
                  -d '{
                    "key_alias": "cursor-dev",
                    "models": ["fast", "smart"],
                    "max_budget": 20,
                    "budget_duration": "1mo",
                    "metadata": {"tool": "cursor", "env": "dev"}
                  }'

上面这个 Virtual Key 月消费上限是 $20，只能调用 fast 和 smart 两个模型别名，超出后自动熔断并返回 429，主 Key 不受影响。这是「个人企业级」治理的最小可行版本。

方法三：日志可视化——你不知道钱烧在哪，就没法省

很多账单问题是「事后才发现」：月底对账单，发现某个 Agent 在上周五安静地烧掉了 $50，但任务早就跑完了。问题不是 Agent 做错了什么，而是你没有实时的 spend 视图。

最简单的可观测性方案：

LiteLLM 内置 Dashboard：litellm --detailed_debug 启动后，访问 /ui 可以看到每个 Virtual Key 的实时 spend、请求量、平均延迟。
每日 spend 告警：用 cron 每天跑一次 sqlite3 litellm.db "SELECT key_alias, spend FROM litellm_verificationtoken"，超过阈值时发 Slack 消息（OpenClaw 接入 Slack 可以做这件事）。
上游账单对齐：每周把 LiteLLM 本地 spend 和 OpenRouter / Anthropic 控制台账单对比一次，差异超过 10% 时说明有「漏网请求」——某个工具绕过了 Gateway 直连上游。

可观测性的价值

上线 spend 监控的团队，平均在第一个月就能找到 20—30% 的「无效消耗」：运行后从未读取结果的 Agent、每次携带全量上下文却只需要最后 5 行的脚本、以及被遗忘在 cron 里的旧任务。

真正的问题不是「怎么省钱」

Jevons 悖论有一个经常被忽视的另一面：他并没有说「效率提升是坏事」。蒸汽机效率提升、煤炭总消耗增加——但英国也因此完成了工业革命。

同理，Token 越来越便宜、你的 AI 账单越来越高，并不一定是坏事。真正需要问的问题是：

多出来的这些 Token，有没有产生等价或超额的价值？
账单里有多少是「有意识的投入」，有多少是「无意识的浪费」？
你有没有一个可视化的系统，能随时回答上面两个问题？

「节约 Token」的目标是错的。「每一个 Token 都花在刀刃上」才是对的。分层路由、预算熔断、消费可视化——这三件事加在一起，不是为了让你用得少，而是为了让你知道自己在用什么、用在哪里、值不值得。

Token 还会继续变便宜。账单也还会继续涨。但如果你建好了这套治理结构，至少涨的是「值得涨的部分」。

FAQ

Jevons 悖论会永远成立吗？在「效用无上限的资源」上，Jevons 悖论通常成立——AI 推理能力几乎可以无限地替代人力，所以价格每降一档，用例就会解锁一批。当 AI 能力触及真正的天花板（比如「已经比所有人都强了，再便宜也没有新用例」），悖论会失效。但那一天目前看不到边。

我能靠「换便宜模型」来控制账单吗？短期有效，但不可持续。一旦你发现便宜模型够用，你会把省下来的预算用到更多任务上——又回到了 Jevons 的轨道。持续有效的控制手段是「预算约束 + 可视化」，而不是「模型降级」。

Agent 乘数效应能消除吗？不能完全消除，但可以控制。关键是：① 给每个 Agent 任务设置明确的最大步骤数/最大调用次数；② 用「结果缓存」避免重复执行相同子任务；③ 在 Orchestrator 层做「是否需要 LLM」的判断——很多步骤用规则引擎处理比调用 LLM 便宜几百倍。

团队规模扩大后账单会更难控制吗？会。人越多，「谁在用什么模型跑什么任务」越难追踪。这时 Gateway 层的 Virtual Key 隔离和 per-user spend cap 就从「最佳实践」变成了「必须有」。建议在团队超过 3 人之前就搭好 Gateway，否则迁移成本会更高。