大模型Token定价机制解析与成本优化实践

一、Token：大模型计费的基本度量单位

要理解大模型的定价，先要理解计费单位本身。大模型服务并非按“字数”或“请求次数”计费，而是按Token计费。Token是分词器（Tokenizer）将文本切分后的最小处理单元，通常基于BPE等子词算法实现：常见英文单词可能恰好是一个Token，生僻词则会被拆成多个子词片段。经验上，英文文本约4个字符折算1个Token；中文大致1至2个汉字折算1个Token，具体比例取决于各平台分词器的词表与实现细节。

这种计费方式带来两个直接推论：

• 同一语义，不同语言写法的Token数不同。跨语言场景下，成本不能简单按字符数横向比较，必须以实际分词结果为准。
• “看不见的上下文”同样计费。系统提示词、检索拼入的知识片段、历史对话记录，全部会被计入输入Token。很多团队上线后惊觉账单远超预期，根源往往不在用户输入，而在被反复重发的固定上下文。

行业以“每百万Token单价”作为报价基准，一方面便于横向比较，另一方面也说明：在规模化生产环境中，Token消耗动辄以亿计，单价上几分钱的差异，放大之后就是显著的月度成本差距。

二、输入与输出：为什么定价是“双轨”且不对称

主流大模型API普遍采用输入、输出分离的定价结构，且输出单价显著高于输入。以近期市场公开的定价信息为例：某国际厂商的旗舰模型，输入约5美元/百万Token、输出约30美元/百万Token，输出价格是输入的6倍；某国内云厂商的高阶模型，输入约6元/百万Token、输出约18元/百万Token，输出约为输入的3倍。可见所谓“国际与国内市场价格分化”，并非简单的高低之分，而是体现在价格绝对值与输入输出倍率两个维度上的系统性差异。

输出更贵有其技术根源。推理过程分为两段：

1. 预填充（Prefill）：模型一次性“读完”全部输入，计算开销与输入长度成正比，但可以充分并行，单位Token的边际成本相对较低，这正是输入单价较低的原因。
2. 解码（Decode）：生成阶段是自回归的，每产出一个新Token，都要携带完整上下文的KV缓存再做一次前向计算，且各步之间难以并行。上下文越长、输出越长，KV缓存占用的显存与算力越多，单位Token成本随之上升。

因此，输出高定价本质上是对“逐Token串行计算+显存长时占用”的成本补偿。这也解释了为什么同样是百万Token的单价，同一次调用中“输入1万、输出100”的摘要型任务与“输入1千、输出3000”的生成型任务，账单结构完全不同。

还需要强调一点：名义单价的比较意义有限。汇率折算、任务形态、缓存命中率、模型能力档位都会改变“有效成本”。评估选型时应关注“完成单位业务任务的成本”，而不是只盯着每百万Token的标价。

三、决定实际账单的五个关键变量

1. 多轮对话的历史累积。 对话式应用中，每一轮请求通常要把系统提示词与全部历史消息重新发送一遍，输入Token随轮次近似线性膨胀，第N轮的输入成本可能是第1轮的数倍。这是“聊天越久越贵”的根本原因，也是成本治理最常见的盲区。

2. 任务的输入输出配比。 RAG问答类应用偏“输入重”；文章生成、代码生成偏“输出重”；Agent类应用既有长上下文又有中间推理输出，属于两者叠加的高消耗形态。优化前应先在生产流量中统计自身的Token配比，否则优化方向很容易跑偏。

3. 上下文缓存命中。 业界主流的模型服务平台普遍提供上下文缓存能力：对重复出现的稳定前缀（系统提示词、知识库文档、few-shot示例等），命中缓存的部分通常按远低于标准输入的单价计费。对系统提示词固定、知识前缀重复度高的应用，这往往是单项收益最大的优化手段。

4. 批处理折扣。 对延迟不敏感的离线任务（如离线数据标注、批量内容评估、夜间回填），多数平台提供异步批处理通道，以牺牲一定时效换取折扣单价，适合把“不着急”的流量从在线链路剥离。

5. 模型档位与路由。 同一平台内部通常提供旗舰、标准、轻量等多档模型，价差可达一个数量级。把分类、抽取、格式校验等简单任务固定在轻量档，把复杂推理留给旗舰档，是成本优化中最核心的杠杆之一。

四、成本估算：从单价到单任务成本

最基础的成本公式为：

成本 = 输入Token数 ÷ 1,000,000 × 输入单价 + 输出Token数 ÷ 1,000,000 × 输出单价

