给 AI 功能算清每月 API 账单

如果你正在给产品加入 AI 功能，PM 或财务团队问的第一个问题几乎总是：“这每个月要花多少钱？”好消息是：对大多数团队来说，答案远比看起来更容易预测。坏消息是：你得先算一算 token 的账。

本文受 Journeyhorizon 团队近期一篇价格分析的启发，介绍一种适合开发者的方法，帮助你估算和控制 LLM API 成本。

训练成本与推理成本：只有一项与你有关

新闻标题里那些“耗资数亿美元”的 LLM，说的是训练前沿模型的成本：GPU 集群、精心整理的数据集、RLHF，以及庞大的研究团队。除非你是一家 AI 实验室，否则这笔账不归你付。

你要付的是通过 API 进行推理的费用：发送的每个 token 和收到的每个 token 都要计费。费用随用量增长，因此你可以像估算其他按用量计费的云服务一样，对它建立成本模型。

API 到底如何计费

下面几条经验法则适用于几乎所有供应商：

• 按 token 付费，而不是按请求付费。一个 token 大约相当于 ¾ 个英文单词。
• 输入和输出分别定价。输出 token 通常比输入 token 贵 2–5 倍，因为生成内容比读取内容需要更多计算。
• 上下文大小会影响价格。很长的上下文窗口可能对应更高的每 token 费率。
• prompt 缓存是你的好帮手。如果每次调用都重复发送相同的 system prompt、商品目录或风格指南，缓存可以大幅降低这部分成本。

价格跨度很大：小型“micro”模型每百万 token 只需几美分，高端推理模型则可能达到每百万 token 数百美元。务必查看供应商最新的价格页面：这些数字变化很快，而且大多在下降。

一个小巧的成本估算器

在写下任何一行功能代码之前，我会先用这个公式：

def monthly_llm_cost(requests_per_month, in_tokens, out_tokens,
                     price_in_per_m, price_out_per_m):
    """Estimate monthly LLM spend in USD."""
    total_in = requests_per_month * in_tokens
    total_out = requests_per_month * out_tokens
    return (total_in / 1_000_000) * price_in_per_m + \
           (total_out / 1_000_000) * price_out_per_m

# Example: natural-language search
# 100k searches/month, ~200 input + ~100 output tokens each,
# on a small model priced at $1 in / $5 out per million tokens
print(monthly_llm_cost(100_000, 200, 100, 1, 5))  # -> 70.0

把你自己的用量和供应商当前的价格代进去即可。要获得真实的 token 数量，可以运行几条有代表性的 prompt，再读取 API 响应中的 usage 字段。

为商品条目自动打标签。 每天处理 10,000 个条目，每个条目约有 100 个输入 token 和 50 个输出 token。这样每个月大约会产生 3,000 万个输入 token 和 1,500 万个输出 token。使用便宜的小模型时，月成本大约在 15–100 美元之间，具体取决于模型档位。相比它替代的人工工作，这点费用微不足道。

客服聊天机器人。 多轮对话会在每一轮重新发送历史记录，因此输入 token 的数量会迅速增长。在这种场景下，缓存、历史记录摘要，以及更便宜的默认模型，最能发挥作用。

这里的关键是：成本随用量线性增长，而模型选择是影响成本倍数的最大因素。同一个功能，仅仅因为默认使用旗舰模型，成本就可能高出 5–10 倍。

降低 LLM 账单的实用方法

• 选择够用的模型。 分类、路由和信息提取很少需要前沿模型。用 2–3 个档位的模型测试你的任务，选择满足质量要求的最便宜模型。
• 精简 prompt。 更短、更清晰的 system prompt，配上一两个优质示例，往往比冗长的 prompt 效果更好，成本也更低。
• 缓存静态上下文。 商品目录、政策文档和风格指南都非常适合缓存。
• 批量处理不紧急的任务。 如果不需要实时得到结果，就批量处理；许多供应商提供有折扣的批处理 API。
• 采用级联方案。 让小模型处理简单的 80% 的任务，只将低置信度的情况交给更大的模型，或者交给人工。
• 限制输出长度。 合理设置 max_tokens；输出是更贵的那一部分。
• 按功能监控成本。 给请求打上功能标签，这样你就能准确知道，产品的哪一部分在推高支出。

如果你不想在内部自行完成所有这些调优工作，Journeyhorizon 提供专门的 AI 成本优化服务，帮助团队选择合适的模型、设计高效的集成架构，并在用量增长时保持支出可控。

自托管：开源就等于“免费”吗？

Llama 或 Mistral 这样的开放权重模型免去了按 token 计费的费用，但取而代之的是 GPU 基础设施、运维工作和工程时间。通常，只有在用量非常大且稳定，或者数据驻留要求使你无法使用第三方 API 时，自托管才划算。

真正的问题不是“我们用得起 LLM 吗？”——对大多数产品来说，答案是用得起。真正该问的是：“这个功能能否通过提高转化率、留存率，或节省运营时间，赚回它消耗的 token 成本？”提前算清 token 的账，选择能够完成任务的最小模型，并从第一天起按功能衡量支出。

如果想查看原始的价格分析，或了解更多关于构建 AI 产品和交易平台的内容，可以看看 Journeyhorizon 的博客。

你最常用的降低 LLM 成本的技巧是什么？欢迎在评论区分享！

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。