LLM 成本治理实践：Token、缓存与预算看板

十一月我们终于把“大模型花钱如流水”的问题控制住了。这篇文章总结了token成本治理的三板斧：监控、缓存、策略。

---

1. 成本透视：先把账算清楚

• Provider：OpenAI + 本地自建模型；
• 核心问题：
  1. Prompt 过长（平均 3.4K token），上下文冗余严重；
  2. 重复问题未复用缓存；
  3. 缺乏预算告警，月底才发现爆雷。

我们搭建了一个“Token 账本”Pipeline：

API 调用 → Kafka → ClickHouse (token_log) → dbt → Metabase 看板

字段包括：model, prompt_tokens, completion_tokens, user_id, feature, success, latency。

---

2. Prompt 策略优化

• 使用模板引擎（Jinja2），把业务规则结构化，减少自然语言废话；
• 压缩上下文：引入会话摘要器（每轮会话超过 3 条时用 tiktoken 计算长度，超出上限先 summarize 再传递）；
• 设定硬阈值：

if prompt_tokens > 2800:
		raise ValueError("prompt too long, please refine")

效果：平均 Prompt Token 降到 1.9K，节省约 44%。

---

3. 缓存与裁剪

• 引入 LangChain 的 SQLCache，Key 由 model + prompt hash + tool_state 构成；
• 对知识库问答，命中率能够达到 63%，直接降低调用次数；
• 对更长的生成任务，采用“分段缓存”：

输入 → 结构化任务 → 子任务调用 → 汇总

---

4. 成本告警与预算控制

• 预算：按产品线设月度预算，超出 80% 时告警；
• 工具：使用 Cloudflare Workers 搭建一个 Token Proxy，将调用先发到 Proxy，再根据策略放行；
• 告警配置（Prometheus Alertmanager）：

expr: sum_over_time(token_cost_total{product="copilot"}[1d]) > 800
for: 5m
labels:
	severity: warning

• 所有成本指标通过 Slack Bot 推送到日常工作频道。

---

5. 模型分级与灰度

• 把模型分成三档：旗舰（GPT-4）、高性价比（GPT-4o-mini）、本地（Qwen2-72B）；
• 调用策略：
  1. 默认走高性价比模型；
  2. 复杂问题（高失败率）或 VIP 客户才切到旗舰；
  3. 批量离线任务尽量用本地模型。

我们还做了一个小工具：根据问题类型动态推荐模型，降低人工判断成本。

---

6. 复盘与收益

指标	改造前	改造后	下降
月均 Token 成本	￥14.2w	￥7.9w	-44%
Prompt 平均长度	3.4k	1.9k	-44%
缓存命中率	12%	63%	+51%

此外我们引入了“成本回溯”机制：

• 每次版本迭代必须更新成本评估；
• 产品上线需填写“成本影响评估表”；
• 每月复盘一次，评估策略是否生效。

大模型的成本治理是一场持久战。只有把“指标、工具、流程”都建立起来，团队才能把钱花在刀刃上，而不是月底才开始补课。