杰文斯悖论：为什么算力会永远不够

杰文斯悖论 / Jevons Paradox
中文：把一样东西变便宜，往往不会让它被用得更少，反而更多。
EN: Make something cheaper and you usually get more of it consumed, not less.

我们来聊个有点反直觉的事：算力一定会越来越便宜，但我们只会越来越觉得它不够用，而且恰恰是因为它变便宜了。

为什么要问这个问题

我们先来看一个挺让人困惑的事实。

过去两年，单位 token 的推理价格大概掉了两个数量级。同样的 GPT-4 级能力，今天的价钱是发布时的几十分之一。按常理，单价跌成这样，GPU 应该没那么紧张了才对（同一块卡现在能干以前好几块卡的活）。

可你我都知道现实是反的：模型越便宜，H100 越难抢，云上的配额越紧，越来越多团队咬牙自建集群。

便宜，没有缓解稀缺，反而加剧了稀缺。

这事听起来违反直觉，但它一点都不新鲜。一个英国人在 1865 年就把它讲透了，讲的还不是芯片，是煤。

它从哪来

1865 年，威廉·斯坦利·杰文斯写了《煤炭问题》。

当时英国正享受蒸汽机效率的飞涨。瓦特那台改良蒸汽机，烧同样的煤能干的活比老式机器多得多。所有人都觉得这是好事，逻辑很顺：机器越省煤，国家烧的煤就越少，英国的煤能用更久。

杰文斯说，错了，而且错得很彻底。他给出的事实是：蒸汽机越省煤，英国烧的煤越多。

不是多一点，是多很多。省煤的技术没有省下煤，它把煤的消耗推上了一个新台阶。

为什么？这就是整件事的核心。

核心直觉

把”效率提升”翻译成”降价”，悖论就不再是悖论。

蒸汽机变省煤，本质是用蒸汽干活这件事变便宜了。东西一便宜，会发生一件关键的事：那些原本因为太贵而根本不会去做的事，突然变得划算了。以前不值得上蒸汽的工厂上了，铺不起的铁路铺了，抽不起水的矿井开始抽水了。

于是需求不是温和地涨，是整片整片地被解锁。新用途冒出来的速度，远远盖过单位能耗下降的速度。

记一个简单的乘法就够了：

总消耗 ＝ 单次消耗 × 使用次数

效率把左边这个数压下去了，但它通过降价，把右边那个数撑大了好几倍、甚至几十倍。两个一乘，总量不降反升。

graph LR
  A[效率提升 = 变便宜] --> B[原本不划算的事变得划算]
  B --> C[需求被整片解锁]
  C --> D[使用次数暴涨]
  D --> E[总消耗反而更高]
  E -.涨上来的需求又催生新场景.-> B

注意那条虚线。这不是一次性的调整（新需求本身会催生更多用途，用途又拉动更多需求），而是个会自己滚大的循环，不是踩一脚刹车就能停的事。

这里有个前提，记住它，后面要用：这一切只在需求有弹性时成立。也就是说，降价得真能勾出大量新需求才行。如果一样东西的需求已经到顶（比如你家一年吃多少盐是固定的），再便宜也勾不出新用途，杰文斯效应就不发生。

映射到 AI：算力就是今天的煤

把”煤”换成”算力”，杰文斯写的那本书，今天可以一字不改地重印。

最直接的是推理。token 单价崩了，于是从前舍不得调大模型的地方，现在毫不犹豫地调：每个 PR 自动 review，每条日志自动打标，每个用户消息实时摘要。这些在 token 贵的时候想都不会想，现在成了默认操作。

Agent 把这件事推到了极致。这里有个细节，值得我们盯一下：一次 Agent 任务背后，藏着几十甚至上百次 LLM 调用（推理一次、反思一次、调一次工具、失败了再重试几次）。单次调用越便宜，工程师在设计 Agent 时就越敢”多调几次”：多让它反思一轮、多塞点上下文、多兜底重试。于是单次成本下降被调用次数的暴涨吃得干干净净，还倒贴。

所以开头那个悖论的答案，到这里已经很清楚了：

推理框架每优化一截（量化、KV-cache、投机解码、更好的 batching），单卡吞吐就上一截，单位成本就降一截——然后需求立刻涌上来，把你腾出来的容量吃光。

这就是为什么我们优化得越好，集群反而越满。这不怪你，这就是杰文斯。它牵扯到一件对 Infra 工程师特别重要的事，我们单独拎出来讲。

工程师视角：别拿”优化省下的容量”做容量规划

前面都在讲道理，这一节落到我们一个具体的动作上。

很多容量规划是这么算的：当前负载 ÷ 新的单卡效率 ＝ 需要多少卡。优化让效率涨了 30%，于是结论是”我们可以少买 30% 的卡”或者”现有的卡能多扛 30% 的量”。

这个算法在杰文斯面前几乎一定会翻车。 因为它假设需求是固定的，而我们刚做完的优化，恰恰会把需求勾上来。实际会发生的是：优化上线，单位成本降了，产品侧（可能就是隔壁组）发现”诶，这能力现在便宜到可以默认全量打开了”，调用量两周内翻几倍，把我们省出来的容量连本带利吃光。

