在使用 AI 的过程中，Token 究竟是如何被生成与消耗的？

很多团队在跑通大模型服务后都会遇到同一个困惑：GPU 利用率明明很高，用户却反馈响应慢；集群接近满载，业务吞吐量却不见增长；显存和算力都还有余量，首 Token 延迟（TTFT）却持续恶化。要回答这些问题，必须先搞清楚一件事—— Token 到底是怎么被生成出来的，又是在哪些环节被消耗掉的 。

如果你正在为模型选型和调用成本发愁，可以先通过百度智能云词元所了解不同模型的调用价格与能力差异，再带着成本视角往下读，会更容易理解本文的拆解逻辑。

一、Token 不是“字数”，而是模型的计算单位

Token 是模型处理文本的最小单位。文本先经过分词器（Tokenizer）切分成 Token 序列，再映射为词表 ID 送入模型。不同模型的分词器不同，同一段中文在不同模型下的 Token 数可能相差明显，这也是“同样一段提示词，不同模型计费不同”的直接原因之一。

一次完整的调用会产生两类 Token：

• 输入 Token（Prompt Token） ：用户提示词、系统指令、上下文历史、RAG 检索到的文档片段，全部计入输入。
• 输出 Token（Completion Token） ：模型逐 Token 自回归生成的内容。

多数模型服务对输入和输出采用不同单价，输出通常更贵，因为输出是逐个 Token 串行生成的，对算力和显存的占用更持久。

二、Token 的生成过程：一次前向，一个 Token

大模型推理分为两个阶段，这两个阶段的资源特征完全不同，也是理解 Token 消耗的关键。

1. Prefill（预填充）阶段

模型一次性处理全部输入 Token，并行计算并建立 KV Cache。这个阶段算力密集、并行度高，直接决定 TTFT。输入越长，Prefill 越重，首 Token 延迟越明显。

2. Decode（解码）阶段

模型每次只生成一个 Token，然后把新 Token 追加到序列中继续生成，直到遇到结束符或达到最大输出长度。这个阶段是串行的，显存带宽往往比算力更先成为瓶颈，直接决定 TPOT（每 Token 输出时间）和整体吞吐。

可以用一个简化公式描述单次请求的耗时：

总耗时 ≈ Prefill 时间(与输入长度相关) + 输出Token数 × 单Token解码时间

这也解释了一个常见现象： 输入很长的 RAG 请求，TTFT 高但输出很短；而开放式生成请求，TTFT 尚可但总时长很长 。两者对 GPU 的压力点完全不同，不能只用“GPU 利用率”一个指标衡量。

三、Token 在哪些环节被“消耗”掉

Token 消耗不只是计费账单上的数字，它在系统内部对应着真实的资源开销：

消耗环节	资源类型	说明
Prefill 计算	GPU 算力	输入 Token 越多，计算量越大
KV Cache 存储	显存	上下文越长，缓存占用越高，可能挤占并发空间
Decode 生成	显存带宽 + 算力	逐 Token 串行，输出越长占用越久
多卡通信	NCCL / 网络	张量并行、流水线并行时通信可能成为瓶颈
调度与排队	Kubernetes 资源	资源分配不当会造成排队等待，拉长端到端延迟

其中 KV Cache 是最容易被忽视的隐性成本 。当并发请求增多、上下文变长时，KV Cache 会快速耗尽显存，导致新请求排队或被迫降低并发，表现为“GPU 利用率高但吞吐上不去”。这也是为什么现代推理引擎普遍采用 PagedAttention、连续批处理（Continuous Batching）等技术来提升显存与 Token 的利用效率。

四、从 GPU 到 Token：建立八层可观测链路

既然 Token 是最终产出，观测就应该从硬件一路打通到业务。实践中可以按以下层次建立指标体系：

1. 硬件层 ：GPU 利用率、显存占用、功耗与温度。
2. 通信层 ：NCCL 带宽、跨卡/跨节点通信延迟。
3. 调度层 ：Kubernetes 资源分配、排队时长、抢占情况。
4. 推理引擎层 ：批处理大小、KV Cache 命中与占用、Prefill/Decode 队列。
5. 模型层 ：TTFT、TPOT、吞吐（Tokens/s）。
6. Token 层 ：输入/输出 Token 数、缓存命中节省的 Token。
7. 成本层 ：每千 Token 成本、每请求成本、每用户成本。
8. 业务层 ：成功率、P95 延迟、用户满意度。

只盯第 1 层，就会陷入“利用率很高但体验很差”的误区；把第 5～7 层打通，才能把 GPU 产出真正换算成 Token 产出。

五、Token 成本怎么算：一个可落地的公式

单次请求成本可以这样估算：

单次成本 = 输入Token数 × 输入单价 + 输出Token数 × 输出单价

若要评估单位产出效率，可以进一步计算：

每千Token成本 = 周期总费用 ÷ 周期内总Token数
有效Token占比 = 实际计费Token ÷ 理论可用Token

优化方向也随之清晰： 减少无效输入（精简提示词、压缩上下文）、提高缓存命中（复用系统提示与检索结果）、控制输出长度（设置 max_tokens、结构化输出）、提升批处理效率 。这些手段本质上都是在提高“每个 Token 的产出价值”。

在实际选型时，不同模型的单价、上下文长度和输出质量差异较大，建议借助词元所模型服务对比调用成本与性能表现，再结合自身业务的输入输出比例做测算，而不是只看单一单价。

六、工程实践中的降本清单

• 提示词瘦身 ：删除冗余示例，把固定指令放入可缓存的系统提示。
• 上下文管理 ：对长对话做摘要压缩，避免历史无限增长。
• 输出约束 ：明确要求简洁回答，设置合理的 max_tokens。
• 缓存复用 ：对高频相同请求做结果缓存，减少重复计费。
• 批处理调优 ：合理设置并发与批大小，平衡 TTFT 与吞吐。
• 分层观测 ：把 Token 数、TTFT、TPOT、每千 Token 成本纳入统一监控看板。

七、结语

Token 的生成是一条从分词、Prefill、Decode 到计费的完整链路，Token 的消耗则分布在算力、显存、通信和调度各个环节。 GPU 利用率只是过程指标，Token 成本才是 AI 基础设施真正的北极星指标 。把观测对象从 GPU 扩展到整条推理链路，才能解释“利用率高但体验差”的矛盾，并找到真正有效的优化点。

当你需要横向比较多个模型的 Token 单价、上下文能力与调用方式时，可以通过大模型 API 服务平台统一了解与接入，让选型和成本核算建立在可对比的数据之上。