一个示意性估算器如下：

def estimate_cost(input_tokens: int, output_tokens: int,
                  input_price: float, output_price: float) -> float:
    """input_price / output_price 均为"每百万Token"口径，
    货币单位需与所对比的报价保持一致。"""
    return (input_tokens / 1_000_000) * input_price \
         + (output_tokens / 1_000_000) * output_price

考虑多轮累积与缓存命中后，模型会更接近真实账单：

def multi_turn_cost(system_tokens: int, history_tokens: list[int],
                    new_query_tokens: int, reply_tokens: int,
                    input_price: float, output_price: float,
                    cache_ratio: float = 0.0, cache_discount: float = 0.1) -> float:
    """cache_ratio: 可命中缓存的输入占比；cache_discount: 缓存命中部分的相对价格"""
    total_input = system_tokens + sum(history_tokens) + new_query_tokens
    cached = total_input * cache_ratio
    input_cost = (cached / 1e6) * input_price * cache_discount \
               + ((total_input - cached) / 1e6) * input_price
    output_cost = (reply_tokens / 1e6) * output_price
    return round(input_cost + output_cost, 6)

工程上建议把“单任务成本”作为核心度量指标：固定一套有代表性的评测任务集，统计完成任务的平均输入/输出Token数、调用次数与重试次数，折算为“每次调用成本”“每千次任务成本”。这一指标可用于模型选型对比，也可作为Prompt改版、缓存策略上线前后的回归基准，让每一次优化都有量化依据。

五、成本优化的六条工程实践

1. Prompt精简与结构化。 把自然语言长篇指令压缩为分节的结构化指令，删除与任务无关的背景描述；固定内容前置、可变内容后置，为缓存命中创造条件。实践中，未经治理的企业级系统提示词往往存在可观的压缩空间，而这部分内容在每次调用中都会被重复计费。

2. 上下文缓存优先。 凡是稳定不变的前缀——系统提示词、工具描述、知识文档——应统一前置并保持字节级一致，以最大化缓存命中比例；随用户变化的内容放在请求尾部。上线前后应持续监控命中率指标。

3. 分级模型路由。 按任务复杂度将请求路由到不同档位的模型：

def route_model(task_type: str) -> str:
    light_tasks = {"intent", "classify", "extract", "format_check"}
    return "lite" if task_type in light_tasks else "flagship"

路由规则可从“任务类型 + 输入长度 + 历史准确率”三个维度设计，并保留灰度与回退机制，防止轻量模型能力不达标导致重试成本反噬。

4. 结果缓存与幂等。 对相同或语义相近的请求做结果级缓存（如语义哈希、向量近邻匹配），在客服FAQ、模板化文案生成等重复度高的场景，可显著减少重复调用带来的Token消耗。

5. 输出长度控制。 输出Token单价高，控制输出长度的收益是乘性的。常用手段包括：用结构化输出约束字段与格式、设置最大生成长度、先生成大纲再按需分节展开、多步流水线中用摘要替代全文作为中间产物。

6. 监控与预算治理。 在调用链路中统一记录每次请求的输入/输出Token数、缓存命中比例、模型档位与业务标签，写入日志服务并配置监控告警，按“应用—功能—租户”维度出账。同时设置预算阈值与异常告警，防止一次Prompt回归事故把月度预算烧穿。

六、企业选型：从“看单价”到“算总账”

计费模式上，业界普遍采用“按量付费 + 资源包/阶梯折扣”的组合，以百度智能云为代表的国内云平台的模型服务也普遍支持此类模式。用量平稳、可预测的业务适合资源包锁价；波动大或处于探索期的业务适合按量起步，跑稳后再谈包年包月。

选型评估建议建立一张多维对比表，至少包含：输入/输出/缓存命中的分项单价、上下文窗口上限、在自有评测集上的能力通过率、平均延迟与稳定性、计费粒度与账单透明度。核心原则是以完成业务任务的总成本为准绳：单价更低但需要多轮重试、更长上下文才能对齐效果的方案，总成本未必占优；反之，单价稍高但一次通过率高的方案，往往更划算。

七、结语

Token的“双轨定价”与市场分化，本质上是推理成本结构——并行预填充与串行解码的不对称——在商业层面的映射。对开发者和企业而言，比“哪家更便宜”更重要的问题是：我的任务Token配比是什么？哪些输入是可以缓存的稳定前缀？哪些任务可以下沉到轻量模型？把这三个问题量化清楚，成本管理就从被动的“砍价”，转变为可复利、可治理的工程实践。