AI 学习笔记（十六）：LLM 成本治理（Cost Governance）最小实践

发表于 更新于 分类于 阅读次数： Changyan： 本文字数： 2.9k 阅读时长 ≈ 3 分钟
从可观测性出发，把 LLM 成本治理落到可执行动作：token 预算、缓存命中、模型路由、降级策略与成本门禁，做到成本可控且不牺牲核心体验。

上一篇我们把可观测性最小闭环搭起来了。
这一篇继续生产运维实践第二部分：成本治理（Cost Governance）。

很多团队的常见状态是：模型效果还行，但成本曲线越来越不可控。
本质原因通常不是“模型太贵”，而是没有把成本做成可观测、可决策、可回滚的工程对象。

这篇不讲大而全的方法论，只讲一套可在一周内落地的最小实践。

1. 先统一口径：你到底在管什么成本

先把“成本”拆成三个可追踪维度：

  1. 流量规模：请求量、并发、峰谷分布
  2. 单位成本：单请求 token 消耗、模型单价、缓存命中率
  3. 返工成本：错误重试、超时重放、人工接管

如果只看“总费用”，你几乎无法做治理。
真正要管的是：单位请求成本是否可控，且在质量约束内可持续下降。

建议把核心目标写成一行：

  • 在不突破质量红线（准确率、拒答率、P95）的前提下，持续降低 cost_per_successful_request

2. 先做一个够用的成本看板

上一篇已经有了日志和指标，这里直接复用，补 6 个成本指标即可：

  1. cost_total：总成本
  2. cost_per_request：单请求成本
  3. cost_per_success：单成功请求成本（更关键）
  4. tokens_in_per_request：单请求输入 token
  5. tokens_out_per_request：单请求输出 token
  6. cache_hit_ratio：缓存命中率

再加两条分组维度：

  • 按 route/provider/model 分组（看路由策略是否合理）
  • 按 prompt_version 分组（看版本变更是否拉高成本）

做到这一步，你才能回答：

  • 成本上涨是流量增长导致，还是单位成本变贵？
  • 是哪个模型/路由在拉高成本？
  • 哪次 prompt 或检索改动导致 token 突增？

3. 四个最小治理杠杆（优先级从高到低）

3.1 杠杆一：token 预算与上下文裁剪

绝大多数线上成本问题都先出在 token。

先做三件事：

  1. 每个场景定义 max_input_tokens 和 max_output_tokens
  2. 检索结果做预算切片：先保留高相关、再保留新鲜、最后再补长文
  3. Prompt 模板版本化，避免“临时追加说明”越积越长

实践建议：

  • 输入预算先按 P95 设阈值，再逐步收紧
  • 输出长度按业务目标定上限，避免“答得越长越贵”

3.2 杠杆二：语义缓存（Semantic Cache）

对高重复问题，缓存是最直接的降本手段。

最小策略：

  1. 用规范化 query（去空格、去时间噪音）做缓存键
  2. 设短 TTL（例如分钟级或小时级，按业务时效调）
  3. 仅缓存“可复用且低风险”的结果（例如 FAQ、标准流程）

不要一上来追求复杂缓存架构，先看命中率和收益比：

  • cache_hit_ratio 上升 10%，通常就能显著压低单位成本

3.3 杠杆三：模型路由分层

不是所有请求都要进“最贵模型”。

可以先做最小两层路由：

  1. 标准层：默认用中等成本模型处理大多数请求
  2. 增强层：仅当风险高/上下文复杂时，升级到高质量模型

关键不是“能路由”，而是有明确升级条件，例如：

  • 用户等级/业务价值高
  • 检索置信度低
  • 首次回答未通过结构校验

3.4 杠杆四：失败成本治理（重试与降级）

隐形成本常来自“失败后不断重试”。

最小规则：

  1. 重试次数设硬上限（例如最多 1 次）
  2. 区分可重试错误和不可重试错误
  3. 超过阈值立即降级（小模型、短回答、规则兜底或人工接管）

目标是避免“为了追求一次成功，把成本拉爆”。

4. 成本门禁：把治理变成发布前检查项

建议把以下规则放进发布门禁：

  1. 新版本 cost_per_request 不得超过基线阈值
  2. 若成本上升，必须同时证明质量收益（准确率/完成率提升）
  3. 单位成本上升且质量无显著提升时，禁止发布

这一步非常关键。
如果没有门禁，成本治理会退化成“事后复盘”。

5. 一段可直接复用的最小成本记录代码（Node.js）

下面示例不依赖外部库，演示如何记录 token 和粗粒度成本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
const PRICE_TABLE = {
  "gpt-4.1-mini": { in: 0.0, out: 0.0 }, // 按你的真实价格配置
};

function estimateCost(model, usage) {
  const price = PRICE_TABLE[model];
  if (!price) return null;
  const input = (usage?.input_tokens || 0) * price.in;
  const output = (usage?.output_tokens || 0) * price.out;
  return Number((input + output).toFixed(6));
}

function logCostEvent(event) {
  console.log(
    JSON.stringify({
      ts: new Date().toISOString(),
      ...event,
    })
  );
}

export function recordLlmCost({ requestId, route, model, usage, success }) {
  const estimatedCost = estimateCost(model, usage);
  logCostEvent({
    event: "llm.cost",
    request_id: requestId,
    route,
    model,
    success,
    input_tokens: usage?.input_tokens || 0,
    output_tokens: usage?.output_tokens || 0,
    estimated_cost: estimatedCost,
  });
}

注意：上面是“治理用估算”，不是财务结算口径。
真正结算要以供应商账单为准，再做周期性对账。

6. 一周内可落地的执行清单

  1. 建立 cost_total、cost_per_request、cache_hit_ratio 看板
  2. 给每个业务路由设 token 预算上限
  3. 落地语义缓存最小策略并观测命中率
  4. 把路由切成“标准层 + 增强层”
  5. 给重试和降级加硬阈值
  6. 在发布流程增加成本门禁
  7. 每周固定复盘：高成本路由、低命中场景、异常突增原因

总结

成本治理不是单点优化，而是把“成本”变成可持续治理的系统能力：

  1. 看得见（指标与看板）
  2. 管得住（预算、路由、降级）
  3. 放得开（有门禁才敢持续迭代）

下一篇我会继续生产运维实践第三部分：LLM 事故响应（Incident Response）最小实践，把告警分级、止血流程、复盘模板和回归闭环串起来。

参考资料

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-cost-governance-minimal-practice/