GenAI FinOps：Token 定价的运作方式

MofCloud
FinOps
12 Aug, 2025

对于 FinOps（财务运营）从业者来说，生成式 AI（GenAI）所宣传的每 Token 价格具有误导性；真正的成本隐藏在细节之中。在我们系列文章的第一部分，曾将“Token 定价的模糊数学”作为云 FinOps 与 GenAI FinOps 的一个关键区别。现在，让我们来揭示那些看似简单的价目表背后隐藏的成本，它们仅仅是复杂冰山的一角。理解这些细微之处，对于管理 GenAI 的支出增长至关重要。

事实上，只关注每百万 Token（MTok）的简单成本，就像仅凭汽油价格来判断一辆车的成本，而忽略了引擎类型、驾驶习惯或维护保养等细节。或者，在云服务领域，这类似于解读存储中的 IOPS（每秒输入/输出操作）成本——表面上很简单，但由于各种操作细节（峰值负载、块大小、存储卷大小等），最终变得异常复杂。一个 GenAI 应用的真正**总拥有成本（TCO）**是由那些很少出现在供应商主页上的因素所驱动的。

本文将剖析 Token 定价真正的运作方式，揭示那些甚至能让经验丰富的 FinOps 专业人士都感到惊讶的隐藏成本。我们将重点关注两个关键点：**“上下文窗口税”（Context Window Tax）**的巨大影响，以及为什么“最便宜”的模型往往不是最经济的选择。

并非所有 Token 都一样

从基本层面来看，生成式 AI（GenAI）模型是根据处理的 Token（即文本的小块）数量来收费的。但 Token 的价格并非固定不变，它会根据 Token 的类型和作用而有显著差异。

输入与输出的成本差距

输入 Token（你发送给模型的数据）和输出 Token（模型生成的数据）之间存在显著的价格差异。生成一个回复比仅仅读取一个提示需要更多的计算量。因此，输出 Token 的定价通常更高，其成本常常是输入 Token 的三到五倍。这对于那些需要生成长篇回复的应用场景（如摘要或创意写作）会产生直接影响。

模态溢价

文本是最便宜的数据形式。随着你转向其他模态（如图像或音频），价格会急剧攀升，这反映了所需的额外处理能力。解释一张图片所需的成本，可以轻易达到解释同等数量文本的两倍。音频甚至更贵，一些旗舰模型的音频输入收费是文本输入的八倍多。

当模型接收图像作为输入并将其“查看”作为生成回复的一部分时，就会产生视觉定价。模型提供商通常不会将视觉定价作为单独计费的单位，而是将图像转换成文本 Token 并以此方式收费。将图像转换为 Token 的算法是提供商独有的，非常复杂且变化频繁。

模型层级税

毫不意外，你需要为性能付费。一个提供商最先进、最尖端的模型会有最高的每 Token 价格。而其更小、更快的“主力”模型则会便宜得多。这就建立了一个清晰的层级关系，即成本通常与推理能力直接相关。

最大的隐藏成本：上下文窗口膨胀

如果这篇文章你只记住一点，那就是：大多数生产环境中的 AI 应用最大的隐藏成本是上下文窗口膨胀。

大多数大型语言模型（LLM）的 API 是无状态的。这意味着模型对过去的交互没有记忆。要进行一个连贯的多轮对话（比如与聊天机器人），你必须在每一条新消息中都重新发送****完整的对话历史。

想象一下，每当你想要增加一个新的句子时，你都必须从头开始重复整个对话。这正是你的 API 调用内部发生的情况。

以一个简单的客户服务聊天机器人为例：

第 1 轮（用户）： “你们的退货政策是什么？”（5 个 Token）
第 2 轮（机器人）： “你可以退回商品…”（50 个 Token）
第 3 轮（用户）： “国际订单怎么办？”（6 个 Token）

