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

你的团队上线了一个 AI 驱动的客服机器人。它运行良好，用户很满意。然后月度账单到了，你发现监控 LLM 调用的基础设施成本比 LLM 调用本身还要高。

这不是假设。团队报告称，将 AI 工作负载监控添加到现有的 Datadog 或 New Relic 设置中，可观测性账单增加了 40-200%。与此同时，推理成本持续下降——GPT-4 级别的性能现在每百万 token 仅需 0.40 美元，而 2022 年末为 20 美元。监控技术栈还没有收到这个消息。

结果是一个倒挂现象，如果不是这么贵的话会很有趣：你花在观察 AI 思考上的钱比让 AI 思考的钱还多。

你的财务团队想要一个数字。AI 智能体系统每月会花费多少钱？你根据平均 Token 使用量给出了估算，乘以预计的请求量，并加上了安全余量。三个月后，实际账单是预测值的 3 倍，而且没人能解释原因。

这并非预算编制的失败，而是建模的失败。传统的成本预测假设单次请求的成本会聚集在一个可预测的平均值附近。智能体系统在每一个层面上都打破了这一假设。执行路径是多变的。每次请求的 LLM 调用次数是多变的。每次调用的 Token 数量是多变的。这些变量之间的相互作用产生了一个带有“肥尾”（Fat tail）的成本分布，从而吞噬了你的利润。

大多数使用 LLM 构建产品的团队都在针对错误的工作负载进行优化。他们过分痴迷于首个 token 生成时间（time-to-first-token）、流式传输延迟和响应速度——结果却发现，其 LLM API 支出的 60% 或更多实际上流向了无人实时监控的夜间摘要任务、数据扩充流水线和分类运行。适用于聊天应用的“延迟优先”思维模式正在主动破坏这些离线工作负载。

LLM 批处理流水线是生产环境 AI 中那些不起眼但至关重要的“劳模”。它是每晚对 50,000 张工单进行分类的任务，是每周用公司描述丰富 CRM 的流水线，也是每天为新文档生成嵌入（embeddings）的运行任务。这些工作负载的设计约束与实时服务有着本质的不同。如果将它们视为聊天 API 的“慢速版本”，问题就由此产生了。

大多数生产环境中的 AI 工程建议都假设你在构建聊天机器人。架构讨论集中在首字时间（TTFT）、流式部分响应以及亚秒级的延迟预算上。但越来越多的真实 LLM 工作负载与聊天界面毫无共同点。它们更像是每晚的数据扩充任务、每周的文档分类运行，以及每月对数百万条记录进行的合规性审查。

这些批处理流水线正是团队悄悄烧钱最多、因无声失败导致数据丢失最严重、以及积累技术债最多的地方——这正是因为来自实时服务的“延迟优先”思维模型不再适用，且尚未有人用更好的方案取而代之。

你的推理模型账单可能很高，但能力差距可能比你想象的要小。在 AIME 2024 数学基准测试中，一个运行四个结构化认知操作的标准 70B 模型，其准确率从 13% 跃升至 30% —— 以极低的推理成本，几乎赶上了 o1-preview 的 44%。在像 GPT-4.1 这样更强大的基础模型上，同样的技术将准确率从 32% 提升到 53%，这实际上在这些基准测试中超越了 o1-preview。

这种技术被称为认知工具脚手架 (cognitive tool scaffolding)，它是过去十年研究如何让语言模型在不改变权重的情况下实现更好推理的最新演变。

大多数团队在向现有的 LLM 流水线添加多模态能力时，往往没有先计算成本。他们用几张测试图片做了原型，运行良好，然后就上线了——直到收到第一张账单。根据调用量的大小，账单上的数字往往介于“令人尴尬”和“灾难性”之间。

问题不在于多模态 AI 在原则上有多贵，而在于每种模态都有独特的 Token 计算逻辑，它们会以一种你凭纯文本直觉无法预料的方式复合叠加。只需一个配置参数——比如视频帧率、图像分辨率模式，或者你是否在每一轮对话中重复发送系统提示词（System Prompt）——都可能在你不经意间，让你的推理费用翻上 10 倍甚至更多。

