对话的平方成本：为什么 AI 聊天支出呈超线性增长

一次 10 轮的对话成本并不是单轮对话的 10 倍，而是接近 55 倍。这是大多数团队在建模 AI 功能的单位经济效益（unit economics）时最容易犯的错误，也是为什么一个在表格上看起来有利可图的产品在生产环境中却在不断亏钱的原因。

错误在于将对话视为一系列独立的请求。事实并非如此。由于 LLM API 是无状态的，每一轮对话都会重新发送累积的全部历史记录。第一轮发送 1 个单位的上下文，第二轮发送 2 个，第十轮发送 10 个。整个会话中计费的总 Token 数是 1 + 2 + ... + N 的总和，其增长趋势为 N²/2 —— 即平方级增长 —— 而你的产品几乎肯定收取的是固定的线性价格。

那些最喜欢你产品的用户，正是那些进行最长对话的用户。他们也是在悄无声息中摧毁你利润空间的人。

那些没被写进融资演示文稿的数学题

让我们从公式开始。一个对话有 N 轮。每一轮增加大约 S 个 Token 的新内容 —— 包括用户消息和模型响应。到第 k 轮时，你发送给模型的输入是 System Prompt 加上之前所有的 k-1 轮内容，再加上新的消息。整个会话中计费的输入 Token 总数为：

k 从 1 到 N 的累加 (System Prompt + (k-1)·S) ≈ N·(System Prompt) + S·N(N-1)/2。

第二个术语才是致命伤。它是关于 N 的二次方（平方）。而大多数人估算时采用的第一项，仅仅是线性的。

举个具体的例子。假设每一轮增加 1,000 个 Token。对于一个 20 轮的会话，简单的“每轮预估”会得出 20,000 个输入 Token。但实际累计输入约为 210,000 个 Token —— 是预估值的 10 倍以上。如果你进行到 50 轮，每一次调用都在重新处理 15 万 Token 的历史记录。到第 100 轮时，运行上下文可能超过 30 万 Token，而在第 101 轮时，这每一位 Token 都要再次付费。

这就是为什么“平均每请求 Token 数”是 AI 成本仪表盘中最危险的指标之一。平均值被短会话所主导，因为大多数会话都很短。但 支出 却被长尾会话所主导，因为每个会话的成本随长度的平方而增加。少数几个 80 轮的高级用户会话在账单上的权重，就能超过数千个 3 轮的会话，而对平均值的贡献却微乎其微。看起来平静的指标背后，隐藏着真正致命的数据。

你最好的用户是你最糟糕的客户

这部分可能会让产品经理感到不安：参与度曲线和成本曲线是重合的。

在固定费率订阅（AI 聊天产品的主流定价模型）中，每个用户无论使用多少都支付相同的价格。这背后的隐含假设是“健身房会员模型”：轻度用户补贴重度用户，最终达到平均平衡。这种模型在重度用户的边际成本有界时是奏效的。但在对话式 AI 中，这个成本是无界的，它是平方级的。

那些与你的产品进行 60 轮深度沟通的用户正在获得巨大的价值。他们也是最有可能续费、最愿意推荐、最常出现在你案例研究中的用户。而他们消耗的成本不是普通用户的 20 倍，而是接近 400 倍，因为他们的会话长度处于 N² 曲线最糟糕的一端。固定定价将你最有价值的客户变成了亏本引流的“负资产”，而且这种转变是无声的，因为标准的分析漏斗中没有任何一项能显示“按会话长度划分的单会话成本”。

随着模型迁移，情况会变得更糟。Token 价格每年都在下降，这诱使团队假设问题会自行解决。事实并非如此。用户在最新、最强的前沿模型发布那一刻就会迁移过去，而前沿模型从来都不便宜。推理模型（Reasoning models）进一步加剧了这个问题：它们会产生大量的中间推理 Token，这些 Token 同样会进入计费历史。当单 Token 成本线呈下降趋势时，单会话成本线却在上升，因为会话长度和模型能力的增长速度都快于价格下降的速度。

为什么 Prompt 缓存救不了你

标准的第一反应是 Prompt 缓存（Prompt Caching），我们需要准确理解为什么它的作用有限。

