跳到正文
MIT Technology Review · AI· Affan Syed·· 3 小时前AI 评分22

别再数 token 了,该数交付了多少软件

Stop counting tokens, start counting what ships

AI 导读

智能体编码任务消耗的 token 可达普通对话提示词的 10 到 50 倍,按 token 计费让高价值工作流反而最贵。文章主张改用「每个已合并 PR 的成本」衡量 AI 编码投入,并建议用网关把常规任务路由到自托管开源权重模型、把前沿模型留给复杂规划。HPE 称其混合 AI 平台将 150 多个内部应用的常规负载迁至本地开源权重模型,token 成本下降 30% 到 50%。

正文 · AI 翻译

当开发者给 AI 智能体分配一项编码任务时,智能体所做的远不止回答一次。它会规划、生成代码、运行测试,并重复这一过程以纠正错误。一项任务消耗的 token 可能比基础聊天提示多 10 到 50 倍。智能体越有用,它发起的调用就越多。在按 token 计价的模式下,创造价值最多的工作流也可能变得最昂贵。

财务压力已经显现。据报道,Uber 在扩大 Claude Code 的使用范围后,到 4 月就已耗尽 2026 年全年的 AI 预算。GitHub Copilot 从固定费率定价转向按量计费的额度。Gartner 预测,到 2028 年,AI 编码的 token 成本将超过开发者的平均薪资。

自然的应对方式是配给:使用上限、席位限制,以及在开发者启动智能体前进行审批。但一刀切的限制可能束缚住真正创造价值的工作流。它们优化的还是错误的数字。每 token 成本衡量的是消耗,而非成果。有些支出反映的是浪费,包括重试和失控的循环。有些则代表着交付软件的工作。计量表无法区分二者,支出上限同样不能。

衡量真正交付的软件

更好的衡量指标是每个已合并拉取请求的成本:AI 辅助开发总成本除以通过评审并被合并的变更数量。同时跟踪返工和缺陷,以免更便宜的变更掩盖了更低的质量。

如果这一成本随着 AI 使用量的上升而下降,且不损害质量,说明开发者正在把更多消耗转化为有用的软件。问题不在于他们用了多少 token,而在于这笔投入产出了多少完成的工作。

改善这一等式需要两项改变:把昂贵的推理留给真正需要它的任务,并降低日常工作的成本。

让模型与任务相匹配

智能体编码并不需要在每一步都使用最强大的模型。对于困难的规划和全新的推理,使用前沿模型,或在政策要求时使用本地部署的旗舰模型。将适合的工作,包括代码生成、测试创建和重复重构,路由到你自行运营的开放权重模型。

网关可以根据任务复杂度、数据敏感性、成本和延迟来路由请求。这样就能把高端推理留给真正值得的时刻,而不是对整个工作流都套用高端定价。计量例外,而非整个工作负载。

开放权重模型让这种分工日益可行。软件工程基准测试显示,领先的开放权重模型在某些任务上可以接近前沿性能。但这并不能证明它们在每个代码仓库或工作流中都等效。在分配生产工作之前,应依据你自己的代码、测试和验收标准来评估候选模型。

改变重复使用的经济性

接下来,要决定谁拥有算力。使用租用的推理,每次调用都会增加账单。使用自有算力,大部分成本在前期投入,因此随着使用量增长,每次额外调用都会变得更便宜。

经济账很简单:按 token 计价让重度使用更昂贵,而自有算力会随着团队使用得越多而越高效。不过,自有并非免费。电力、运营、维护和折旧都必须考虑在内。真正重要的数字是每个已合并拉取请求的全负载成本。

自有容量还能带来一种永远不会出现在账单上的价值:对敏感代码的控制权。当代码生成和测试在本地运行时,专有代码始终留在企业内部。只有经过批准的规划提示词和受管控的例外情况,才会通过企业控制的网关发送到外部模型。这打开了那些因安全顾虑而通常阻碍采用的敏感代码库,而最大的收益正等待在那里。

测试运营模式

在 HPE,一个混合 AI 平台将来自 150 多个内部应用的常规工作负载路由到本地运行的开源权重模型,包括在 HPE Private Cloud AI 上运行的模型。结果:token 成本降低了 30% 到 50%。

这就是混合的意义所在。借助 HPE Private Cloud AI,拥有自己的推理能力并不意味着放弃前沿模型。在你拥有的容量上运行大量工作,并让网关发送最难的任务。

数据还显示,驱动支出的是使用量,而非授权人数。前 5% 的用户产生了大部分消耗,而同一许可证下使用最多的用户的使用量大约是最少用户的 450 倍。如果重度用户从少数人增长到劳动力的一半,在人数不变的情况下,月度支出可能增加约 4.4 倍。你的用户构成会有所不同,这正是你需要对其进行衡量的原因。

HPE 追踪两项指标,并建议客户也这样做。第一,追踪每活跃开发者成本,因为对所有许可证取平均值会掩盖驱动支出的重度用户。第二,追踪每合并拉取请求成本,因为它将 AI 支出与交付的软件联系起来。

在改变基础设施之前,先为这两项成本建立基线。然后在自有容量上运行一个完整的开发周期。如果随着使用量增长,这两项指标都没有改善,那么你当前的模式可能仍是更好的选择。

为采用而构建,而非为配给而构建

自有容量并不适合所有人。使用量低或不可预测时,API 更有利,因为不会有资本被闲置的基础设施占用。当持续需求让容量保持忙碌时,自有才划算。大多数企业将采用混合模式:前沿 API 用于要求高或间歇性的工作,自有容量用于可重复的批量工作。受管控的网关决定什么可以离开企业,因此你既能获得前沿模型,又不必放弃对代码的主权。

随着开发者越来越依赖编码智能体,使用量将持续上升。真正的选择在于,这种增长是体现为更大的可变成本账单,还是体现为在你拥有的容量上交付更多软件。引领 AI 辅助开发的公司不会为了控制成本而限制采用。它们将构建一种运营模式,让更多 AI 使用改善经济效益,而不是削弱经济效益。

要了解更多关于 HPE Private Cloud AI 的信息,请访问 HPE。

本内容由 HPE 制作。并非由 MIT Technology Review 的编辑人员撰写。

来源:MIT Technology Review · AI · technologyreview.com