在 Amazon Bedrock 上优化单任务成本并验证智能体 ROI

本系列第 1 部分构建了控制 Amazon Bedrock 支出的运营模型：使用 AWS Identity and Access Management (IAM) 主体标签和 Cost and Usage Report 2.0 进行归因，通过模型调用日志实现可观测性，在三个层级执行管控，并建立审查节奏。该层回答了“谁花了钱”，并且你可以阻止他们。但它无法告诉你这笔支出是否花得值。

本文回答第 1 部分有意留下的两个问题。第一：为什么这个工作流成本高昂？答案需要以每任务成本而非每 token 成本来思考。第二：智能体是否比人类做得更好？答案需要基线、受控实验以及与决策挂钩的评分卡。

在本文中，你将学习一个计算真实模型成本的框架（包括定价页面上未展示的四个隐藏成本驱动因素），通过缓存、路由和输出约束降低每任务成本的技术，以及一套用人类基线、留出实验和五维评分卡衡量智能体 ROI 的纪律。本文面向两类读者：掌握优化杠杆的应用和平台工程师，以及需要向领导层证明智能体支出合理性的产品负责人和 FinOps 合作伙伴。

每任务成本，而非每 token 成本

每 token 价格便于快速比较，但它并不反映你实际支付的费用。公布的价格反映的是单个 token 的成本。你的账单反映的是完成一项任务的成本。任务是你的应用要求模型完成的一个完整工作单元：解决一封支持邮件、从一张发票中提取字段，或回答一个用户问题。一项任务从请求开始，直到获得可用结果，无论需要多少次模型调用。

价格更低的模型可能并不是运行成本更低的那个。更便宜的模型可能将你的文本拆分成更多 token、用填充内容拉长响应、误读你的工具 schema 并反复循环修正，或在回答前消耗数千个推理 token。这些成本都不会出现在 Bedrock 定价页面上。

四个隐藏成本驱动因素

四个模型特征决定了公布的价格在你的工作负载上实际花费多少。

分词器效率

token 不是单词，且在不同模型之间并不等同。每个模型系列使用不同的分词器和词汇表。相同的文本、代码或 JSON 负载会拆分成不同的 token 数量。如果模型 A 的标价低 15%，但其分词器对你的数据需要多 40% 的 token（在结构化 schema 和数值数组上很常见），那么模型 B 更便宜。对于非英文文本，差距会更大：许多分词器会将非拉丁文字拆分成比等效英文多两到三倍的 token。

输出对齐与冗长程度

输出 token 的成本通常比输入 token 高 3–5 倍（比例因系列而异。请参阅 Bedrock 定价页面）。一个忽略“仅返回原始 JSON”等格式约束的模型，会让你为填充词支付输出溢价。一个严格遵循格式指令的模型则通过生成更少这些更昂贵的输出 token 来节省费用。

智能体循环效率

Agentic 工作流彻底改变了成本计算方式。工具使用（函数调用）让模型可以调用外部函数，这需要一个多轮循环：分析提示词、决定调用工具、等待观察结果、生成答案。每一轮都会将完整的对话历史和工具结果作为输入 token 重新发送。一个需要四轮的模型（每轮都重新发送更大的上下文负载）的成本远高于一次就完成的模型。

推理开销

许多模型支持扩展思考，在给出可见答案之前先进行思维链推理。推理 token 按输出 token 计费，因此一个在给出 200 token 答案之前思考了 2,000 token 的模型，会向你收取 2,200 token 的费用。有些模型会隐藏推理过程，但仍然对其收费。建议先关闭推理，仅当基准测试显示质量差距足以证明成本合理时才启用。

每任务成本：一个计算示例

图 1：从五个成本维度比较两个模型。标价只是决定实际成本的五个因素之一

考虑一个 agentic 工作流：读取一封 750 词的客户邮件，提取实体，调用 API 验证账户状态，并输出严格的 JSON。以下比较使用示例价格（请始终基于你自己的数据和当前的 Bedrock 定价进行基准测试）：

