LLM 成本测算

LLM 成本测算

"一次调用几分钱，一天十万次就是几百块"：AI 产品的成本随用量线性增长，不先算清楚，定价、预算、模型选型都是拍脑袋。本页给出一套从单次调用到月成本的估算方法，以及常用降本手段与成本决策原则。

先记住一个心智模型：AI 产品的成本 = 单次成本 × 调用量。模型能力再强，算不清这两项，产品越大亏得越多。

本页路线：先看懂计费模型，再按三步法估算单次成本与月成本，然后从「只看 token 费」扩展到完整成本（TCO）与单位经济模型，最后落到成本治理与告警；文末给出三类典型产品的成本结构示意案例，方便按形态对照。

flowchart LR
    request[真实请求] --> tokens[统计输入、输出与思考 token]
    tokens --> unit[代入单次成本公式]
    unit --> volume[DAU、人均次数与功能加总]
    volume --> factor[叠加重试、评测与 Agent 工程系数]
    factor --> tco[加入存储、向量库与人工等 TCO]
    tco --> decision[预算、毛利与成本护栏]

成本测算的主链是「真实用量 → 单次成本 → 业务量 → 工程损耗 → 完整账单」，最后才把结果用于预算和产品决策。

计费模型

不同供应商的计费方式差异很大，先看懂常见的几种：

• Token 计价（主流）：输入、输出分开计价，输出单价通常高于输入；报价单位一般是每百万 token，写作 $X/M（如 $3/M 表示每 100 万输入 token 收 3 美元）。
• 缓存折扣：系统提示、知识库前缀等稳定内容会命中 prompt 缓存，命中部分按折扣价计费。把固定内容放到 prompt 前缀并保持格式不变，就能持续吃折扣（提示词精简与结构技巧见 提示词工程）。
• 批处理折扣：非实时任务（批量摘要、离线分类）走批处理队列，通常 5 折左右，代价是延迟从秒级变为小时级。
• 其他模式：订阅/按席位（按人头包月）、多模态按图折算 token（见 多模态）、推理平台按用量分钟计费。结构各不相同，不要用一套公式套所有供应商。

除上述四种外，还有几类常见计费方式，容易在预算里漏掉：

• 多模态按内容折算：图像通常按「每张图折合 N 个 token」计费，音视频按秒或按时长折算，一张高清图可能抵几千 token。OCR、截图理解、视频审核类产品的成本结构会与纯文本完全不同（见 多模态）。
• 嵌入与向量库：embedding 生成按 token 计价（一次调用输出一个向量）；向量库本身按存储量 + 索引构建 + 查询计费，自建（开源向量库 + 自有服务器）与托管服务（按存储与请求付费）结构不同，规模化后存储与查询费可能超过 embedding 调用本身（检索方案见 RAG）。
• 推理平台与自托管：API 按 token 计费、零运维；推理平台（按部署实例、GPU 时、vCPU 时计费）与自托管则是固定算力成本 + 运维人力，单价随利用率摊薄。调用量小用 API，规模化后自托管边际成本更低，但要自己跟进模型版本（权衡见 LLM API 与供应商）。
• 微调计费：训练阶段按数据 token + GPU 时长计费，推理阶段另有价格；微调后的模型通常比同规格基础模型贵，值不值要用省下的 token、提升的效果来算（基础概念见 LLM 训练）。
• 思考 token 按输出计费：推理模型（reasoning model）在回答前产生内部思考 token，按输出单价计费且不可省略，effort 档位越高思考越长：「想得多深」直接变成成本项（机制与档位见 模型能力与边界）。
• 免费额度与限流：多数供应商提供免费额度（每月免费 token、免费调用次数）与速率限制（RPM/TPM，即每分钟请求数/每分钟 token 数）。免费额度影响起步期成本，限流影响峰值成本与体验。这两项都写在定价页上，签约前要一并读。

成本估算三步法

第一步:算单次调用成本

单次成本 = 输入 tokens ÷ 1,000,000 × 输入单价 + 输出 tokens ÷ 1,000,000 × 输出单价

