几乎所有商用大模型 API，统一采用 Token 作为计费最小单位，多数开发者只停留在 “输入一段文字扣对应费用” 的表层认知，在 RAG 知识库问答、超长文档解析、多轮长对话场景中，经常出现单次调用费用远超预期的情况。很多人疑惑，只是多粘贴了几千字参考文档，账单成本却出现断崖式上涨，核心根源不在文本字数本身，而是 Token 背后绑定的 GPU 算力、显存、带宽与推理架构成本。本文从分词机制、推理双阶段、KV 缓存资源消耗三个底层维度，完整拆解 Token 计费逻辑，解释长文本成本失控的核心诱因，并落地开发者可直接复用的成本优化思路。

一、Token 不是文字，是大模型推理的基础计量单元

想要看懂计费逻辑，首先要厘清 Token 的本质。Token 中文译为词元，是大模型分词器 Tokenizer 切割文本后得到的最小语义计算单元，并非汉字、单词、标点一一对应换算央視網。

中英文分词规则存在明显差异，中文单个汉字、常用两字词汇基本对应 1 个 Token，生僻词、连续符号会被拆分为多个词元，行业通用经验值为 1Token 约等于 0.7 个汉字；英文中基础短单词占 1 个 Token，长难词汇、复合词会被切分为子词片段，平均 1Token 对应 0.75 个英文单词。文本中的空格、换行、特殊符号、代码注释都会独立占用 Token 额度，全部计入计费统计。

服务商放弃按字符、请求次数定价，核心原因是不同文本的推理资源消耗差异极大。两段同等字数的文本，生僻内容、长序列上下文带来的矩阵运算量会成倍提升，按请求次数收费会出现严重成本失衡。Token 直接映射模型每一层神经网络的浮点运算次数，能精准量化 GPU 资源消耗，实现 “消耗多少资源，支付多少费用” 的标准化计费逻辑，也是行业统一采用该计量标准的根本原因。

一次完整 API 调用的 Token 分为两类独立计费项：输入 Prompt Token 与输出 Completion Token，二者单价长期存在差距，绝大多数厂商输出 Token 定价为输入的 1.5 至 3 倍。输入 Token 包含系统角色指令、历史对话全量内容、检索召回文档、用户当前提问，所有送入模型的上下文序列全部统计；输出 Token 仅统计模型逐段生成的回复内容，两类 Token 分开核算账单，不存在互相抵扣规则。

二、Token 计费底层：Prefill 预填充与 Decode 解码双阶段算力差异

单次大模型推理分为两个完全独立的计算流程，二者硬件瓶颈、并行效率、资源消耗天差地别，这也是输入、输出 Token 定价分化的底层根源。

2.1 Prefill 预填充阶段：处理输入文本，算力密集、高并行

用户提交完整上下文后，模型进入预填充阶段，一次性并行处理全部输入 Token，批量计算所有词元对应的 QKV 向量，生成完整 KV 缓存数据，最终输出第一个回复 Token。该阶段属于计算密集型任务，瓶颈为 GPU 浮点算力，张量核心能够满负载运行，硬件利用率可达 90% 以上。

自注意力机制的计算复杂度为 O (n²)，序列长度 n 翻倍，整体浮点运算量提升四倍。长文本场景下，输入 Token 数量激增，预填充阶段矩阵乘法运算量呈平方级上涨，GPU 单次推理耗时同步拉长，服务器单位时间可承载的并发请求数量大幅下降，硬件分摊成本自然抬升。

但预填充具备极强并行优势，所有输入 Token 已知，GPU 多核心同步运算，单位算力能批量处理上万词元，单个 Token 分摊的硬件成本更低，因此厂商给到输入 Token 的单价普遍更低。

2.2 Decode 解码阶段：生成回复内容，显存带宽密集、串行执行

预填充完成后进入解码阶段，也就是模型输出文字的过程。大模型属于自回归生成架构，下一个 Token 的预测结果严格依赖前一个词元，无法并行批量计算，只能逐一生成文本。

每生成一个输出 Token，GPU 都需要完整读取整段 KV 缓存、加载全部模型权重参数，完成单次注意力计算。此时 GPU 算力核心大量闲置，硬件利用率仅 20%-40%，性能瓶颈从算力转为显存带宽，大量时间消耗在显存数据读写传输上，单 Token 占用的 GPU 时间远高于预填充阶段，这就是输出 Token 定价更高的核心原因。

同样处理 4000 个输入 Token 与 1000 个输出 Token，预填充阶段耗时仅 0.5 秒左右，解码阶段耗时可达 5 秒，十倍的时间差直接体现在定价差异上。

三、长文本调用成本陡增的核心元凶：线性膨胀的 KV Cache 显存占用

