如何计算 LLM API 成本

主流大模型 API 按 Token 用量计费，一个月度账单的构成可以拆成四项：

· 调用次数：每天发起多少次请求；
· 输入 Token：每次请求发送的内容量（系统提示词、历史对话、用户输入都算）；
· 输出 Token：模型每次生成的内容量；
· 单价：输入与输出各自按每百万 Token 计价，且价格不同；部分厂商还有缓存命中价与峰谷价。

适用范围：本文适用于按 Token 后付费的对话/推理类 API。订阅制套餐、按次计费（如部分生图/视频接口）、预留算力等模式不在本文公式范围内，需按各自计费文档计算。

价格一律以每百万 Token为计价单位，与厂商官方定价页一致。Token 是模型处理文本的最小单位：1 个汉字约 1~2 个 Token，1 个英文单词约 1 个 Token，具体以各厂商分词器为准。注意换算：厂商给出的是"每百万 Token 的价格"，单次请求的 Token 数通常远小于百万，计算时要先除以 1,000,000。

原币种必须保留：国内厂商（DeepSeek、GLM、Kimi、Qwen、混元、MiniMax、MiMo、Step）以人民币（CNY）刊例，OpenAI / Anthropic / Google 的模型以美元（USD）刊例。比较与估算时美元价格按参考汇率（中国外汇交易中心人民币汇率中间价，标注汇率日期）折算人民币，折算值仅供参考——页面不会把 $ 原价伪装成 ¥，也不在不同币种的原始数字间直接比大小。

第二节那句"1 个汉字约 1~2 个 Token"只是量级经验，不能当计费依据。Token 由厂商的分词器（tokenizer）决定，主流实现是 BPE 一类的子词切分：把高频子串收进词表，遇到词表外的内容就退回到更小的片段，最差情况退到字节级。OpenAI 开源的 tiktoken 在 README 里把这套性质写得很清楚——可逆无损、能处理任意文本（包括训练时没见过的文本）、压缩后比原始字节更短，"实践中平均 1 个 Token 约等于 4 字节"（该经验值针对其训练与评测所用的文本分布，不是普适常数）。

这里有两个直接后果。第一，同一段文字在不同厂商的分词器下 Token 数不同：编码表不同、合并规则不同，跨厂商用"字数 × 系数"互相换算必然出错。第二，文本的"信息密度"比长度更能决定 Token 数：自然语言散文的切分效率高，代码与结构化数据低。

几类容易低估的输入：

· 中文：常见汉字多落在词表内，但生僻字、异体字、繁体与全角标点常被拆成多个 Token；
· 代码：缩进空格、括号、下划线、驼峰命名的每一段都可能单独成 Token，同样的字符数下代码的 Token 数通常明显高于散文；
· 结构化数据：JSON 的引号与花括号、CSV 的分隔符、表格线都是额外 Token；
· 随机串：UUID、哈希、Base64、订单号这类高熵字符串几乎无法被合并，往往逐段甚至逐字节切分；
· 长空白与重复标点：连续空格、Markdown 缩进、装饰性分隔线都会被如实计量。

所以正确做法不是估算，而是拿真实样本实测：调用对应厂商的分词接口，或对 OpenAI 系模型用 tiktoken 的 encoding_for_model 取该模型的编码再 encode() 计数。样本要覆盖你最长的输入形态（含 system prompt 与工具定义），而不是只测一句用户提问。

计费的是序列化之后整包发送的内容，不是"用户这一句话"。一次请求的输入通常由四块拼成，其中后两块最容易被漏算：

· 系统提示词：角色设定、输出格式要求、few-shot 示例。它每次都发送，因此它的长度会按调用次数线性放大；
· 历史消息：多轮对话场景下，每轮都会把之前的输入与输出重新发送一遍，输入量随轮数近似线性增长（这也是多轮对话比单轮贵得多的原因）；
· 工具定义：Tool Calling 的函数名、描述与参数 JSON Schema 属于请求体的一部分，按输入 Token 计费；挂 20 个工具与挂 3 个工具，每轮输入都会差出一截，工具描述写得越啰嗦差得越多；
· 当前用户输入与附件：文本直接计入；图片、音频、视频是否折算成 Token、按什么公式折算，各家规则不同，本站模型库只在 模型档案 的 modalities 字段声明支持哪些模态，不声明折算系数——需要精确值时请查该厂商的多模态计费文档。

