2026 年 9 月 2 日，微软在 SEMICON Taiwan 提出一个值得关注的基础设施指标：有用产出率（useful yield）。它强调，AI 基础设施的进步不应只看建成多少算力，还要看芯片、内存、网络和电力能以多高效率转化为有用智能，例如每美元、每瓦产生更多 Token，同时提高吞吐并降低延迟。
这个判断对采购云资源、建设算力中心的企业很重要，但如果把它直接带到业务部门，“每美元产生多少 Token”仍然不够。Token 是计算系统的产出，不是企业经营的产出。一份生成得很便宜、却因事实错误被退回三次的合同草稿；一次响应很快、却没有解决客户问题的服务对话；一批自动生成、最终无人采用的分析，都可能让技术效率看起来很好，业务效率却持续恶化。
因此，企业需要把“有用产出率”再向业务侧推进一步：不只核算一次模型调用花了多少钱，而要核算每个被业务接受、能够进入下一环节的结果，消耗了多少完整资源。
AI 成本正在变便宜，但任务也在迅速变重
国际能源署（IEA）在 2026 年发布的《Key Questions on Energy and AI》中指出，软硬件进步使单个 AI 任务的能耗近年来至少以每年一个数量级的幅度下降。但与此同时，推理、视频生成和 Agent 等新型任务，一次任务可能比简单文本生成多消耗数百乃至数千倍能源。
这揭示了企业很容易忽视的反弹效应：单位调用成本下降，不一定带来总成本下降。更便宜的推理会鼓励更多用户、更长上下文、更多候选方案、更高频重试，以及能够连续调用搜索、数据库、代码和业务系统的 Agent。单次价格可能下降，任务数量和任务深度却同时上升。
企业内部常见的成本看板仍停留在以下指标：
这些指标适合管理供应和技术运行，却不能回答管理层最关心的问题：这些消耗最终产生了多少可用结果，减少了多少返工，改善了哪个客户、收入、风险或运营指标？
- 购买了多少算力、账号或调用额度；
- 每百万 Token 的输入和输出价格；
- 模型响应时间与每秒吞吐；
- 每个部门的调用量和活跃用户数；
- 相比人工操作，单次自动化步骤节省了多少时间。
“生成成功”与“业务接受”之间，还有一条成本链
一次 AI 输出从生成到创造价值，通常要经过至少四道门槛：
许多项目只计算第一层。于是，重试、人工校正、低质量结果造成的返工、系统集成、评测、审计和失败后的处置，都被放在模型账单之外。最终容易出现一种假节约：自动生成成本下降了，但复核队列越来越长；模型回答更多了，但专家要花更多时间判断哪些回答可信；业务部门减少了录入工作，却增加了异常处理和客户解释。
更合理的核算单位不是“每次调用”，而是“每个被接受的业务结果”。可以用一个简单口径开始：
单位有效结果成本 =（模型与基础设施成本 + 数据与工具成本 + 人工复核成本 + 失败重试成本 + 运行治理成本）÷ 被业务接受的结果数。
这里的“接受”必须由具体场景定义。例如，销售场景可以是一份经客户经理确认、进入 CRM 下一阶段的机会摘要；采购场景可以是一组通过规则校验、可供采购员比较的报价；客服场景可以是一项在规定时间内解决、且没有再次联系的请求；设备维护场景则可以是一份经工程师确认、证据完整并转为工单的处置建议。
如果没有这个定义，团队很可能通过大量生成低价值输出，把平均 Token 成本做得越来越漂亮。
- 技术完成：模型返回结果，工具调用没有报错；
- 质量合格：事实、格式、规则和安全要求达到预设标准；
- 业务接受：责任人员愿意采用，结果可以进入下一流程；
- 结果兑现：采用后确实改善了周期、收入、质量或风险。
建立一张从资源到业务结果的“产出账”
企业不必一开始就追求全公司统一的精确模型。更务实的做法，是为每个高频 AI 场景建立一张可对账的产出账：
这张账最关键的不是把所有成本折算到小数点后两位，而是让技术与业务看到同一条因果链。模型团队不能只交付调用量，业务团队也不能只报一个难以归因的“效率提升”。双方需要共同约定有效结果、失败结果和人工投入的定义。
对 Agent 场景，还应保留每次任务的工具调用轨迹和终止原因。同一个最终答案，有的可能一次生成完成，有的经历十几次搜索、反复调用昂贵模型并由员工重写。两者在“任务完成数”中相同，在真实成本和可扩展性上完全不同。
- 核算层：需要记录什么：需要回答的问题
- 资源消耗：模型、Token、推理时长、算力、电力或云费用：为完成任务实际用了多少技术资源
- 执行消耗：搜索、数据库查询、第三方接口、工具调用与重试：Agent 为获得结果走了多少步
- 质量消耗：自动评测、人工复核、修改、驳回与升级：生成结果离可用还有多远
- 有效产出：被接受、进入下一流程并按时完成的结果：有多少输出真正被业务采用
- 经营结果：周期、一次完成率、收入、损失、投诉或风险变化：被采用之后是否产生了预期价值
采购模型与算力，要用自己的工作负载比较
不同模型、硬件与部署方式之间的效率差异，需要标准化基准帮助比较。MLCommons 在 2026 年 7 月发布 MLPerf Endpoints v0.7，开始构建面向数据中心推理端点、可滚动更新的可比基准，并计划在 1.0 版本加入更面向采购者的规则、归一化方法和 Agent 工作负载。
这类行业基准很有价值，但企业不能把通用排行榜直接当成采购结论。真实成本会受到上下文长度、输出长度、并发模式、峰谷负载、数据位置、工具调用、质量阈值和服务等级要求影响。一个在标准任务上吞吐更高的方案，未必能以更低成本完成企业自己的长文档审查、跨系统查询或低延迟交互。
采购测试应至少包含三组样本：日常高频任务、复杂长尾任务和不能出错的高风险任务。对每种候选方案，同时观察：
这样，模型选择才会从“哪个参数更多、榜单更高”转为“哪个组合能更稳定地交付我们的业务结果”。
- 达到相同质量门槛时的完整任务成本，而非默认参数下的调用单价；
- 首次通过率、平均重试次数和人工修改时间；
- 高峰并发下的延迟、排队与超时；
- 更换模型、压缩上下文或降低精度后，业务接受率是否变化；
- 失败时能否降级、转人工并保留足够证据。
优化顺序应从无效工作开始，而不是先压低单价
当 AI 预算承压时，企业最直觉的动作是谈折扣、换便宜模型或缩短提示词。这些动作可能有效，但通常不是最大成本来源。更应先检查四类无效工作：
优化时可以按“取消、简化、路由、缓存、再工程化”的顺序处理：先停止无人使用的产出，再缩短不必要的上下文和步骤；随后按难度与风险选择模型，把稳定结果与公共数据缓存复用；最后才考虑更深的系统、模型或硬件改造。
这也意味着成本治理不能由基础设施团队独立完成。财务部门看到的是账单，平台团队看到的是调用，业务团队知道结果是否被采用，风险与质量团队掌握失败后果。只有把这些数据连接起来，企业才能判断成本上升究竟来自有效业务扩张，还是来自低质量和重复劳动。
- 没有明确使用者和下一步动作，却被定时批量生成的报告；
- 同一任务因质量门槛不清，被模型和员工反复改写；
- Agent 在缺少停止条件时循环搜索或调用工具；
- 低风险任务使用了过度昂贵的模型，高风险任务却省略了必要复核。
不要把能源数字直接换算成单个企业的收益
IEA 预计，全球数据中心用电量将从 2025 年约 485 TWh 增长到 2030 年约 950 TWh，其中 AI 专用数据中心的用电增长更快。这说明算力、电力和基础设施约束正在成为真实经营条件，也解释了微软为何强调跨芯片、内存、网络、电力、冷却、软件和工作负载优化。
但宏观用电预测不能直接证明某家企业的 AI 成本会上升，也不能证明某种云服务、本地部署或硬件采购必然更节能。微软的“有用产出率”目前是基础设施战略主张，并不是一套已经统一定义、可直接审计的企业业务指标；IEA 的能耗数据属于全球预测，也存在技术进步、使用增长和任务结构快速变化带来的不确定性；MLPerf Endpoints v0.7 则仍是基础版本，买方规则和 Agent 工作负载尚在继续扩展。
这些来源共同支持的是一个方向，而不是一个通用 ROI 数字：当 AI 调用更便宜、任务更复杂、基础设施约束更显著时，企业必须把技术效率和业务有效性放进同一套核算中。
企业真正需要提高的，是“有效结果密度”
过去，企业容易把 AI 建设规模表达为多少账号、多少模型、多少 GPU、多少 Token。下一阶段，更有解释力的指标应该是：在给定资金、算力、电力和专家时间下，系统交付了多少被业务接受且产生结果的工作。
这可以称为“有效结果密度”。它不鼓励团队少用 AI，而是要求每一次扩容、升级和自动化，都能说明新增资源转化成了什么结果；当转化率下降时，组织能定位问题究竟在模型、数据、流程、复核还是需求本身。
因此，企业审查下一笔 AI 预算时，不妨暂时把“每百万 Token 便宜了多少”放到第二页，先在第一页回答三个问题：什么才算这个场景的有效结果？从生成到被接受的完整成本是多少？随着使用规模扩大，这个成本是在下降，还是被重试、复核和无效产出悄悄推高？
能持续回答这三个问题，企业购买的才不只是更多计算，而是一套把有限资源稳定转化为业务价值的能力。
