成本估算与监控

通过API集成大型语言模型会带来直接的运营成本，这种成本通常随使用量增加。与传统软件主要成本可能固定（如服务器托管）不同，LLM应用程序的成本会根据API调用的数量和复杂程度而波动。未能预估和跟踪这些成本可能导致预算超支，并使应用程序在财务上难以维持。因此，了解定价机制并主动跟踪使用情况是应用程序开发周期的主要组成部分。

了解LLM定价模型

大多数商业LLM提供商根据处理的文本量收费，通常以tokens（令牌）衡量。务必记住，一个令牌不完全是一个单词；它通常是子词 (subword)单元。对于英文文本，一个常见的经验法则是1个令牌大约相当于4个字符或约0.75个单词，但这可能会因语言和模型使用的具体分词 (tokenization)器 (tokenizer)而有很大不同。

典型定价模式的几个重要方面包括：

1. 输入令牌与输出令牌： 许多提供商会区分发送给模型（提示词 (prompt)、上下文 (context)和输入数据）的令牌和从模型接收（生成的完成内容）的令牌的成本。通常，输出令牌比输入令牌更昂贵，这反映了生成过程中的计算投入。
2. 模型层级： 能力更强或更大的模型通常每个令牌的成本比更小、更快的模型高。为您的任务选择合适的模型是管理成本的直接途径。对简单任务使用最强大的模型可能会导致不必要的开销。
3. 上下文窗口大小： 具有更大上下文窗口（允许更长的提示词和历史记录）的模型可能具有不同的定价结构或层级。
4. 附加功能： 一些提供商可能会对微调 (fine-tuning)、图像输入处理或专用部署等功能收取额外费用。

务必查阅您所用LLM提供商（例如OpenAI、Anthropic、Google、Cohere）的具体定价页面，以获取最准确和最新的信息。价格可能会有所调整，并且不同提供商和模型之间差异可能很大。

开发期间的成本估算

在部署应用程序之前，估算潜在成本是明智的。这包含了解每次API调用的成本和预期的使用模式。

令牌计数

第一步是确定您的典型提示词 (prompt)和预期完成内容包含多少令牌。

• 提供商工具： 许多API提供商提供在线分词 (tokenization)器 (tokenizer)工具或计算器，您可以在其中粘贴文本并根据其特定模型查看令牌计数。
• 库： 您可以使用库以编程方式估算令牌计数。例如，OpenAI为Python提供了tiktoken库，该库允许您在本地计算其模型的令牌：

import tiktoken

# 适用于 gpt-3.5-turbo 和 gpt-4 等模型的示例
encoding = tiktoken.get_encoding("cl100k_base")

prompt_text = "Translate the following English text to French: 'Hello, how are you?'"
completion_text = "Bonjour, comment ça va ?"

prompt_tokens = len(encoding.encode(prompt_text))
completion_tokens = len(encoding.encode(completion_text))

print(f"Estimated prompt tokens: {prompt_tokens}")
print(f"Estimated completion tokens: {completion_tokens}")

# 输出 (示例，具体数字可能略有不同):
# Estimated prompt tokens: 15
# Estimated completion tokens: 7

计算请求成本

一旦您能估算输入和输出的令牌计数，并且知道提供商的每令牌定价，就可以计算单次API请求的成本。

令 $C_{in}$ 为每输入令牌成本，$C_{out}$ 为每输出令牌成本。 令 $T_{in}$ 为输入令牌数量，$T_{out}$ 为输出令牌数量。

单次请求的成本（$Cost_{req}$）可估算为： $Cost_{req} = (T_{in} \times C_{in}) + (T_{out} \times C_{out})$

例如，如果：

• $C_{in}$ = $0.0005 / 1K 令牌 =$0.0000005 / 令牌
• $C_{out}$ = $0.0015 / 1K 令牌 =$0.0000015 / 令牌
• $T_{in}$ = 500 令牌
• $T_{out}$ = 150 令牌

则： $Cost_{req} = (500 \times 0.0000005) + (150 \times 0.0000015)$ Cost_{req} = 0.00025 + 0.000225 = $0.000475

这看起来可能不多，但如果每月有成千上万甚至数百万次请求，成本就会变得非常可观。

估算应用程序级别成本

要估算应用程序的总成本，请考虑：

• 每次请求的平均令牌数： 根据典型用例进行估算。
• 每个用户会话的请求数： 用户通常与LLM交互多少次？
• 活跃用户数： 您预期有多少用户？
• 使用频率： 用户每天、每周或每月与应用程序交互的频率如何？

预测总成本需要将平均请求成本乘以给定时期（例如一个月）内估计的总请求数。创建一个简单的电子表格模型来调整这些变量并了解潜在的成本范围通常很有帮助。

跟踪使用情况和成本

“估算很有用，但使用情况务必仔细跟踪。”

1. 提供商控制面板： 您跟踪实际支出的主要工具是LLM API供应商提供的控制面板。这些控制面板通常显示按模型、API端点和时间段细分的使用情况。它们是计费信息的权威来源。请熟悉可用的报告和分析。

2. 应用程序级别日志： 在您的应用程序内部实现日志记录，以记录每个API调用的详细信息。这应包含：

   • 时间戳
   • 使用的模型
   • 输入令牌计数（如果API响应中可用或估算）
   • 输出令牌计数（通常在API响应中返回）
   • 调用延迟
   • 发起请求的用户或会话标识符（如果适用）
   • 触发调用的特定功能或工作流标识符

   这些细粒度数据使您能够分析哪些功能或用户群体是成本的主要来源，发现潜在的低效率，并将使用量激增与应用程序活动联系起来。

3. 预算和警报： 大多数云和API提供商都允许您设置预算并配置警报。为您的LLM API使用量设置月度预算，并创建警报，以便在支出接近或超过特定阈值（例如预算的50%、90%、100%）时通知您。这可以作为防止意外成本飙升的保护措施。

4. 定期分析： 不要只设置监控；定期审查使用数据。寻找趋势：

   • 成本增长是否快于用户增长？这可能表明效率低下。
   • 特定功能是否成本过高？
   • 某些用户是否产生了异常高的成本？
   • 在特定时间是否有意外的激增？

   这种分析有助于您就优化措施做出明智的决定。

成本优化策略

尽管像缓存这样的详细优化技术会在其他地方介绍，但请考虑这些与成本相关的策略：

• 模型选择： 使用满足给定任务质量要求的成本最低的模型。评估更简单的任务是否可以使用更便宜的模型来处理。
• 提示工程 (prompt engineering)： 更短、更有效的提示词 (prompt)可降低输入令牌成本。
• 输出长度控制： 在适当的情况下，使用max_tokens等参数 (parameter)限制生成响应的长度（和成本）。
• 缓存： 存储并重复使用相同或非常相似请求的响应（下一节介绍）。
• 批处理： 如果API支持且您的应用程序逻辑允许，在单个批次中发送多个请求有时会更高效，尽管这在基于聊天的模型中不太常见。
• 防抖/速率限制： 防止用户在短时间内意外或故意进行过多的调用。

下图显示了基于不同模型层级的每令牌定价，模型选择如何对成本产生很大影响。

不同模型层级每百万令牌（输入+输出平均）的成本比较。请注意成本轴上的对数刻度，这显示了明显的成本差异。

管理LLM API成本并非一次性任务，而是一个持续的过程。通过了解定价模型、主动估算、勤奋跟踪并应用优化策略，您可以构建出功能强大且在财务上可持续的LLM应用程序。