输出侧还有一个常被忽略的边界：推理（reasoning）内容算不算输出 Token。部分模型默认开启思考模式，思考过程本身也要生成；它是否计入 usage 的输出量、是否单独计价，口径由厂商决定（例如 DeepSeek 的价格页把两种模式并列，并声明"按模型输入 + 输出 Token 总量"计费，但具体哪些内容进 output 仍以接口返回的 usage 为准）。估算时如果忽略了推理开销，输出项会系统性偏低。

一个可操作的估算顺序：把请求体完整序列化成 JSON → 用分词器测这段 JSON 的 Token 数 → 再乘调用次数。跳过第一步直接对"用户输入"估算，是最常见的低估来源。

本文前面的公式是"从假设推成本"，真实账单是"从用量推成本"。两者能对上，前提是假设与 usage 口径一致。主流 API 都会在响应里返回本次调用的用量，但字段名与拆分粒度因厂商而异，没有任何一个是行业标准，不要照抄某一家的字段去解析另一家：

· DeepSeek：输入侧拆成 prompt_cache_hit_tokens 与 prompt_cache_miss_tokens，两者之和即本次输入的 prompt Token 总量，可直接算命中率；命中部分与未命中部分的单价不同（核验于 2026-10-31 的官方 Context Caching 文档与价格页）；
· Anthropic：官方定价页把"缓存读取"与"缓存写入"列为独立价格行，并注明缓存价格以 5 分钟 TTL 为基准、另有延长缓存的选项；响应中缓存与用量的具体字段名请以该厂商的 API 文档为准（本次核验只覆盖了定价页，接口字段未逐项核对）；
· 其他厂商：缓存命中量有的单独给字段，有的只给"输入总量"不再拆分，还有的把工具调用、图片、批量接口的计量放在独立对象里。接入前先把你要用的那几个字段打印出来看一遍，比读三篇博客可靠。

拿到 usage 之后，做三步对照：

· 第一步，量级对照：把 30 天的 usage 输入总量除以真实请求数，得到"实测单次输入"，与你在 成本计算器 里填的单次输入值比。差 2 倍以内通常是假设粗糙，差一个数量级说明漏算了 system prompt、历史或工具定义；
· 第二步，结构对照：把命中量除以（命中 + 未命中）得到实测命中率，替换计算器里的 30% 默认假设；若命中率长期接近 0，先检查前缀是否被时间戳、用户 ID、随机排序破坏，而不是先去调价格假设；
· 第三步，账单对照：用实测 usage 与官方单价重算一遍，与厂商账单比较。差额的常见来源是失败请求与重试（它们同样消耗 Token 甚至全额计费）、缓存写入费、跨档位计价、以及免费额度与资源包抵扣。差额持续存在时，先确认账单里的计价档位与时段，再怀疑公式。

这三步做完，你手上的"单次输入 / 单次输出 / 命中率 / 调用次数"就不再是拍脑袋的假设，而是从自己日志里长出来的参数；本文的公式仍然成立，只是代入了你自己的数字。

输入与输出分开计算再相加：

· 输入成本 = 调用次数 × 单次输入 Token ÷ 1,000,000 × 输入单价
· 输出成本 = 调用次数 × 单次输出 Token ÷ 1,000,000 × 输出单价
· 总成本 = 输入成本 + 输出成本

其中输入单价可能不是单一值：命中上下文缓存的部分按更低的缓存命中价计费，于是：

· 输入有效单价 = 缓存命中率 × 缓存命中价 +（1 − 缓存命中率）× 未命中价

分时段定价的模型（如 DeepSeek）还需先确定请求落在高峰还是低谷时段，两者单价不同。未公开缓存价的模型没有"缓存命中价"可用，只能按未命中价计—— unknown 不是 0。

部分模型按单次输入长度分档计价：例如 MiniMax M3 输入 ≤512K 适用低档（输入 ¥2.1 / 输出 ¥8.4 每百万 Token），>512K 跳到高档（¥4.2 / ¥16.8）；Claude Haiku 5.5 以提示词 ≤100K 为界分 0.1 / 0.5 美元两档。计算时要先用你的单次输入长度选对档位，再代入公式。

未公开档位不补价：GPT-6 Luna 与 GPT-6.1 Sol 的 >272K 长上下文档费率官方定价页未公布数值——该范围内估算必须如实返回"无法估算"，套用低档价格会得到偏低的虚假数字。本站计算器和对比页遇到未公开档位一律拒绝估算。

在你的单次输入不超过低档上限的常见业务里（多数对话、RAG、Agent 场景远低于 100K~512K），分档不影响结果；只有超长文档整本注入时才需要先检查档位边界。