示例：每次调用输入 2,000 tokens、输出 500 tokens，模型报价输入 $3/M、输出 $15/M：

• 输入：2,000 ÷ 1,000,000 × \(3 = **\)0.006**
• 输出：500 ÷ 1,000,000 × \(15 = **\)0.0075**
• 单次成本 ≈ $0.0135（约 1.4 美分）

单次成本是后面一切计算的地基，务必按"你真实会发的 prompt"估算，而不是厂商示例。

拿真实 token 数的三个来源（按顺序做，别停在心算）：

1. 官方 tokenizer：每个模型家族有各自的 tokenizer，把线上真实请求的 prompt 原文（含系统提示、工具定义、知识库片段）粘进去数一遍；中文「1 字 ≈ 1~2 token」只是粗略换算
2. 调用返回的 usage 字段：每次 API 响应都带本次的输入/输出 token 数（含缓存命中与思考 token），开发期把线上日志打出来，统计每次请求的 token 分布，比估算准一个量级
3. 按输入构成拆开统计：系统提示、工具定义、知识库检索片段、多轮历史各占多少。这一步决定后面优化该压哪一块，也决定缓存收益有多大

缓存命中要加权：真实请求中稳定前缀命中缓存后，输入按缓存折扣价计费，单次成本 = 命中率 × 缓存价 + (1 − 命中率) × 原价。上线前先按 0% 命中估（最坏情况），上线后按月回填真实命中率。

第二步:算业务量

日成本 = 日调用次数 × 单次成本；月成本 ≈ 日成本 × 30 天。

以上面的 $0.0135/次 为例：

单次"几分钱"不吓人，乘以调用量才是成本的大头：10 万日调用就是每年数十万美元的支出，这个数必须在写 PRD 前就算清楚。

日调用量本身也要估出来：日调用数 ≈ 日活用户（DAU） × 人均调用次数。人均次数来自产品设计：每个核心功能一次请求、Agent 每步一次请求，把这些列进功能清单逐个累加，比拍脑袋准得多。

功能清单逐项累加的写法（示例：1 万 DAU 产品，数字为教学假设）：

拆到功能级之后，再补三个修正：

• 按用户分层：免费/付费、重度/轻度用户的人均次数可能差 10 倍，分层估算再相加，不要用全体平均
• 峰值与均值分离：人均次数是均值，还要估峰值倍率（如晚高峰是日均的 3 倍）。峰值决定限流配置与预算上限，均值决定月成本
• 季节性：有淡旺季的业务（电商大促、开学季）按峰值月估，而不是月月相同；月成本按 30 天还是 22 个工作日也要统一口径

第三步:加工程系数

真实账单永远高于理论值：重试、日志与评测跑分、多路调用（Agent 多步）、灰度测试都会额外消耗。建议在理论成本上乘 1.2~1.5 倍作为工程系数：

沿用上例：日 1 万调用、单次 $0.0135，月成本 \(4,050 × 1.3 ≈ **\)5,265**。

系数取多少取决于业务形态：请求波动大、依赖外部评测、Agent 多步调用多的产品取 1.5，反之可取下限 1.2；上线后按月回填真实账单，持续校准这个系数。

把「1.2~1.5」拆成可解释的损耗来源（表中增量为教学示例，非实测统计）：

各来源的增量（示例）可叠加，也可直接按业务形态取区间：纯对话产品取下限 1.2，Agent 多步 + 频繁灰度上 1.5。

另外还有非模型成本要在预算里单列：存储、向量库、评测与标注人工、人工兜底（如客服升级转人工）。模型 token 费通常只占总成本的一半上下。

一个判断输入/输出占比的小技巧：AI 客服（上下文 + 知识库长输入、短回复）输入占大头，优化重点是压上下文与缓存；写作工具（长输出）输出占大头，优化重点是控制输出长度。

降本策略

按杠杆大小排序，从最省事的开始：

