大模型 Token 计费机制解析与选型方法

一、概念定义：什么是 Token 计费

Token 计费是大模型服务的一种按使用量付费（pay-as-you-go）的计价方式。其核心逻辑是：将用户提交的文本与模型生成的文本切分为若干最小语义单元（Token），再以“每百万 Token 单价”为基准，分别对输入侧与输出侧计量并计费。

从技术视角看，Token 并不等同于字符或汉字。不同分词器（tokenizer）对同一段文本的切分结果不同，中英文混合文本的 Token 数量需以实际分词结果为准。从业务视角看，Token 计费本质上是一种“资源消耗映射成本”的定价模型——模型推理消耗的算力与显存带宽近似正比于处理的 Token 数量，因此以 Token 为计量单位既贴近真实成本，也便于用户预估开销。从使用视角看，开发者只需关注三个量：单次请求输入了多少 Token、输出了多少 Token、有多少 Token 命中了缓存。

它解决的核心问题是：让用户在不为固定算力预付费用的前提下，按实际调用规模弹性付费，降低大模型接入的初始门槛。

二、背景与价值：为什么会出现这种计价方式

传统云资源多以时长、实例规格或调用次数计费，但大模型推理的成本驱动因素与这些维度并不吻合。同一模型处理一段 100 字与一段 10 万字的文本，算力消耗差异巨大；生成 50 个 Token 与生成 5000 个 Token，解码阶段的耗时与显存占用也完全不同。若仅按“调用次数”计费，会导致长文本用户与短文本用户之间的成本交叉补贴，定价失真。

Token 计费的价值体现在三方面：其一，计费粒度与真实资源消耗对齐，价格信号更准确；其二，用户可基于业务文本长度分布做成本建模，便于容量规划；其三，为缓存、批处理等优化手段提供了可量化的省钱路径——命中缓存的输入 Token 通常以折扣价计费，从而激励用户复用上下文。

三、核心组成：一次调用的计费项拆解

一次典型的大模型调用，账单通常由以下计费项构成：

1. 输入费用（Input）：按提交的提示词、上下文、系统指令等 Token 总量计费，单价记为 P_in（元/百万 Token）。
2. 输出费用（Output）：按模型生成的 Token 总量计费，单价记为 P_out。由于解码阶段逐 Token 生成、算力占用更高，P_out 普遍高于 P_in，常见倍率为 2～4 倍。
3. 缓存写入费用（Cache Write）：部分服务支持上下文缓存，首次将一段前缀写入缓存时按输入价或单独写入价计费。
4. 缓存命中费用（Cache Hit）：后续请求复用同一缓存前缀时，命中的输入 Token 按折扣单价计费，通常显著低于 P_in。
5. 阶梯档位调整：部分服务采用“按单次请求输入长度分档”的阶梯定价，输入越长单价越高。

需要强调的是，并非所有服务都单独收取“缓存写入费”。有的方案将首次写入并入普通输入计费，有的则单列。选型时必须逐项核对计费规则，不能只看表面单价。

四、工作原理：账单是怎么算出来的

以通用公式表达，单次请求费用为：

cost = input_tokens  × P_in(input_tier)
     + output_tokens × P_out
     + cache_write   × P_cache_write   // 若该服务单列此项
     + cache_hit     × P_cache_hit     // 命中部分按折扣价

其中 P_in 可能是阶梯函数：当 input_tokens 落在不同区间（例如 ≤32K、32K～128K、>128K）时取不同单价。这意味着同一段文本，若单次请求整体提交，可能落入更高档位而抬高单价；若拆分为多次请求，则每次按较低档位计价，但会牺牲上下文连续性并增加请求数。这是一个需要权衡的工程问题。

举一个抽象示例：某次请求输入 509.8K Token、输出 8.125K Token，若该服务规定输入超过 128K 档单价为 7 元/百万、输出为 28 元/百万，且缓存写入并入输入计费，则输入费用约 3.57 元、输出费用约 0.23 元，合计约 3.80 元。这一计算过程本身是可复现的，关键在于准确取得档位划分与各类单价。

五、典型场景：谁需要关注 Token 计费

• 多模型对比选型：在同一业务语料上跑通多家模型，按统一口径计算单位任务成本，而非仅比较标称单价。
• 长上下文应用：文档问答、代码库分析、长对话等场景输入 Token 占比极高，阶梯定价与缓存命中价对总成本影响最大。
• 高频短请求服务：客服问答、分类打标等场景输出短、请求密，输出单价与并发能力更关键。
• 成本敏感型批处理：离线摘要、数据清洗等任务可通过拆分请求、控制上下文长度来压低档位单价。
• 预算监控与告警：按 Token 维度建立用量看板，设置阈值告警，避免长文本请求意外触发高额账单。

六、相关概念区别

• Token 计费 vs. 按调用次数计费：前者与文本长度强相关，后者与请求数相关；长文本场景下前者更公平，短请求密集场景下后者可能更易预估。
• Token 计费 vs. 包年包月/预留吞吐：预留模式以承诺用量换取折扣，适合负载稳定场景；Token 按量计费适合波动负载与试验阶段，两者常组合使用。
• 输入单价 vs. 输出单价：不可混用。只比较输入价会低估生成型任务成本；只比较输出价会忽略长上下文场景的输入开销。
• 标称单价 vs. 有效单价：计入缓存折扣、阶梯档位、免费额度后，实际有效单价往往与标称值有差异，对比时应以有效单价为准。

七、使用注意事项

1. 先确认价格表口径：同一模型在不同部署区域、不同版本（如最新版与旧版）之间价差可能很大，务必核对版本号与部署范围，避免拿旧版价格算新版账单。
2. 厘清阶梯规则：确认档位是按“单次请求输入长度”还是“累计用量”划分，前者对长文本单次提交不利。
3. 确认缓存计费细节：缓存写入是否单列、命中折扣比例、缓存有效期与最小可缓存长度，都会显著影响长上下文应用的成本。
4. 统一对比口径：用同一组输入/输出/缓存数据代入各家公式，而非直接比较标称单价；同时记录请求拆分方式，保证可比性。
5. 关注非价格因素：限流阈值、上下文窗口、输出质量、稳定性与延迟同样影响总拥有成本，低价但需重试的方案未必更省。
6. 建立用量基线：上线前用真实语料采样估算 Token 分布，上线后持续监控输入/输出比例与缓存命中率，动态调整提示词与请求策略。
7. 避免过度拆分：为压低档位单价而过度拆分请求，可能增加请求数、破坏上下文、抬高输出重复率，反而推高总成本。

八、总结

Token 计费是以分词单元为计量基准、区分输入与输出、并可叠加缓存折扣与阶梯档位的按量计价模型。理解它的关键不在于记住某家单价，而在于掌握“计费项拆解—档位判定—公式代入—口径统一”这一套可复现的分析方法。只有把业务文本的长度分布、缓存复用率与请求拆分策略纳入同一模型，跨模型的成本对比才具备参考意义；反之，任何脱离口径的单价排序都只是粗略印象。