别再数词元,开始数交付成果
摘要
《麻省理工科技评论》认为,团队应以每个已合并拉取请求的成本,而非每个词元的支出,来衡量 AI 开发成本,并建议采用模型路由和自有的开放权重模型算力,以遏制智能体编程不断攀升的成本。
<p class="wp-block-paragraph">当开发者向 AI 智能体布置编程任务时,智能体所做的远不止一次回答。它会制定计划、生成代码、运行测试,并重复这一过程以纠正错误。单个任务消耗的 token 数量可能是普通聊天提示的 10 到 50 倍。智能体越有用,发起的调用就越多。在按 token 计费的模式下,创造价值最多的工作流也可能成为成本最高的工作流。</p>
<p class="wp-block-paragraph">财务压力已经显现。据报道,Uber 在扩大 Claude Code 的使用后,到 4 月就耗尽了 2026 年全年的 AI 预算。GitHub Copilot 从固定费率定价转向按量计费的额度模式。<a href="https://www.gartner.com/en/newsroom/press-releases/2026-06-24-gartner-predicts-ai-coding-costs-will-surpass-average-developer-salary-by-2028-as-token-consumption-surges" target="_blank" rel="noopener">Gartner 预测</a>,到 2028 年,AI 编程的 token 成本将超过开发者的平均薪资。</p>
<figure class="wp-block-image size-large"><img fetchpriority="high" decoding="async" height="1688" width="3000" src="https://wp.technologyreview.com/wp-content/uploads/2026/10/iStock-2297734847.jpg?w=840" alt="" class="wp-image-1147870" srcset="https://wp.technologyreview.com/wp-content/uploads/2026/10/iStock-2297734847.jpg 3840w, https://wp.technologyreview.com/wp-content/uploads/2026/10/iStock-2297734847.jpg?resize=300,169 300w, https://wp.technologyreview.com/wp-content/uploads/2026/10/iStock-2297734847.jpg?resize=768,432 768w, https://wp.technologyreview.com/wp-content/uploads/2026/10/iStock-2297734847.jpg?resize=1536,864 1536w, https://wp.technologyreview.com/wp-content/uploads/2026/10/iStock-2297734847.jpg?resize=2048,1152 2048w" sizes="(max-width: 3000px) 100vw, 3000px" /></figure>
<p class="wp-block-paragraph">最自然的应对方式是限制使用:设置用量上限、席位限制,并要求开发者在启动智能体前获得审批。但一刀切的限制可能会束缚那些正在创造价值的工作流。而且,这些措施优化的指标也不对。每 token 成本衡量的是消耗,而非成果。有些支出属于浪费,包括重试和失控循环;有些则是交付软件所需的工作。计量工具无法区分二者,支出上限同样不能。</p>
<h3 class="wp-block-heading"><strong>衡量实际交付的软件</strong></h3>
<p class="wp-block-paragraph">更好的衡量指标是每个已合并拉取请求的成本:将 AI 辅助开发的总成本除以通过审查并完成合并的变更数量。同时跟踪返工和缺陷,避免成本更低的变更掩盖质量下降的问题。</p>
<p class="wp-block-paragraph">如果随着 AI 使用量增长,这项成本在不牺牲质量的前提下下降,就说明开发者正在把更多消耗转化为有用的软件。关键不在于他们用了多少 token,而在于这笔投入产出了多少已完成的工作。</p>
<p class="wp-block-paragraph">要改善这一投入产出关系,需要做出两项改变:将昂贵的推理资源留给确实需要的任务,并降低日常工作的成本。</p>
<h3 class="wp-block-heading"><strong>让模型与任务相匹配</strong></h3>
<p class="wp-block-paragraph">智能体编程并不需要每一步都使用最强大的模型。对于复杂规划和创新性推理,应使用前沿模型,或在政策要求时使用本地部署的旗舰模型。将适合的工作,包括代码生成、测试编写和反复重构,分配给自行运营的开放权重模型。</p>
<p class="wp-block-paragraph">网关可以根据任务复杂度、数据敏感性、成本和延迟来路由请求。这样就能将高端推理资源留给值得使用它的环节,而不是让整个工作流都承担高端定价。对例外情况按量计费,而非对全部工作负载按量计费。</p>
<p class="wp-block-paragraph">开放权重模型正让这种分工变得越来越可行。软件工程基准测试表明,领先的开放权重模型在某些任务上可以接近前沿模型的表现。但这并不意味着它们在每个代码仓库或工作流中都能达到同等水平。在将生产工作交给候选模型之前,应使用自己的代码、测试和验收标准对其进行评估。</p>
<h3 class="wp-block-heading"><strong>改变重复使用的成本结构</strong></h3>
<p class="wp-block-paragraph">接下来,决定由谁拥有算力。使用租用的推理服务时,每次调用都会增加账单。使用自有算力时,大部分成本已在前期投入,因此随着使用量增长,每次新增调用的成本会越来越低。</p>
<p class="wp-block-paragraph">其中的经济逻辑很简单:按 token 计费会让高频使用变得更昂贵,而自有算力则会随着团队使用量增加而提高成本效益。不过,拥有算力也并非没有成本。电力、运营、维护和折旧都必须纳入考量。真正重要的指标是包含全部成本的每个已合并拉取请求成本。</p>
<p class="wp-block-paragraph">自有算力还带来一种永远不会体现在发票上的价值:对敏感代码的控制权。当代码生成和测试在本地运行时,专有代码就能留在企业内部。只有获准的规划提示和受管控的例外请求,才会通过组织控制的网关发送给外部模型。这让那些通常因安全问题而难以采用 AI 的敏感代码仓库也能使用 AI,而最大的收益往往就在这些仓库中。</p>
<h3 class="wp-block-heading"><strong>检验运营模式</strong></h3>
<p class="wp-block-paragraph">在 HPE,一个混合 AI 平台将来自 150 多个内部应用的常规工作负载,路由至本地运行的开放权重模型,其中包括在 HPE Private Cloud AI 上运行的模型。结果是:token 成本降低了 30% 到 50%。</p>
<p class="wp-block-paragraph">这正是混合模式的意义所在。借助 HPE Private Cloud AI,自行掌控推理算力并不意味着放弃前沿模型。在自有算力上运行大批量工作,并让网关将最困难的工作发送出去。</p>
<p class="wp-block-paragraph">数据还表明,推动支出增长的是使用量,而非获得许可的人数。使用量最高的 5% 用户产生了大部分消耗,在相同许可下,用量最高者的使用量约为最低者的 450 倍。如果高频用户从少数增长到员工总数的一半,即使员工人数不变,月度支出也可能增至约 4.4 倍。你的用户构成会有所不同,这也正是需要实际衡量的原因。</p>
<p class="wp-block-paragraph">HPE 跟踪两项指标,并建议客户也这样做。第一,跟踪每位活跃开发者的成本,因为按全部许可数计算平均值,会掩盖推动支出增长的高频用户。第二,跟踪每个已合并拉取请求的成本,因为它将 AI 支出与实际交付的软件联系起来。</p>
<p class="wp-block-paragraph">在改变基础设施之前,先确定这两项成本的基准值。然后在自有算力上运行一个完整的开发周期。如果随着使用量增长,两项指标未能同时改善,那么当前模式可能仍是更好的选择。</p>
<h3 class="wp-block-heading"><strong>为普及应用而构建,而非限制用量</strong></h3>
<p class="wp-block-paragraph">自有算力并不适合所有人。使用量较低或难以预测时,API 更有优势,因为无需将资金投入闲置的基础设施。只有持续的需求让算力得到充分利用,拥有算力才会带来回报。大多数企业将采用混合模式:用前沿模型 API 处理要求高或间歇性的工作,用自有算力处理可重复的大批量任务。受管控的网关决定哪些内容可以离开企业内部,让你既能使用前沿模型,又能保有代码主权。</p>
<p class="wp-block-paragraph">随着开发者越来越依赖编程智能体,使用量将持续上升。真正的选择在于:这种增长是体现为更高的可变成本账单,还是体现为利用自有算力交付更多软件。引领 AI 辅助开发的企业不会通过限制采用来控制成本。它们将构建一种运营模式,让更多的 AI 使用改善经济效益,而不是削弱它。</p>
<p class="wp-block-paragraph"></p>
<p class="wp-block-paragraph"><em>如需进一步了解 HPE Private Cloud AI,请访问 <a href="https://www.hpe.com/us/en/products/private-cloud/pcai.html?utm_campaign=FY26_AI_GB_GD_AMS_NA_Speed_time_to_AI_Value-NVIDIA&utm_medium=PS&utm_source=BNG&utm_content=521223665&plid=PSF26-00003328&ef_id=5c0f993b7a99180be139f3edca721c4c:G:s&s_kwcid=AL!13472!10!81157839054491!!!!81158075081756!!605741192!1298524459994371&msclkid=5c0f993b7a99180be139f3edca721c4c" target="_blank" rel="noopener">HPE</a>。</em></p>
<p class="wp-block-paragraph"><em>本内容由 HPE 制作,并非由《麻省理工科技评论》编辑团队撰写。</em></p>
<p class="wp-block-paragraph"></p>
查看缓存全文
缓存时间: 2026/11/02 15:21
# 别再计算 token,开始衡量交付成果
来源:https://www.technologyreview.com/2026/11/02/1147702/stop-counting-tokens-start-counting-what-ships
当开发者向 AI 智能体分配编码任务时,智能体所做的不只是回答一次问题。它会制定计划、生成代码、运行测试,并反复执行这一过程来纠正错误。单个任务消耗的 token 数量可能是普通聊天提示的 10 到 50 倍。智能体越有用,发起的调用就越多。在按 token 计费的模式下,创造价值最多的工作流也可能变得最昂贵。
财务压力已经显现。据报道,优步扩大使用 Claude Code 后,到 4 月就耗尽了 2026 年全年的 AI 预算。GitHub Copilot 从固定费率转向按量计费的点数制。Gartner 预测(https://www.gartner.com/en/newsroom/press-releases/2026-06-24-gartner-predicts-ai-coding-costs-will-surpass-average-developer-salary-by-2028-as-token-consumption-surges),到 2028 年,AI 编码的 token 成本将超过开发者的平均薪资。
面对这种情况,人们自然会想到限制用量:设置使用上限、限制席位数量,以及要求开发者在启动智能体前获得审批。但一刀切的限制可能会约束那些真正创造价值的工作流。它们优化的指标也不对。每个 token 的成本衡量的是消耗,而非成果。有些支出属于浪费,包括重试和失控循环。有些则用于完成软件交付。计量表无法区分二者,支出上限也同样不能。
### **衡量交付的软件**
更好的指标是每个已合并拉取请求的成本:将 AI 辅助开发的总成本除以通过审查并完成合并的变更数量。同时跟踪返工和缺陷,避免成本更低的变更掩盖了质量下降。
如果随着 AI 使用量增加,这项成本不断下降,同时质量不受影响,就说明开发者正将更多消耗转化为有用的软件。问题不在于他们使用了多少 token,而在于这笔投入带来了多少已完成的工作。
要改善这一投入产出关系,需要做出两项改变:将昂贵的推理资源留给真正需要它的任务,并降低常规工作的成本。
### **让模型与任务相匹配**
智能体编码并不需要每一步都使用最强大的模型。对于复杂规划和创新性推理,应使用前沿模型;如果政策要求,则使用本地部署的旗舰模型。将适合的工作,包括代码生成、测试编写和重复性重构,交给自行运营的开放权重模型。
网关可以根据任务复杂度、数据敏感性、成本和延迟来路由请求。这样就能把高价推理留给值得使用它的环节,而不是让整个工作流都按高价计费。对例外情况按量计费,而不是对全部工作负载如此计费。
开放权重模型使这种分工日益可行。软件工程基准测试表明,领先的开放权重模型在某些任务上的表现可以接近前沿模型。但这并不意味着它们在每个代码仓库或工作流中都具有同等能力。在分配生产工作之前,应使用自己的代码、测试和验收标准来评估候选模型。
### **改变重复使用的成本结构**
接下来,决定由谁拥有算力。使用租用的推理服务时,每次调用都会增加账单。拥有自有算力时,大部分成本已在前期投入,因此随着使用量增加,每次额外调用的成本会越来越低。
其中的经济逻辑很简单:按 token 计费会让高强度使用变得更昂贵,而自有算力则会随着团队使用量增加而变得更高效。不过,拥有算力也并非没有成本。电力、运营、维护和折旧都必须纳入考虑。真正重要的数字,是计入全部成本后每个已合并拉取请求的成本。
自有算力还带来一种从不体现在发票上的价值:对敏感代码的控制权。当代码生成和测试在本地运行时,专有代码始终留在企业内部。只有经过批准的规划提示和受治理的例外请求,才会通过组织控制的网关发送到外部模型。这让敏感代码仓库也能使用 AI——安全问题通常会阻碍这些仓库采用 AI,而最大的收益也往往蕴藏其中。
### **检验运营模式**
在 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(https://www.hpe.com/us/en/products/private-cloud/pcai.html?utm_campaign=FY26_AI_GB_GD_AMS_NA_Speed_time_to_AI_Value-NVIDIA&utm_medium=PS&utm_source=BNG&utm_content=521223665&plid=PSF26-00003328&ef_id=5c0f993b7a99180be139f3edca721c4c:G:s&s_kwcid=AL!13472!10!81157839054491!!!!81158075081756!!605741192!1298524459994371&msclkid=5c0f993b7a99180be139f3edca721c4c)。*
*本内容由 HPE 制作,并非由《麻省理工科技评论》编辑团队撰写。*
相似文章
@github: 使用更多令牌并不总是意味着更好的结果。👀 AI编码效率的真正衡量标准是代理是否……
GitHub Copilot 通过优化上下文管理而非令牌数量来提升AI编码效率,在减少不必要工作的同时,借助基准测试和实验验证的改进来确保任务质量。
令牌效率的时代,库的时代
本文反思了开发者对AI代码助手的迅速采用,以及随着AI使用变得更加企业化和计量化,对令牌效率和成本指标的关注日益突出。
编程代理是否变得昂贵,还是我们对成本的衡量方式有误?
本文质疑编程代理的真实成本是否包含隐藏的人力监督和调试,认为真正的价值应以可信输出来衡量,而非原始 token 消耗。
每个AI提示都需花费成本——这改变了一切
文章认为,AI的真正挑战不仅在于构建更智能的模型,更在于以规模化的方式降低成本效率,强调了减少token使用、提升速度以及优化基础设施的重要性。
@paulg: 尽管你按令牌为AI付费,但那不是推理的单位,因为随着模型改进,每个令牌能解决更多问题……
文章认为,虽然AI是按令牌付费的,但令牌并不是真正的推理单位,因为效率随着模型进步而提高,建议基于问题解决链创建一个新单位。