正确的姿势是：容量按”这次降价会解锁多少新需求”来估，而不是按”当前负载除以新效率”来估。 给爆发留 headroom，而不是把省出来的空间当成可以省下的预算。我见过太多”优化完反而更缺卡”的复盘，根因都在这。

至于 Agent 工程师，同一个道理换个地方咬我们：便宜会诱导我们把 Agent 设计得越来越啰嗦。记得主动给它设个预算上限（每个任务最多调几次、上下文最多多大），否则成本会跟着能力一起失控，而且一开始根本察觉不到，等账单来了才知道。

投资视角：这条链解释了一个矛盾现象

杰文斯也是理解 AI 算力这门生意的一把钥匙，而且它和”模型都白菜价了，卖铲子的还能有什么搞头”那种直觉正好相反。

链条是这样的：

推理变便宜 → 调用量暴涨（更多场景、更多 Agent）→ GPU 需求不降反升 → 云算力需求上升 → 更上游的 HBM、先进封装、甚至电力，跟着一起紧张。

这就解释了那个表面上矛盾的画面：模型 API 在疯狂降价的同一时间，GPU、云、电力却在持续吃紧。 降价不是需求的终点，是需求的起点。

绕回到我们写代码这件事：这条链给工程师的真正启示，不是”该买哪只股票”，而是一个该刻进系统设计里的判断：算力会长期稀缺，把它当成永久约束，别当成临时困难。 别写”等卡便宜了、等配额松了再来优化”这种 TODO，那一天不会来。受限才是常态，那就按受限来设计。

生活视角：你早就见过它了

这套机制不只在机房里。

洗碗机省了你洗一次碗的力气，结果你不是省下时间去干别的，而是用更多的碗、洗得更勤，反正”洗碗”这件事变便宜了。修一条更快的路，短期省时间，长期却让大家搬得更远，通勤总时间一点没少（城市规划里管这叫”诱导需求”，本质就是杰文斯）。

最扎心的一个：你用上了更快的 IDE、更聪明的代码补全，结果不是早点下班，而是被默认”你现在应该能写更多代码了”。

把这个想明白，对你设计 AI 工具其实很重要：省下来的产能，会被更高的预期吃掉。 所以当你做一个”帮工程师提效”的 AI 功能时，值得我们诚实地问自己一句：我到底是在帮人省时间，还是只是在悄悄抬高对他的要求？这个问题的答案，往往决定了这个功能是被爱还是被恨。

常见误解

最容易记歪的一点：

杰文斯悖论 不是“效率提升一定会让总消耗增加”。

它的准确说法是：在需求有弹性的前提下，效率提升可能让总消耗增加。 是”可能”，不是”必然”，而且挂着条件。把它当成铁律到处套，会闹笑话。

另一个误解更危险：把它读成”所以优化没意义”。恰恰相反，优化极其有意义（它解锁了海量原本根本不存在的价值）。杰文斯从来没说”别优化”，它说的是另一件事：别指望优化能让你少买资源。 优化的回报是解锁新东西，而不是省下旧开销，这两件事我们得分清楚。

什么时候不成立

知道一个模型什么时候失效，比记住它本身更值钱。杰文斯不成立的关键，就是需求没有弹性，也就是降价勾不出新需求：

需求已经到顶的时候。盐再便宜你也不会多吃。有些内部工具的调用量就是固定的，模型再降价，调用次数也不会涨，这种场景下，优化是实打实地省钱，没有反噬。

真正的瓶颈不在你优化的那一环的时候。如果你的系统卡在数据质量、卡在某个牌照、卡在人，那把推理成本压再低，也引爆不了需求，因为用户的脚卡在别处。

用量被硬封顶的时候。合规要求、预算硬上限、监管配额，需求想涨也涨不上去。

判断方法简单到一句话：**”这玩意要是再便宜 10 倍，会有人想多用吗？而且想用的地方多吗？”** 答案是”会，而且有的是地方”，杰文斯就成立；答案是”不会，就这么多需求”，就不成立。AI 推理显然是前者，这正是为什么这个一百多年前的悖论，在今天格外刺眼。

相关模型

杰文斯不是孤立的，它挂在一张网里。下面这些是同一张网上的邻居（这些文章我会陆续补上）：

• 机会成本 / Opportunity Cost：算力变便宜，真正改变的是”这块卡该拿去干什么”的排序。
• 供需 / Supply & Demand：杰文斯说到底，是一个关于需求弹性的故事。
• 正反馈 / Positive Feedback：新需求催生新场景，是个自我放大的环。
• 诱导需求 / Induced Demand：修路和扩集群，是同一个剧本。

一句话记住

中文：效率不会消灭稀缺，它只是把稀缺挪个地方。所以别等算力变便宜——它便宜下来的每一分，都会被你解锁的新需求重新吃掉。
EN: Efficiency doesn’t kill scarcity; it just relocates it. So don’t wait for compute to get cheap—every bit of cheapness gets eaten by the new demand you just unlocked.