大模型成本治理:到底该量什么
用量增长时让模型开销保持可预测的那几个关键指标。
先按业务任务归集,而不是只看 token 单价
一次文档问答可能包含检索、生成、工具校验、重试和人工修正。先定义“完成”:答案通过哪些检查,失败由谁处理,取消或超时怎样计入。把费用归集到业务任务,才能比较得到同等可用结果的代价。厂商请求成功不等于业务验收成功。
单任务总成本公式
C_task = Σ C_model_attempt + C_retrieval + C_tools + C_runtime + C_human
C_model_attempt = (U×p_in + R×p_read + O×p_out + W×p_write) / 1,000,000
C_human = minutes / 60 × hourly_rate
C_per_accepted = batch_total_cost / accepted_task_count
U 是未缓存输入 token,R 是缓存读取 token,O 是输出 token,W 是另行计费的缓存写入 token;p 为对应的虚拟单价,单位均为 USD/百万 token。各项费用统一成同一货币、同一批次。只汇总实际适用的计费类别:若写入已含在输入计价中,不得再加一遍。检索、工具、运行与人工费用也不能重复分摊。
失败尝试仍计入分子;分母只统计通过业务验收的任务。若响应丢失,先核对原厂记录再判定用量,不能按“未收到结果”自动记零。共享缓存或运行费用应有固定、可复核的任务分摊规则。
说明用假设:一批 100 个任务
以下全部是说明用假设,不是真实客户案例,不是任何云厂商或模型报价,也不是节省承诺。
-
批次有 100 个任务;每次完整尝试使用 2,000 输入与 500 输出 token。这里的失败是完整输出后的业务验收失败,所以失败请求同样产生这组 token 费用。
-
主模型虚拟输入/输出单价为 2/8 USD 每百万 token,故一次尝试为 0.004 + 0.004 = 0.008 USD。每任务检索一次,费用 0.001 USD;重试复用检索材料。每次尝试另有校验/工具费 0.0005 USD,批次分摊运行费固定 0.080 USD。表内人工费为零。
-
基线有 20 次首轮验收失败,均重试一次。为便于演算,本例假设所有重试都通过验收,最终完成 100 个任务;真实评测不能预设这一结果。
完整演算:便宜的请求不一定带来更好的结果
缓存
每次命中复用 1,000 输入 token,虚拟读取价为 0.5 USD/百万 token;另外 1,000 输入仍按普通价计费,因此命中请求为 0.002 + 0.0005 + 0.004 = 0.0065 USD。120 次尝试中有 10 次冷请求、110 次命中;10 次各写入 1,000 token,假设额外写入价为 1 USD/百万 token。内容与权限不变,首轮失败仍为 20 次。
缩短提示词
首轮输入减为 1,000,输出仍为 500,单次 0.006 USD;但假设缺少约束使 40 次首轮验收失败,全部恢复完整 2,000 输入后重试一次,每次 0.008 USD。不是用缩短后的单价计算修正请求。
模型分流
40 个简单任务使用虚拟输入/输出价为 0.5/2 USD 每百万 token 的小模型,单次 0.002 USD;其中 16 次验收失败,升级主模型。其余 60 个任务直接使用主模型,其中 12 次重试;主模型共 60 + 16 + 12 = 88 次。首轮总失败 28 次,总尝试 128 次。
Baseline: 120 × 0.008 = 0.960
0.960 + 0.100 + 0.060 + 0.080 = 1.200
Cache: 10 × 0.008 + 110 × 0.0065 = 0.795
writes = 10 × 1,000 × 1 / 1,000,000 = 0.010
0.795 + 0.010 + 0.100 + 0.060 + 0.080 = 1.045
Short: 100 × 0.006 + 40 × 0.008 = 0.920
0.920 + 0.100 + 0.070 + 0.080 = 1.170
Routing: 40 × 0.002 + (60 + 16 + 12) × 0.008 = 0.784
0.784 + 0.100 + 0.064 + 0.080 = 1.028
| 方案 | 首轮失败/100 | 总尝试 | 批次总费用 USD |
|---|---|---|---|
| 基线 | 20 | 120 | 1.200 |
| 缓存 | 20 | 120 | 1.045 |
| 短提示词 | 40 | 140 | 1.170 |
| 模型分流 | 28 | 128 | 1.028 |
| 方案 | 每验收任务 USD |
|---|---|
| 基线 | 0.01200 |
| 缓存 | 0.01045 |
| 短提示词 | 0.01170 |
| 模型分流 | 0.01028 |
另看一种终局失败情形:若基线费用仍为 1.200 USD,但只有 95 个任务验收通过,则每成功任务为 1.200 ÷ 95 ≈ 0.01263 USD。若另外 5 个任务各需人工 2 分钟,虚拟人工成本为 30 USD/小时,则新增 5 × 2 ÷ 60 × 30 = 5 USD;假设人工最终全部修复,每完成任务为 (1.200 + 5) ÷ 100 = 0.062 USD。不要把这组额外假设混入上表。
如何选择:把质量和失败路径一起比较
缓存的本例总费用较低且首轮失败不变,前提是文档版本、权限、有效期和缓存键正确。命中率下降、写入频繁或旧内容命中会改变结论;测量命中与质量,不只看读取单价。
短提示词使首轮每次请求的输入减半,但整批输入从 120 × 2,000 = 240,000 变为 100 × 1,000 + 40 × 2,000 = 180,000 token,只减少 25%。重试抵消了部分收益;批次费用仅从 1.200 变为 1.170,首轮失败从 20 增至 40。若延迟或人工修正不可接受,即使 token 更少也应回退。
分流在本例降低费用,却把首轮失败增至 28。它只适用于客户明确批准的多模型应用策略,不代表 Corebyte 会替换已采购的指定型号。不得静默降级;记录实际模型、路由理由与回退。用包含边界任务的同一批样本验证分类和升级规则。
用量与账单不一致,从哪里排查
-
先对齐边界:核对账号/项目、精确模型与版本、地区与路由、币种、结算周期和时区。把当前用量预估与已结算账单分开,不混用两者。
-
以任务编号串起每次尝试与原厂请求标识。查 SDK 自动重试、应用重试、超时后重发和流式断线;一次用户点击可能有多次计费尝试。未知结果先标记待核对,不重复加账或漏记。
-
对齐计量定义与单位:输入、输出、缓存读写、推理或工具类别按该厂商字段核对。不要把已含缓存的总输入再次加上缓存;token、百万 token、秒和容量小时分别换算。
-
从请求明细汇总到账期,再核对延迟入账、套餐抵扣、折扣/退款、税费和另列服务费。某项没有凭据时保留差异,不用猜测的“有效单价”抹平。
-
按差额金额排序追踪:先查无法关联请求的费用,再查重复、用量类别及单价条件。保留脱敏请求标识、计量字段、时间与账单行;默认不保存凭据、完整提示词和客户文档。
可复用的成本核对清单
- 每条记录有 task_id、attempt_id、原厂请求标识、模型/版本、路由、起止时间、状态和业务验收结果。
- 计量字段保留原始单位,费用区分模型、检索、工具、运行与人工;每项有来源和分摊规则。
- 同一批样本对照费用、验收率、重试数、端到端延迟及人工修正,不只比较单次调用。
- 设置输出、循环、重试和并发边界;明确额度不足、超时和未知结果的处理。费用告警不等于实际限流。
- 变更模型、缓存策略或任务流程后重新核对;未经样本与账单证据,不承诺固定节省幅度。
实际价格与类别应核对 Amazon Bedrock 价格说明或所用厂商的当期条款。本文的虚拟数据仅说明计算与诊断方法。