LLM 应用的成本核算——Token 计费到单位经济
LLM 应用的成本核算方法。按 Token 计费、成本归因、单位经济三层展开，给出各层所需表格与公式，并梳理优化杠杆与治理要点，供核算成本毛利。
一 成本核算的目标：从"花了多少"到"值不值"
LLM 应用的成本核算要回答三个递进的问题：① 每次调用花了多少（token 计费层）② 每个用户 / 每次会话花了多少（归因层）③ 每个业务单元（订单 / 工单 / 付费会话）的毛利是多少（单位经济层）。多数团队的核算停在第 1 层（月底看 API 账单），但真正的决策（"这个 feature 做不做""定价定多少""要不要换小模型"）依赖第 2、3 层的数据。本文把三层拆开讲清。
二 Token 计费层：把账算准
| 成本项 | 计费方式 | 常见坑 |
|---|---|---|
| 输入 token | 按 token 数 × 输入单价（每 1000 token） | 长上下文请求单价不高但量巨大；"重复发同一 prompt"是最常见的浪费源（缓存命中率低） |
| 输出 token | 按 token 数 × 输出单价（通常是输入的 4-5 倍） | 输出不可截断（被 max_tokens 截断的也算全价）；"模型话痨"（同一问题输出 500 token vs 50 token）成本差 10 倍 |
| 缓存命中（cached token） | 多数供应商缓存命中输入 token 单价 1/10 或免费 | 缓存键设计不当（prompt_version / 参数差异）导致命中率虚低；要单独统计"缓存命中率"作为优化 KPI |
| 批处理 / 异步 | 部分供应商批处理价 5 折 | 延迟敏感型请求不适用；"能不能批"要按任务 SLA 分层 |
| 自建推理（自建 / vLLM / GPU） | GPU 时 × 单价（按 H / 月 或按 token 摊销） | GPU 利用率 <30% 时自建成本高于 API；利用率是自建 vs API 的分界指标（见本站《LLM 网关》的路由策略） |
| 嵌入 / 重排 | 通常按调用次数或 token 另计 | 多模态嵌入（ColPali 类）单价是纯文本嵌入的 10-30 倍；检索链的"隐形成本" |
核算工具落地要点：每次响应后按实际 token 数回写用量（不是估算），并把 (租户 / feature / 模型 / prompt_version / 渠道) 作为归因维度打 label。没有 label 的账单是"一锅粥"——只能看到总成本，看不到"谁在烧钱"。
三 归因层：把钱算到"人"和"事"上
- 按 feature 归因：同一应用的"智能客服 / 摘要 / 代码补全"三个 feature 各占多少成本？这决定优化优先级（成本高的 feature 先优化，不是最复杂的先优化）。
- 按用户分层归因：付费用户 vs 免费用户的 token 成本分布长尾极重（top 1% 用户常占 30-60% 成本）；免费用户的成本上限（每日 / 每月 token cap）是产品决策的核心参数，不是技术细节。
- 按会话归因：一次会话 = 多轮 = 多次模型调用 + 多次检索 + 多次工具调用；会话级成本是"用户体验价格"的锚点（"问一个问题值多少钱"对用户可感知）。
- 按失败成本归因：重试 / 降级 / 拒答后的二次调用也是成本；"一次问对的请求"与"问了三遍才过的请求"成本差 3 倍，失败率直接进成本模型。
- 归因到具体 prompt 版本：prompt 变长的版本 token 成本上涨，prompt 精简的版本下降——版本化（见本站《提示词版本管理》）是成本归因的前提，没有版本号的成本数据无法复盘"哪版 prompt 最烧钱"。
归因看板的最小集：feature × 模型 × 时段的三维成本热力图 + top-10 消耗会话列表 + 每日 / 每 feature 成本曲线。有了这三块，"成本从哪来"的问题 5 分钟内能答。
四 单位经济层：从成本到毛利
| 业务单元 | 收入侧 | 成本侧（直接 + 分摊） | 毛利公式 |
|---|---|---|---|
| API 按次 | 单次调用定价（如 ¥0.05 / 次） | token 成本 + 网关 / 基础设施分摊 | 单价 - 单次 token 成本 - 分摊 |
| 订阅制（月费） | 月费 / 用户 | 用户月均 token 成本 + 服务 / 支持成本 | 月费 - 月均成本 - 支持成本 |
| 按结果计费（每解决工单） | 每工单定价 | 工单平均 token 成本 × 解决轮次 + 人工兜底成本 | 工单价 - 轮次 × 单次成本 - 人工分摊 |
| 企业定制（包年） | 年费 | 年 token 预算 + 专属部署 / 运维 / 支持 | 年费 - 年成本 - 专属资源 |
单位经济核算的三个关键判断：① 毛利是否为正（直接成本 < 收入，否则业务模型不成立）② 毛利是否覆盖间接成本（研发 / 运维 / 支持 / 合规分摊后的"真毛利"）③ 毛利随规模是否改善（token 成本随调用量下降有规模效应，但人工成本不一定——"越卖越亏"的陷阱多在间接成本没摊匀前）。
经验值参考：多数 LLM 应用的"直接 token 成本 / 收入"在 5-30% 区间健康；>50% 说明定价或模型选型有问题；<10% 说明可能过度优化（牺牲了质量或留了过多毛利空间）。
五 成本优化：六大杠杆的优先级
| 杠杆 | 做法 | 典型降幅 | 风险 / 代价 |
|---|---|---|---|
| 缓存 | 精确 + 语义缓存（重复查询直接返回） | 10-40%（靠重复率） | 时效性内容不能缓存；缓存一致性维护 |
| 模型分级（cascade） | 简单任务走小模型，复杂任务走大模型 | 30-70%（靠任务分布） | 级联本身有延迟代价（双跑）；小模型质量下限要够 |
| 上下文精简 | prompt 瘦身 / 检索结果截断 / 历史轮次压缩 | 10-30%（靠 token 长度） | 信息丢失影响质量；"删了上下文 = 删了质量"的排查成本高 |
| 批处理 / 异步 | 非实时任务走批处理 API（5 折） | 50%（批处理部分） | 延迟不可控；只适合可延迟任务 |
| 自建 vs API 交叉 | 稳定负载自建（利用率 >30%），波动峰值走 API | 20-50%（靠利用率） | 自建运维成本；模型升级迁移成本 |
| 输出约束 | max_tokens 硬上限 + 简洁提示词约束 | 10-30%（靠输出长度） | 过度截断导致回答不完整；"话痨"改善有限 |
优先级原则：先测后优化——每个杠杆的收益取决于任务分布（重复率 / 任务复杂度分布 / 上下文长度分布），不测就优化是盲动。正确顺序：归因看板跑两周 → 看"成本 top-5 的 feature / 会话类型" → 对 top-5 逐个上杠杆（每上一个，复盘实际降幅与预期差）→ 全量推广验证过的杠杆。
六 成本治理：让成本不失控
- 预算与熔断：每租户 / 每 feature 设日 / 月预算（按成本模型倒推），超 80% 告警、超 100% 熔断（降级到小模型或限流）。熔断不是"停止服务"，是"降档服务"——带能力声明的 200 响应优于硬 500。
- 用量异常检测：分钟级成本突增（>3σ）自动告警——典型场景是"单租户的提示词被恶意刷量"或"某个 feature 陷入重试循环"。异常检测的响应动作要自动化（自动限流 + 人工确认），不能只报不处理。
- 成本 SLA：内部约定"每 feature 的单会话成本上限"，与质量 SLA 并列作为上线门槛——"质量 95% + 单会话成本 ¥0.02"比"质量 95%"更有意义；成本超 SLA 的方案要过"为什么贵 + 值不值"的评审。
- 成本复盘（月度）：每月出"成本月报"——总成本 / 环比 / top-5 消耗 feature / 优化杠杆效果 / 下月预测。月报的对象是产品与业务负责人，不是只有技术团队看。
- 定价联动：单位经济核算结果直接喂给定价决策——成本涨 20% 而定价没动，毛利被吃掉，要有"成本 - 定价"联动机制（季度复审一次定价合理性）。
七 常见误区
| 误区 | 问题 |
|---|---|
| "月底看账单就够了" | 账单只有总数，没有归因；"花了多少"不等于"值不值"——没有 feature / 用户 / 会话维度的成本数据，优化无从下手 |
| "越便宜越好" | 小模型的质量下限可能不满足业务（客服答错的成本 > 多花的大模型 token 成本）；成本优化要带质量约束（"质量 95% 下的最低成本"） |
| "缓存能省 50%" | 语义缓存只在高重复率任务域成立；先测命中率再决策，客服 / FAQ 类可能 30%，创作类可能 5%——别先开缓存再算账 |
| "自建一定省" | 利用率 <30% 时自建成本高于 API；"自建省 50%"的多数案例是高利用率 + 稳定负载，波动峰值高的场景自建反而贵（峰值 GPU 空置） |
| "prompt 越短越省" | 删上下文 = 删质量，删掉的信息会让模型答错 → 重试 → 总成本反而涨；上下文精简要带质量回归测试（见提示词版本管理） |
| "成本是技术团队的事" | 单位经济是产品 / 业务决策（定价 / feature 取舍 / 免费额度）的核心输入；只让技术团队看成本 = 成本优化没有决策闭环 |
八 落地清单（按周推进）
- 第 1 周：建归因 label 体系（feature / 用户层 / 模型 / prompt_version / 渠道），所有请求打 label；cost calculator 脚本上线（按 label 出成本）
- 第 2 周：归因看板（feature × 模型 × 成本热力图 + top-10 会话 + 成本曲线）；开始"连续两周只能看不能动"的成本观测期
- 第 3 周：对 top-5 消耗 feature 各选 1 个杠杆试点（按任务分布选：重复率高 → 缓存；任务简单 → 模型分级；上下文长 → 精简），量测实际降幅
- 第 4 周：预算与熔断上线（按 unit-econ 倒推）；异常检测（分钟级 3σ）+ 自动限流动作
- 第 5-8 周：单位经济报表（收入 - 直接成本 - 分摊 = 毛利）对接财务；成本 SLA 写进 feature 上线门槛；月度成本复盘机制固化
一句话收束：LLM 成本核算的终点不是"每月少花多少钱"，是"每个业务单元的毛利清楚、每个决策有数字撑"。归因是地基（没有它一切优化是盲动），单位经济是屋顶（把成本翻译成业务语言），治理是护栏（让成本在决策范围内不失控）。三层齐了，"LLM 贵不贵"才从一句抱怨变成一道可算的题。