模型 A：(6,150 x $0.50 + 750 x $1.50) / 1,000,000 = $0.0042

模型 B：(1,000 x $1.00 + 150 x $3.00) / 1,000,000 = $0.00145

图 2：为什么价格更高的模型成本反而低 65%。每一额外轮次都会重新发送不断增长的上下文负载，使账单不断累积

为什么价格高 2 倍的模型成本反而低 65%：三个叠加因素。模型 A 的分词器将邮件切分成多 50% 的 token，使每个输入负载膨胀。它用填充内容扩充 JSON，使输出 token 增至三倍。而且它与工具 schema 不匹配，需要两轮纠正，每轮都重新发送不断增长的历史记录。

每成功任务成本

前面的示例假设两个模型最终都会成功。在生产环境中它们不会，而失败很少是免费的。公式如下：

对于重试直至成功的工作流：

cost per successful task = cost per attempt / success rate

对于失败即升级的工作流：

cost per successful task = cost per attempt + (1 - success rate) x escalation cost

当启用提示缓存时，输入进一步分为三类：按基础费率计费的未缓存输入、低于基础费率的缓存读取，以及高于基础费率的缓存写入。

在你自己的工作负载上测量

哪个模型实际上更便宜，只有基于你自己的数据进行基准测试才会显现。Amazon Bedrock 模型评估是管理质量这一半的托管功能：定义标准、上传提示词数据集，并获得带有自动指标和可选人工审核的评分结果，无需自定义基础设施。

不过，仅凭质量分数无法产生账单。另外三个 Bedrock 功能提供了你用来定价的 token 和轮次计数：

• CountTokens 返回给定模型针对给定负载会计费的输入 token 数量，而无需运行推理。这是在为生成花费任何成本之前，比较各候选模型分词器效率（驱动因素 #1）的最便宜方式。
• 模型调用响应携带一个 usage 块，其中包含 inputTokens、outputTokens、cacheReadInputTokens 和 cacheWriteInputTokens。在单个任务的各轮次中累加这些值，就能得到前述每次尝试成本公式的四个项。一个需要注意的地方：启用缓存时，inputTokens 只统计未缓存的 token，因此你的总输入量为 inputTokens + cacheReadInputTokens + cacheWriteInputTokens。将它们相加可了解总体占用，但要分别计价，因为这三者按不同费率计费。在整个过程中多次评估这一点，并根据当前活跃负载来设置缓存检查点。随着应用推进、工具变得陈旧，缓存检查点会发生漂移。这意味着，在 3 个月后漂移发生时，你会向缓存写入更多内容。持续评估数据以实现最优缓存使用，成为降低成本的主要杠杆。
• 模型调用日志记录 将每次调用的 token 数量写入 Amazon Simple Storage Service（Amazon S3）或 Amazon CloudWatch Logs，因此你可以基于真实生产流量而非样本，衡量完成所需轮次。使用 请求元数据 标记调用，以便按团队、功能或实验对这些记录的 token 数量进行切分。然而，这些是日志字段，不是成本分配标签，永远不会出现在 AWS Cost Explorer 或你的成本和使用报告中。应用程序推理配置文件 确实会进入这两者，粒度为每天每种使用类型。该粒度适合计费分摊，但对于每任务成本来说过于粗糙。将记录的 token 数量乘以公布费率，得到的是近实时估算，而非账单。除非你对其进行建模，否则它不会反映承诺、批量定价或预置吞吐量。在将其视为账单之前，请与你的成本和使用报告进行核对。

降低每任务成本：四个杠杆

四个驱动因素各有一个杠杆，且每个都有深入文档记录。提示缓存 减少了使模型 A 昂贵的重发上下文，这使其成为代理路径上最大的收益。智能提示路由 将简单请求发送给同一系列中更便宜的模型。工具 schema 加上 maxTokens 上限，比散文式指令更可靠地抑制冗长，并且在基准测试表明扩展思考能收回成本之前，保持其关闭。批量推理 将批量单轮工作的费率减半，尽管它排除了工具调用和多轮交互。

