实测：Claude Haiku 5.5 成本竟是 GPT-6 Luna 的12倍

一场关于廉价模型的意外翻车

当 Anthropic 推出被定位为"最便宜"的 Claude Haiku 5.5 时，不少开发者期待它能摆脱 Claude 系列长期被诟病的"token 吞噬者"形象。然而一位 Reddit 用户用经典的 voxel pagoda（体素宝塔）测试给出了一个令人意外的结论：在完成同一个任务时，Claude Haiku 5.5 的成本竟是直接竞品 GPT-6 Luna 的 12 倍。

这个结果之所以值得深入讨论，是因为它揭示了一个常被忽视的事实——模型的"单价便宜"和"实际使用便宜"完全是两回事。定价表上的数字，远不足以反映真实工作负载下的开销。

测试数据：差距来自哪里

测试者选择了业界常用的 voxel pagoda 生成任务，两个模型均在 atomic.chat 平台通过各自订阅接入，并均设置为 xhigh 推理强度。实测数据如下：

模型	推理强度	输入 token（缓存）	输出 token	API 等效成本
Claude Haiku 5.5	xhigh	268.8M（262.7M）	4.46M	$24.96
GPT-6 Luna	xhigh	64.5M（61.1M）	1.18M	$1.96

从数据可以看出两重差距叠加。首先是 token 消耗量本身：Haiku 5.5 的输入 token 高达 2.688 亿，是 Luna（6450 万）的四倍多，输出 token 也接近四倍。这印证了测试者的判断——Haiku 依旧是个"token goblin"（token 妖怪），并没有如期望般变得精简。

真正的成本黑洞：100k 上下文后的5倍计费

如果只是 token 多了四倍，成本差距不至于拉到12倍。测试者指出，真正的罪魁祸首是 Claude Haiku 5.5 在上下文超过 100k token 后，API 价格会直接翻五倍。

这个阈值在实际的 agent（智能体）工作流中几乎形同虚设。在一个连续的 agent 会话里，几乎每一轮对话的上下文都会轻松突破 10 万 token，这意味着绝大多数请求都在以五倍单价计费。四倍的 token 量再乘以频繁触发的五倍计费，最终叠加出了那个惊人的12倍成本差。

相比之下，GPT-6 Luna 的高价计费阈值被设定在 272k token，门槛高出近三倍。更关键的是，在默认配置下，Luna 到达该上限时会自动进行上下文压缩（auto-compact），从机制上主动规避了触发高价区间的风险。

阶梯式上下文计费（tiered context pricing）是近年大模型 API 普遍采用的定价策略：供应商以某个 token 长度为分界线，低于该长度按标准单价计费，超过后切换到更高单价。这一设计的商业逻辑在于，处理超长上下文对算力（尤其是 KV cache 显存）的消耗远超线性增长，因此供应商倾向于通过价格信号让开发者主动控制上下文长度。对于以单次问答为主的应用，阈值往往不会被触达；但在 agent 场景中，每一轮工具调用的结果、历史对话、系统提示都会被拼入上下文窗口并随轮次线性累积，导致几乎每次请求都处于高价区间。因此，阶梯计费的实际影响完全取决于应用的上下文增长模式，而非模型的标价本身。

对开发者的现实启示

这次对比给实际构建 AI 应用的开发者提供了几条值得记住的经验。

定价阈值比单价更重要。 很多模型采用阶梯计费，低上下文时单价诱人，但一旦跨过某个 token 门槛，成本会非线性飙升。在选择模型前，务必确认这个阈值在哪里，以及你的典型工作负载是否会频繁越过它。

Agent 场景放大一切成本。 单次问答可能永远触不到 100k 的红线，但 agent 会话会不断累积上下文。如果你的产品形态是多轮自主执行的智能体，上下文增长模式几乎决定了最终账单。

自动压缩机制是实打实的省钱设计。 Luna 的 auto-compact 并非锦上添花，而是在高价阈值处主动踩刹车的关键功能。缺乏类似机制的模型，需要开发者自行实现上下文管理来控制开销。

需要说明的是，本文结论来自单一 Reddit 用户的 voxel pagoda 测试，样本有限，不同任务类型下的表现可能存在差异。但它清晰地传递了一个判断：评估模型成本时，不能只看每百万 token 的标价，而要把 token 消耗效率、计费阈值和实际工作负载模式综合起来算一笔总账。对于把"最便宜"写在宣传语里的模型，这笔账尤其值得自己亲手算一遍。

上下文压缩（context compression / auto-compact）是指在上下文窗口接近某一阈值时，自动将历史对话或中间推理结果进行摘要或截断，以减少后续请求的 token 数量。其本质是以少量信息损失换取大幅降低的计费成本。实现方式可分为两类：模型服务商在 API 层面内置的自动压缩（如 Luna 的 auto-compact），以及开发者在应用层自行管理的显式压缩——例如周期性地调用一次摘要请求替换原始历史记录。前者对开发者透明但灵活度低，后者需要额外工程投入但可精细控制压缩时机与策略。对于没有内置压缩机制的模型，开发者若不主动介入，上下文将无限增长，最终持续触发高价阈值。