LLM API 成本怎么算：把 token 账算清楚

做 LLM 应用，最常被问的一句话是"这个功能每天要花多少钱"。答案取决于一个变量：每次请求消耗多少 token。这篇把这笔账拆开算一遍，顺便讲讲哪几个地方最容易算错。

token 到底是什么单位

模型不按字数收费，按 token 收费。token 是模型处理文本的最小单元，大致规律：英文 1 个 token 约等于 3/4 个单词；中文因分词方式不同，通常 1 个 token 对应 1 到 1.5 个汉字。具体比例取决于你用的模型的 tokenizer，但量级够用——中文 1000 字大约 700 到 1000 token。

一个容易忽略的点：上下文里的每样东西都是 token。用户消息、系统提示、工具函数定义、检索出来的文档片段、历史轮次，全部计入输入。很多应用的实际输入 token 是"用户那段话"的 5 到 10 倍。

一次请求的成本怎么算

账单公式很直白：

成本 = (输入 token 数 + 输出 token 数) × 对应单价

两个坑先说清楚。第一，输入和输出的单价通常不一样，输出一般更贵，比例从 2 倍到 5 倍不等。第二，单价在阶梯计价和包月额度下会变，小规模测试时得出的"单次成本"放到量大之后不一定成立。

举个具体例子。一个客服机器人：

- 系统提示 800 字 ≈ 900 token

- 保留最近 10 轮对话，平均每轮 150 字 ≈ 1000 token

- 检索注入 3 段产品文档 ≈ 800 token

- 模型回复约 200 字 ≈ 250 token

单次请求约 2700 token 输入 + 250 token 输出。假设单价为输入 0.5 美元/百万 token、输出 1.5 美元/百万 token（各厂商差异很大，以下都用这个假设做例子）：

单次 ≈ 2700/1000000 × 0.5 + 250/1000000 × 1.5 ≈ 0.0017 美元

一天 1 万次请求 ≈ 17 美元/天，月成本约 500 美元。这个数字的量级感是真的：一个每周 50 万次请求的中等规模客服，月账单过万并不夸张。

成本优化只有四条路

1. **压缩上下文**。历史对话最常见的做法是加"过期"：超过 15 分钟的轮次丢弃，或用摘要替代原文。检索文档注入前先做一次相关性过滤，只留最相关的 1 到 2 段。每砍掉 500 token 输入，万次请求就省 5 万 token/天。

2. **缓存稳定前缀**。系统提示、工具定义这类每次都重复的长文本，多数厂商支持 prefix caching，命中部分按折扣价计费。系统提示越长、请求量越大，缓存收益越明显。这是改动最小、见效最快的一招。

3. **按难度路由**。分类、匹配、格式化这类任务，用规则或小模型；真正需要多步推理的请求才交大模型。这不是口号，而是一个 if 分支的事，通常能把大模型调用量压掉一大截。

4. **限制输出长度**。max_tokens 设一个合理上限，配合提示词明确"3 句话内回答"。一个回答 50 字够用的场景不该允许模型啰嗦到 500 字——输出 token 单价又高，啰嗦等于双倍花钱。

这四个手段的组合拳，把单请求成本压掉 30% 到 50% 是常见水平，而且不影响回答质量。

怎么知道自己实际花了多少

别靠估算，靠日志。每次 API 响应的 usage 字段里有 prompt_tokens 和 completion_tokens，把这两个数写进你的访问日志，按天聚合，就是一个真实的成本曲线。不要等月底对账单才发现超了。

两个常见异常要能立刻发现：

- 输入 token 突然翻倍：多半是某处的上下文拼接出了 bug，比如在循环里重复注入同一段文档，或者历史轮次没截断。

- 请求开始大量报"超过上下文长度"：上下文快满了，你的压缩策略失效了，要么砍历史，要么换长上下文模型（后者更贵）。

小结

把 token 用量当成和响应时间一样的工程指标：有监控、有预算、有告警。上线前列一个静态估算，跑一周后用真实 usage 数据修正一遍。之后每次改提示词、调上下文物、换模型，都重新校验一次。成本问题不是一次性算出来的，是持续校准出来的。