大模型定价怎么看,把 token 折算成每月 API 成本

第一次帮团队接大模型 API 的人,几乎都被一件事坑过:Demo 阶段一个月花不到十块钱,功能一上生产,账单直接翻到四位数。问题不在模型变贵,而在没人提前把 token 量级折算成钱。这篇就把计费逻辑、各家价格、月成本估算和降本手段一次讲透。

输入 token 和输出 token 是两个价格

大模型 API 几乎都按 token 计费,而且关键一点:输入 token 和输出 token 分开计价,输出通常更贵。输入是你喂给模型的内容,包括系统提示、对话历史、检索到的资料;输出是模型生成的回答。

为什么输出贵?生成每个 token 都要跑一次完整的前向推理,而输入可以批量并行处理,算力成本不一样。多数厂商的输出单价是输入的三到五倍。这就带来一个反直觉的结论:两个工作流总 token 数相同,一个短 prompt 长回答,一个长 prompt 短回答,前者可能贵出一大截。所以做预算时,一定要把输入和输出拆开估,而不是拿总数乘一个均价。

想知道自己一段 prompt 到底占多少 token,可以先用 /zh/t/ai-token-counter/ 数一遍,再把数字带进成本估算,比拍脑袋准得多。

各家定价怎么对比才不踩坑

横向比价时,别只看单价高低,要看价格和你的用量结构是否匹配。常见的几类:

旗舰模型:能力最强,输入输出单价都高,适合复杂推理、代码、长文理解。
中端模型:能力打折但单价低一个数量级,适合分类、抽取、改写这类规模化任务。
轻量模型:单价极低,适合路由、打标签、简单问答这种高频低难度调用。

真实项目里很少全用一个模型。一个用户动作背后可能是:轻量模型做意图路由,中端模型做检索改写,旗舰模型出最终答案。把每一跳的模型和 token 量分别算,才是接近真实账单的做法。比价时也要留意厂商的缓存折扣、批量接口价、地区价,这些都能把同一个模型的实际单价改写。

一个真实用量的月成本估算

举个具体例子。某客服自动化,每天 12000 张工单,每张工单触发 2 次模型调用,平均每次调用输入 1500 token、输出 500 token。假设用中端模型,输入每百万 token 0.5 美元,输出每百万 token 1.5 美元。

算一笔账:

每天输入 token = 12000 × 2 × 1500 = 3600 万,成本 36 × 0.5 = 18 美元。
每天输出 token = 12000 × 2 × 500 = 1200 万,成本 12 × 1.5 = 18 美元。
每天合计 36 美元,按 30 天算,月成本约 1080 美元。

注意这里输入 token 是输出的 3 倍,但因为输出单价高 3 倍,两边花的钱反而打平。如果当初只按输入量估算,会把成本算少一半。这种量级风险,手算容易漏,用 /zh/t/llm-pricing-calculator/ 把输入输出、请求量、单价分别填进去,单次、每千次、每日、每月成本会一次列清,还能直接换个模型价格对比。

降本的几个实在办法

成本算出来偏高时,有几条路比换便宜模型更稳:

用上下文缓存。很多厂商对重复的输入前缀(固定的系统提示、长文档)提供缓存折扣,命中缓存的部分单价能降到原价的几分之一。把不变的内容放在 prompt 最前面,缓存命中率更高。
精简 prompt。删掉冗长的示例、重复的格式说明、用不上的对话历史。输入 token 每砍一截,成本和延迟一起降。
控制输出长度。在 prompt 里明确要求简洁回答,或设置最大输出 token,避免模型啰嗦。输出贵,省这部分性价比最高。
分级调用。能用轻量模型解决的别上旗舰,把贵模型留给真正难的环节。

把 token 和成本的关系记成一句话

我自己带团队接模型时,定了一条铁律:任何功能转生产前,必须先把每天的输入 token 总量、输出 token 总量、对应单价摆出来,算出月成本,写进评审文档。就这一步,过去半年帮我们拦下过两次预估差十倍的方案。token 不是抽象的技术指标,它是直接乘出账单的计量单位,越早折算成钱,决策越不会跑偏。

记住:月成本 ≈(日输入 token × 输入单价 + 日输出 token × 输出单价)× 天数。把这个公式刻进脑子,再配合工具核验,大模型的账就不会再吓你一跳。

Made by Toolora · Updated 2026-06-13