证明代理 ROI：描述人类基线

高效不等于有价值。一个代理可以完美优化，却仍然不值得运行。决定预算的问题是：这个代理比人类做得更好吗？

先记录人类流程

代理 ROI 中最大的错误是试图在未先描述人类工作流的情况下证明价值。在构建或扩展代理之前，用运营术语写下当前流程：什么触发工作、涉及哪些人类角色、交接点在哪里、完成如何定义。这听起来像官僚主义。它实际上是测量设计。下游的每个 instrumentation 决策（什么算作一次运行、什么算作成功、人类时间花在哪里）都源自这一描述。

在代理上线前测量基线

借助所描述的流程，在有意义的窗口内测量人工基线：完成时间、排队时间、实际投入、重开率、升级率、每任务成本和结果质量。基线必须在智能体上线前测量，而不是事后凭记忆重建。回顾性基线会系统性地美化智能体：人们记得平均情况，却忘了那些快的。

将工作流作为实验进行埋点

基线建立后，从第一天起就将智能体工作流作为实验进行埋点。每次运行都获得一个 trace ID，每个有意义的步骤都可观测。工作流运行记录将模型调用之上的所有内容聚合为一个可分析单元：

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

有三个字段值得强调：

experiment block：在运行创建时打标，并传播到 Bedrock 请求元数据中，使模型级和工作流级记录能够干净地关联。

humanMinutes：大多数团队遗漏、却最需要的内容。没有它，“智能体完成了工作”会悄然排除人类花在审查上的 35 分钟。

revenueEventId：让日后收入归因成为可能的钩子。记录它不花成本，事后却无法重建。

规则是：如果工作流遥测无法回答业务问题，埋点就是不完整的。

将成本与结果关联

随着调用日志落入 Amazon S3（第 1 部分）、工作流运行记录进入分析存储，一次关联就能产生真正重要的指标。Amazon Bedrock 日志记录的是 token，而非美元，因此首先构建一个视图，根据 token 数量和你的模型费率表为每次调用定价，并按运行 ID 聚合。然后用 Amazon Athena 查询：

SELECT
  w.workflow,
  w.variant,
  COUNT(*) AS runs,
  SUM(IF(w.outcome_status = 'success', 1, 0)) AS successes,
  ROUND(SUM(c.est_cost_usd) /
    NULLIF(SUM(IF(w.outcome_status = 'success', 1, 0)), 0), 2)
    AS cost_per_success,
  ROUND(SUM(w.retries) * 1.0 /
    NULLIF(SUM(IF(w.outcome_status = 'success', 1, 0)), 0), 2)
    AS retries_per_success,
  ROUND(SUM(w.human_minutes) /
    NULLIF(SUM(IF(w.outcome_status = 'success', 1, 0)), 0), 1)
    AS human_min_per_success
FROM workflow_runs w
JOIN invocation_costs_by_run c ON c.run_id = w.run_id
GROUP BY w.workflow, w.variant
ORDER BY cost_per_success DESC

注意：上述查询中显示的列名和关联键仅为示例。请根据你的调用日志 schema 和工作流遥测存储进行核实，它们可能因实现而异。

每次成功结果的成本、每次成功的重试次数、每次成功的人工分钟数，是经得起挑剔 CFO 检验的三个数字。每次调用的成本会美化那些循环的智能体。每次成功的成本则不会。注意变体分组：同一查询按实验组拆分，就是 ROI 对比。

正确比较智能体与人类

最可信的评估是 A/B 或留出测试。受控处理组和对照组将智能体辅助的工作流与人工基线进行比较，而不会将结果与市场、季节或组织变化混淆。

对于面向客户或与收入挂钩的工作流，在访客、线索、账户或案例层面随机化。对于内部工作流（支持运营、编码助手），使用匹配队列：团队、仓库组或 pod。

比较涵盖四个维度：

