在《在基础设施层实现AI成本实时可见性的理由与方案》中，我提出，AI度量难题从技术层面来看，似乎终于得到了解决，企业如今可以将AI作为一项战略性投资来管理，而不再是抱着碰运气的心态进行投入，这是AI发展下一个阶段最具标志性的转变，但有一点需要澄清：只有当企业的技术架构允许这样做时，这一判断才成立。

我的工作让我有机会深入企业的工程团队，帮助一线技术人员衡量和优化云成本与AI成本。最大的障碍很少是预算或专业能力不足，而在于AI支出与云支出不同，它无法直接关联到任何可以添加标签的对象。一次Token调用没有明确的责任归属，一个API密钥可能承载着多个团队的十几种工作流，而真正消耗资金的通常是智能体，而不是某个具体的人。

这些团队需要的答案，只有深入应用程序底层、观察实际运行情况才能获得。实现这一点并不需要开展多么复杂的工程项目，但确实需要访问工作负载运行所在的机器，而托管服务从架构层面就不提供这种访问权限。

因此，我现在首先会问一个问题：“你们的推理任务究竟运行在哪里?”答案决定了我们能够获得的AI成本洞察究竟有多准确、多完整，以及有多大实际使用价值。

平台架构的选择所带来的影响很容易解释，但日后想要改变却代价高昂。运行AI，要么使用由云服务提供商代为运营的服务，要么使用由自己管理的计算资源，也就是由自己控制的虚拟机(VM)或容器节点。几乎所有团队都在几个月前就根据平台工程方面的考量做出了选择，当时的决策依据与AI度量毫无关系。那时，人们还没有意识到，这一选择也会决定企业日后能够在多大程度上了解自身业务。

但现实已经摆在眼前。Gartner预计，到2028年，财富500强企业平均每家运行的智能体将超过15万个，而2025年时，这一数字还不到15个。面对少数几个工作负载时尚可容忍的盲区，一旦扩展到数以十万计的智能体，就会演变成一个令人头疼的严重问题。

选择托管服务有充分的理由

为了避免被指责存在偏见，我先说明一点：我经常建议客户使用托管服务。托管服务能让你更快地获得一个可以实际运行的智能体，同时还会替你处理扩缩容、补丁更新、服务可用性和容量管理等工作，这些事情都不是企业形成差异化竞争优势的关键。

如果你带着三名工程师和一份AI路线图来找我，我会建议你尽可能多地使用无服务器架构和托管服务，自行运营基础设施需要专门的平台团队，也需要相应的技术成熟度，因此，这实际上取决于企业的规模和所处的发展阶段。

这些优势已经得到了充分验证，其他方面的取舍则往往要到后期才会显现，尽管CIO大多早已权衡过其中的利弊，但仍有必要简要提及。

AI领域中已经可以量化成本的取舍

模型选择最直接地体现在成本上，开放权重模型通常可以运行在由企业自行控制的基础设施上，而托管模型目录中的模型在可用性方面可能滞后，也可能限制可选模型的范围。当新模型能够显著改变推理的经济性或性能表现时，这种差异就尤为重要。如果你使用的托管服务没有提供自己想要的模型，就无法通过该服务将请求路由到这个模型。

Stripe在8月份同意以超过70亿美元的价格收购OpenRouter，这充分表明了市场对模型路由价值的认可。当然，你仍然可以在托管服务内部实现不同模型之间的路由，但你必须将路由器编写到自己的应用程序代码中，并在服务之外自行运行。可你购买这项托管服务，本来就是为了不必亲自处理这些事情。

服务提供商的发布节奏也决定了你何时才能使用新功能，例如，许多自行管理基础设施的团队在MCP发布后的几天内就开始基于它进行开发，而直到今年3月，AWS的智能体运行时才开始支持有状态的MCP服务器，比MCP发布晚了一年多。

还值得注意的是，智能体之间相互移交任务可能会产生额外的执行或初始化成本，而在自行管理的节点上，你可以让资源保持预热状态，避免每次都从头初始化，此外，企业级身份验证并不总是托管服务提供的选项之一，因此你可能仍然需要自行构建相应的认证流程。在受监管行业中，如果无法证明数据的存储位置或处理位置，也可能直接导致整个方案无法落地。

对于任何管理过平台的人来说，这些都不是什么新鲜事，也不足以成为彻底否定托管服务的理由。你可以为每一项取舍估算成本，再决定是否值得付出代价，但接下来要讨论的问题，性质就完全不同了。

AI成本可见性是一项不对等的取舍

首先，我们来看看托管服务提供商究竟会向你披露多少AI支出信息。账单会按照服务提供商的结算周期出具，其中可能详细列出各项服务的支出，通常还能细化到具体账户或API密钥，这些信息可以告诉你，哪些地方的支出增加了，哪些地方的支出减少了。

