AI 的成本全是错觉 —— 用「点数 / 订阅 / 压缩」拆解你的「Token 经济」
引子：史上第一位「AI 节目主持人」,其实根本不是 AI
1985 年 4 月 4 日,英国 Channel 4 的电视电影《Max Headroom: 20 Minutes into the Future》里,出现了一个号称「世界第一」的角色——「世界首位电脑生成的电视主持人」Max Headroom(马克斯·黑德罗姆)。他说话一卡一卡的,声音时不时断片,背景跑着数字噪点,一看就是「电脑在说话」的那种感觉。
可这是一场宏大的错觉。里面其实是真人演员 Matt Frewer。乳胶和泡棉特效化妆、隐形眼镜、玻璃纤维做的西装——光化妆每次就要四个半小时。真正用 CG 做的只有「背景」,主体是个大活人。靠刺眼的灯光和后期剪辑,硬把人「装」成 CG(Wikipedia)。
术语注:Max Headroom … 1985 年英国电视里的虚构角色,世界首个号称「电脑生成」的电视节目主持人。在华语圈知名度不高,这里你只需记住:它表面上是 AI,实际是人扮的——一个故意制造出来的「假 AI」。
术语注:CG(电脑图形,Computer Graphics) … 用计算机生成的图像。Max Headroom 玩的是「全做成 CG 的样子,其实全靠人力」——以当年的技术来说,这是一种反方向、特别费工的演出。
四十年过去,我们在 AI 这件事上,还在不停地把「外表」和「实体」搞混。尤其是成本。点数显示、订阅账单、按 token 计费——你的直觉一次次被骗。
这篇文章,讲的是我在短短一天里真真切切踩过的三个成本错觉,我会用一手信息(亲身经历、实测日志、官方来源)把它们一层层拆开。作为技术话题这不算花哨,但一旦你能从「结构」上理解「自己到底为什么、付了多少钱」,你用 AI 的方式本身都会改变。
术语注:token(令牌) … LLM(大语言模型)处理文字的最小单位,粗略可以理解为「词的碎片」。一个汉字也可能被切成多个 token。计费和速率限制都以 token 数为基准。请先记住:AI 的成本既不是先按人民币算、也不是先按美元算,而是先按「token」在跑的。
错觉① 单价陷阱 ——「我问 AI 价格,它把数字多报了两个数量级」
某天,我把 Agent 功能(让 AI 自动连轴转干活的模式)跑了半天,余额显示变成了 6,333.14 点(credit)。「一点」到底是多少钱?我一时手痒,干脆问了提供这服务的 AI 本身。
术语注:点数(credit,信用点) … 服务内部使用的自有货币。它和真实货币(人民币、美元)的兑换比率由服务方决定,所以屏幕上的数字和真实成本之间,永远隔着一层「缓冲(一道换算手续)」。直觉之所以失灵,原因就在这里。
我:「6,333.14 点是多少钱?」
AI:「1 点 = 1 美元。所以 6,333.14 点 = 6,333.14 美元。」
……约合九千多美元(按约 7.2 的汇率折人民币约 4.5 万元)。半天烧这么多,这是出事故了。我当场血压飙升。
赶紧去问客服,正确答案是——
客服:「100 点 = 1.00 美元。6,333 点约合 63.33 美元(约人民币 460 元)。」
整整差了 100 倍。而且这误差恰好就是 100 倍 =「点 / 美元」的兑换比率本身。这不是汇率问题,是 AI 把 1 点 = $1 和 100 点 = $1 搞反了——单位搞错,直接变成了两个数量级的惊吓(真是哭笑不得)。
从这一例能引出的教训,看似不起眼,其实挺重
- 在我这一个例子里,AI 在「自家的资费」这个一手信息上,把数字错了两个数量级。 我不会就此推广成「AI 一定会出错」;但只要 LLM 本质上是个「按概率生成看起来最像那么回事的字符串」的装置,它在数值和自我指涉(关于它自己的事实)上出错的可能性就是结构性、永远存在的。所以:涉及数值、涉及它自身的回答,绝不能照单全收。
-
「点数」这个单位本身,就是一种「让真实成本看不见」的 UX 设计。 当
人民币 → 点 → 美元中间夹了两层缓冲,用户就没法凭一瞬间的直觉判断贵还是便宜了。是否有意为之,从外部无法验证;但从结构上说,它确实让真实成本更难看清(类似游戏里的「钻石充值」)。如果是故意的,这就属于「暗黑模式(dark pattern)」那一类设计。
比喻在哪儿会失效:我说它「像游戏钻石充值」,但游戏的钻石是一次性用掉,点数是按工作量逐渐消耗——两者并不一样。它们唯一的共同点,只是「真实成本无法凭直觉读出」这一条。
—— 先喘口气 ——
「单价和直觉对不上」,这是第一个错觉。下面反过来,我要用实测,推翻另一种错觉:「我是不是付太多了?」
错觉② 包月的真正价值 ——「我用够本了吗?」该怎么正确解读
我用的是 Claude(Anthropic 公司的 AI),订的是 Max 套餐 20x(每月 200 美元,约人民币 1,450 元)。某天我突然犯嘀咕:「钱不算少,这玩意儿……我回本了吗?」
这里关键的一点是:像 Max 这样的包月套餐,本质不是「计量表」,而是「速率限制」。
术语注:按量计费(计量表) … 用多少算多少钱,出租车模式。
术语注:速率限制(rate limit) … 「每 5 小时 / 每周,最多用到这里」的速度上限。没用掉的额度不能结转,过期就清零。类似电力合同里的「安培数(最大同时用电量)」。
术语注:订阅(包月) … 每月固定金额,在上限内随便用。
所以「用够本了吗?」其实有两层意思:(A) 回本了吗(价值),和 (B) 撞到上限了吗(消耗)。这两者很容易混为一谈,但完全是两码事。
我实测了一下
要衡量「价值」,只要算「假如这些用量改用 API 按量计费,要花多少钱」就行。我把本地积攒的自己的使用日志(约 54,000 条消息),按现行的 API 官方单价换算了一遍。
| 期间 | 折算成 API 的成本 | 相对于每月 200 美元的倍数 |
|---|---|---|
| 本月(截至 20 日) | 约 6,400 美元 | 约 32 倍 |
| 按 30 天节奏外推 | 约 9,600 美元 | 约 48 倍 |
| 上月 | 约 2,920 美元 | 约 15 倍 |
单价依据:Claude Opus(Max 套餐里主力的高端模型)若走 API,输入 $5 / 输出 $25(每百万 token)。而 Max 是固定包月。折算下来光本月就跑出了 32 倍的工作量。每月约 1,450 元的合约,若按量付费相当于跑了近 100 万日元(约人民币 4.8 万元)级别的量。
注意:这个 32 倍,是「长时间 Agent 自动作业」这类重负载特有的数字。 如果是平常以对话为主的用法,因为缓存复用吃不上,倍数会小得多。而且,如后文所说,这个换算是把全部用量都按高端模型 Opus 的单价来估的,属于偏上限的算法——实际应当把混在里面的便宜模型(如 Sonnet)那部分打个折来读。
……到这里,要执行「数字异常漂亮时,先怀疑它的构成」(honest disclosure,诚实披露)
32 倍是真的,但不拆开构成,就会高估。换算金额里,约有一半是缓存读取。
术语注:prompt 缓存(提示词缓存,prompt cache) … 当你反复发送同一段上下文时,从第二次起可以按约 1/10 的单价复用。长时间的自动作业里,这种缓存读取量极其庞大(我这边达到了 90 亿 token)。
也就是说,是「90 亿 token × 超低单价」把金额顶了上去。这不是注水,而是「真按官方 list 价格计费就是这个数」的正确换算。但比起「单价 × 总量」的朴素算法,看清「谁是支配项」才是诚实的读法。支配项是「缓存读取的 90 亿 token」,因此请记住:这个倍数强烈依赖于缓存复用 = 强烈依赖于负载类型(workload-dependent)。
结论:(A) 钱完全回本了(32 倍)。(B) 是否撞到上限则是另一回事——如果「已达使用上限」频繁弹出,说明顶到天花板了;如果不弹,说明还有余力。要分这两层来读,才算正确。
与 FullSense 的关联:从设计上「原理性地」杜绝「账单无上限」的惊吓
我正在开发的 FullSense,口号是「能在自家电脑上运行的、有责任感的、爱多管闲事的 AI 生态系统」,由三个相互独立的开源项目组成。它根子上的设计理念是本地优先(local-first)——个人信息、企业机密、传感器数据,一律不往外发。
这个「错觉②」,从背面照亮了「本地优先」的价值。按量计费那种「账单无上限」的惊吓(跑半天就烧出几万块!?),在本地运行下原理上不会发生——因为「电费」这个上限会物理性地兜住。云端 AI 的「方便,但账单读不准」的焦虑,对比本地 AI 的「慢,但可预测」——我认为,这正是普及与否的分水岭。
—— 以上讲的是「已经在花的成本」。下面进入「在掏钱之前就先把它减下来」——
错觉③ 在掏钱之前先减量 ——一个叫「Headroom」的开源项目,以及名字里的妙处
第三个错觉,是「token 在送进模型之前,其实是可以减量的」这一发想上的盲区。很多人想当然地以为「用了就只能付」。
正好戳中这一点的,是 Netflix 的资深工程师 Tejas Chopra 在 2026 年 1 月公开的开源项目 Headroom(github.com/chopratejas/headroom,Apache-2.0 许可证,更新活跃;截至 2026-06-21 已有 ★4 万以上、处于 v0.2x 系列,The Register 也做了报道)。星数和版本变动很快,最新情况请以官方仓库为准。
它到底做什么
它是夹在你的应用和 LLM API 中间的一层「上下文压缩层」。在 Agent 把内容送进 LLM 之前,它会把工具输出、日志、文件、RAG 片段、对话历史,按内容智能地压缩。
- content-aware(内容感知)压缩:JSON 数组只保留异常值,构建日志只保留报错行。冗余的机器元数据、反复出现的 JSON schema、重复的模板,比人类写的散文好压得多——它正是冲着这块下手。
- 可逆:在压缩处留下标记,原文保留在本地,模型若需要可以把原始数据再调回来(仓库里把这叫「可逆压缩 = CCR」)。在公开基准(GSM8K / TruthfulQA / SQuAD v2 / BFCL 四种)上,报告称精度基本维持不变。
- 实现:提供 Python/TypeScript 库 / 透明代理 / 面向 Claude Code 等 Agent 的 wrapper(包装层) / MCP 服务器,侵入程度可自选。实现用 Python/Rust 写成,针对不同对象用不同的专用算法(JSON 专用、代码专用、训练好的压缩模型等等)。
官方号称 token 削减 60~95%(GitHub 说明里也写明了)。据 The Register 报道(2026-05-31 时点的官方推算),所有用户合计节省了约 70 万美元、2,000 亿 token。
术语注:RAG 片段(RAG chunk) … RAG(检索增强生成)是指「先去检索、把查到的参考资料喂给 LLM」的做法;「片段」就是检索回来的那一块块参考文档。它作为「资料」塞给 LLM,是吃 token 的主犯之一。
术语注:MCP 服务器 … MCP(Model Context Protocol,模型上下文协议)是把外部工具/数据接到 AI 上的一种标准协议;「MCP 服务器」就是该协议的一个具体实现端。
……到这里,同样要怀疑它的构成(honest disclosure,诚实披露)
那个抢眼的「95%」是上限值。我诚实地把注意事项列出来:
- 95% 说的是「机器输出占多数的输入」。 因为对象是日志、JSON、重复 schema 才有效。对人类散文(普通文章),削减幅度要小得多。 官方自己也承认「机器输出比人类散文更好压缩」。
- 压缩率越高,精度的安全余量就越薄。 在公开基准里也给出了这样的条件:SQuAD v2 是「压缩 19% 时精度 97%」,BFCL 是「压缩 32% 时精度 97%」——也就是说,压缩率和精度是此消彼长(trade-off)。所以并不是「无论什么输入,削掉 95% 精度都不变」——同一份输入下,「削 95%」和「精度维持」无法同时成立。
- 「same answers(回答不变)」是基准上的主张。 既然它是基于内容感知的启发式(经验法则,heuristic),那么比如在安全 / 取证用途里,被判为「冗余」而删掉的日志行里,可能恰好残留着检测信号——这个风险是存在的。采用之前,应当用你自己的数据去验证「删了之后结果不掉」。
- 它还处在 v0.x。迭代很快,但要上生产环境,需自行验证。
名字里的妙处:AI 史绕了一圈,押上了韵
而且这个工具——官方没有给出命名由来的说明,但笔者读来,名字是在向 Max Headroom 致敬。headroom 在技术语境里本就是「余量 / 余地」的通用词,作为「给 token 上限腾出『余量(headroom)』的工具」名也很自然——在此之上,它和开头那位「初代 AI 主持人(其实是人力 = 错觉)」形成了双关。这巧合得简直过分。
于是构图就成了这样——四十年前,一个「装成 AI 的人」(Max Headroom)登场;四十年后,一个「借了它名字的工具」(Headroom),在削减 AI 成本的错觉。 初代是「制造错觉」的一方,当代是「削减错觉」的一方。命名绕了一圈,正好咬合(这纯属笔者的解读,开发者本人并未明说)。
三层模型:把「你为什么、付了多少钱」拆开来看
三个错觉,其实只是**「付费对象」所处的层不同**而已。整理一下就是下面这样(表格最后一行,是本文作为「第四层」提到的架构层)。
| 层 | 错觉的真面目 | 有效对策 |
|---|---|---|
| 单价层(点数 / token 价格) | 显示的错觉(点数的两层缓冲) | 换算成真实货币,把直觉找回来 |
| 计费模型层(包月订阅 vs 按量计量) | 结构的错觉(「用够本了吗?」被搞混) | 价值 = API 换算倍数 / 消耗 = 速率天花板,分开来测 |
| 预处理层(压缩) | 忽视了「还能减」的余地 | 用 Headroom 等,在送进模型之前先削 |
| 架构层(llcore) | 「保持成本」的错觉(内存随 token 数成正比膨胀) | 用线性 attention 把状态固定为常数,长文本下内存也不膨胀 |
而 FullSense / llcore 瞄准的,是位于这之下的第四层。
- 架构层:我正在开发的研究框架「llcore」,正在探索把 Transformer 的注意力机制,替换成常数状态的线性 attention,使「保持上下文所需的内存」不再随 token 数成正比。
大白话:普通的 attention,上下文越长,就得一直抱着「过去的全部」,所以记忆成本越涨越高。线性 attention 把这份记忆卷进一个固定大小的状态里,因此长文本下内存也不容易膨胀。不过,正因为「卷起来了」,细节被漏掉是有可能发生的——这就是「压缩着保存」这个比喻会失效的地方。
Headroom(预处理层)和 llcore(架构层)不是竞争,而是互补。Headroom 负责「减少要读的量」,llcore 负责「降低保持的成本」。它们对准的是同一颗北极星「token 效率」,只是处在不同的高度。两个轮子一起转,才有合力。
实务处方
把错觉拆穿之后,给出现实的行动方式。
- 按量 API(自己调 API 的应用)→ 引入 Headroom 降低真实成本。 这里减下来的是真金白银。Apache-2.0、本地代理,所以不会多增加对外发送(和「本地优先」理念也很合)。
- 包月订阅(Claude Code 等)→ 减的不是钱,而是「速率额度的余量」。 Headroom 官方提供了 Claude Code 的 wrapper。token 减少 = 更不容易撞到「每 5 小时 / 每周」的天花板,这就是字面意义上的 headroom(余量)。
- 先测,再说别的。 把自己的使用日志按 API 换算,算出价值倍数。然后——一旦跑出异常漂亮的数字,在得意之前,先怀疑它的构成(我那 32 倍,也有一半是缓存)。
结语:养成「把外表和内核分开看」的眼睛
AI 的成本,既不取决于屏幕上显示的单价,也不取决于月底账单上的数字,而是由**「结构」**决定的。点数这种呈现方式、是包月还是按量这种计费模型、以及「送进去之前还能削」的预处理余地——任何一层,只要被「外表」牵着走,判断就会出错。
四十年前的 Max Headroom 教给我们的,归根结底就是这句话——把花哨的外表(错觉)和朴素的内核(实体),分开来看。就像那位一卡一卡、一脸未来感的 AI 主持人,其真身不过是个涂了四个半小时妆的人。
FullSense 高举的「本地优先」「honest disclosure(诚实披露)」,正是为此而备的工具。在为账单发慌之前,不妨把自己的 token 经济,从结构上盘点一次。多半你会发现,成本的真身,和你以为的并不在同一个地方。
参考
- Headroom(OSS,Tejas Chopra):https://github.com/chopratejas/headroom
- The Register 报道(2026-05-31):https://www.theregister.com/ai-ml/2026/05/31/netflix-wiz-creates-app-to-slash-ai-bills-then-open-sources-it/5248702
- Max Headroom(Wikipedia):https://en.wikipedia.org/wiki/Max_Headroom
- FullSense / llive 设计理念:https://qiita.com/furuse-kazufumi/items/cab6bb47a72ebedf5436
本文中的数值(点数换算、Max 套餐的 32 倍、token 构成明细)均基于笔者的亲身经历及自身使用日志的实测。此外,Headroom 的星数、版本、节省金额等外部数值,是写作时点(2026-06)公开信息的取值,均会变动。AI 套餐的资费、速率限制、开源项目的规格变动都很剧烈,做采用决策时请以各官方的最新信息为准。