从 Token 到 Transformer · 02 / 10
“这段提示词只有两千字，为什么还是很慢？”
这个问题里的“字”不是模型真正使用的尺度。语言模型接收和生成的都是 token 序列；对系统来说，token 同时是长度单位、计算单位，商业 API 中还经常是计费单位。把它只当成换了一种名字的字数，会漏掉几乎所有重要的工程影响。
一次请求有两段不同的时间
推理延迟通常可以拆成两个阶段。
第一段是 prefill：模型读完已有输入，为整段上下文建立内部状态。输入越长，这一步通常越重。标准全量 self-attention 需要比较大量位置关系，计算和显存压力会随序列长度快速上升；具体实现可以用缓存、稀疏注意力或分块策略缓解，但“长输入更贵”仍是基本事实。
第二段是 decode：模型基于已有状态，一个 token 接一个 token 地生成答案。输出 20 个 token 和输出 2,000 个 token，不只是内容长度不同，也意味着完全不同的串行生成时间。KV cache 能避免重复计算全部历史，却不能把自回归生成变成一次性输出。
因此，优化延迟时必须先问清楚：慢在读入，还是慢在生成。只设置一个模糊的“最大 token 数”通常解决不了根因。
成本不只来自用户输入
许多模型服务按输入与输出 token 分别计价，有些还区分缓存命中与未命中。真正进入账单的内容通常包括：
- system prompt 与工具说明；
- 对话历史；
- 检索回来的文档片段；
- 用户本轮输入；
- 模型生成的输出；
- 结构化模板和用户看不到的特殊 token。
一个看似只有一句话的请求，背后可能携带数万 token 的历史和工具定义。做成本分析时，只统计输入框里的字符数，会低估最昂贵的部分。
上下文窗口是一块共享空间
上下文窗口不是“模型最多能读多少正文”，而是本次推理所有 token 的总预算。历史对话、RAG 片段、代码文件和预期输出会竞争同一块空间。
当总长度接近上限时，系统只能做几件事：截断、摘要、分块，或拒绝请求。最危险的情况不是请求直接报错，而是某段重要背景在自动截断中悄悄消失。模型随后给出的答案可能依然流畅，却建立在不完整的信息上。
这也是 token 数量会影响“效果”的主要原因：并不是多一个 token 会让模型变笨，而是低价值内容会挤占证据、约束和输出所需的空间。
批处理还有一笔隐形账
推理服务常把多条请求组成 batch，以提高硬件利用率。不同序列要放进规则张量时，短输入通常会 padding 到批次中的某个统一长度。
如果一条 200-token 的请求与一条 8,000-token 的请求被粗暴地放在一起，前者可能携带大量无效填充。成熟的服务会按长度分桶、动态批处理或使用更紧凑的注意力实现，目的都是减少这类浪费。
所以 token 成本既是内容问题，也是调度问题。同一组请求换一种 batching 策略，吞吐可能显著不同。
真正值得优化的是信息密度
“尽量写短”不是可靠的提示词原则。过度压缩会删除边界条件，让模型只能猜。更好的目标是让每一段上下文都承担清晰职责：
- 保留会改变答案的事实和约束；
- 删除重复背景与无效礼貌用语；
- 检索只返回能支持当前问题的证据；
- 长历史提炼为可核验的状态，而不是反复原样拼接；
- 给输出设置与任务相匹配的长度，而不是一律追求长答案。
例如，要求模型“详细、全面、深入地分析，并尽可能多地列举”通常只会扩大输出，却没有定义质量。相比之下，“给出三个方案，按风险和实施成本比较，每项不超过 120 字”同时限定了结构和预算。
一个实用的预算拆法
在产品里，可以把总窗口拆成四个桶：
text固定开销：system prompt、工具定义、模板 任务输入：用户问题、文件、检索证据 工作余量：模型推理和中间结果需要的空间 输出预算：最终回答允许生成的长度
先测量固定开销，再为不同任务设置输入和输出上限。监控时至少记录 input tokens、output tokens、首 token 延迟、总延迟和截断原因。没有这些数据，“优化 token”很容易退化成凭感觉删字。
小结
Token 把模型的语言行为连接到了真实的系统资源：输入越长，prefill 越重；输出越长，串行生成越久；上下文越拥挤，重要信息越容易被挤掉；服务按 token 计费时，成本也会随之增长。
好的 token 管理不是一味缩短文本，而是把有限的上下文留给最能改变答案的内容。