多数开发者误以为长文本只是增加少量输入 Token，仅产生线性增长的小额开销，实际长上下文带来的额外成本集中在 KV 缓存资源占用，这也是超长文档、多轮对话场景账单失控的关键。

KV 缓存是预填充阶段生成、解码阶段持续复用的上下文状态存储，保存所有历史输入与已生成输出的 Key、Value 向量，解码时每一步都需要读取全部缓存数据完成注意力计算。KV 缓存占用显存容量与上下文 Token 总量呈线性正相关，70B 参数大模型每 1000 个 Token 大约占用数 GB 显存，4K 上下文单请求缓存即可占用 4GB 以上显存空间。

长文本带来三重不可逆的资源损耗，直接推高调用成本： 第一，显存占用暴涨，单张 GPU 可承载的并发请求数量断崖式下降。常规短上下文单卡可同时服务数十条请求，当上下文拉长至 8K、32K，单卡并发量可能降至个位数，服务器硬件利用率大幅下滑，服务商只能通过抬高单价覆盖闲置硬件成本。 第二，显存带宽压力持续放大。解码阶段每次生成新 Token 都要完整遍历全部 KV 缓存，上下文越长，单次读写的数据量越大，显存带宽成为硬性瓶颈，单条请求生成速度变慢，服务器单位时间处理请求总数减少，硬件单位产出成本提升。 第三，预填充计算量平方级上涨。自注意力 O (n²) 复杂度决定，输入文本长度翻倍，矩阵运算总量提升四倍，1 万 Token 长文档的预填充算力消耗，远高于两段 5000Token 短文本分开调用的总和，叠加显存开销，综合成本会出现陡峭上涨。

举一个 RAG 业务真实场景对比：单次请求系统提示 500Token、用户提问 200Token，无检索文档，总输入 700Token，输出 300Token；另一场景系统提示不变，额外接入 4 份共 4500Token 的超长知识库文档，总输入 5200Token。表面仅增加 4500 个输入 Token，但预填充阶段算力提升数十倍，KV 缓存显存占用扩大 7 倍以上，单次调用综合成本提升 6 至 8 倍，即便输出内容长度不变，账单金额也会大幅攀升。

除此之外，多轮对话场景存在隐性成本叠加。每一轮对话都会把历史全部问答内容打包送入上下文窗口，轮次越多，输入 Token 持续累积，若不做对话总结、历史截断，十几轮对话后上下文长度轻松突破上万 Token，成本持续滚雪球式增长。

四、易被忽略的计费细节：缓存 Token 差异化计价

主流厂商均上线 Prompt Caching 提示词缓存机制，用于缓解重复长前缀带来的成本压力，这也是长文本场景为数不多的降本手段，同时属于容易被忽略的计费规则。

缓存机制采用前缀匹配逻辑，若连续多次请求开头存在完全一致的长文本，例如固定数千字系统提示、重复调用的知识库片段，服务端会复用第一次预填充生成的 KV 缓存，重复命中的缓存 Token 仅收取原价 10%-50% 的折扣费用，大幅降低重复长上下文开销稀土掘金。

但缓存存在硬性限制，仅匹配完整前缀，任意一个字符、标点、换行改动，都会导致整条缓存失效，需要重新全量计算计费；同时缓存存在 5 至 30 分钟有效期，低频调用场景无法发挥作用。对于一次性超长文档解析、单次独立问答场景，缓存机制无法生效，长文本的高额成本无法通过该方案抵消。

五、面向业务落地的长文本成本管控方案

结合 Token 计费底层逻辑，从推理资源消耗根源出发，给出四类可直接落地的降本手段：

1. 严格控制上下文窗口有效长度，剔除冗余文本。RAG 检索阶段增加文档过滤逻辑，只召回与用户问题强相关的片段，放弃全量知识库拼接；长对话设置滑动窗口，定期对久远对话做结构化总结，用百 Token 以内摘要替代数千字原始对话，从源头减少输入 Token 总量。
2. 充分利用提示词缓存优化固定前缀。将角色定义、工具调用规则、通用业务约束全部放在请求最前端作为固定前缀，保证多轮请求前缀完全一致，最大化缓存命中率，降低重复系统提示的计费成本。
3. 拆分超长文本分段调用，规避 O (n²) 算力损耗。上万字文档不要一次性送入上下文，拆分为多段短文本分批调用，每段独立完成问答，分散预填充阶段的平方级运算压力，同时减少单次 KV 缓存显存占用，降低综合资源消耗。
4. 区分模型选型，长上下文场景选择优化架构模型。采用 GQA 分组查询注意力、滑动窗口注意力的大模型，同等 Token 数量下 KV 缓存显存占用更低，长文本推理硬件损耗更小，长期批量调用能稳定压缩成本。