同样一个 agent，贵的那个反而省 65%：账要算到人头上

两个模型，跑同一个 agent 任务：读一封 750 词的客户邮件，抽实体，调 API 查账户状态，输出严格 JSON。

模型 A 的牌价是 $0.50 / 百万输入、$1.50 / 百万输出；模型 B 是 $1.00 / $3.00，整整贵一倍。

实际每个任务的账单：A 花 $0.0042，B 花 $0.00145。贵的那个省 65%。

这是 AWS 在 2026-11-12 那两篇 Bedrock 成本博文里给的算例（Part 1 讲怎么归因到人，Part 2 讲怎么把成本和产出对上）。它想说的只有一句话：价目表上的单价不是你付的钱，你的账单是"完成一个任务"的钱。

一、先把"任务"这个词定义清楚

一个任务 = 你的应用让模型做完的一件完整的事：回一封客服信、从一张发票里抽字段、回答用户一个问题。从请求开始，到拿到可用结果为止，中间调了几次模型都算同一个任务。

单价便宜的那个模型，跑到你的负载上不一定便宜。便宜模型可能：

• 把你的文本切得更碎（同样的内容，多得多的 token）；
• 用废话填满回答；
• 读不懂工具 schema，来回纠错多跑几轮；
• 在给出 200 token 答案之前，先烧掉几千个推理 token。

这四件事，在价目表上一条都不写。

二、四个隐形成本

三、那个 65% 是怎么来的

（图源：AWS ML Blog，同一篇。）

算式只有两行：

A: (6,150 × $0.50 + 750 × $1.50) / 1,000,000 = $0.0042
B: (1,000 × $1.00 + 150 × $3.00) / 1,000,000 = $0.00145

三个复利因素叠在一起：tokenizer 把邮件切成多 50% 的 token（每一轮都放大）、输出填充词把输出量翻了 3 倍、与工具 schema 不齐导致两轮纠错而每轮都重发更长的历史。

四、把"失败"和"缓存"也算进去

上面假设两个模型最终都成功。生产里不是这样，而失败很少免费：

重试到成功型：单成功任务成本 = 单次成本 / 成功率
失败即升级型：单成功任务成本 = 单次成本 + (1 - 成功率) × 升级成本

开启 prompt caching 之后，输入还要拆成三桶计价：未命中缓存的输入（基准价）、缓存读（低于基准）、缓存写（高于基准）。

官方提醒一句很实用的：缓存检查点会漂——三个月后你的工具集变了、写进缓存的东西更多了，所以缓存命中率要持续复测，不是一个设完就忘的参数。

五、在自己数据上量，别信样例

• CountTokens：不算推理就能拿到"这个模型对这段载荷会收多少输入 token"，是最便宜的横向比价工具；
• 模型响应里的 usage 块：inputTokens / outputTokens / cacheReadInputTokens / cacheWriteInputTokens。坑在这里：开了缓存后 inputTokens 只算未命中部分，真实输入量是三者之和，但计价要分开；
• 模型调用日志：每次调用的 token 数落到 S3 或 CloudWatch Logs，可以按 team / feature / 实验打标切分。但它是日志字段，不是成本分配标签，永远不会出现在 Cost Explorer 或 CUR 里；乘以牌价得到的是近实时估算，不是发票（承诺用量、批量、预留吞吐都不会体现）；
• 应用推理配置（application inference profile）：能进 Cost Explorer 和 CUR，但粒度是"每天一个用量类型"——做内部计费够用，做单任务成本太粗。

六、从"有人花了钱"到"这是谁的账"

这一半是 Part 1 的内容，路径很短，但要按顺序：

① 归因数据是白送的。 Bedrock 对每个推理请求都记 IAM principal（user 或 role），你不需要改任何推理调用。

（图源：AWS ML Blog《Tokenomics at scale》。）

② 一人一 role → 打 principal 标签。 静态标签，对该 principal 的每个请求都生效：

aws iam tag-role \
  --role-name BedrockDeveloperRole-alice \
  --tags Key=user,Value=alice@example.com Key=team,Value=platform Key=CostCenter,Value=CC-1001

