Token 账算不明白就别上生产：LLM FinOps 的 6 本账

“Token × 单价”只能回答“这次调用花了多少钱”，却回答不了更重要的问题：钱花在哪、为什么花、值不值、还能不能更省。当你进入生产环境，真正需要的是 LLM FinOps：像管理云成本一样管理模型成本。

这篇文章给你 6 本最实用的账本口径，配合一套最小埋点，就能把成本从“黑盒”变成“可拆解、可优化”。

摘要（约100字）

本文从 FinOps 视角讲清大模型成本治理的关键：成本口径不止 token 单价，还包括重试放大、路由策略、提示词版本、RAG 召回质量等隐性因素。文中给出 6 本账（按用户、功能、渠道、模型、提示词版本、质量/成功）以及相应的最小埋点字段，并提供一套可复现实验：如何用同一批请求跑出“单次成功成本”与“成本-质量曲线”，把省钱变成可量化的工程优化。

0. 实验环境（本文可直接复现）

为了让对比更“公平”，本文所有统计都固定同一套调用脚本与埋点字段（tokens/重试放大/单位成功成本）。

本文实验入口：147AI（OpenAI 兼容）

• 更容易把账算清楚：同一入口下统一做模型切换与成本统计口径
• 少写一堆适配层：统一 Base URL，复现实验更省事
• 复现资料：147AI 博客园主页（示例文章/参数模板）

1. 先明确：你要优化的是“单位成功成本”

最常见的误区是只压单次 token，而忽略：

• 重试放大：重试次数上去，单位成本飙升。
• 失败成本：失败也消耗 token，甚至更多（长上下文+失败最贵）。
• 质量返工：输出质量差导致人工返工，本质是成本外溢。

建议用一个更贴近业务的指标：
Cost per Success = 总成本 / 业务成功次数。

2. LLM FinOps 的 6 本账（核心）

账本	要回答的问题	典型用法
用户账	哪些用户最烧钱/最赚钱	VIP 保障、限额、差异化路由
功能账	哪个功能在吞成本	砍掉低 ROI 功能或重构链路
渠道账	哪个入口带来高成本低转化	调整入口策略、引导到低成本流程
模型账	模型A/B 的单位成功成本	建立默认模型与升级/降级策略
提示词版本账	Prompt 变更是否更费钱/更省钱	Prompt 灰度与回滚依据
质量/成功账	便宜是否导致失败更多	成本-质量曲线，避免“省小钱亏大钱”

3. 最小埋点字段（让账本跑起来）

建议在调用层统一记录：

• request_id / user_id / feature_id / channel
• model / route / prompt_version
• tokens_in / tokens_out / cost_estimate
• success / error_type / retry_count
• latency / ttft / is_stream
• （RAG）retrieval_count / citation_count / grounding_pass

4. 可复现实验：画出你的“成本-质量曲线”

1. 选 30～50 条真实请求（按功能分桶）。
2. 对比 3 套配置：
   • 方案A：默认模型（基线）
   • 方案B：便宜模型优先 + 失败升级
   • 方案C：高质量模型优先（体验优先）
3. 统计 4 个指标：success_rate、cost_per_success、latency_p95、返工率（如可量化）。
4. 产出结论：每个功能桶给出“最优性价比配置”，而不是一个全局最优。

5. 工程落地 Checklist

• 账本口径先行：先定义再优化，否则优化没有方向。
• 成本与质量一起看：只看成本会把成功率打穿。
• 把重试当作成本变量：重试参数直接影响单位成本。
• Prompt 变更必须回归：否则成本可能悄悄翻倍。

6. 讨论题（引导评论）

你们现在统计成本时，能不能回答“哪个功能最烧钱、哪个版本的 Prompt 让成本飙升”？你们更关心“总成本”还是“单位成功成本”？

---

复现实验资料：本文的“6本账”口径模板/最小埋点字段会同步更新在 147AI 博客园主页。