下面用一个数据完整（含公开缓存价）的真实模型演示全部步骤。所有取值来自本站唯一数据源 models.json，模型页附官方来源与核验日期：

缓存命中价：当请求的输入与历史请求有相同前缀时，厂商允许命中上下文缓存，命中部分按明显低于标准输入价的缓存价计费。保持稳定的系统提示词与文档前缀能提高命中率。只有官方公布了缓存命中价的模型才能享受这项折算；本站对未公开的模型一律按未命中价计，不假设存在缓存折扣。

缓存写入费是另一项容易被忽略的计费项：部分厂商对"写入缓存"单独收费（如 GPT-6 Luna 30 分钟档 $0.125 / 百万 Token、Claude 系列 5 分钟档 $0.125 起）。写入费与缓存保留时长相关、和调用量假设耦合，本站示例月成本未计入，各模型档案页已单独注明。

峰谷定价：以 DeepSeek 为例，高峰时段（工作日 9:00-12:00、14:00-18:00，北京时间）按标准价计费，其余时间（夜间、午间、周末与法定节假日全天）按约为高峰一半的低谷价计费。把可延后的批量任务调度到低谷时段，是确定性的降本手段。本站成本计算器与对比页的"示例月成本"统一按低谷价（错峰）口径计算，并在页面明示。

月度估算 = 日均调用次数 × 30 天 × 单次成本。三个假设需要你按真实业务取值：

· 调用次数：用日志统计日均请求量，而非峰值；
· 单次输入：把系统提示词、历史对话与本次输入一起估算——多轮对话场景下输入会随轮数增长；
· 单次输出：长文生成场景输出可能远超输入，而输出单价通常更高。

本站对比页的"示例月成本"固定使用日均 100 次、单次输入 2000 / 输出 800 Token、错峰低谷价、缓存命中率 30% 的假设，只用于横向对比，不代表你的实际账单。

· 误区 1：输入输出同一个价。输出单价通常是输入的 2~4 倍，只按输入估价会严重低估；
· 误区 2：未知价格当 0。官方未公开缓存价不等于缓存免费，按 0 计算会得到虚假的低成本；
· 误区 3：跨厂商口径直接比数字。不同厂商的档位划分（按输入长度分档）、优惠策略（限时折扣、Token Plan）不同，比较时必须先统一口径：刊例原价、同档位、同用量假设；
· 误区 4：忽略输出占比。摘要、写作类应用输出 Token 常占大头，估算时输出项权重要上调；
· 误区 5：把估算当账单。免费额度、资源包、阶梯价格都会使实际账单低于刊例估算；反之超出免费额度后可能更高。估算只用于预算与选型对比。

Reflex Hub 的模型价格与参数维护在唯一数据源 models.json 中，每条数据标注官方来源链接与"最后核验日期"（verifiedAt），页面页脚汇总全部来源。价格核验时间 ≠ 页面内容更新时间：仅重新核验而价格未变时，页面与 sitemap 的更新日期保持不变（完整时间语义见定价方法论）。本站尽可能逐项复核，但仍存在两类限制：一是官方未公布的数值（如个别模型的上下文窗口）只能标记未决，不会编造；二是价格会随厂商调整而变化，引用本文算例时请回到对应官方页面确认最新价格。

第三至第五节（Token 计量、输入构成、usage 核对）另参考以下官方资料，均于 2026-10-31 实际访问核验： tiktoken README（BPE 分词与"平均 1 Token ≈ 4 字节"的经验值）、 DeepSeek Context Caching 文档（usage 的命中/未命中字段）、 Claude 定价页（缓存读取/写入单价与 5 分钟 TTL 基准）。 各厂商的 usage 字段名与拆分粒度并不统一，本文不把任何一家称为行业标准。

· 代入你的真实用量，用 成本计算器 估算各模型月成本；
· 查阅模型库收录各模型的价格与参数档案（模型库，示例模型见上表链接；美元定价模型示例见 GPT-6 Luna 档案）；
· 两款候选模型难以取舍时，用 模型对比 做逐项比较，例如 DeepSeek V4.1 Flash 对比 GLM-5.3-Flash 或 DeepSeek V4 Pro 对比 Kimi K3；
· 想看固定用量下全部模型的横向价差，读 定价比较指南；
· 想按业务场景（聊天机器人 / RAG / 编码 Agent）估算，读 场景成本案例；
· 全部教程见 计算指南目录。