11. Token 计费与用量控制怎么做？
整理 Token 计费、用量统计与预算控制方案。
简单回答
Token 计费的核心是精确统计每个请求的 input tokens 和 output tokens，按模型和请求类型定价计费。用量控制包括预算上限、速率限制和用量告警。关键难点是 output tokens 只有在推理完成后才知道确切数量，以及不同模型的 tokenizer 计算方式不同。
详细解释
Token 统计
每个请求需要精确记录 input_tokens（发送给模型的 Prompt 的 token 数）和 output_tokens（模型生成的回答的 token 数）。如果是调用外部 API（OpenAI、Anthropic），响应体里通常会返回 usage 字段，包含精确的 token 数。如果是自建推理服务，需要自己用模型的 tokenizer 计算。
不同模型的 tokenizer 不同，同一段文本在 GPT-4 和 LLaMA 中的 token 数可能差 20%~30%。所以 token 统计必须用对应模型的 tokenizer，不能用通用的 word count 估算。一个常见的做法是在 Gateway 层统一做 token 计数，用 tiktoken（OpenAI）或 transformers 库的 tokenizer。
计费模型
最常见的计费方式是按 token 定价，input 和 output 价格不同（output 通常贵 2~ 4 倍，因为生成比编码更消耗算力）。不同模型价格也不同（GPT-4 比 GPT-3.5 贵 10 ~30 倍）。
计费粒度可以是按用户、按团队、按项目、或按 API Key。toC 产品通常按用户设配额（免费额度 + 付费额度），toB 产品通常按企业做月度计费。
一个容易忽略的成本项是"隐藏的 token 消耗"。System prompt 每次请求都要重复发送，它的 token 也算钱。RAG 检索结果可能很长，也消耗大量 input tokens。Agent 场景中一个用户请求可能触发多次 LLM 调用（工具调用循环），实际 token 消耗可能是用户可见输出的 5~10 倍。
用量控制
预算上限：为每个用户/团队设置每日或每月的 token 预算。接近上限时发告警，达到上限时限制使用或降级。速率限制：每分钟/每小时的 token 消耗限制，防止短时间内大量消耗。用量告警：异常用量检测——如果某个用户的消耗突然飙升（可能是 Prompt 注入导致的无限循环，或者 Agent 死循环），需要及时告警并介入。
Prompt Caching 的成本优化
如果多个请求有相同的 system prompt 前缀（在大模型应用中这很常见），可以利用 Prompt Caching 技术。Anthropic 和 OpenAI 都提供了 Prompt Caching 功能，缓存命中后 input tokens 的价格大幅降低（通常 10%~25%）。在 system prompt 很长的场景下（比如 RAG + 工具定义可能有几千 token），Prompt Caching 的节省效果非常显著。
工程实现
计费系统通常异步处理。每个请求完成后把 token 用量写入消息队列，计费服务消费队列做累加和扣费。不要在请求关键路径上同步做计费，影响延迟。用量数据存储建议用时序数据库（InfluxDB、TimescaleDB）或列式存储（ClickHouse），方便做时间维度的聚合分析。
面试时可以这样答
Token 计费的基础是精确统计每个请求的 input 和 output tokens。调外部 API 的话响应里有 usage 字段，自建服务需要用对应模型的 tokenizer 自己算。不能用字数估算，不同模型的 tokenizer 差异可以到 20%~30%。
计费模型通常按 token 定价，input 和 output 分开算，output 更贵。一个容易忽略的点是隐藏消耗——system prompt、RAG 结果、Agent 多轮调用，实际 token 消耗可能是用户可见输出的好几倍。
用量控制要做预算上限、速率限制和异常告警。特别要注意 Agent 场景的死循环——一个请求可能触发几十次 LLM 调用，token 消耗爆炸。
成本优化方面，Prompt Caching 在 system prompt 很长的场景下效果非常好，缓存命中后 input 成本可以降到原来的 10%~25%。计费系统本身建议做异步处理，不要影响请求延迟。
常见追问
- 流式输出中途用户断开连接了，已经生成的 token 该不该计费？
- 怎么预估一个请求的 token 消耗？能不能在请求前就告诉用户大概花多少钱？
- 多模态输入（图片、文件）的 token 消耗怎么计算？