计算与预测 API 成本
编写 Python 辅助程序,在发送请求前通过统计令牌数量并应用各模型的定价来估算成本,避免收到意外账单。
计算与预测 API 成本 是 CoddyKit 上的免费 AI Engineering Academy 课时。 这是第 3 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 AI Engineering Academy 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 AI Engineering Academy 课程共包含 4 节课。
为什么成本预测很重要
当 LLM 应用达到一定规模后,API 成本可能会高得令人意外。一次看似只需 0.002 美元的查询,运行 100,000 次后就会变成 200 美元。如果没有成本预测和监控,AI 功能可能产生出乎意料的云账单,其金额甚至会超过您全部基础设施支出的总和。
好消息是,在发送请求之前,LLM 成本完全可以预测:您知道所使用的模型,可以使用 tiktoken 计算输入令牌数,还可以根据 max_tokens 设置或历史平均值估算输出令牌数。从第一天起就将成本预测纳入应用,可以避免账单带来的意外。
OpenAI 的定价结构
OpenAI 会分别对输入令牌和输出令牌收费,输出令牌的价格通常高出 3~4 倍。价格因模型而异。以下是 2025 年的参考价格(价格会变动,请始终查看当前定价页面):
- gpt-4o-mini:输入约 0.15 美元/百万令牌,输出约 0.60 美元/百万令牌
- gpt-4o:输入约 2.50 美元/百万令牌,输出约 10.00 美元/百万令牌
- text-embedding-3-small:约 0.02 美元/百万令牌
模型之间的成本差异非常大:按输入令牌计算,gpt-4o 的价格约为 gpt-4o-mini 的 17 倍。模型选择是控制成本最有效的手段——请始终从满足质量要求的最便宜模型开始。
成本估算辅助函数
请构建一个在发送任何请求前调用的成本估算器。它使用 tiktoken 计算输入令牌数,根据 max_tokens 参数估算输出令牌数,查询每个模型的单价,并返回以美元计的预估成本。请在开发过程中调用它并记录结果,从而逐渐了解不同查询类型的成本。
import tiktoken
# Prices per million tokens as of early 2025
PRICING = {
'gpt-4o': {'input': 2.50, 'output': 10.00},
'gpt-4o-mini': {'input': 0.15, 'output': 0.60},
'gpt-4-turbo': {'input': 10.00, 'output': 30.00},
'text-embedding-3-small': {'input': 0.02, 'output': 0.0},
}
def estimate_cost(messages, model='gpt-4o-mini', expected_output_tokens=500):
enc = tiktoken.encoding_for_model(model)
input_tokens = sum(
len(enc.encode(m.get('content', ''))) + 4
for m in messages
) + 3
if model not in PRICING:
raise ValueError(f'Unknown model: {model}')
rates = PRICING[model]
input_cost = (input_tokens / 1_000_000) * rates['input']
output_cost = (expected_output_tokens / 1_000_000) * rates['output']
total = input_cost + output_cost
print(f'Model: {model}')
print(f'Input tokens: {input_tokens} (${input_cost:.6f})')
print(f'Est. output tokens: {expected_output_tokens} (${output_cost:.6f})')
print(f'Estimated total: ${total:.6f}')
return total从 API 响应跟踪实际成本
每次 API 调用后,响应对象都会包含实际使用的令牌数量。请提取这些数据,记录实际成本,并将其与预估值进行比较。随着时间推移,预估输出令牌数与实际输出令牌数之间的差距,可以告诉您使用量预测得有多准确;而这些记录则可以提供按功能或用户群体划分的成本明细。
import openai
client = openai.OpenAI()
PRICING = {
'gpt-4o-mini': {'input': 0.15, 'output': 0.60},
}
def chat_with_cost_tracking(model, messages):
response = client.chat.completions.create(
model=model, messages=messages
)
usage = response.usage
rates = PRICING.get(model, {'input': 0, 'output': 0})
actual_cost = (
(usage.prompt_tokens / 1_000_000) * rates['input'] +
(usage.completion_tokens / 1_000_000) * rates['output']
)
print(f'Input: {usage.prompt_tokens} tokens')
print(f'Output: {usage.completion_tokens} tokens')
print(f'Total: {usage.total_tokens} tokens')
print(f'Actual cost: ${actual_cost:.6f}')
return response, actual_cost预测每月成本
知道每次请求的平均成本和预期请求量后,预测每月成本就很简单了。请构建一个成本模型电子表格或简单的 Python 脚本,以便测试不同的假设:如果每日活跃用户数量翻倍会怎样?如果我们增加一项功能,使每次用户操作发起 3 次 API 调用而不是 1 次,会怎样?
def project_monthly_cost(
avg_cost_per_request,
requests_per_day,
days=30
):
daily_cost = avg_cost_per_request * requests_per_day
monthly_cost = daily_cost * days
print(f'Avg cost/request: ${avg_cost_per_request:.6f}')
print(f'Requests/day: {requests_per_day:,}')
print(f'Daily cost: ${daily_cost:.2f}')
print(f'Monthly cost: ${monthly_cost:.2f}')
# Growth scenarios
for multiplier in [2, 5, 10]:
scaled = monthly_cost * multiplier
print(f' At {multiplier}x traffic: ${scaled:.2f}/month')
# Example: customer support bot
project_monthly_cost(
avg_cost_per_request=0.002, # 2 cents per support query
requests_per_day=5000
)模型选择对成本的影响
降低成本最有效的手段,是使用满足质量要求的最便宜模型。对于许多任务,gpt-4o-mini 的表现与 gpt-4o 相当,但成本约低 17 倍。在默认使用功能最强大的模型之前,请先针对您的具体任务对较便宜的模型进行基准测试;只有当质量低于您的阈值时,才切换到更昂贵的模型。
分层路由策略甚至更加有效:按照复杂度对传入请求进行分类,将简单查询路由到便宜的模型,将复杂查询路由到昂贵的模型。即使将 70% 的流量路由到便宜模型、30% 路由到昂贵模型,也能节省约 70% 的 AI 成本。
提示词长度与成本
提示中的每个令牌都会产生费用。一个本可以在不损失含义的情况下压缩的冗长系统提示,会直接增加每次请求的 API 账单。请对提示的令牌数量进行基准测试,并寻找措辞精简的机会。同样,较长的少样本示例通常也可以替换为更短的等价示例,而不会牺牲准确性。
对于 RAG 系统,检索到的上下文通常是提示中占比最大的部分。如果返回 10 个很大的文本块,而实际上 3 个精心选择的较小文本块就足够,那么每次查询都会浪费令牌。请调整检索策略,在最大化相关性的同时尽量减少重复上下文。
通过批处理提高成本效率
OpenAI 提供了一个批处理 API,可以异步处理请求,价格比标准价格低 50%。如果您的使用场景对延迟不敏感——例如文档处理、夜间分析任务和批量内容生成——那么批处理 API 只需极少的代码改动,就能将成本降低一半。
批处理请求以 JSONL 文件的形式提交,在 24 小时内处理完成,然后从 API 获取结果。这非常适合按计划运行且不需要实时响应的预处理流程。
import openai
import json
client = openai.OpenAI()
# Create batch request file
requests = [
{'custom_id': f'doc-{i}',
'method': 'POST',
'url': '/v1/chat/completions',
'body': {
'model': 'gpt-4o-mini',
'messages': [{'role': 'user', 'content': f'Summarize document {i}'}],
'max_tokens': 200
}}
for i in range(100)
]
# Write to JSONL
with open('/tmp/batch_input.jsonl', 'w') as f:
for req in requests:
f.write(json.dumps(req) + '\n')
# Upload and submit (50% off list price)
print('Would submit batch for 100 documents at 50% discount')
# batch_file = client.files.create(file=open('/tmp/batch_input.jsonl','rb'), purpose='batch')
# batch = client.batches.create(input_file_id=batch_file.id, endpoint='/v1/chat/completions', completion_window='24h')设置支出限额
请始终配置支出限额,以防止成本失控。在 OpenAI 控制台中,您可以设置每月支出上限,达到限额后 API 访问将被切断。请将硬上限设为您能接受的最高支出,并将软上限设为该数值的 80%,这样在达到硬上限之前,您会收到电子邮件警告。
在应用代码中,请实现一个存储在数据库中的按用户或按功能划分的预算。每次调用 API 前检查预算,如果预算已用尽则返回错误。这样可以防止某个失控的用户或批处理任务中的错误在几小时内耗尽您整个月的配额。
通过缓存避免重复的 API 调用
最便宜的 API 调用,就是您根本不需要发出的调用。请在应用层实现缓存,从缓存中提供相同请求的结果,而不是再次调用 API。即使只是使用提示的 SHA256 哈希值作为键的简单 Redis 缓存,也能在生产应用中消除相当一部分重复调用。
对于嵌入,缓存的效果尤其明显:相同的文本只应进行一次嵌入。请将嵌入与原始文本一同存储在向量数据库中,并在调用嵌入 API 前检查是否已有对应的嵌入。在 RAG 流程中,文档嵌入会在建立索引时计算一次,之后每个检索到这些文档的查询都可以重复使用。
import hashlib
import json
# Simple in-memory cache (use Redis in production)
_cache = {}
def cached_completion(client, model, messages, **kwargs):
cache_key = hashlib.sha256(
json.dumps({'model': model, 'messages': messages}).encode()
).hexdigest()
if cache_key in _cache:
print('Cache HIT - no API call made')
return _cache[cache_key]
response = client.chat.completions.create(
model=model, messages=messages, **kwargs
)
_cache[cache_key] = response
print('Cache MISS - API call made')
return response构建成本仪表板
在生产环境中,您需要按功能、用户和模型拆分查看 AI 成本。请构建一个成本仪表板,将每次 API 调用的令牌数量和相关元数据(用户 ID、功能名称、模型)记录到时序数据库中。然后进行汇总,以回答诸如以下问题:哪个功能带来的支出最多?高频用户产生的成本是否明显更高?修改提示后,单次查询的成本是否呈上升趋势?
这种可见性对于制定数据驱动的优化决策至关重要,这样您就不必猜测应该从哪里削减成本。大多数公司会发现,20% 的功能占据了 80% 的 AI 支出,而优化这些功能会带来远超其占比的效果。
快速检查
请测试您对本课 AI 工程概念的理解。
课程回顾
在本课中,您学习了以下内容:通过使用 tiktoken 计算输入令牌并估算输出令牌,可以在发送请求前预测 API 成本;模型选择是影响成本的最大因素——对于合适的任务,gpt-4o-mini 的成本可能比 gpt-4o 低 17 倍;以及缓存、批处理和支出限额可以防止生产环境中的成本失控。接下来,我们将探讨如何管理超出上下文窗口限制的长对话。
常见问题解答
「计算与预测 API 成本」课时是免费的吗?
是的 — 「计算与预测 API 成本」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 AI Engineering Academy 课程的其余内容,请升级到 CoddyKit PRO。 AI Engineering Academy 课程共包含 4 节课。
「计算与预测 API 成本」这节课中我会学到什么?
编写 Python 辅助程序,在发送请求前通过统计令牌数量并应用各模型的定价来估算成本,避免收到意外账单。 你通过在浏览器中直接运行的动手代码来练习 AI Engineering Academy,全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 AI Engineering Academy 需要有经验吗?
无需任何先前经验。CoddyKit 上的 AI Engineering Academy 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 3 节课,共 4 节。
「计算与预测 API 成本」课时需要多长时间?
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。
我能在这节 AI Engineering Academy 课中编写并运行代码吗?
能。每节 AI Engineering Academy 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。
此课程中的所有课时
- 什么是令牌?
- 上下文窗口:大小与影响
- 计算与预测 API 成本
- 保持在上下文范围内的策略