1. Prompt 压缩与缓存：减输入 token：精简系统提示、按需携带知识库片段、利用缓存折扣（见 提示词工程）
2. 模型分级路由：简单请求（分类、抽取、改写）走小模型/低成本模型，复杂请求才调旗舰。头部 AI 应用的标准做法（分层思路见 LLM API 与供应商）
3. 控制输出长度：max_tokens 上限 + 输出格式约束（JSON/模板）。输出单价高于输入，压输出往往比压输入见效更快
4. 批处理 + 小模型替代：非实时任务走批处理折扣；高频固定场景用蒸馏/微调小模型替代大模型（基础概念见 LLM 基础）
5. 工程侧兜底：应用层缓存（相同请求直接复用结果）、失败重试上限、单用户限额：防止意外用量把成本打穿

每条杠杆的实施细节与反例：

1. Prompt 压缩与缓存
   • 实施：系统提示精简到「不能再短」后做缓存前缀固化，把稳定内容（知识库、规则）放在前缀且保持格式不变；知识库按检索结果动态拼接，不整库塞入；缓存命中率进看板，按月看趋势
   • 反例：为了命中缓存把个性化信息也塞进前缀：缓存要求前缀稳定、个性化要求前缀变化，强行合并会牺牲效果，省下的钱不够填流失
2. 模型分级路由
   • 实施：先按意图分类把请求分流（简单分类/抽取走快模型，复杂推理走旗舰），再用评测集校准阈值；路由与降级链一起设计：快模型低置信 → 升级旗舰重试 → 仍失败进人工兜底；上线后监控各档位请求占比与升级率（做法见 模型能力与边界）
   • 反例：没有评测就路由：两档模型在任务上没有差异时，路由只增加一层复杂度；阈值过激进会表现为升级率升高、成本反而上涨
3. 控制输出长度
   • 实施：max_tokens 按「够用」设上限；结构化输出（JSON Schema）约束格式与长度；推理模型用 effort 低档压思考 token（见 模型能力与边界）
   • 反例：输出压得太短导致答案不完整，用户重问：一次变两次调用，总成本反而上升；输出质量下降引发的流失是隐性成本，降本不能只盯单价
4. 批处理 + 小模型替代
   • 实施：把任务按是否实时分队列，非实时（批量摘要、离线分类）走批处理折扣；高频固定场景收集数据做蒸馏/微调小模型，推理成本可降一个量级
   • 反例：蒸馏需要数据与迭代周期，业务变化快时模型马上过时；在线客服、支付风控等实时场景不能硬走批处理，延迟不可接受
5. 工程侧兜底
   • 实施：应用层缓存设合理 TTL、重试上限（如 2 次）与指数退避、单用户/单租户日限额、异常调用熔断（超长输出、高频循环）
   • 反例：缓存 TTL 过长给用户返回过期结果；限额一刀切误伤付费用户：限额要与用户分层绑定，超限走降级而不是断供

降本的前提是不牺牲效果：先量化当前成本构成（输入/输出各占多少），再按杠杆排序逐项做 A/B 对照，每项优化都盯住效果指标不下降。

flowchart TD
    baseline[量化当前成本与效果基线] --> lever[选择一个降本杠杆]
    lever --> ab[A/B 对照：效果、延迟与成本]
    ab --> pass{效果不降且单位经济改善？}
    pass -->|是| rollout[小流量灰度并扩大]
    pass -->|否| rollback[回退并分析损失]
    rollout --> monitor[监控成本/调用、成本/DAU 与毛利]
    monitor --> baseline
    rollback --> lever

降本不是单纯压低 token 费，而是用可回退的实验确认效果、延迟与毛利同时达标。

成本护栏与 ROI

护栏（防止成本失控）：

• 单用户/单租户日限额，超限降级或限流（风控与合规思路见 出海与合规）
• 成本看板：按产品、功能、用户维度拆分每日成本
• 异常告警：单日成本环比突增（如 >50%）立即告警排查

成本看板设计（护栏要靠看板落地，不是靠感觉）：

指标三件套：日成本（总额）、成本/调用（单位成本，对提示词与模型变更最敏感）、成本/DAU（用户规模与成本的比值，看「增长是否吃掉毛利」）；再加环比（日对日、周对周，避开周期波动）作为异常入口。告警阈值的完整设计见下文「成本治理与告警」一节。

