← 返回文章列表

大模型成本治理:到底该量什么

用量增长时让模型开销保持可预测的那几个关键指标。

先按业务任务归集,而不是只看 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 会替换已采购的指定型号。不得静默降级;记录实际模型、路由理由与回退。用包含边界任务的同一批样本验证分类和升级规则。

用量与账单不一致,从哪里排查

  1. 先对齐边界:核对账号/项目、精确模型与版本、地区与路由、币种、结算周期和时区。把当前用量预估与已结算账单分开,不混用两者。

  2. 以任务编号串起每次尝试与原厂请求标识。查 SDK 自动重试、应用重试、超时后重发和流式断线;一次用户点击可能有多次计费尝试。未知结果先标记待核对,不重复加账或漏记。

  3. 对齐计量定义与单位:输入、输出、缓存读写、推理或工具类别按该厂商字段核对。不要把已含缓存的总输入再次加上缓存;token、百万 token、秒和容量小时分别换算。

  4. 从请求明细汇总到账期,再核对延迟入账、套餐抵扣、折扣/退款、税费和另列服务费。某项没有凭据时保留差异,不用猜测的“有效单价”抹平。

  5. 按差额金额排序追踪:先查无法关联请求的费用,再查重复、用量类别及单价条件。保留脱敏请求标识、计量字段、时间与账单行;默认不保存凭据、完整提示词和客户文档。

可复用的成本核对清单

  • 每条记录有 task_id、attempt_id、原厂请求标识、模型/版本、路由、起止时间、状态和业务验收结果。
  • 计量字段保留原始单位,费用区分模型、检索、工具、运行与人工;每项有来源和分摊规则。
  • 同一批样本对照费用、验收率、重试数、端到端延迟及人工修正,不只比较单次调用。
  • 设置输出、循环、重试和并发边界;明确额度不足、超时和未知结果的处理。费用告警不等于实际限流。
  • 变更模型、缓存策略或任务流程后重新核对;未经样本与账单证据,不承诺固定节省幅度。

实际价格与类别应核对 Amazon Bedrock 价格说明或所用厂商的当期条款。本文的虚拟数据仅说明计算与诊断方法。