被忽略的成本武器

2026 年，主流大模型的上下文窗口普遍达到百万 token 级别。产品讨论的焦点往往是「能不能塞进整本书」「能不能分析全量代码库」。但少有人讨论一个问题：百万级上下文的单次调用成本是多少？

我算了一笔账。假设你的产品日活 10 万，人均日对话 5 轮，平均每轮上下文长度 50K token。以当前主流 API 定价，日均模型成本轻松突破五位数。这个数字还没算 embedding、RAG 检索、安全审核的叠加成本。

更隐蔽的是：上下文窗口越大，用户越倾向于往里塞更多东西——冗余的历史对话、无关的参考文档、重复的指令。这些"垃圾 token"你不仅要为它们付费，它们还会稀释模型的注意力，降低输出质量。

AI 产品的三种成本结构

传统 SaaS 的边际成本趋近于零——多服务一个用户的服务器开销几乎忽略不计。AI 产品则完全不同，每次推理都有真实的计算消耗。我把市面上的 AI 产品归纳为三种成本模型：

模型一：固定成本型

自部署开源模型，推理在自有 GPU 集群上完成。成本结构类似传统 SaaS——有固定基础开销，边际成本很低但不是零。

适合场景：用户量大、调用模式稳定、对延迟和可控性有高要求。

模型二：线性成本型

调用商业 API，按 token 计费。每多一个用户、每多一轮对话都会同步增加成本。毛利和用户增长强相关。

适合场景：MVP 阶段快速验证、非高频使用场景、或者用户付费意愿足够覆盖 API 成本。

模型三：混合型

简单任务走自部署小模型，复杂任务调用商业大模型 API。通过智能路由控制成本。

适合场景：有多层次任务复杂度的产品，这是 2026 年越来越多团队采用的方案。

产品层的成本优化策略

成本优化不是后端的事。产品经理在功能设计阶段做的选择，直接决定了日后的成本曲线。

策略一：上下文剪枝

你应该为用户设计一个「对话精华」机制，而不是让他们无限追加历史消息。可以在 UX 层做：

  • 超过 10 轮的对话，自动折叠早期消息并提供摘要
  • 文件上传后，只保留与当前问题相关的片段进入上下文
  • 系统指令系统指令控制在必要长度内，避免"预防性冗余"

策略二：缓存命中

高频相似问题，缓存上一轮的推理结果。不是简单的 key-value 缓存，而是语义相似度匹配。当用户问「帮我写一封催款邮件」和「帮我写一封收款提醒」，本质上是一个需求，可以复用基础输出加微调。

策略三：用量可视化

给用户一个使用额度仪表盘——不是为了制造焦虑，而是让重度用户理解服务的成本结构。当用户看到「本月已消耗 80 万 token」，他们天然会减少不必要的长篇追问，而这恰恰会提升对话的精准度和效率。

成本意识的真正价值

AI 产品经理不需要会算 GPU 集群的折旧，但需要能回答三个问题：

  • 一个活跃用户的日均成本是多少？
  • 这个成本随着用户增长是线性还是指数级变化的？
  • 用户愿意为此付多少钱？

如果第三个问题的答案小于第一个问题的答案，产品的问题不是成本太高，而是价值太薄。