每个后端工程师都知道重试是必不可少的。每个分布式系统工程师都知道重试是危险的。当你让 LLM agent 负责重试工具调用时，你会同时遇到这两个问题，而且还有一个新问题：每次重试都会消耗 token。一个不稳定的 API 端点可能会在不到一分钟的时间内，将一个 0.01 美元的 agent 任务变成一场 2 美元的灾难。

重试风暴问题并不新鲜。分布式系统几十年来一直在处理惊群效应（thundering herds）和级联故障。但 agent 系统放大了这个问题，而微服务模式无法完全解决它，因为重试逻辑存在于一个不理解背压（backpressure）的概率推理引擎中。

大多数构建 LLM 应用的团队都了解 Prompt caching —— 这是 API 提供商提供的一种前缀重用机制，旨在对重复的输入 Token 进行折扣。部署其上一层技术的团队则少之又少：语义缓存 (Semantic Caching)，它能彻底消除那些语义相同但表述不同的查询所产生的 LLM 调用。这种差距并非源于怠惰，而是源于对语义缓存供应商文档中 “95% 准确率” 含义的普遍误解。

那 95% 的数字指的是缓存命中时的匹配正确性，而不是缓存实际被命中的频率。实际生产环境中的命中率从开放式聊天的 10% 到结构化 FAQ 系统的 70% 不等 —— 在你编写任何缓存代码之前，你应该先计算出你处于该范围的哪一侧。

你的 AI Agent 在开发阶段的成本比你想象的要低，但在生产环境中的成本却远超你的预料。API 账单——大多数团队针对其进行优化的指标——仅占在生产环境中运行 Agent 真实总成本的 10–20% 左右。其余部分则隐藏在大多数工程预算从未明确建模的层级之中。

这很重要，因为决定大规模部署 Agent 并不是一个真正的技术决策。而是一个单位经济效益决策。那些基于不完整成本模型做出决策的团队，正是六个月后报告投资回报率 (ROI) 为负的那些团队。

大多数工程师都低估了微调成本，低估程度达三到五倍。训练运行只是账单中最小的一部分。数据整理、实验失败、部署基础设施以及持续的模型维护才是预算真正的去向。跳过这类计算的团队往往会在投入微调项目数月后才意识到，一个设计良好的 few-shot 示例提示词本可以在一周内解决问题。

本篇文章将深入探讨完整的经济账——微调在整个生命周期中的实际成本、LoRA 和 PEFT 何时能让这笔账划算，以及一个基于真实生产数据在微调和提示词工程之间进行选择的决策框架。

大多数采用知识蒸馏的团队，都在错误的理由和错误的时机下做出了这个决定。他们看到一个70B模型吞噬了推理预算，读到蒸馏可以产出一个"同样出色"的7B学生模型，便立即开干。六周后，他们得到了一个在验证集上表现良好的蒸馏模型，上线后却开始大规模输出自信满满的废话。验证集来自与教师模型合成训练数据相同的分布，而真实流量并非如此。

蒸馏是一种优化工具，而非能力升级手段。只有在特定条件下，经济账才算得过来——而且失败模式足够隐蔽，团队往往要等到用户先发现问题。

每个销售 LLM 网关的供应商都会向你展示一张标有“95% 缓存命中率”的幻灯片。那张幻灯片不会告诉你的是小字说明：这个数字是指在找到匹配项时的匹配准确度，而不是找到匹配项的频率。实际的生产系统命中率为 20–45% —— 营销与现实之间的差距正是大多数团队踩坑的地方。

语义缓存（Semantic caching）是一项非常有用的技术。但在不了解其失效模式的情况下部署它，会导致你以极高的置信度向用户返回错误答案，并让你纳闷为什么支持工单翻了一倍。