ROI 对照：成本永远要放在"省了什么、赚了什么"里看：

成本不是越低越好，"单位收益成本"（成本 ÷ 带来的收益）才是决策指标。

做完这道题，你就掌握了完整的成本测算流程：单次成本 → 业务量 → 工程系数 → 月预算，以及每条降本杠杆该往哪使劲。

完整账单不止模型费：继续读「完整成本明细（TCO）」与「单位经济模型」，把成本放进商业模型；想按行业形态对照，看文末「三类产品的成本结构案例」。

价格结构示例(2026-08,以官方为准)

定价页上的数字变动频繁，本节只给结构与量级，精确单价一律以官方页面为准（引用日期 2026-08-24；2026-08-23 的价格快照汇总见 模型能力与边界）。下表为四家主流供应商的 2026-08 量级对比（示例档位，非全部模型）：

表中数字为 2026-08-23 快照（源：各官方定价页，经本站 模型能力与边界 整理），仅供量级参考；签约、算账、写 PRD 一律以官方定价页为准。国产模型（豆包、通义、Kimi 等）同为按 token 计费，部分按输入长度分段计价，价格以 火山方舟 等官方页面为准。

读这张表要先知道的四条量级规律：

• 旗舰与入门模型的输入单价可差一个数量级（约 10 倍），输出单价差得更多：「简单任务用便宜模型」的省钱空间就在这里
• 输出单价通常是输入单价的 3~10 倍，所以「压输出」往往比「压输入」见效更快
• 缓存、批处理、错峰三类折扣叠加后，同一请求的实付可能相差数倍：成本优化的第一件事是确认这些折扣用没用上
• 免费额度只够起步与试用，规模化后按量付费是常态；免费额度的门槛（是否绑卡、是否限模型）以官方页面为准

完整成本明细(TCO)

「只看 token 费」是预算的第一版，不是完整账单。完整成本（TCO，总拥有成本）要覆盖八类科目：

摊进去算的原则：随调用量线性变动的科目（推理、缓存、嵌入、按量存储）计入单次成本，定价与预算用；一次性与固定科目（评测集建设、微调训练、工具开发、运维人力、合规认证）按产品生命周期摊销到月：定价时同样要覆盖。只算推理费的定价，毛利会被摊销成本悄悄吃掉。

TCO 月度公式（示意）：

TCO/月 = 推理费 + 缓存费 + 嵌入与向量库费 + 存储费 + 评测与标注人力 + 人工兜底人力 + 工程摊销 + 合规摊销

示例：日 10 万次调用的 AI 客服，月推理费 $30,000（示例，输入大头），缓存存储 $500，向量库 $1,500，评测与标注 $2,000，人工兜底 $3,000，工程摊销 $4,000：TCO 约 $41,000，约为推理费的 1.4 倍（示例数字，非真实报价）。这与三步法里「模型 token 费通常只占总成本的一半上下」互相印证：预算按 TCO 做，单次成本按计入单价的科目算。

单位经济模型(Unit Economics)

成本算清楚后，要放进商业模型看「每次调用是赚是亏」。以下为示意模型，数字是教学构造，非真实报价；方法框架与 商业化与定价 一致（其「unit economics 的 AI 变体」一节给出推理成本/用户与毛利率两个必算科目）。

单次调用毛利

单次调用毛利 = 单次调用收入 − 单次调用全成本。订阅产品把客单价折算到调用：单次调用收入 = 客单价 ÷ 人均月调用次数；单次调用全成本 = 计入单价科目 + 摊销摊到每次调用。

示意：月订阅 $20（示例）、付费用户人均月调用 300 次 → 单次调用收入约 $0.067（示例）；单次全成本 $0.02（示例）→ 单次毛利约 $0.047，毛利率约 70%（示例）。这个数就是模型选型、缓存、路由所有降本动作的最终裁判：降本动作都要回到毛利率变化来评估。

转化率、客单价与免费额度

付费用户只占注册用户的一部分，而免费用户也有成本：单位经济必须把转化结构算进去：

