8.0
热点
AI SCORE
技术实践2026-08-10 16:54
AI执行正确也可能亏损：生产环境的隐性成本陷阱
dev.to · AI#AI成本#LLM工程#生产环境
Editor brief · 编辑速览
分析AI工作流中模型调用次数、上下文大小、外部API重试等导致的成本溢出，即使执行结果正确也会造成财务损失。
想象一位客户在生产环境中触发了一个 AI 工作流。
请求到达授权层。
客户拥有有效的使用权限。
有足够的用量容量可用。
授权成功。
系统检索了所需的上下文，调用了模型，执行了一个外部工具，并产生了预期的结果。
用量被正确记录。
客户的余额被更新。
结果被交付。
可观测性显示绿色。
没有异常被抛出。
没有重复执行发生。
没有用量事件丢失。
后续也没有出现对账问题。
从工程角度看，系统行为完全符合设计预期。
现在从另一个角度看待同一执行。
该工作流需要多次模型调用。
上下文比平时更大。
一个外部 API 增加了另一个可变成本。
一个中间步骤失败并需要重试。
最终结果在客户可用之前需要额外处理。
这些都没有使执行变得不正确。
客户有权使用该工作流。
基础设施安全地处理了重试。
用量被精确计量。
客户按照产品规则被收费。
然而，在计算了产出有用结果的实际成本后，该执行产生的收入低于其消耗的成本。
这个执行在经济上就是不健康的。
这种区分很重要，因为生产系统通常被设计用来检测不正确的行为。
它们不太可能告诉你，即使技术行为正确，也会产生不健康的经济效益。
正确的执行不等于健康的执行
AI 基础设施在回答运行时正确性问题方面变得越来越好。
请求是否被授权？
客户是否有权使用该功能？
消费是否被原子性地应用？
重试是否被幂等地处理？
用量是否被正确记录？
应用状态是否与商业状态保持同步？
这些都是重要的问题。
答错这些问题可能导致重复消费、错误访问、收入损失或破坏客户体验。
但即使一个系统正确回答了所有这些问题，仍然有一个问题没有得到解决：
这次执行在经济上是否可持续？
考虑同一工作流的两个属性。
左边不能保证右边。
一个请求可能完全被授权，但仍然很昂贵。
用量可能被精确计量，但仍然代表一种不健康的消费模式。
一次重试可能完全幂等，但仍然给一个本已低利润率的工作流增加了合法成本。
一个客户可能完全按照计划被收费，但服务成本仍然超过该计划产生的收入。
这不是反对运行时正确性的论点。
运行时正确性是基础。
没有它，经济图景首先就不值得信赖。
但正确性告诉我们系统是否按照其规则行事。
它不一定告诉我们这些规则是否产生了健康的业务结果。
这是另一个问题。
而 AI 使得这种区分越来越难以忽视。
AI 让这个问题变得不同
传统软件一直都有基础设施成本。
数据库要花钱。
存储、带宽和第三方服务要花钱。
但对于许多 SaaS 产品来说，一个额外客户操作的边际成本相对较小。
用户打开另一个仪表盘。
创建另一个项目。
运行另一个数据库查询。
发送另一个内部请求。
基础设施执行了更多工作，但业务的 economics 通常不依赖于单个操作的盈利能力。
AI 改变了这种关系。
单个客户请求可能触发一串具有直接可衡量可变成本的操作序列：
输入和输出 token
而且这些成本很少是统一的。
同一功能在一次执行中可能很便宜，在另一次执行中可能相当昂贵。
一个简短的support问题可能只需要一次小模型的调用。
一个复杂的研究任务可能需要一个长的上下文窗口、多次模型调用、检索、多个工具和重复的推理步骤。
两者可能在产品中表现为同一功能。
在操作层面，它们不是相同的工作负载。
在经济层面，它们可能完全不同。
这在架构和业务经济效益之间创造了更紧密的联系。
模型选择很重要。
上下文大小很重要。
重试行为很重要。
工作流设计很重要。
工具选择很重要。
异常处理很重要。
不是因为每次昂贵的执行都一定是坏的。
如果一个昂贵的工作流创造了足够的价值或支持了足够的收入，它可以完全健康。
重要的一点是，执行现在有了一个不能总是从请求是否成功来推断的经济维度。
成功请求的成本不是全部成本
假设一个 AI 工作流最终成功完成。
最终执行消耗了 $0.18 的模型推理成本。
很容易把 $0.18 记为产生该结果的成本。
但生产工作流很少作为孤立的模型调用存在。
实际执行历史可能更像这样：
客户请求
↓
模型调用
↓
工具调用
↓
工具超时
↓
重试
↓
第二次模型调用
↓
外部 API
↓
人工修正
↓
成功结果
最终模型调用可能花费了 $0.18。
但 $0.18 不一定是该业务产出该结果所花费的成本。
失败的尝试仍然消耗了资源。
重试仍然消耗了资源。
工具调用可能产生了第三方费用。
外部 API 可能有其自身的使用成本。
人工干预可能引入了支持或运营开销。
因此，有用的经济单位并不总是最终成功的请求。
有时它是产生成功结果所需的整个路径。
这种区分很重要。
想象两次执行产生相同的客户可见结果：
执行 A
1 次模型调用
1 次成功的工具调用
无重试
总执行成本：$0.24
执行 B
2 次模型调用
1 次失败的工具调用
1 次重试
1 次成功的工具调用
总执行成本：$0.61
从产品角度看，两个工作流都成功了。
从计费角度看，客户可能支付了完全相同的金额。
从经济角度看，它们并不等价。
这就是执行层可见性变得有用的地方。
不是因为每个内部操作都需要成为一个财务指标。
那本身就会带来复杂性。
归因是有成本的。
instrumentation 是有成本的。
人工support可能难以精确分配。
共享基础设施成本很少能完美映射到单个请求。
目标不是在任意粒度上进行完美核算。
而是有足够的可见性来理解经济上有意义的差异来自哪里。
对于某些产品，模型和 API 成本可能提供足够的可见性。
对于其他产品，重试、工作流阶段或人工干预可能会实质性改变经济效益，值得被纳入。
适当的归因级别取决于产品。
但原则仍然成立：
成功的 AI 结果的成本可能包括产生它所需的每次有意义的尝试——而不仅仅是最终成功的那次请求。
这也改变了我们对失败的思考方式。
一次失败的执行并不总是在财务上中性的。
客户可能永远不会收到结果。
业务可能仍然需要为失败前完成的工作付费。
在足够大的规模下，这种差异变得重要。
一个技术正确的用量账本可以准确告诉你消耗了什么。
理解这些消耗是否创造了可持续的价值需要另一层分析。
客户盈利能力是一个分布问题
汇总指标有用，因为它们压缩了复杂性。
平均每客户收入。
平均基础设施成本。
在公司层面，这些数字可以提供一个令人安心的画面。
但平均值隐藏了分布。
而在 AI 产品中，这种分布可能非常重要。
考虑同一计划下的两个客户。
$200 / 月
两者使用相同的产品。
两者在收入仪表盘中显示为同等价值的账户。
然而，它们的底层 economics 可能看起来非常不同。
客户 A
短上下文
标准模型
可预测的工作流
很少重试
极少支持
每月服务成本：$38
客户 B
长上下文
昂贵的模型路由
多次工具调用
频繁重试
异常密集的工作流
经常需要支持干预
每月服务成本：$176
收入相同。
经济效益不同。
客户 A 贡献了可观的利润。
客户 B 可能仍然盈利，但只是勉强盈利。
添加一些不常见的执行路径、额外的支持请求或代价高昂的故障，这个账户就可能变得无利可图，而账单系统中却看不出任何问题。
客户支付了恰好应该支付的金额。
产品交付了恰好承诺的内容。
问题存在于收入与服务成本之间的关系中。
这就是为什么客户盈利能力本质上是一个分布问题。
一个投资组合在总体层面可能看起来很健康，却包含了经济特征截然不同的客户。
100 位客户
↓
平均毛利率：70%
↓
看起来很健康
但在平均值之下：
70 位客户 → 高利润率
20 位客户 → 中等利润率
8 位客户 → 低利润率
2 位客户 → 负利润率
70% 的平均值并没有错。
它仅仅是不完整。
它告诉了你投资组合的情况。
它没有告诉你利润从何而来。
我在《你的 AI 业务可以在利润率收缩的同时增长》中从商业角度探讨了这个问题，分析了为什么平均值会掩盖截然不同的客户和工作流经济状况。
当 AI 消耗量在不同账户之间差异显著时，这种区别变得尤为重要。
这也意味着高使用量不应该被自动视为问题。
高级用户可能产生大量成本，同时也产生大量收入、留存价值或战略重要性。
另一个客户可能消耗少得多的基础设施，但由于定价、支持开销或低效的工作流，经济上仍然缺乏吸引力。
仅凭使用量不能决定盈利能力。
收入、消耗量与服务成本之间的关系才能。
问题不在于哪些客户使用了最多的 AI。而在于服务他们的经济模型是否保持健康。
工作流盈利能力可能比模型成本更重要
客户级盈利能力提供了一个有用的视角。
但它仍然留下了一个重要问题未解答。
为什么一个客户的服务成本比另一个更高？
答案通常存在于更深入的一层。
在它们执行的工作流中。
AI 工程团队自然会监控以下基础设施指标：
这些指标是有价值的。
它们帮助团队了解系统的行为方式。
但它们不一定能解释这种行为是否创造了足够的价值来证明其成本是合理的。
考虑两个工作流。
工作流 A
成本：$1.40
结果：
一个合格的销售机会
工作流 B
成本：$0.22
结果：
一份很少被使用的内部摘要
工作流 B 更便宜。
这并不自动使其在经济上更好。
相关问题取决于产品试图完成什么。
客户通常不会购买 token、推理调用或工具执行作为最终目的。
他们购买的是结果。
一个已解决的支持工单。
一份已处理的文档。
一项已完成的研究任务。
一个成功完成的智能体工作流。
这表明还有另一个有用的分析单元：
每有效结果的成本。
不是仅仅衡量：
每次模型调用的成本
而是理解：
工作流总成本
↓
成功结果
↓
每有效结果的成本
假设一个支持自动化系统处理了 1,000 次对话。
基础设施指标显示：
AI 总成本：$420
这个数字很有用。
但想象一下，只有 600 次对话在没有升级的情况下得到解决。
查看成功的结果提供了额外的上下文：
$420 总执行成本
÷
600 次已解决的对话
=
每次已解决对话 $0.70
现在基础设施成本可以与更接近商业价值的东西进行比较。
这可能有助于回答以下问题：
自动化是否仍然比替代方案更便宜？
哪些工作流产生了最昂贵的成功结果？
重试是否显著改变了结果经济？
更换模型能否在不降低完成质量的情况下改善成本？
某些执行路径是否昂贵但在经济上仍然合理？
这个指标并非普遍适用。
定义"有效结果"可能很困难。
一些产品通过渐进的方式而非离散完成来创造价值。
研究助手可能影响了一项决策，但没有产生易于衡量的经济事件。
AI 编码工具可能节省了难以精确归因的开发人员时间。
多步骤智能体系统可能在多个工作流中产生价值。
归因可能很快变得比它提供的洞察更复杂。
因此，目标不是将每个 AI 产品强行套入单一的盈利能力指标。
架构上的教训更简单。
当基础设施成本可以与其产生的客户活动和业务结果联系起来时，它才变得更有用。
Token 成本告诉你模型消耗了什么。
工作流成本告诉你系统消耗了什么。
结果经济学开始告诉你这种消耗是否值得。
这些是不同层次的理解。
优化之前的可见性
一旦团队发现 AI 成本在不同客户和工作流之间差异显著，自然的反应是优化。
引入更严格的限制。
不同地路由请求。
这些都可能是合理的决定。
但它们假设了一个重要前提：
团队已经了解了经济问题实际在哪里。
不断上涨的模型账单告诉你支出增加了。
它没有告诉你是哪些客户导致了增长。
高 Token 计数告诉你系统处理了更多上下文。
它没有告诉你那个上下文是否产生了有价值的结果。
高重试率告诉你执行需要额外的尝试。
它没有告诉你那些重试是必要的、浪费的还是经济上显著的。
不断下降的毛利率告诉你业务的运营成本在增加。
它没有告诉你为什么。
在优化之前，团队越来越需要足够的可见性来连接系统的多个层级：
客户
↓
工作流
↓
执行
↓
重试 / 失败
↓
使用量
↓
成本
↓
结果
目标不是完美的归因。
完美的归因可能是不可能的或不必要地昂贵的。
目标是决策质量的可见性。
足够的信息来区分截然不同的情况。
例如，假设基础设施成本增加了 20%。
没有额外的上下文，明显的反应可能是将更多流量转移到更便宜的模型。
但更深入的可见性可能揭示，增长主要来自一个工作流经历重复工具故障。
模型不是问题所在。
或者，可能是一个客户群体因为新的产品行为开始使用明显更长的上下文。
定价模型可能需要关注。
或者，成本增加是因为客户正在完成更多高价值的工作流。
在这种情况下，更高的基础设施支出可能是完全健康的。
因此，同样的成本增加可能代表：
浪费
或
产品增长
或
定价错配
或
工作流低效
或
健康的高价值使用
仅凭数字无法告诉你属于哪一种。
这就是为什么没有可见性的优化基本上是猜测。
工程正在成为经济分析的一部分
一旦执行数据与客户和工作流联系起来，熟悉的工程信号开始获得第二层含义。
重试率不再仅仅是可靠性指标。
它也可能解释为什么一个工作流的成本高于预期。
计量差异不再仅仅是数据质量问题。
它可能扭曲公司对客户盈利能力的理解。
过期的授权不再仅仅是访问控制问题。
它可能允许在不再有效的商业条件下进行昂贵的执行。
对账缺口不再仅仅是操作不一致。
它可能阻止业务了解记录的收入和实际消耗是否描述了相同的现实。
这并不意味着工程团队应该变成财务团队。
也不意味着每个基础设施决策都应该被简化为利润率。
可靠性、延迟、质量和客户体验仍然独立地重要。
变化在于这些关注点不能再总是被孤立地评估。
在 AI 产品中，基础设施行为越来越多地影响业务的 经济行为。
考虑一个模型路由决策。
工程可能评估：
延迟
质量
可靠性
每次调用成本
这些都是有用的维度。
但一旦同一执行与工作流结果联系起来，另一个比较成为可能：
模型 A
每次调用成本更高
更好的完成率
更少的重试
更高的有效结果率
模型 B
每次调用成本更低
更低的完成率
更多的重试
更多的升级
更便宜的模型不一定更便宜的工作流。
更昂贵的 workflow 不一定是更差的商业决策。
答案取决于结果经济学。
这正是工程遥测开始变成商业智能的地方。
不是因为基础设施指标突然变成了财务指标。
而是因为连接它们提供了双方独立都无法获得的上下文。
到目前为止，我们一直在讨论 AI 系统的两个不同属性。
第一个是熟悉的。
系统应该正确运行。
请求应该被授权。
消费应该是原子的。
重试应该是安全的。
使用应该是准确的。
商业和应用状态应该保持一致。
运行时授权是这个问题的一部分。在《最昂贵的 AI 请求是你应该阻止的那个》中，我探讨了决定一个 AI 请求是否应该执行本身如何成为一个经济决策。
我们可以将其理解为运行时正确性。
系统是否正确执行了？
但整篇文章中的例子揭示了另一个问题。
假设所有这些保证都成立。
请求已被授权。
workflow 已正确执行。
重试是合法的。
使用被准确记录。
客户完全按照计划被收费。
但完成的结果仍然成本高于其经济所能支撑的。
运行时是正确的。
业务结果是不健康的。
推理这第二个属性的一个有用方式是经济正确性。
不是作为一个成熟的行业类别，而是作为一个心智模型。
这种技术上的正确执行是否也有经济意义？
这个区别看起来很简单：
两者都不能替代另一个。
建立在不正确的运行时数据上的经济分析不可信。
而没有经济可见性的技术正确执行仍然可能产生不健康的业务。
一个可持续的 AI 产品越来越需要理解两者。
正确的执行
+
经济理解
↓
更健康的 AI 经济
这并不意味着每个请求在执行前都需要实时盈利能力计算。
这通常是不切实际的、不必要的或基于不完整信息的。
有些经济性只能在 workflow 完成后才能理解。
有些成本稍后才到来。
有些结果难以量化。
有些客户应该理性地以更低的利润率服务，出于战略原因。
因此，经济正确性不是一个二元的运行时规则。
它是一种提问方式：系统的技术行为是否与业务的经济目标保持一致。
而提出这个问题需要连接传统上存在于不同系统中的信息。
理解 AI 经济所需的信号已经存在于许多生产系统中。
问题是它们通常存在于不同的地方。
支付系统了解商业状态。
授权系统了解执行是否被允许。
AI 提供商报告模型消耗。
应用日志描述执行行为。
计量系统记录使用情况。
可观测性平台捕获失败和重试。
产品系统可能知道 workflow 是否产生了有用的结果。
财务部门看到收入和总成本。
每个系统都包含故事的一部分。
很少有系统包含整个故事。
因此，一次简化的执行可能在多个层面生成信息：
商业状态
↓
授权
↓
执行
↓
计量
↓
重试 / 失败
↓
结果
↓
经济
单独来看，这些信号回答有用的问题。
商业状态告诉我们客户购买了什么。
授权告诉我们操作是否被允许。
执行遥测告诉我们实际发生了什么。
计量告诉我们消耗了什么。
失败数据告诉我们发生了哪些额外工作。
结果数据告诉我们 workflow 是否达到了目标。
经济数据告诉我们服务该活动最终花费了多少。
更难的问题是连接它们。
假设一个客户产生异常高的模型支出。
仅这个事实告诉我们很少信息。
也许客户是无利可图的。
也许他们是公司最有价值的账户之一。
也许特定的 workflow 效率低下。
也许提供商开始产生更多失败。
也许重试在部署后增加了。
也许使用量增加是因为产品提供了显著更多的价值。
成本信号只有在能够被上下文中解释时才会变得有用。
这指向一个超越传统可观测性的架构方向。
我们可以将其理解为运行时智能。
不是作为一个成熟的基础设施类别，也不是作为一个自动知道哪些业务决策正确的系统。
而是将运行时行为与其周围的商业和经济上下文连接起来的能力。
不是只观察：
发生了什么？
系统开始帮助团队理解：
发生了什么？
对于哪个客户？
在哪个 workflow 中？
在什么商业条件下？
花费了多少？
在哪些失败或重试之后？
产生了什么结果？
这些额外的上下文可以使基础设施数据对工程和业务团队都更有用。
它可以帮助揭示以下模式：
成本服务发生显著变化的客户
重试严重影响经济的 workflow
负责不成比例基础设施支出的执行路径
使用增长快于其产生价值的特性
因为产生高价值结果而保持健康的昂贵 workflow
预期消耗与观察到的消耗之间的差异
目标不是自动化每个决策。
可见性可能导致定价变更。
或 workflow 重新设计。
或不同的模型路由。
或更好的重试处理。
或产品决策。