缓存作用于稳定的前缀。供应商允许你标记 Prompt 的前端 —— 通常是 System Prompt 和其他固定的模板 —— 这样在缓存命中时，重新读取该前缀可以享受巨大的折扣（通常约 1 折）。如果你的 System Prompt 很大且保持不变，缓存确实大有裨益。

但回过头看成本公式。缓存攻击的是线性项 —— 即 N·(System Prompt) 部分。它对平方项几乎无能为力。不断增长的对话历史并不是一个稳定的前缀：每一个新的用户消息、工具结果和推理轨迹对于该轮来说都是唯一的，并且是首次出现。它从未被缓存过，因为它之前从未存在过。你可以将 到目前为止 的对话缓存为 下一轮 的前缀，这在边际上有所帮助，但缓存的 TTL（生存时间）很短，且任何编辑、分支或重试都会导致从编辑点开始的前缀失效。

缓存是一项真正的优化，但它不是结构性的解决方案。N(N-1)/2 这一项依然存在，而且这一项是无限制增长的。

将会话长度视为一等约束

解决方法不是某种单一的技巧。它需要你决定将会话历史视为一种带有预算的受管资源，就像操作系统对待内存那样，而不是一个任由其增长直至溢出的追加日志。

以下是一些模式，大致按实现成本排序：

• 滑动窗口截断（Sliding-window truncation）。 只保留最近的 K 轮；随着新轮次的加入丢弃最旧的内容。这几乎是免费的，它将平方级成本压平为线性成本，因为一旦达到窗口大小，计费历史就不再增长。代价是“健忘”：模型会忘记早期的上下文和早期决策背后的逻辑。这对于浅层的支持聊天没问题，但对于长程推理任务很危险。

• 摘要检查点（Summarization checkpoints）。 当历史记录超过某个阈值（例如目标预算的 70-80%）时，将较旧的部分压缩成一段精炼的摘要，只保留最近几轮的原文。这在限制 Token 数量的同时保留了长会话的大意。代价是额外的一次摘要调用以及在衔接处可能损失的一些保真度。这是严肃的长程助手产品的核心模式。

• 分层压缩级联（Tiered compression cascades）。 最健壮的生产系统不会只选一种策略。它们会先压缩冗长的工具输出，然后应用滑动窗口，最后才调用 LLM 摘要作为最终手段。每一层都比下一层更便宜，因此最昂贵的选项运行频率最低。

• 带有优雅移交的硬上限（Hard caps with graceful handoff）。 当一个会话确实无法以可负担的成本继续时，主动结束它 —— 保存状态快照，告知用户，并提供一个携带摘要的新线程。诚实的边界总好过无声的利润流失。

无论你选择哪种方式，架构的核心点是一样的：上下文压力必须是 可观测的。在你的仪表盘中针对会话长度监控计费的输入 Token 数。绘制分布图，而不是平均值。一旦你能看到 N² 曲线，截断与质量之间的权衡就会变成一个刻意的工程决策，而不是你在收到账单时才发现的意外。

定价必须承认曲线的存在

工程手段可以压平平方曲线，但不能免费让它变成线性的 —— 每一种缓解方案都在用质量或延迟换取 Token。因此，定价模型必须吸收剩下的压力。

纯粹的固定费率定价与平方级成本基础在结构上是不匹配的。现实的选择是具备“用量感知”能力的定价：对于长会话消耗更快的信用积分池、感知长度的阶梯定价，或者是“固定基础费 + 超额计量”的混合方案。每种方案都有信任成本 —— 用户不喜欢无法预见的计量，尤其不喜欢怀疑某个功能被刻意限制是为了推销超额包。这种信任成本是真实存在的，值得仔细管理。但它仍小于每个高级用户账户上背负的无限制增长债务的成本。

对于产品团队来说，诚实的认知应该是：对话不是一系列消息，而是一个在每一轮都要重新计费的上下文窗口。那些在仪表盘、缓解方案和定价中内化了 N²/2 逻辑的团队，才能构建出经得起自身成功考验的功能。而那些根据平均值进行估算的团队，其产品表现最好的一周，往往就是财务团队开始介入质询的那一周。