③ 多人共用一个 role（或走网关）→ 必须用 session tags。 principal 标签区分不了共用 role 里的人，因为每个会话带的标签一样。session tags 在承担角色时传入，动态、可变化；同 key 时 session 标签赢。前提是 role 的信任策略允许 sts:TagSession，三条传法：sts:AssumeRole --tags、OIDC 的 https://aws.amazon.com/tags claim、SAML 的 PrincipalTag:* 映射。上限 50 个标签。

注意一个坑：你已经采集了 saml:sub 不等于它能用——IdP 那边要单独把它映射成 PrincipalTag:* 属性语句，信任策略要允许 sts:TagSession，两者是独立配置的。

④ 激活成本分配标签。 标签不打勾不会进账单数据。Billing → Cost allocation tags → 类型选 IAM principal → 选中激活。组织里只能在管理账户（payer）激活。两个时间点：标签 key 要等该 principal 至少调过一次 Bedrock 才出现；新 key 最多 24 小时才可激活，激活后再 24 小时才开始填数据；默认不回溯——想用之前就得激活。

⑤ 建 CUR 2.0 导出。 Data Exports → 新建 CUR 2.0（Standard）→ Additional export content 里勾 Include caller identity (IAM principal) allocation data → Time granularity 选 Hourly → Report data integration 选 Amazon Athena（输出 Parquet，并顺带给你一个建 Glue 表的 setup 脚本，这个脚本得你自己跑一次，控制台不会替你建）。列名前缀：principal / session 标签是 iamPrincipal/，资源标签是 resourceTags/（比如 team 这个 key 会变成 iamPrincipal/team）。AWS 有个现成查询集：aws-samples/sample-cur-iam-principal-bedrock-tracking。

⑥ 执行：Budgets + Deny。 建一个作用域为 Bedrock、过滤到某个身份或标签值的 Budget，挂一个 budget action：到阈值就应用一条 Deny IAM 策略。这是"能限住"的部分，不需要写应用代码。

（图源：同上。）

真正能用的 Deny 策略是只拒贵的那档，便宜模型留着让人继续干活：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": ["arn:aws:bedrock:*::foundation-model/[HIGHER-COST-MODEL-ID]"]
    }
  ]
}

分级不是靠多个预算，而是一个阈值挂多个动作、一个预算挂多个阈值：80% 拒高价款、100% 拒中档、低价款始终不拒。可以选择自动执行，也可以要求人工在 Alert 页面点批准；但至少配一条通知，告诉被限的人为什么访问变了。

连坐陷阱：budget action 挂在 IAM user / group / role 上。如果大家共用一个 role，Deny 一挂，整组人一起被掐，不只是超支那个。所以"账算到人头上"的前提是一人一 role（或网关按人下发 session tags）。联合身份、没有常驻 IAM 身份的，要用前一篇文章那套按用户的执行方案。

6.1 七个坑（做之前先看）

6.2 选哪条路，看你要什么

七、证明这个 agent 值不值

省下来的钱不等于价值。决定预算的那个问题是：这个 agent 比原来的人做得更好吗？

先把人工流程写下来。 什么触发这个工作、涉及哪些角色、交接点在哪、什么算完成。这听起来像官僚，其实是测量设计——下游所有埋点（什么算一次运行、什么算成功、人的时间花在哪）都从这段描述里掉出来。

在上线前测基线。 完成时间、排队时间、实际投入、重开率、升级率、单任务成本、产出质量。基线必须是上线前测的，事后回忆重构出来的基线会系统性偏袒 agent：人记得平均情况，忘了那些特别快的。

把工作流当实验来埋点。 每次运行一个 trace ID，一条 run 记录把模型调用之外的东西也聚成一个可分析单元：

{
  "runId": "run-8f3a2c",
  "workflow": "renewal-risk-summary",
  "principalArn": "arn:aws:sts::123456789012:assumed-role/BedrockRuntimeRole/gw-alex",
  "team": "sales-ai",
  "experiment": { "variant": "treatment", "holdout": false, "promptVersion": "v14" },
  "ops": { "latencyMs": 41200, "retries": 1, "toolCalls": 6, "humanApprovals": 1, "humanMinutes": 35 },
  "econ": { "inputTokens": 48210, "outputTokens": 3105, "cacheReadTokens": 31500, "estCostUsd": 0.87 },
  "outcome": { "status": "success", "accepted": true, "reopened": false, "revenueEventId": "opp-44121" }
}

