AWS博客提出按“每任务成本”核算Bedrock模型开销，并给出智能体ROI评估方法
AWS机器学习博客作者Majd Arbash在系列文章第二部分提出：比较Bedrock模型价格应看完成一个任务的总成本，而非每token单价；评估智能体价值则需在部署前测量人工基线，并以对照实验和五维记分卡衡量。文中数字为示例性测算。
AI解读：AWS博客文章指出，Bedrock定价页上的每token价格不能反映实际账单；作者主张以“每任务成本”比较模型，即从请求到可用结果的全部调用开销。
文章列出四项定价页未体现的成本因素：分词器效率、输出冗长度、智能体多轮工具调用循环、推理token开销。作者以一组示例价格测算：标价高一倍的模型因分词更省、输出更短、一轮完成，单任务成本为 0.00145 美元，低于低价模型的 0.0042 美元。
作者称生产环境还需按成功率折算：重试型流程用单次成本除以成功率，失败上报型流程加上失败率乘上报成本；启用缓存时输入分为未缓存、缓存读、缓存写三种费率分别计价。
文章建议用Bedrock的CountTokens、模型调用响应中的usage字段和调用日志获取token与轮次数据，再按当前价格估算成本，并与Cost and Usage Report对账；文中示例的计费口径与列名由作者注明为示意。
评估智能体回报时，作者要求在部署前记录人工流程并测量完成时间、积压时间、返工率、上报率、单任务成本等基线，部署后把每次运行作为实验记录，并按效率、质量、成本、业务价值四个维度与人工做对照。
作者给出五维记分卡，将采用率、完成率、质量、单位经济性和业务影响分别标为绿、黄、红，并称红色对应退役或重新设计；文中阈值是起点建议，需按自身数据校准，文章未提供客户实测效果数据。
AWS机器学习博客发布系列文章第二部分，主题是如何在Amazon Bedrock上计算“每任务成本”并衡量智能体投资回报。作者Majd Arbash称，定价页上的每token价格不反映实际账单，模型应按完成一个完整任务的总开销来比较。
文章同时给出评估智能体是否优于人工的方法：先描述并测量现有人工流程，再把智能体工作流当作实验记录运行数据，与基线做对照，并以五维记分卡决定扩大、调整或停用。文中计算示例使用示意价格，作者提醒需以自身数据和当前Bedrock定价为准。
四项未体现在价格页上的成本因素
文章把任务定义为一次完整工作单元，例如处理一封客服邮件、从一张发票提取字段或回答一个问题，可包含多次模型调用。作者称低价模型未必更便宜，并列出四项影响实际成本的因素：
分词器效率：不同模型家族的分词方式不同，同一段文本、代码或JSON可能被拆成不同数量的token；作者称非拉丁文字常被拆成英文对应内容的二到三倍token。
输出冗长：作者称输出token单价通常是输入的 3 至 5 倍，具体比例依模型家族而定，并让读者查阅Bedrock定价页；不遵守“只返回原始JSON”等格式要求的模型会因填充内容增加这笔开销。
智能体循环效率：工具调用需要多轮往返，每轮重新发送完整对话历史和工具结果作为输入；作者称需要四轮完成的模型，成本远高于一次完成的模型。
推理开销：扩展思考产生的推理token按输出token计费，作者称某模型先思考 2000 token再给出 200 token答案，就按 2200 token计费；部分模型不展示推理过程但仍收费。文章建议先关闭推理，仅在评测显示质量差距值得这笔成本时开启。
示例测算与生产环境的成功率折算
文章用一个智能体工作流做示例：读取 750 词客户邮件、提取实体、调用API核实账户状态、输出严格JSON。作者设定两组示意价格，其中模型A输入 0.50 美元/百万token、输出 1.50 美元/百万token，模型B分别为 1.00 和 3.00 美元。
按作者的假设，模型A第一轮输入 1500 token、最终输出 450 token、需三轮纠错，累计输入 6150 token、输出 750 token，单任务成本 0.0042 美元；模型B第一轮输入 1000 token、输出 150 token、一轮完成，单任务成本 0.00145 美元。作者将差价归因于分词多 50%、输出约为三倍、多出两轮纠错三个叠加因素。
作者补充，上述测算假定两个模型最终都成功。生产中失败并非零成本：对重试直到成功的流程，每成功任务成本等于每次尝试成本除以成功率；对失败即上报的流程，则加上失败率乘以上报成本。
启用提示缓存时，输入分为未缓存输入、缓存读取和缓存写入三部分，分别按不同费率计价；模型调用响应中的inputTokens在启用缓存时只计未缓存token，作者提醒需把三项相加才能得到总输入量，但计费要分开。
降低单任务成本的四个手段
文章为四项成本因素各配一个手段：提示缓存削减智能体路径上反复发送的上下文，作者称这是该路径上收益最大的措施；智能提示路由把简单请求交给同家族中更便宜的模型；工具schema加maxTokens上限比文字指令更能约束输出长度；扩展思考默认关闭，直到评测证明其质量收益抵得上成本。
另有批量推理，作者称可把批量单轮工作的费率减半，但不支持工具调用和多轮交互。文章未给出这些手段在实际客户工作负载上的节省比例。
人工基线与实验式记录
文章把“智能体是否比原来的人工做得更好”作为决定预算的问题，并称智能体回报评估中最大的错误是在未描述人工流程的情况下试图证明价值。作者要求在建设或扩大智能体前，以操作语言写下现有流程：什么触发工作、涉及哪些角色、交接点在哪里、如何定义完成。
基线需在智能体上线前测量，覆盖完成时间、排队时间、实际投入、返工率、上报率、单任务成本和结果质量。作者称事后凭记忆重建的基线会系统性偏向智能体，因为人记得平均情况而忘记快的那部分。
上线后，作者建议每次运行分配trace ID，并记录包含实验分组、人工审核分钟数、token用量、估算成本、结果状态和收入事件ID的工作流运行记录。作者强调humanMinutes字段：缺少它，“智能体完成了工作”会漏掉人工审核所花的时间。
把成本与结果关联，并与人工对照
作者建议把Bedrock调用日志（记录token而非美元）与工作流运行记录按运行ID关联，先按token数和价目表折算每次调用成本，再用文中给出的Athena查询示例按工作流和实验分组计算每成功任务成本、每成功任务重试次数和每成功任务人工分钟数。作者注明查询中的列名和连接键为示意，需按实际日志schema核对。
对照评估方面，作者建议采用A/B或留出组实验：面向客户或与收入相关的工作流按访客、线索、账户或案例随机分组；内部工作流按团队、代码库分组或小组匹配队列。比较维度为效率、质量、成本和业务价值。作者称若智能体改善一个维度却明显恶化另一维度，结果是不明确的，部署需要调整。
收入影响被作者称为最难证明的指标，并建议用留出组实验把智能体带来的增量收入与整体业务增长区分开。
五维记分卡与红黄绿判定
文章提出一张与决策挂钩的小型记分卡，按采用率、完成率、质量、单位经济性和业务影响五个维度给出绿、黄、红三档，并称阈值是起点而非规定，需按自身数据校准。
按文中表述，采用率为活跃用户占目标用户比例，超过 70% 为绿、40% 至 70% 为黄；完成率中 90% 以上为绿；质量维度以目标为参照，达到目标的 75% 至 90% 为黄；单位经济性超过预算 1.5 倍为红；业务影响相对基线显著为正为绿、没有或为负为红。
文章把绿定义为扩大、黄为调整、红为停用或重新设计，并称是否愿意真正停用红色智能体，决定记分卡其余部分是否可信。文章未提供客户实测的效果数据。