LLM 成本管理实战：从 Token 账单到单位经济学（2026 版）

AI 项目的财务事故，大多不是”效果不行”，而是”成本失控”

同一个客服机器人，两家客户各跑三个月：A 的模型账单是 B 的 50 倍。代码结构几乎一样，差在没人管成本——A 的每次对话都把全部历史重发给模型，B 在网关层做了历史截断；A 所有请求都走旗舰模型，B 把 80% 的简单问题路由给了小模型。

LLM 成本管理的本质，不是”选便宜的模型”，而是把”每次业务动作花多少钱”变成一个可度量、可设限、可告警的工程指标。 这篇文章给一套能直接落地的框架：成本结构拆解 → 单位经济学 → 四层降本杠杆（含量化收益）→ 预算与告警 → 多项目分摊 → 上线前自检表。

---

一、先拆成本结构：钱到底花在哪

1.1 Token 计费的三个”反直觉”

计费项	单价关系	量级关系	失控风险
输入 Token	基准价（最便宜）	通常是输出的 5-20 倍	高——上下文膨胀、历史重发
输出 Token	3-5 倍于输入	受 max_tokens 约束	中——跑题/循环生成会放大
推理 Token（o1/R1 类）	按输出计费	不可见、不可控（模型自己决定想多少）	高——一个”简单问题”可能想 8000 token
缓存命中输入	10-25% 基准价	同输入	低——但提示词结构不对就永远不命中
Embedding	约为输出的 1/10	RAG 场景量很大	低——容易被忽略
Rerank	按文档对数计费	每次检索 20-100 对	低——容易被忽略

三个最常见的成本陷阱：

1. 上下文膨胀：多轮对话每轮重发全部历史，第 N 轮输入 = 前 N-1 轮之和。10 轮对话的总输入 ≈ 第 1 轮的 55 倍（等差数列）。
2. 隐形调用：超时重试、JSON 解析失败重新生成、级联路由的”探测调用”——这些在账单里和正常调用一样计费，但没人记账。
3. 推理 Token 黑洞：用 o1/R1 类模型时，reasoning token 按输出计费但内容不可见。同一个问题，思考 200 token 和 8000 token 的差价是 40 倍，而你无法直接从请求参数控制。

1.2 拆账单：三个维度

拿到月度账单，按 模型 × 调用方 × 场景 三维度拆开（网关层记录每次调用的 model / api_key / scenario_tag / tokens，聚合即可）：

场景        模型           输入Token   输出Token   成本(元)  占比
客服-FAQ    qwen-turbo     42,000,000   3,100,000    680     38%
客服-工单   qwen-max       8,500,000    2,900,000   1,020    57%
摘要-离线   qwen-turbo     96,000,000   1,200,000     95      5%

这张表一眼能看出问题：客服-FAQ 场景 85% 的 Token 花在输入上（42M 输入 vs 3.1M 输出）——大概率是历史没截断；客服-工单用 max 模型占了 57% 成本——看是否所有工单都值得 max。

没有这张表，一切优化都是猜。

---

二、单位经济学：用 Cost per Task 替代”单次调用价格”

2.1 为什么 $/request 是错的指标

单次调用价格是”单价”，不是”业务成本”。两个反例：

• 小模型更贵的陷阱：小模型 $0.1/次、成功 70%（30% 要人工兜底）；大模型 $0.5/次、成功 99%。人工成本 $5/次时：小模型总成本 = 0.1 + 0.3×5 = $1.6，大模型 = 0.5 + 0.01×5 = $0.55。选便宜的单价，总成本贵 3 倍。
• RAG 的隐藏成本：一次”问答”实际是 embedding + 向量检索 + rerank + LLM 生成 4 个成本项，LLM 生成往往只占 60-80%，剩下的是”基础设施税”。

2.2 Cost per Task 的算法

Cost per Task = Σ(任务链路上所有调用成本) / 业务完成的任务数

落地四步：

1. 定义”任务”：客服=一条工单闭环（不是 API 请求数）、摘要=一篇文档产出、代码审查=一个 MR 处理。
2. 链路记账：网关层给每次调用打 task_id（业务侧生成，贯穿 embedding→rerank→LLM），聚合出每任务总成本。
3. 分母用”业务完成”：人工兜底的工单也算完成（成本里含人工），失败重试的任务按 1 个任务计。
4. 和基线比：上 AI 前的人工成本/任务 vs 上 AI 后的（模型成本 + 系统运维分摊 + 人工兜底×兜底率）。只有这个对比能回答”这个项目值不值”。

2.3 三个配套指标