为了处理第 3 轮，应用程序不仅仅发送 6 个新 Token。它发送的是整个历史记录：【第 1 轮用户 + 第 2 轮机器人 + 第 3 轮用户】，总计 61 个输入 Token。随着对话的继续，每一轮新对话的输入 Token 数量都会急剧膨胀，成本也随之水涨船高。这种因维持上下文而不断升级的成本，就是上下文窗口膨胀。在一个长期的对话中，这种膨胀的成本很容易就会使实际生成的输出成本相形见绌，从而导致令人震惊且意想不到的成本超支。

如果你的系统提示（system prompts）或其他上下文内的护栏很长，这种情况会更加严重，因为它们作为输入 Token，在每一条消息中都会被发送。

这就造成了一个理解 GenAI 支出的悖论： 尽管单个输出 Token 的价格通常比输入 Token 贵约 300%，但输入 Token 累积的巨大数量意味着在任何对话式应用中，它几乎总会占据你总支出的主导地位。请注意，这同样适用于 LLM 之间的“对话”，例如在智能体系统中。

上下文窗口膨胀也为多媒体带来了隐藏的重复成本。当你在对话的第一轮发送一张图片时，你会产生一笔视觉处理费用。但这并非一次性收费。因为这张图片成为了对话历史的一部分，在后续的每一轮中，你都会为同样的视觉处理费用被悄悄地再次收费。这可能尤其具有隐蔽性，因为视觉成本通常与文本 Token 成本捆绑在一起。

上下文窗口膨胀揭示了 GenAI 运营中的一个关键隐藏成本： 因维持对话历史而产生的不断累积的 Token 数量。这种成本会随着交互时间的增长呈指数级增长，并强调了深入理解 Token 使用机制对于有效预测和管理支出的必要性。

GenAI 成本优化技术

提示词缓存

缓存指的是对数据进行临时存储，以便在未来的请求中能够更快地访问，而无需多次处理相同的输入。提示词缓存分为两种类型：隐式缓存和显式缓存。

隐式提示词缓存

隐式提示词缓存必须由模型提供商（如 OpenAI、Anthropic、Azure 等）启用。提供商会使用算法来检测上下文窗口中是否存在重复的 Token 模式，并自动启用缓存以节省 GPU 的利用率，从而降低成本。这项功能无需从业者进行任何操作，它会自动发挥作用来降低成本。

显式提示词缓存

显式提示词缓存则要求用户有意地将上下文放入缓存中。当你不想依赖模型提供商的算法来确保缓存命中时，这项功能非常有用，但使用起来可能比较棘手。其计费模式通常是，先收取一笔“写入”内容的预付费用，这笔费用通常高于将相同数据作为输入发送给 LLM 的每 Token 成本。随后的 API 调用可以在该缓存的生命周期内以大幅折扣“读取”这些缓存内容。

每个提供商的缓存生命周期细节各不相同，这需要从业者进行盈亏平衡的计算。如果你从缓存中读取的次数不足以抵消最初较高的写入成本，那么你实际花费的钱会比完全不使用缓存更多。因此，这是一个强大的工具，但需要仔细分析使用模式，以确保它确实能为你省钱。

语义缓存

虽然提示词缓存能带来成本效益，但从业者还可以探索 “语义缓存”（semantic caching）。它根据提示词的含义或语义相似性 来存储 AI 的回复。与需要精确输入匹配的简单提示词缓存不同，语义缓存根据请求的含义（而非完全相同的 Token）来存储和检索回复。

语义缓存利用向量嵌入（vector embeddings）来识别和检索相关的缓存回复，即使输入略有不同，也能有效减少 Token 的处理量和相关成本。

当你有高频率的输入，且这些输入会产生相同的输出时，语义缓存是最佳选择。例如，一个客服聊天机器人有大量常见问题，且这些问题都有固定的答案。通过对这些问题进行语义缓存（而不是简单的提示词缓存），当用户提出本质上相似（但措辞不完全相同）的问题时，系统将直接输出缓存中的回复，而无需与大型语言模型（LLM）进行往返通信以生成新回复。

