别再数 token 了,该数交付了多少:HPE 谈 AI 编程成本该怎么算
Stop counting tokens, start counting what ships
HPE 提出用“每个已合并 PR 的成本”替代 token 消耗量来衡量 AI 编程投入,并称其混合 AI 平台把 150 多个内部应用的常规负载路由到本地开源权重模型后,token 成本下降 30% 至 50%。文章指出单个智能体编程任务消耗的 token 可达普通对话提示词的 10 至 50 倍,Uber 据称在 4 月就用完了 2026 年全年 AI 预算,GitHub Copilot 也已从固定费率转向按量计费。HPE 建议把高难度规划留给前沿模型、把代码生成与测试等重复工作交给自建开源权重模型,并同时跟踪每位活跃开发者成本和每个已合并 PR 成本。
正文 · 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 制作,并非由《麻省理工科技评论》编辑团队撰写。
在 AlphaGo 对阵围棋冠军李世石十年之后,当今的 AI 仍未真正利用上让那场胜利成为可能的机制。