指标	定义	用途
Cost per Task	见上	项目 ROI、横向比较
Token Efficiency	完成任务 / 每百万 Token	提示词工程是否有效（同样任务花了更少 Token）
Quality-Adjusted Cost	Cost per Task / 质量分（人工抽检或 LLM-as-a-Judge）	防止”降本=降质”的自欺

---

三、四层降本杠杆：按顺序上，收益可量化

杠杆	典型收益	风险	适用
① 上下文瘦身	输入 Token -20~40%	低（截断策略要测）	所有多轮/长文场景
② Prompt Caching	长前缀输入再 -50~75%	低	长系统提示/长文档问答
③ 模型路由	整体 -40~70%	中（质量波动）	流量难度分布不均
④ Batch Inference	离线场景 -50%（供应商折扣）	无（延迟不敏感）	摘要/标注/批量生成

顺序很重要：先瘦身再缓存（瘦身后前缀更稳定，命中率更高）→ 再路由（路由到小模型后缓存收益变小）→ 批处理最后（独立于前三者）。

3.1 上下文瘦身（第一优先级，零风险）

• 历史截断：只保留最近 N 轮 + 更早轮次的摘要（用 1/10 价格的模型离线生成）。10 轮以上对话输入通常降 50-70%。
• System Prompt 瘦身：把”人设+规则+示例”里用不到的示例删掉（few-shot 示例 3 个通常够，10 个是浪费）。
• RAG 场景：top-K 从 10 降到 5 + rerank 精排，召回质量通常不掉，输入降 40-60%。
• 结构化输出：要求模型输出紧凑格式（JSON 无冗余字段、markdown 列表不嵌套），输出 Token 降 10-30%。

3.2 Prompt Caching（长前缀场景的 50-75%）

命中条件：请求前缀与缓存的前缀逐字节一致。工程要点：

1. 提示词”前静后动”：固定内容（人设、规则、长文档、few-shot 示例）全部放前缀，变化内容（用户问题、检索结果）放后面。
2. 多轮对话：历史本身成为前缀——第 N 轮的前 1~N-1 轮内容天然命中，只要你不重排历史。
3. 不要在前缀里放时间戳/随机 ID：一个变化的字段会让后面全部失效。
4. TTL 意识：供应商缓存通常 5-10 分钟 TTL，低频场景（每天几百次）命中不了，别指望。

3.3 模型路由（40-70%，但有质量代价）

三种路由策略，按复杂度递进：

• 规则路由：按场景硬编码（FAQ→小模型，复杂分析→大模型）。最稳，先做这个。
• 级联路由（cascade）：小模型先答 + 置信度判定（输出”我不确定”或格式校验失败）→ 升级大模型。省 50%+ 且质量兜底，代价是简单任务也有一次小模型开销。
• 语义路由：用小模型/embedding 对请求做难度分类再分发。最灵活但引入额外调用成本，流量大（日均 >10 万）才划算。

级联的置信度判定是核心：不要只靠”模型说自己不确定”（模型普遍过度自信），组合用——输出格式校验 + 关键词兜底（“无法确定/信息不足”）+ 长度异常（异常短/异常长）。

3.4 Batch Inference（离线场景固定 50%）

摘要、数据标注、批量生成、评测跑分——一切不要求实时返回的场景，走供应商 batch API（OpenAI/通义等普遍 50% 折扣）。注意：

• 结果 24h 内返回（供应商 SLA），业务侧要有”完成回调 + 超时补跑”。
• batch 文件按场景拆分，别把高优和低优混在一个文件里（一个文件一起返回）。
• 成本记账时 batch 调用的单价要单独标记，否则 Cost per Task 算错。

---

四、预算与告警：把成本当 SLA 管

4.1 Token Budget：硬上限 + 软告警

budgets:
  - scope: { project: cs-bot, scenario: faq }
    monthly_limit_tokens: 200_000_000     # 输入+输出合计
    warn_pct: 80                          # 到 80% 发告警
    on_exceed: degrade                    # 降级到小模型 / 拒绝 / 审批放行
  - scope: { project: cs-bot }            # 项目级总闸
    monthly_limit_tokens: 300_000_000
    on_exceed: block                      # 直接拒绝 + 通知负责人

实现要点：

• 计量在网关层：每次调用记录 input_tokens / output_tokens / reasoning_tokens / model / api_key / scenario / task_id，累加到 Redis（或 Prometheus Counter），不信任客户端自报。
• 双闸门：场景级（细粒度降级）+ 项目级（总闸熔断），两层都要有——只有一层时，某个场景的 bug 会烧穿整个项目。
• on_exceed 三选一：degrade（降级小模型，业务不中断）/ block（拒绝，适合内部工具）/ approve（人工审批放行，适合大客户 SLA 场景）。