效率：完成时间、节省的工时、排队时间减少。

质量：错误率、批准率、重开率、升级率。

成本：每任务成本、每次成功结果成本、总服务成本。

业务价值：转化提升、留存提升、扩展率、每销售代表或每工作流的收入。

如果智能体改善了一个维度却显著降低了另一个维度，结果就是模糊的，部署需要调优。

收入：最难的指标

效率提升是 ROI 论证中最容易证明的部分。收入影响则更难衡量，而它正是管理层据以拨款的指标。在与收入相关的工作流中，要衡量智能体是否提升了转化率、响应时间、交易推进或每位销售代表的收入。留出测试（holdout tests）是将可归因于智能体的增量收入与整体业务自然增长区分开来的最可靠方法。

当收入提升真实存在时，对话的性质就变了。组织不再追问 Bedrock 账单是否上涨，而是开始追问这笔额外支出是否换来了业务产出的实质性增长。

记分卡

基于我们与客户合作中的观察，一个强有力的运营模型并不需要五十个指标。真正有效的是一个小型记分卡，它与决策挂钩，并按固定节奏对每个生产环境中的智能体进行评审。

以下阈值只是起点，而非规定。请结合您自己的智能体集群数据和组织背景进行校准。

绿色意味着扩展：智能体在满足成本和质量阈值的同时优于基线。黄色意味着调优：有前景但需要改进。红色意味着退役或重新设计：智能体消耗了成本却没有足够可衡量的价值。真正愿意让红色智能体退役，正是让记分卡其余部分可信的关键。

结论

在本文中，您了解了如何通过考量四个隐藏成本驱动因素（分词器效率、输出对齐、智能体循环效率和推理开销）来计算模型的真实成本，如何通过提示缓存、模型路由、输出约束和批量推理来降低每任务成本，以及如何通过衡量人工基线、将工作流作为实验进行埋点、将成本与结果关联并进行留出对比来证明智能体 ROI。

成本优化这一半回答了“为什么这么贵，我该如何解决”。ROI 这一半回答了“智能体是否比原来的人工更好”。结合第 1 部分的运营模型（归因、观测、执行、优化、运营），它们构成了一个完整的框架：您可以看到是谁花的钱、解释原因、减少浪费，并为剩余部分提供依据。

要开始使用，请使用 Amazon Bedrock 模型评估 针对您自己的提示对首选模型候选进行基准测试，从 usage 块或您的 调用日志 中捕获 token 和轮次，按当前 Bedrock 定价 计价，再除以成功率。关于 ROI 衡量，请参阅 Well-Architected Agentic AI Lens 了解智能体成本治理最佳实践。

如果您发现了其他在 Amazon Bedrock 上降低每任务成本或衡量智能体 ROI 的技术，欢迎在评论中告诉我们。

关于作者

Majd Arbash

Majd Arbash 是 AWS 驻多伦多的企业解决方案架构师，他帮助大型企业客户构建安全、可扩展的云解决方案并采用生成式 AI。作为 Serverless 和生成式 AI 技术领域社区的成员，Majd 专注于应用现代化、安全以及动手实践生成式 AI 实验。

Aswath Ram A Srinivasan

Aswath 是 Bedrock 的高级专家解决方案架构师，专注于 Bedrock 核心模型、功能以及成本优化/归因。他帮助 ISV 和战略客户解决他们的挑战，并与企业团队合作，负责任地设计兼顾性能、成本和运营简便性的推理架构。业余时间他是一名摄影师，喜欢阅读关于神经符号 AI 和负责任 AI 的科学期刊论文。

Ajit Mahareddy

Ajit 是一位经验丰富的产品和上市（GTM）领导者，在产品管理、工程和上市方面拥有超过 20 年的经验。在担任当前职位之前，Ajit 曾在 Uber、Turing 和 eHealth 等领先科技公司领导产品管理，构建 AI/ML 产品。他热衷于推进生成式 AI 技术，并推动生成式 AI 产生现实世界的影响。