本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Stop counting tokens, start counting what ships

SponsoredProvided byHPE When a developer gives an AI agent a coding task, the agent does more than answer once. It plans, generates code, runs tests, and repeats the process to correct errors. A single task can use 10 to 50 times more tokens than a basic chat prompt. The more useful the agent becomes, the more calls it makes. With per-token pricing, the workflows creating the most value can also become the most expensive.

由 HPE 赞助提供。当开发人员向 AI 智能体下达编码任务时，智能体所做的不仅仅是回答一次。它会进行规划、生成代码、运行测试，并重复该过程以纠正错误。单个任务使用的 Token 数量可能是基础聊天提示词的 10 到 50 倍。智能体越有用，它调用的次数就越多。在按 Token 定价的模式下，创造价值最高的工作流往往也可能变得最昂贵。

The financial pressure is already visible. Uber reportedly exhausted its entire 2026 AI budget by April after expanding its use of Claude Code. GitHub Copilot moved from flat-rate pricing to metered credits. Gartner predicts that AI coding token costs will surpass average developer salaries by 2028. The natural response is rationing usage caps, seat limits, and approvals before developers launch agents. But blanket limits can restrict the workflows delivering value. They also optimize the wrong number. Cost per token measures consumption, not results. Some spending reflects waste, including retries and runaway loops. Some represents the work of shipping software. A meter cannot distinguish them, and neither can a spending cap.

财务压力已经显现。据报道，Uber 在扩大使用 Claude Code 后，到 4 月份就耗尽了其 2026 年全年的 AI 预算。GitHub Copilot 已从固定费率定价转向计量积分制。Gartner 预测，到 2028 年，AI 编码的 Token 成本将超过开发人员的平均工资。自然的反应是进行配给，即在开发人员启动智能体之前设置使用上限、席位限制和审批流程。但一刀切的限制可能会阻碍那些能够创造价值的工作流。它们优化的指标也是错误的。单位 Token 成本衡量的是消耗，而非结果。部分支出反映的是浪费，包括重试和失控的循环；而另一部分则代表了交付软件的工作量。计量器无法区分两者，支出上限也做不到。

Measure the software that ships A better measure is cost per merged pull request: total AI-assisted development cost divided by the number of changes that pass review and are merged. Track rework and defects alongside it so cheaper changes do not conceal lower quality. If that cost falls as AI usage rises, without compromising quality, developers are converting more consumption into useful software. The question is not how many tokens they use, but how much finished work the investment produces. Improving that equation requires two changes: reserve expensive inference for tasks that need it, and lower the cost of routine work.

衡量交付的软件。一个更好的衡量指标是“每个合并拉取请求（PR）的成本”：即 AI 辅助开发的总成本除以通过审查并合并的变更数量。同时跟踪返工和缺陷，以确保更便宜的变更不会掩盖较低的质量。如果该成本随着 AI 使用量的增加而下降，且不影响质量，那么开发人员就是在将更多的消耗转化为有用的软件。问题不在于他们使用了多少 Token，而在于这项投资产生了多少成品工作。改善这一等式需要两个改变：将昂贵的推理留给真正需要的任务，并降低日常工作的成本。

Match the model to the task Agentic coding does not require the most powerful model at every step. Use a frontier model, or an on-premises flagship when policy requires it, for difficult planning and novel reasoning. Route suitable work, including code generation, test creation, and repeated refactoring, to open-weight models you operate yourself. A gateway can route requests according to task complexity, data sensitivity, cost, and latency. This reserves premium inference for the moments that justify it rather than applying premium pricing to an entire workflow. Meter the exception, not the workload. Open-weight models make this division increasingly practical.

将模型与任务匹配。智能体编码并不需要在每一步都使用最强大的模型。对于困难的规划和新颖的推理，请使用前沿模型，或者在政策要求时使用本地部署的旗舰模型。将合适的工作（包括代码生成、测试创建和重复重构）路由到您自己运营的开放权重模型。网关可以根据任务复杂度、数据敏感性、成本和延迟来路由请求。这使得高级推理仅在必要时使用，而不是将高昂的定价应用于整个工作流。要计量的是例外情况，而不是工作负载。开放权重模型使得这种划分变得越来越可行。

Software-engineering benchmarks show that leading open-weight models can approach frontier performance on some tasks. That does not establish equivalence across every repository or workflow. Evaluate candidates against your own code, tests, and acceptance criteria before assigning production work. Change the economics of repeated use Next, decide who owns the capacity. With rented inference, every call adds to the bill. With owned capacity, most of the cost is committed upfront, so each additional call gets cheaper as usage grows. The economics are simple: per-token pricing makes heavy use more expensive, while owned capacity becomes more efficient as teams use it more.

软件工程基准测试表明，领先的开放权重模型在某些任务上可以接近前沿模型的性能。但这并不意味着它们在每个代码库或工作流中都等同。在分配生产任务之前，请根据您自己的代码、测试和验收标准来评估候选模型。改变重复使用的经济性。接下来，决定由谁拥有算力。使用租赁的推理服务，每次调用都会增加账单。而拥有算力意味着大部分成本是预先投入的，因此随着使用量的增加，每次调用的成本会变得更低。经济账很简单：按 Token 定价使得高频使用变得更贵，而拥有算力则随着团队使用量的增加而变得更高效。

