返回资讯中心
外部精选
行业深度
#趋势观察#Artificial intelligence#sponsored

AI编程代理token消耗激增,Uber提前耗尽2026年AI预算

来源标题:Stop counting tokens, start counting what ships

AI编程代理单任务token消耗量可达普通对话的10至50倍,按token计费模式下高价值工作流成本最高。Uber据报在4月已用完2026年全年AI预算,GitHub Copilot转向按量计费。Gartner预测到2028年AI编程token成本将超过开发者平均薪资。

MIT Technology ReviewAffan Syed2026/11/2 · 2 天前15 分钟阅读

以下正文由 AI 翻译自 MIT Technology Review(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

当开发者给 AI agent 一个编程任务时,agent 不只是回答一次。它会规划、生成代码、运行测试,并反复修正错误。一个任务消耗的 token 可能是一次基础对话提示的 10 到 50 倍。agent 越有用,调用就越多。在按 token 计价的模式下,创造最多价值的工作流也可能变得最昂贵。

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

自然的应对方式是配给——使用上限、席位限制、开发者启动 agent 前的审批。但一刀切的上限可能限制真正创造价值的工作流,而且它们优化的指标本身就错了。每 token 成本衡量的是消耗,不是结果。有些支出反映的是浪费,包括重试和失控循环;有些则代表着交付软件的工作。计量表区分不了两者,支出上限也区分不了。

衡量交付的软件

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

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

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

让模型匹配任务

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

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

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

改变重复使用的经济性

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

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

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

测试运营模式

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

这就是混合的意义。借助 HPE Private Cloud AI,拥有自己的推理并不意味着放弃前沿模型。把量大的一部分跑在你拥有的算力上,让网关发送最难的工作。

数据还显示,驱动支出的是使用量,而不是授权人数。前 5% 的用户产生了大部分消耗,同一许可证下最重的用户使用量大约是最轻用户的 450 倍。如果重度用户从少数人扩展到一半员工,在人数不变的情况下,月度支出可能上升约 4.4 倍。你的构成会有所不同,这正是你需要衡量它的原因。

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

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

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

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

随着开发者越来越依赖编程 agent,使用量将持续上升。真正的选择在于:这种增长是表现为更大的可变成本账单,还是表现为在自有算力上交付更多软件。引领 AI 辅助开发的公司不会通过配给采用来控制成本。它们会构建一种运营模式,让更多 AI 使用改善经济性,而不是削弱它。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →