Token 计费与成本优化：把大模型账单砍掉一半
Token 计费单位 · 输入/输出差异 · 缓存 · 批处理 · 成本治理清单
核心结论：大模型账单 = 输入量 × 输入价 + 输出量 × 输出价，而输出往往比输入贵数倍。降本的第一杠杆永远是「少生成、复用上下文」。
一、先把账算明白
| 计费项 | 含义 | 省钱重点 |
|---|---|---|
| 输入 Token | 你发给模型的全部文本 | 精简提示、用缓存 |
| 输出 Token | 模型生成的内容 | 限长度、要求简洁 |
| 缓存输入 | 命中的重复前缀 | 折扣计费 |
二、四条最划算的降本手段
- 压输出：设
max_tokens上限，提示词要求「不超过 N 字/条」，砍掉冗余客套话。 - 吃缓存：把不变的长系统提示、知识片段放请求最前面，变化内容置后，稳定命中提示词缓存折扣。
- 分层模型：简单任务用极小模型，仅复杂任务上旗舰，见选型指南。
- 批处理：离线大批量任务走批处理接口，时效换折扣。
三、成本治理清单
- 给每个 API Key、每个业务线设独立配额与预算告警；
- 对单用户/单 IP 限流，防恶意刷取；
- 监控「输入远大于输出」的异常模式（可能是提示词被注入循环）；
- 定期复盘高消耗会话，沉淀为更小模型的模板。
⚠ 误区：很多人只盯着「哪家更便宜」，却忽略输出长度失控。同样的任务，要求简洁与不要求，账单可能差数倍。
四、常见问题
Token 到底是什么，怎么算钱？
Token 是模型处理文本的最小单位，中文约 1-2 字为一个 token。费用按「输入 token 数 × 输入单价 + 输出 token 数 × 输出单价」累计，输出通常比输入贵数倍。
为什么输出比输入贵那么多？
生成是逐个 token 自回归计算，算力成本高于一次性编码输入。因此控制输出长度（如限制 max_tokens、要求简洁）对降本最直接。
提示词缓存（Prompt Caching）怎么省？
当多轮请求前缀相同（如系统提示、知识库片段），缓存命中后该部分按折扣计费。把不变的长上下文放前面、变化内容放后面，能稳定吃到缓存折扣。
批处理（Batch）适合什么场景？
对时效性不高的任务（如夜间批量摘要、离线分类），用批处理接口通常有明显折扣，适合异步大批量。
怎么防止账单突然爆炸？
设置用量上限与预算告警、对每用户/每接口限流、监控异常调用，并在代码里强制 max_tokens 上限。
免费额度算在成本里吗？
免费额度可覆盖验证期，但生产应按「满价」做预算，避免额度取消后成本跳变。
缓存一定省钱吗？
仅当请求前缀高度重复时才划算；每次都不同的长上下文反而可能因对齐开销略增延迟，需实测。