76 篇博文 含有标签「cost-optimization」

你的基础设施账单上的每一项其他支出都经过了审核。有人为数据库集群提交了采购订单。有人在购买可观测性 SaaS 之前清点了席位。有人在团队将 Kubernetes 占用空间翻倍之前进行了容量审查。然后，模型 API 出现了，而这一切都没有发生。

一名工程师将他们的 API 密钥添加到了配置文件中。他们写了一个 create() 调用，看起来与代码库中的其他函数调用完全一样。它上线了。而财务部门第一次得知这个功能作为一个成本中心存在，是在月度发票上的一个差异项——一个没人预测过、没人批准过、也没人能立即解释的数字。

这就是 AI 的 FinOps 鸿沟，它不是一个监控问题。它是一个披着监控外衣的治理问题。即使你拥有完美的仪表板，依然会感到惊讶，因为早在支出出现在图表上之前，它对你的审批流程就是不可见的。

大多数团队购买推理资源的方式，就像他们的前辈在 2010 年购买 EC2 时一样：全部按需（on-demand），按 token 计费，且在两个维度上同时让人措手不及。账单是一个意外。速率限制（rate limit）是另一个——在发布的中途出现的 429 错误，就在你从未预留的按需资源池被其他同样选择支付零售价的人争抢时。然后有人打开定价页面，发现供应商一直都在悄悄销售预留容量：预置吞吐量（provisioned throughput）、承诺使用折扣（committed-use discounts）、按单位小时计费而不是按百万 token 计费。云计算行业花了十年时间才内化的预留实例决策，现在就摆在 token 面前，但几乎没有人移植这一套玩法。

这种现象的原因并非无知。而是你为计算资源学习的预留实例数学模型无法直接迁移，而它失效的方式恰恰是在惩罚那种天真的承诺。预留一个 EC2 实例是在赌你一年后仍然需要那种实例类型。预留一块 token 吞吐量则是在赌你一年后仍然需要 那个模型——而模型的生命周期是以月计算的，而不是以十年计算。承诺的结构很熟悉，但你所承诺的对象却并非如此。

你的云账单可以具体到标签，告诉你上个月一个被遗忘的 S3 存储桶花费了 14,000 美元。但如果你问 LLM 账单同样的问题——到底是哪个功能烧掉了价值 40,000 美元的 token——大多数公司的真实反应只能是耸耸肩。供应商的发票上每个模型、每个 API 密钥只有一行记录，而三个团队共享这个密钥，财务报表中的 “AI 成本” 行则是根据人头、感觉，或者在上次规划周期中抱怨最少的人来分摊的。

这不仅仅是一个小的簿记烦恼。当没人能说出每一美元的 token 支出背后具体对应哪个功能时，会出现两种失败模式。低成本的功能被限制了，因为它们与昂贵的功能共用一个预算额度。而真正浪费的功能却永远存在，因为它们的成本是隐形的——被分摊到了共享的密钥、共享的缓存以及服务于六个不同产品界面的共享智能体（agent）循环中。

FinOps 基金会 2026 年的调查发现，目前 98% 的组织都在积极管理 AI 支出，而一年前这一比例为 63%，再前一年仅为 31%——这是该基金会有记录以来最快的采用曲线。每个人突然都在做 “AI 领域的 FinOps”。但很少有人注意到，云 FinOps 的核心原语——资源标签（resource tag）——在 token 的世界里并不存在，而且现代 LLM 使用的三个特定机制正活跃地破坏着成本归因。

打开你的 Token 仪表板，针对其中的每一个工作负载问一个问题：是否有真人在等待这个响应？对于大多数在生产环境中运行智能体（Agent）的团队来说，诚实的回答是：至少有一半以上的账单并非如此。评估套件（Eval suites）、向量回填（embedding backfills）、每日报告生成、批量分类、隔夜代码迁移、昨日工单总结——这些任务都没有用户在盯着进度条。然而，几乎所有这些任务都流经交互式端点，以全额价格支付，并与那些真正对延迟敏感的请求竞争同样的容量。