Ownership is not free, though. Power, operations, maintenance, and depreciation all must be considered. The number that matters is the fully loaded cost per merged pull request. Owned capacity also delivers a type of value that never appears on an invoice: control over sensitive code. When code generation and testing run on-premises, proprietary code stays inside the enterprise. Only approved planning prompts and governed exceptions go to external models, through a gateway the organization controls. That opens the sensitive repositories where security usually stalls adoption, and where the biggest gains are waiting.

不过，拥有算力并非没有成本。电力、运营、维护和折旧都必须考虑在内。真正重要的数字是“每个合并拉取请求的完全分摊成本”。拥有算力还提供了一种永远不会出现在发票上的价值：对敏感代码的控制。当代码生成和测试在本地运行时，专有代码会保留在企业内部。只有经过批准的规划提示词和受控的例外情况才会通过组织控制的网关发送到外部模型。这解锁了那些通常因安全问题而阻碍采用的敏感代码库，而那里正是最大收益所在。

Test the operating model At HPE, a hybrid AI platform routes routine workloads from more than 150 internal applications to open-weight models running on premises, including on HPE Private Cloud AI. The result: token costs down 30 to 50%. That is the point of hybrid. With HPE Private Cloud AI, owning your inference does not mean giving up frontier models. Run the volume on capacity you own and let a gateway send the hardest work. Data also shows that usage, not licensed headcount, drives spend. The top 5% of users generated most of the consumption, and the heaviest used roughly 450 times more than the lightest on the same license.

测试运营模式。在 HPE，一个混合 AI 平台将来自 150 多个内部应用程序的日常工作负载路由到本地运行的开放权重模型，包括在 HPE Private Cloud AI 上运行的模型。结果是：Token 成本降低了 30% 到 50%。这就是混合模式的意义所在。有了 HPE Private Cloud AI，拥有自己的推理能力并不意味着放弃前沿模型。在您拥有的算力上运行大批量任务，并让网关处理最困难的工作。数据还显示，驱动支出的不是授权人数，而是使用量。前 5% 的用户产生了大部分消耗，而在同一授权下，最重度的用户的使用量大约是最轻度用户的 450 倍。

If power users grow from a small minority to half the workforce, monthly spend can rise about 4.4 times with flat headcount. Your mix will differ, which is exactly why you need to measure it. HPE tracks two metrics and recommends customers do the same. First, it tracks cost per active developer, because averaging across all licenses hides the power users driving spend. Second, it tracks cost per merged pull request, because it connects AI spending to software that ships. Baseline both costs before changing infrastructure. Then run a complete development cycle on owned capacity. If both metrics do not improve as usage grows, your current model may still be the better choice.

如果超级用户从少数群体增长到员工总数的一半，那么在授权人数不变的情况下，月度支出可能会增加约 4.4 倍。您的组合情况会有所不同，这正是您需要进行衡量的原因。HPE 跟踪两个指标，并建议客户也这样做。首先，跟踪“每个活跃开发人员的成本”，因为在所有授权中取平均值会掩盖驱动支出的超级用户。其次，跟踪“每个合并拉取请求的成本”，因为它将 AI 支出与交付的软件联系起来。在更改基础设施之前，先确定这两个成本的基准。然后在拥有的算力上运行一个完整的开发周期。如果随着使用量的增加，这两个指标都没有改善，那么您当前的模式可能仍然是更好的选择。

Build for adoption, not rationing Owned capacity is not for everyone. Low or unpredictable usage favors APIs, with no capital tied up in idle infrastructure. Ownership pays off when sustained demand keeps it busy. Most enterprises will run hybrid: frontier APIs for demanding or intermittent work, owned capacity for repeatable volume. A governed gateway decides what leaves the building, so you get frontier models without giving up sovereignty over your code. As developers lean harder on coding agents, usage will keep rising. The real choice is whether that growth shows up as a bigger variable-cost bill or as more software shipped on capacity you own.

为采用而构建，而非配给。拥有算力并不适合所有人。低频或不可预测的使用量更适合 API，因为这样不会有资本被闲置的基础设施占用。当持续的需求使其保持忙碌时，拥有算力才会有回报。大多数企业将采用混合模式：将前沿 API 用于高要求或间歇性的工作，将拥有的算力用于可重复的大批量工作。受控的网关决定了哪些数据可以离开企业，因此您既能获得前沿模型，又不会放弃对代码的主权。随着开发人员越来越依赖编码智能体，使用量将持续上升。真正的选择在于，这种增长是表现为更庞大的可变成本账单，还是表现为在您拥有的算力上交付了更多的软件。

The companies that lead AI-assisted development will not ration adoption to control costs. They will build an operating model where more AI use improves the economics instead of undermining them. To learn more about HPE Private Cloud AI, please visi

那些在 AI 辅助开发方面处于领先地位的公司，不会通过限制采用来控制成本。他们将建立一种运营模式，在这种模式下，更多的 AI 使用会改善而非削弱经济效益。欲了解更多关于 HPE Private Cloud AI 的信息，请访问。