• 转化率：免费 → 付费的比例。示意：转化率 4%，即每 25 个免费用户养出 1 个付费用户（示例）
• 免费层成本：免费用户人均月成本（示例 $0.5，走小模型 + 每日限额；若放开展示旗舰模型、无限次数，可到 $5）
• 付费用户成本：人均月成本（示例 $3，全功能 + 高额度）

免费额度是获客成本还是护栏，由数字决定。同一 $20 订阅（示例），两种免费层设计：

免费层设计不同，毛利差一倍以上：免费额度策略本质是成本策略（免费层设计原则见 商业化与定价 的「套餐结构设计」）。

订阅 vs 用量定价

• 订阅：收入固定，成本随用量线性涨：重度用户是毛利杀手，必须配用量分层（如 ChatGPT 的 Go/Plus/Pro 档位，以 官方定价页 为准）与用量墙
• 按量定价：收入与成本同向变动、天然对冲，但用户怕「账单爆炸」，需要用量预估与预算护栏（见下文「成本治理与告警」）
• 混合（订阅 + 用量包）：订阅保底 + 用量变现，是 AI 加购功能的典型解法（Notion 按信用点计费，以 官方定价页 为准）

Agent 类产品:一次任务 = N 次调用

Agent 产品把一次任务变成 N 次调用，单次任务成本天然不确定：

• 示意：一次生成周报任务 ≈ 意图识别 1 次 + 数据检索 2 次（含 embedding 查询）+ 撰写 1 次 + 修正重试 0.5 次 ≈ 4~5 次调用（示例）；复杂任务可触发 20 次以上，成本波动可达 10 倍
• 按任务定价（示例 0.5 元/份周报）对用户友好，但任务成本波动大 → 需要单任务调用上限 + 超限降级护栏
• 按调用定价对供应商安全，但用户无法预估账单 → 用用量包 + 用量预估器缓解
• 更优解是按成功结果计价：只对达标产出收费，失败成本留在产品侧。对质量有信心时的差异化定价

计价单位的选择（任务/调用/token/成功结果）与定价流程见 商业化与定价。

单位经济自检五问（上线前逐条回答）：

1. 单次调用毛利是正的吗？重度用户（前 10% 用量）的毛利呢？
2. 免费层成本摊到每个付费用户后，毛利率还剩多少？
3. 模型涨价 2 倍时，毛利会变成多少？（敏感性分析做法见 商业化与定价）
4. 一次任务的调用次数上限设了吗？超限是降级还是熔断？
5. 摊销成本（评测、人工、工程）进定价了吗？

成本治理与告警

估算会过时，治理要常开。成本治理 = 预算上限 + 看板 + 告警 + 归属，四件套缺一不可。

预算上限(四层)

软上限（超了只告警）与硬上限（超了自动熔断/降级）要分开：硬上限是最后的保险，不能依赖人工处理；软上限用于日常管理。限流降级与风控思路见 出海与合规。

看板维度与指标

• 时间维度：日 / 周 / 月成本，环比（日对日、周对周，避开周期波动）
• 拆分维度：产品、功能、租户、用户、模型档位、供应商、Prompt 模板
• 核心指标：日成本、成本/调用、成本/DAU、缓存命中率、各模型成本占比、预算消耗率、重试率
• 运营指标：异常调用数（超长输出、高频循环、爬虫）、人工兜底率（客服升级比例）

看板的维度拆法与指标三件套见上文「成本护栏与 ROI」一节。

告警阈值设计

• 环比突增：单日成本环比 >50% 立即告警（现有护栏默认值）；更稳的做法是环比 >30% 且绝对值超过 $X 双条件，避免小基数噪音
• 消耗速度：日成本 > 月预算 ×（已过天数 ÷ 月天数），即「消耗过快」预警
• 预测偏差：用 7 日均线预测月成本，预测值超预算 80% 预警、100% 熔断
• 分级响应：黄色（预警，人工核查）与红色（熔断，自动降级）两级；红色阈值要低到「最多亏一天」：宁可误伤，不可打穿
• 降噪：连续触发 N 次才告警、非工作时间合并通知，避免告警疲劳

成本归属与分摊