每个主流供应商都会以一半的成本运行这些可延迟的工作。OpenAI 的 Batch API、Anthropic 的 Message Batches 以及 Gemini 的 batch 模式都为异步作业提供统一的 50% 折扣，以换取 24 小时的完成窗口。这种折扣不需要谈判，不需要承诺消费，也不需要工程上的壮举。它只要求你在架构中承认，某些工作是可以等待的——而大多数团队从未做出过这种让步，因为没有人将“延迟交付”作为一个设计决策。

我们以前看过这类戏码。多年来，抢占式实例（Spot instances）为云计算提供了 60–90% 的折扣，但大多数团队仍将所有业务保留在“按需（on-demand）”模式下。这并非因为节省的费用不真实，而是因为使用它们被迫面对一个令人不安的问题：我们哪些工作负载可以容忍中断？回答了这一问题的团队构建了检查点（checkpointing），并将计算账单削减了一半以上。没回答的团队则继续支付“凡事皆紧急”税。批处理层级是同样的岔路口，只不过坐标轴从“中断容忍度”变成了“延迟容忍度”——而且智能体工作负载每项任务消耗的 Token 是聊天机器人的 5 到 30 倍，这使得不作选择的代价要昂贵得多。

每一个主流模型提供商都在以半价向你出售同样的 Token。OpenAI、Anthropic 和 Google 都提供 Batch API，其收费仅为同步请求费率的 50% —— 模型相同、提示词相同、输出也相同 —— 唯一需要你做出的让步是：接受 24 小时的完成窗口，而不是在几秒钟内获得答案。对于一个每月在推理上花费 50,000 美元的团队来说，这意味着有 25,000 美元摆在桌面上，无需更改任何一行提示词即可领取。

大多数团队从未领取过这笔钱。并不是因为折扣被隐藏了 —— 它就在每一个定价页面上 —— 而是因为领取它需要回答一个组织内从未有人问过的问题：我们的推理调用中，哪些真正需要立即得到答案？ 事实证明，这是一个架构问题，而大多数公司的诚实回答是：“我们从未对它们进行过分类，所以默认情况下所有任务都运行在交互式通道中。” Batch 折扣并不是一个定价脚注。它是一场测试，考验你的系统是否了解自身的延迟需求 —— 而大多数系统都未能通过测试。

最近我交流的一个团队花了三个工程师周的时间，将平均 Prompt 从 4,000 Token 削减到了 2,600 Token。他们以此为荣 —— 纯 35% 的降幅，实打实的数据，幻灯片里漂亮的图表。然后有人反向算了一笔账：这笔节省每月大约为 1,800 美元。而他们投入的三个工程师周，折算成全额薪酬成本大约是 25,000 美元。按照这个月度消耗率，这笔优化大约需要 14 个月才能回本 —— 这还是假设 Prompt 永远不变、模型永远不降价，且那些工程师没有更有价值的东西可做的情况下。

然而，这些假设一个都没成立。下个季度 Prompt 改了两次。他们使用的模型本身就降价了 40%。而那些工程师那个月没能发布的特性，恰恰是最大客户一直询问的功能。

大多数财务团队都把第一张 LLM 账单放错了地方。它出现在实验阶段，当时只有少数工程师正在使用 API 密钥进行原型设计，它看起来确实就是当时的样子：研发支出 (R&D)。每月花费几千美元来弄清楚这项技术是否可行。因此，无论是在认知上还是在实际操作中，它都被归入了研发支出，没有人对此深究。

随后，功能上线，使用量攀升，第一季度还是可以忽略不计的误差项，到了第四季度就变成了云服务账单中增长最快的成本。问题从来不在于金额大小。问题在于成本已经悄然改变了类别——从对构建某项功能的固定投入，变成了服务每一位用户的变动成本——而思维模型却没有随之转变。

这种分类错误是目前 AI 产品中最昂贵的会计错误，而且它本质上甚至不是会计错误，而是预测错误。

一个只被写入却从未被读取的缓存算不上缓存。它只是一个增加了额外延迟、按 KB 计费的日志系统。而这种失效模式最残酷的版本是，从每个角度看缓存都是健康的：set 调用成功，get 调用返回迅速，键（key）格式正确，值（value）有效，TTL 设置合理。唯一的问题是，没有任何一次 get 调用能找到之前 set 调用写入的键，因为键中的一个字段在每次计算时都会发生变化。