但账单未必能告诉你，究竟是哪条工作流导致了这些变化，是哪个客户或哪位员工触发了相关操作——注意，这里说的是实际触发操作的人，而不只是创建工作流的人。账单也无法帮助你将支出与业务成果、生产力或收入建立对应关系，账单并不等于价值度量。

再深入一步来看，一个AI智能体也绝不只是单一服务，它由模型调用、MCP服务器、向量数据库、API、提示词管理系统，以及工作流所依赖的其他组件共同构成，这些配套组件的成本占比可能相当可观。如果无法单独审视这些成本，你就只能根据估算来做判断。

你无法准确说出某项功能的实际服务成本，无法判断按照已经签订的合同条款，哪些客户账户能够盈利，也无法确定成本高昂的部分究竟是模型本身，还是围绕模型运行的其他一切，因此，你只能进行粗略估算，而所有下游分析都会继承这些估算不可避免的误差。

业界常见的变通办法，是对应用程序进行埋点监测，跟踪每一次模型调用，并在整个工作流中传递成本数据，我已经多次采用这种方式构建解决方案，如果基础设施由你自己控制，这种方法确实有效。

但在托管运行时环境中，你实际上是在对别人控制的执行模型进行埋点监测。你可以跟踪自己发起的调用，却未必能看到自己正在为哪些初始化操作付费、各个执行步骤之间发生了怎样的编排，或者平台代你执行了多少次重试。你可以获得自己编写的代码所产生的详细数据，却难以充分了解其周围发生的一切，而意外的成本往往就藏在这些环节中。

AI领域代价高昂的问题通常也是间歇性出现的，而不是持续、稳定或可以预测的。例如，智能体可能在无法满足的检索请求上陷入循环，某条工作流可能退回到成本高昂的前沿模型;一次提示词修改也可能增加上下文长度，进而推高此后每一次调用的成本。如果你每月才检查一次账单，就只能发现AI支出比上个月更高，却不知道原因是什么。

如果能够按照每次请求的粒度实时监测成本，就可以立即定位出现异常的工作流，而且通常很快就能修复问题，这种能力还决定了你能多快介入并控制成本。

如何实现实时、按请求归因的成本分析

要获得这种细粒度的实时视图，一种方法是监测内核，利用与安全和可观测性工具相同的eBPF技术，在不触碰上层应用程序的情况下观察系统调用。

在这样的实现方案中，可以将计算和网络活动追溯到相关进程及请求，再将对外发起的模型调用与服务提供商的成本数据关联起来，它的优势在于，不再依赖开发人员记得为每一次调用添加埋点。

但这里存在一个限制：这种方法只适用于你能够控制宿主机的环境，而符合这一条件的场景比大多数人想象的要少。

在AWS上，这意味着EC2实例，以及运行在由EC2实例提供底层计算资源的ECS或EKS节点上的容器工作负载，但这不包括Fargate，因为在Fargate中，你无法控制宿主机内核。

这一原则同样适用于其他云平台：由客户控制的虚拟机和Kubernetes节点可以提供内核访问权限，而无服务器架构和完全托管的运行时环境通常无法提供这种权限。

这是一条明确的分界线：要么你具备这种能力，要么就不具备，没有可以绕过这一限制的变通方案。

这并不意味着托管服务本身就是错误的选择，云服务提供商提供的遥测数据和应用程序埋点仍然很重要，只是它们无法提供同等水平的基础设施层可见性。如果你的推理任务运行在一台你无法控制的机器上，那么你所能获得的基础设施层可见性，就只能达到服务提供商愿意向你开放的程度。即使智能体数量不断增长、成本可见性的价值日益提高，这种可见性的上限也不会因此改变。

智能体工作流正转向按任务定价

如今，每Token价格仍然是衡量AI支出的标准单位，但对于智能体而言，这并不是合适的衡量方式。与聊天场景相比，智能体会消耗多得多的Token，输入Token往往占据大部分成本;而即使是同一项任务，不同执行轮次的Token消耗量也可能存在很大差异，因此，即便单个Token更便宜，完成一项任务的总成本仍然可能更高。

真正能够反映价值的指标，是每项已完成任务的成本。

但要对任务进行定价，就必须将支出与该任务对应的具体工作流及可衡量的结果关联起来。在你能够控制的基础设施上，可以获得这种可见性，而在托管运行时环境中，你大多只能根据汇总账单进行推断。

过去两年，行业奖励的是快速交付产品和功能，下一个阶段，竞争优势将属于那些清楚了解每项任务的成本及其价值的企业，看不清实际工作过程的企业，将不得不与那些能够看清这一切的企业展开竞争。

企业网D1net(www.d1net.com)：

国内头部to B IT门户，旗下运营国内头部的甲方CIO专家库和智力输出及社交平台-信众智(www.cioall.com)。旗下运营19个IT行业公众号(微信搜索D1net即可关注)。

版权声明：本文为企业网D1Net编译，转载需在文章开头注明出处为：企业网D1Net，如果不注明出处，企业网D1Net将保留追究其法律责任的权利。