在特定的使用条件下，语义缓存可以带来最高的成本节约。

批量处理

对于非紧急任务，比如分析一批文档，模型提供商通常会为异步处理提供大幅折扣，折扣力度常常超过 50%。这是一种强大的成本节约工具，但它要求你将应用程序设计为能区分实时工作负载和批量工作负载。

批量处理的工作负载不会像典型的 API 调用那样以 Token 流的形式返回；相反，它们会在 24 小时内以文件的形式交付。你可以利用这项功能，用一半的常规成本，来尝试各种不同的模型和/或提示组合，从而获取非生产工作负载的比较数据样本。批量处理是一项必须由模型提供商提供的功能，而不是模型本身具备的。

为什么“最便宜”的模型并非总是最经济的选择

为了省钱而默认选择每 Token 价格最低的模型是很诱人的。然而，一个更便宜但能力较弱的模型，可能需要更长、更复杂的提示词才能产生好的结果。它也可能需要更多的重试，或者生成冗长、低质量的输出，需要进一步的精炼。

你需要考虑的是获得一个成功结果的总成本。定义“成功结果”可能是一个挑战，这将是未来博客的主题。一个更强大、“昂贵”的模型可能能够理解一个简单的提示词，在第一次尝试时就给出正确答案，并提供一个简洁、准确的回复。这次单一的成功交易总 Token 成本，可能远低于从一个“更便宜”的模型中费力地获得一个可用答案所累积的成本。

因此，应以业务价值和成功结果为优化目标，而不仅仅是 Token 的原始成本。

提供商：从哪里购买至关重要

最后，你用来访问模型的平台可以从根本上改变其成本结构。这不仅仅关乎每 Token 的价格，而是与为不同客户需求量身定制的整体经济模型有关。

超大规模云服务商（Azure, AWS, GCP）：企业级封装

这些平台为大型企业提供了云生态系统内的企业级安全、合规和集成服务，尽管成本较高，但提供了极大的便利和价值。

值得注意的是，即使是同一个开源模型，不同供应商之间的定价也可能存在显著波动。从历史经验来看，不同供应商的价格差异可能高达 30%。此外，这里还存在一些隐性因素需要考量，例如推理速度、模型的量化（quantization）、被截断的上下文窗口长度，以及提供商允许模型在回复前进行“思考”步骤的推理工作量。

超大规模云服务商也提供了为运行模型预置容量的选项，但不同云服务商之间的定价差异非常复杂。

真正的度量单位：使用案例

大型语言模型的一个有趣之处在于，即使是相同的提示词，不同的模型也可能产生不同数量的输出 Token。这种可变性意味着两个模型可以用不同的方式解释和生成对同一输入文本的回复。

尽管 Token 很有意思，但它们终究只是整个拼图的一小部分。要真正理解利用 AI 实现某个业务成果的总拥有成本（TCO），唯一的方法是衡量整个使用案例。

一个使用案例是完成给定结果所需的完整流程，它可以是一个自主智能体、一个数据处理管道，或是任何涉及一系列 GenAI 调用和工具的工作流。一个典型使用案例可能需要多个 AI 模型协同工作，以及传统的云资源来托管所使用的数据。

这使得 FinOps 的关注点从 Token 成本转移到使用案例的单位经济效益。由于每次运行的 Token 数量都不同，而且复杂的用例可能涉及在回复前进行“思考”的推理模型，因此每个单元的成本并不是一个固定价格，而是一个分布区间。有时一次交易可能只花费一美分的一小部分；而另一些时候，它的成本可能要高得多。

此外，使用案例的单位经济效益对变化极其敏感。调整一个提示词、更换一个模型，或改变底层数据架构，都可能以惊人的方式改变成本分布。这意味着要理解真正的 TCO，需要工程和财务团队之间进行深入且持续的协作。只有通过共同努力，他们才能将技术变革与由此产生的单位经济效益变化联系起来，从而确保每个由 AI 驱动的使用案例都具有财务可行性。