4.2 Cost SLO：成本也是 SLO

不是”成本越低越好”，而是**“每任务成本 ≤ X”**。把成本指标和延迟、成功率并列进监控大盘：

SLO	目标	告警阈值
Cost per Task（客服）	≤ 0.8 元	7 天均值 > 1.0 元
P99 延迟	≤ 8s	P99 > 12s（5min 窗口）
成功率	≥ 99%	< 98%（5min 窗口）

Cost per Task 超标通常意味着：路由变了（大模型占比上升）、提示词变长了、流量结构变了（简单问题占比下降）、供应商调价。这四个原因，前两个你能控制，后两个要写进合同和变更流程。

4.3 三条必设的异常检测规则

1. 单调用 output token > P99 × 3：跑题/循环生成/提示注入导致的”复读机”，单次能烧掉正常调用的 100 倍。
2. 单租户日成本 > 历史 7 日均值 × 3：滥用、攻击（有人拿 API Key 刷）、或 bug（重试风暴）。
3. 整体成本环比周 +50%：流量结构变化、供应商调价、或某个新场景上线没做预算。

告警必须带归因（模型/调用方/场景/Top 异常请求样本），否则 on-call 收到”成本超了”四个字没法止血。

---

五、多项目分摊：内部 AI 能力怎么算账

规模	方案	要点
<5 个团队	统一预算，出场景报表	不分摊，每月成本复盘会过异常项
5-20 个团队	项目级 Key + 独立预算	网关按 Key 计量，成本中心映射项目，超额审批
20+ 团队（AI 中台）	内部定价结算	结算价 = 供应商成本 × 1.1-1.3（含运维摊销），用量仪表盘三视图

三条铁律：

1. 计量在网关，不信任客户端——客户端自报的 token 数既不准也不安全。
2. 分摊到”场景”不到”团队”——一个团队 Key 下混着 FAQ 和复杂分析，永远算不清；场景标签在网关强制要求。
3. 月成本复盘 10 分钟——过一遍异常 Top 5（哪个场景/项目/模型，环比变化，为什么），比任何成本报表都有用。

---

六、上线前成本自检表

检查项	通过标准
基线测算	有”预估月调用量 × 任务链路成本 = 月成本”的测算表，含 3 倍流量余量
计量埋点	网关记录 model/key/scenario/task_id/tokens 五要素，可聚合出 Cost per Task
预算闸门	场景级 + 项目级双层预算，on_exceed 策略明确
历史截断	多轮对话有截断/摘要策略（N 轮可配置），实测第 10 轮输入 ≤ 基准 3 倍
前缀稳定	System Prompt 无时间戳/随机 ID，长文档放前缀，缓存命中监控已埋
路由策略	简单流量有明确的小模型路径，级联的升级判定有格式+关键词双校验
离线场景走 Batch	摘要/标注/批量任务全部走 batch API，单价单独记账
异常告警	三条规则（单调用 P99×3 / 租户日成本 3× / 周环比 +50%）已配，告警带归因
推理模型隔离	o1/R1 类模型限定在”确实需要深度推理”的场景，有 reasoning token 监控
调价应对	供应商调价流程：成本测算 → 路由调整 → 预算重设（3 步，1 周内完成）

---

成本管理是 AI 项目的”第二架构”

很多团队把成本当”上线后的运营问题”，结果第一版全量旗舰模型 + 全量历史重发，账单出来当天就找架构师。成本管理应该在写第一行业务代码之前定下来——计量埋点、预算闸门、路由策略，这三样进了架构，后面的降本都是微调；没有这三样，每次降本都是重构。

我们交付过多个成本敏感项目：客服系统通过”截断+缓存+级联路由”组合拳把单任务成本压到人工成本的 1/4、内部中台通过场景级分摊让 20+ 团队各算各的账、离线标注管线全量 Batch 化省掉一半预算。如果你正在规划 AI 项目，欢迎带着账单（或预估）来聊——先帮你做成本结构分析（钱花在哪、能省多少、怎么省），再谈实施。

---

延伸阅读：

• LLM 模型选型与路由实战 — 能力-成本矩阵与三类路由策略
• 云成本优化实战 — 账单分析、资源优化与架构降本
• LLM 评测体系实战 — Eval Set 设计与质量-成本权衡的评测方法
• 企业私有知识库 RAG 落地实战 — RAG 链路各环节的成本构成
• AI 项目上线后怎么评估 — Cost per Task 在项目评估中的用法
• LLM 结构化输出实战 — 解析重试与降级路径的成本账：失败兜底怎么不烧钱

需要 LLM 成本结构分析、预算体系搭建或降本改造？联系我们 获取免费评估。