三个字段值得单独说：experiment 块在运行创建时打戳并传入 Bedrock 请求元数据，让模型层和工作流层的记录能干净地 join；humanMinutes 是最多团队漏掉、又最需要的——不记它，"agent 干了这活"就悄悄排除了人审的那 35 分钟；revenueEventId 现在记不要钱，事后补不回来。

把成本和结果 join 起来。 日志记的是 token 不是美元，所以先建一张视图把每次调用按 run ID 定价，再在 Athena 里算三个数——单成功任务成本、每次成功的重试次数、每次成功消耗的人工分钟。这三个数能扛住 CFO 的追问；"单次调用成本"只会美化那些爱循环的 agent。

对比 agent 和人要用 A/B 或 holdout。 面向客户/营收相关的，按访客、线索、账户或工单随机；内部流程（客服、编码助手）用匹配队列（团队、仓库组、pod）。四个维度看：效率、质量、成本、业务价值——一个维度涨、另一个明显掉，结论就是模糊的，得继续调。

最后落到五维记分卡（官方给的起点阈值，不是标准）：

绿 = 扩；黄 = 调；红 = 停或重做。真正敢把红的 agent 下线，这套记分卡才有公信力。

八、我们的整理

8.1 从账单到人，四步就够

8.2 四个杠杆，按性价比排

1. prompt caching——agent 路径上最大的一笔，因为它砍的是"每轮重发"；
2. 工具 schema + maxTokens——比在 prompt 里求它"别废话"可靠；
3. 模型路由——同族里把简单请求丢给便宜模型；
4. 批量推理——批量单价近似砍半，但不支持工具调用和多轮，只适合单轮批量活。

推理开关放在最后：先关，等基准证明它赚得回来再开。

8.3 和我们既有几篇的关系

• Agent 成本体检：92,413 个 token 的启动账（10-15）讲的是"上下文预算"这一个角，这篇补的是"任务级"的账；
• LLM 成本预测 和 哪些编程语言的 Token 效率最高 是同一个 tokenizer 效率问题在编码场景的实测版本——AWS 这篇把它的商业含义说清了：牌价低 15% 的模型，可能因为多切 40% 的 token 而更贵；
• LLM 成本控制简明教程 是手段清单，这篇给了验收口径（单成功任务成本 + 每次成功的人工分钟）。

九、三步动作

1. 今天：拿你最贵的那条 agent 流水线，用 CountTokens 把 2–3 个候选模型跑一遍，比的是 token 数不是价格。
2. 本周：在你的 run 记录里补 humanMinutes 和 runId 两个字段——没有这两个，后面所有 ROI 都是猜。
3. 下次评审：只拿三个数上报——单成功任务成本、每次成功的重试次数、每次成功的人工分钟；其他都不要。

本文由 Software 2.0 编译整理，转载请注明出处。

Sources

• 原文：Majd Arbash、Ajit Mahareddy、Aswath Ram A Srinivasan《Optimizing cost per task and proving agent ROI on Amazon Bedrock》，AWS Machine Learning Blog，2026-11-12 https://aws.amazon.com/blogs/machine-learning/optimizing-cost-per-task-and-proving-agent-roi-on-amazon-bedrock/
• 前一篇：Arun Chandapillai 等《Tokenomics at scale: Track and cap Amazon Bedrock spend per IAM principal with CUR 2.0 and AWS Budgets》，AWS Machine Learning Blog，2026-11-12 https://aws.amazon.com/blogs/machine-learning/tokenomics-at-scale-track-and-cap-amazon-bedrock-spend-per-iam-principal-with-cur-2-0-and-aws-budgets/

同主题阅读

• Agent 成本体检：92,413 个 token 的启动账
• 哪些编程语言的 Token 效率最高？
• 默认模型是没锁的依赖：15 天三变，评测怎么记

参考支柱：AI 基建 / 评测 / 安全、Agent / MCP / 自动化。