这是一个关于调试过程的故事：为了“能分辨出我正在看的是哪条缓存记录”，一位工程师在缓存键中添加了一个时间戳。结果，在没人察觉的两个星期里，系统悄悄地为每场对话多支付了 14 次额外的 LLM 调用费用。

你的事故时间线显示没有部署。你的代码没有变。你的流量组合没有变。你的提示词也没有变。然而，你的 p99 输出长度在一周内翻了一番，下游渲染层开始截断响应，而且在流量没有请求更长答案的情况下，你的输出 Token 账单增长了 38%。这种变化是真实的，回归是可以衡量的，但你的版本控制系统中没有记录——因为发生变动的值是你的代码从未发送过的。

供应商提高了一个隐式默认值。发布说明将其归类为“改进的长内容表现”。有问题的参数是 max_tokens，你的应用程序从第一天起就忽略了它，因为文档中记录的默认值很慷慨，而且你的输出很少接近这个值。默认值从 4096 移动到 8192，以适应供应商新模型中更长的推理过程。无论你是否想要，你的应用程序都获得了新的默认值，因为缺少参数本身就是一种配置选择——而供应商拥有更改其背后值的权利。

这种故障模式下，供应商侧的“无操作”（no-op）发布会作为行为变化、成本变化和用户体验（UX）变化同时在你的系统中传播，而你团队唯一的诊断信号是月底寄来的账单。

一个平台团队发布了一次提示词重构，将平均响应成本降低了 32%。这个改动非常简单：剥离了 “解释你的推理过程” 前导语，要求模型仅返回 JSON 对象，并删除了从模型文本中解析推理逻辑的后处理步骤。仪表板变绿了。季度回顾中的单位经济效益页面从黄色变为了金色。平台团队中没有人想到要咨询风险团队，因为这个改动没有触及客户收到的任何答案。

两个季度后，一位受监管客户的审计员要求提供一份六个月前的贷款拒绝信的决策理由。团队调取了追踪记录。输入在那，输出也在那。推理过程消失了 —— 不是因为有人删除了它，而是因为它在重构发布的那天起就停止生成了。客户的合规计划一直运行在推理逻辑存储在追踪记录库中的假设之上；平台团队一直运行在推理逻辑不是任何人的问题，因为面向客户的答案没有变化的假设之上。孤立来看，这两个假设都是正确的。但结合在一起，它们让客户面临了一项监管违规审计发现，并让平台团队失去了一份合同续签。

产品团队发布了个性化功能。智能体（Agent）现在会直呼用户姓名，根据用户的偏好调整回答长度，了解用户在医疗行业工作，并尊重用户在提及日期时所处的时区。用户满意度的提升是真实且可衡量的——A/B 测试显示点赞率提升了四个百分点，随后功能全量上线。三周后，财务部门指出推理成本大约翻了三倍，而 AI 团队中没人能立即解释原因。

解释就在系统提示词（System Prompt）构建器中一行被埋没的代码修改里。每个用户的上下文——姓名、偏好的回答长度、行业、时区——都被添加到了系统提示词的开头，以便模型在每一轮对话中都能看到。这使得从第一个 Token 开始，每个用户的 Prompt 都是独一无二的。你的供应商提供的 Prompt 缓存——原本能以标准价格的十分之一服务大约 90% 的输入 Token——失效了。延迟几乎没有波动，所以性能仪表盘（Performance Dashboard）依然显示绿色。直到月底，计费仪表盘才反映出这一情况。

你的规划器输出了五次工具调用。从纸面上看，这是一个干净的解决方案：lookup_user、search_documents、call_external_api、spawn_sub_agent、request_human_approval。轨迹优雅、逻辑自洽，智能体最终也会给出正确答案。可在生产环境中，这五个步骤分别耗时 12 毫秒、800 毫秒、4 秒、2 分钟和 6 小时。规划器从未察觉，它这五步计划在成本上跨越了九个数量级。


这并不是幻觉。模型选对了工具，顺序也合理。它做不到的——工具模式根本没给它做这件事的途径——是去推理：计划的最后一步在性质上和第一步完全不同。在规划器眼里，工具就是工具，计划图中每个节点的权重都是 1。