详细解释
Token 预算（Token Budgeting） 这个词儿在中国互联网圈子又叫”Token 成本治理”或”AI 成本控制”——一句话定义就是：你公司一年打算在 LLM API 上花多少钱，这笔钱怎么按部门 / 产品线 / 功能点拆分配额，以及怎么用技术手段把每一块钱花得最值。Token 价格看起来很便宜（每百万输入 $0.15 到 $5 不等），但一旦你业务上线 100 万日活，平均每人 30 轮对话，一不留神月账单能冲七位数。预算做早了（产品阶段就规划）是成本优化；做晚了（账单超了才管）就是事故抢修。
真实 SaaS 产品：从 0 到 1 亿 Token/天 的五层预算架构
根据 唯元智创 服务过的 300 家 AI 客户实战经验，90% 产品的 Token 成本优化可以按下面五层金字塔做，每一层能让你的单位输出成本下降 20% 到 60%，合起来整体成本会是”一开始不做优化”的 10% 到 20%。
| 优化层级（金字塔从下往上） | 技术手段 | 成本下降幅度 | 实施复杂度 | 对效果影响 |
|---|---|---|---|---|
| ① 分级路由（选对模型就赢一半） | 简单任务 → 小模型（如 qwen-2.5-7b）；中等任务 → 中模型；高难推理/数学/多语言 → 大模型（如 qwen-2.5-72b 或闭源 SOTA） | 40% 至 70% | 低 | 0% 影响（模型分对了效果反而更好） |
| ② 提示词瘦身 | 删掉没用的 Few-shot 示例、缩短 System Prompt 废话、用结构化模板代替自然语言长篇解释 | 20% 至 50% | 低 | -1% 到 +2%（反直觉：短 Prompt 往往还更准） |
| ③ KV 缓存复用 + 提示词缓存 | 多轮对话保留 KV Cache 增量推理；文档问答把企业知识库上下文做 Prompt Caching（唯元智创支持 prompt-cached 价格 50% 折扣） | 25% 至 60% | 中 | 0% 影响（只是把重复算的部分省了） |
| ④ 结构化输出来截短 | 开启 JSON / XML Schema 模式强制固定输出，别让模型写”好的，以下是提取到的实体：“这种客套话 100 字符；直接 {entities: [...]} | 15% 至 30% | 低 | +3% 效果（少了废话，下游解析反而更稳） |
| ⑤ 后处理 + 缓存 + 回退组合 | 相同用户重复问题先做 Redis 语义缓存命中（命中率通常 20% 到 40%）；大模型失败时路由回小模型兜底 | 20% 到 40% | 中高 | -1% 影响（命中了是历史结果，但几乎用户感知不到） |
实战例子：某 AI 客服 SaaS，上线一个月后 Token 成本 28 万/月。按上述五层优化三个月后：
- 分级路由：把 80% 的 FAQ/闲聊单轮问句转到 7B 小模型（成本降到原来 1/6）
- 提示词瘦身：System Prompt 从 1200 Token 减到 320 Token
- Prompt Caching：客服知识库背景段命中后，输入费打 5 折
- JSON 结构化输出：原先每次回答写”根据公司规定…”铺垫 80 字，现在直接返回意图 + 操作卡片
- 语义缓存：相同问题（改了个语气词）直接命中 Redis，38% 的请求没打 API
最终月账单：6.3 万 / 月（同比 -77.5%），客户满意度评分 4.7 → 4.8（反而略涨）。
三个常见”伪省钱”陷阱
做 Token 预算优化时避以下三条坑，别把钱花去又把产品做崩：
- “只要温度设 0 就省钱”：错，Temperature 只影响输出采样，不决定输出 Token 数量；短任务温度 0 反而会把模型的”跳脱创造力”杀了，客服对话会像机器读稿。
- “max_output_tokens 设 128 最省”：错，max_output_tokens 是”最大允许输出”不是”保底输出”——设太低会把本该 200 Token 说明白的答案砍到一半就停了，用户反而投诉。正确做法：根据任务分桶，分类任务 max=32，总结任务 max=512，写作任务 max=2048。
- “全公司统一用一个大模型 Key 就是省”：错，你无法分业务线做预算归因（不知道哪个产品线花的钱超标了）。正确做法是 唯元智创控制台 API Key 子账号体系 一条产品线 / 一个功能点一个独立 Key，每个 Key 独立设置
spend_limit日/月上限和rate-limit，谁超了砍谁。
唯元智创的 Token 预算看板（免费）
唯元智创 为所有企业客户提供 3 个预算治理工具：
- Token 成本归因看板：按 Key / 模型 / 用户 ID / 日 四维聚合，Top-N 超支 API 自动高亮。
- Spend Limit 熔断（见 Spend Limit 词条）：单个 Key 到阈值直接 402 Payment Required 返回，防止事故性账单。
- 分级路由 SDK：一行代码
client.chat.completions.with_fallback([SMALL_MODEL, BIG_MODEL])自动分级，不卡业务。
常见问题
怎么估算一个新产品的初始 Token 预算？
用”用户数 × 人均会话 × 会话输入 + 会话输出”三条公式算。先给几个基准数：单轮纯问答输入 800 Token、输出 400 Token；多轮对话（客服）累积输入 3000 Token、输出 1200 Token；带 RAG 的问答输入 4000 Token、输出 600 Token。例如：冷启动产品，日活 1 万，每人每天 3 轮”短问答” → 10k × 3 × (800+400) = 3600 万 Token / 日，按唯元智创分级路由均价 ¥2.5/百万输入 + ¥8/百万输出，≈ ¥144/天 → 初始月度预算 4320 元，给 2 倍冗余打 1 万就够。预算 10% 用来做 Spend Limit 熔断阈值上限（1000 元/日），安全启动。
流式 SSE 输出会比非流式更费 Token 吗？
发现成本超了，紧急救火应该先做哪三件事？
顺序非常重要，别乱：① 先对 Key 设 spend-limit 日上限 + RPM 限流（立竿见影，不会再往上爆）；② 立即把分类/抽取/翻译类确定性任务切到小模型；③ 把 System Prompt 中超过 500 Token 的”公司介绍 + 历史对话压缩”换成 Prompt Caching 固定块。通常 1 小时内就能把超支打回预算线内，之后再慢慢做分层路由 + 缓存 + 结构化的长期优化。