• 所有调用打成本标签（product/feature/tenant/user/model），账单按标签拆分：没有标签的成本无法治理
• 免费用户成本单独列账，不被订阅毛利掩盖；代金券、免费额度按名义价记账、到期核销
• 多团队共用账户时用内部结算价（按标签汇总对账），把成本责任落到团队，而不是「成本是公司的」

三类产品的成本结构案例(示意)

三类典型产品的成本结构示意（教学构造，非真实公司数据；数字均为示例，价格以官方页面为准）。与三步法中的「输入/输出占比判断」呼应，展示同一套方法在不同产品形态上的落法。

AI 客服:输入大头

结构：上下文 + 知识库检索使输入 token 远大于输出（示意：单次输入 3,000、输出 150）。

• 成本占比（示意）：推理 85%（其中输入约 75%）、缓存存储 5%、人工兜底 10%
• 优化抓手：① prompt 缓存（知识库与系统提示前缀化，目标命中率 50% 以上）② 检索压缩（只带相关片段，不整库塞入）③ 模型分级（首轮快模型、复杂转旗舰）④ 人工升级率控制在 1%~2%
• 反例教训：知识库全量拼接进 prompt 而不做检索，输入 token 翻几倍，缓存也难以命中。输入大头的产品，检索质量直接决定成本

写作工具:输出大头

结构：长输出为主（示意：输入 500、输出 800~2,000），输出单价高于输入，输出费占大头。

• 成本占比（示意）：输出 70%、输入 15%、评测与人工抽检 10%、其他 5%
• 优化抓手：① max_tokens 上限与结构化输出约束 ② 初稿走快模型、精修走旗舰 ③ 非实时任务（批量改写、润色）走批处理 ④ 输出质量抽检，防止「长而劣」白花钱
• 反例教训：无限输出 + 旗舰模型写初稿，单次成本是快模型 + 上限的 10 倍以上。输出大头的产品，长度约束是第一杠杆

Agent 工作流:多步调用 + 工具执行

结构：一次任务 = 多次模型调用（规划、工具调用、反思重试）；工具执行本身不按 token 计费，但失败重试会放大成本（示意：单任务 5~10 次调用，重试占 20%~30%）。

• 成本占比（示意）：主任务模型 60%、重试与多路 20%、嵌入与检索 10%、人工兜底 10%
• 优化抓手：① 任务级调用上限与熔断（防止死循环）② 中间结果缓存（相同子任务不重复跑）③ 计划压缩（减少不必要的步骤）④ 模型分级（子任务走小模型）
• 反例教训：没有重试上限的 Agent，一个 bug 会让一次任务循环调用上百次、单日成本打穿预算。这就是工程系数取 1.5 的真实来源

三类案例的共性结论：无论哪种形态，降本第一梯队都是缓存 + 模型分级 + 限额护栏；差异在于主攻方向：客服压输入、写作压输出、Agent 压步数。

来源：主题参考 AIPM Wiki（archlizheng/AIPM-Wiki，CC BY-NC-SA 4.0）的「LLM 成本测算入门」专题；本文内容由本站自行撰写。

来源说明

本文为原创整理。价格类信息以官方页面为准（引用日期 2026-08-24）；文中计算示例、示意模型与案例均为教学构造，数字非真实报价。2026-08-23 价格快照的汇总见本站 模型能力与边界，定价方法框架见本站 商业化与定价。

1. OpenAI Pricing（官方，输入/输出/缓存/批处理价）
2. Anthropic Models Overview（官方，Claude 5 家族定位与价格）
3. Gemini Pricing（官方，免费层、缓存、Batch 档位）
4. DeepSeek API 定价（官方，高峰/非高峰计价）
5. 火山方舟模型价格（官方，豆包按量计费与免费额度）
6. ChatGPT 官方定价页（官方，订阅分层）
7. Claude 官方定价页（官方，订阅分层）
8. Notion 官方定价页（官方，信用点计费）
9. 模型能力与边界（本站，2026-08-23 定价快照与推理模型机制）
10. 商业化与定价（本站，unit economics 变体、敏感性表与定价案例）

更新记录

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用