1. 为什么要在扩大规模前预估 LLM API 成本
在把 LLM API 接入新功能或产品之前先算清楚预期成本,能避免用户量增长后账单突然失控。对于提示词较长、或存在多轮对话的服务尤其重要——单次请求看起来很便宜,但按天、按月累积后规模会截然不同。这个计算器同时展示单次请求成本和每月模拟结果,帮助你在扩大规模前建立预算概念。
计算 GPT、Claude、Gemini 等主流 LLM API 的 token 成本。可直接输入 token 数,或粘贴文本进行估算,并查看按月用量估算的预估成本。
在把 LLM API 接入新功能或产品之前先算清楚预期成本,能避免用户量增长后账单突然失控。对于提示词较长、或存在多轮对话的服务尤其重要——单次请求看起来很便宜,但按天、按月累积后规模会截然不同。这个计算器同时展示单次请求成本和每月模拟结果,帮助你在扩大规模前建立预算概念。
token 是模型处理文本的最小单位,与单词或字符并非一一对应。英文中常用"约 4 个字符对应 1 个 token"作为经验法则,但这只是近似值,实际数值取决于各模型所用的分词器(如 BPE)。尤其是中文、日文、韩文等 CJK 语言,往往比英文每个字符消耗更多 token(单个字符常被拆分为多个子词 token),因此相同字符数下,实际成本可能明显高于等量的英文文本。
大多数厂商对输出(生成)token 的定价都比输入(提示词)token 高出数倍,本页数据中的每个模型都遵循这一规律。输入可以一次性处理(编码),而输出需要逐个 token 顺序生成(解码),计算量和延迟都更大。因此,让回复保持简短是降低成本尤为有效的手段。
提示词缓存(上下文缓存)让厂商可以在服务端缓存反复出现的系统提示词、长上下文或文档,当后续请求再次出现相同内容时,以更低的费率处理。这在系统提示词或对话历史每轮都会重复发送的对话式场景中收益最大。但如果每次请求发送的都是全新文本,缓存则不适用,因此本计算器中"缓存命中时"的数值仅作参考场景,并非保证值。
①不要让提示词比任务实际需要的更长,只包含必要的上下文;②充分利用提示词缓存来处理跨请求重复出现的系统提示词或上下文;③把分类、摘要等简单任务路由给更便宜的小模型,而不是旗舰模型;④将多个请求打包成批处理(batch),利用批处理折扣或吞吐量优化。仅这四点就能显著降低实际运营成本。
本计算器基于各厂商公开的标价(list price)API 费率进行估算,未考虑批量折扣、企业合同、预置吞吐量(provisioned throughput)、免费额度、区域差异定价,以及速率限制(rate limit)带来的实际处理延迟等因素。实际账单金额可能因合同条款而异,请将本工具作为预算规划的起点,最终数字请直接向厂商确认。