通过批处理作业和提示缓存降低 LLM API 成本：实用手册

许多团队为 LLM API 支付过高的费用，因为他们通过相同的同步路径发送每个请求。这适用于聊天、编码助理、支持代理、支付流程以及等待用户的任何内容。对于评估、标记、丰富、审核扫描、嵌入回填、夜间报告和内容预处理来说都是浪费。

实际问题不是“哪种型号最便宜？”它是：哪些工作实际上需要立即响应，哪些工作可以等待？一旦您回答了这个问题，AI API 成本控制就变成了一个工程工作流程：对流量进行分类，将延迟容忍作业发送到支持的批处理，构建重复的缓存提示，并衡量失败、重试和运营开销后的实际节省。

首先按工作负载而非模型进行成本审核

在更改架构之前，导出最近 API 使用情况的示例并按工作负载对其进行分组。有用的审核表应包括：

• 端点和模型：聊天完成、响应、嵌入、审核或特定于提供商的端点。
• 平均输入和输出标记：将长提示与短分类任务分开。
• 提示形状：稳定的系统指令、可重用的示例、模式、检索上下文和动态用户数据。
• 延迟要求：秒、分钟、小时或下一个工作日。
• 用户可见性：是否有人正在等待结果。
• 重试和失败率：格式错误的请求、验证失败、提供程序超时、过期作业和重复提交。
• 所有权：项目、团队、客户、API 密钥或合作伙伴帐户。
• 业务 SLA：结果仍然有用的最新时间。

此审计通常会发现“LLM 流量”不是一项工作负载。它是交互式产品功能、内部自动化、报告、数据准备和质量评估的组合。将它们视为一个成本中心隐藏着最容易的节省。

使用三通道工作负载分类器

简单的分类器可以防止团队将错误的流量转移到批次中，然后因未达到预期而感到惊讶。

泳道1：实时交互请求

保持这些同步。它们包括聊天用户体验、副驾驶、支持代理、人机交互审查、实时搜索或检索流程以及具有直接副作用的工具调用。如果用户正在等待，则延迟会消除更便宜的响应的价值。

建议：通过模型选择、提示修剪、速率限制管理、缓存（如果适用）以及仔细重试来优化此通道。不要将其发送到 24 小时批处理队列，除非产品明确将其呈现为后台任务。

通道 2：可以等待几分钟的近线请求

这些作业不需要阻止页面加载，但它们可能仍然具有同一会话或同一小时的期望。示例包括上传后文档分析、表单提交后的 CRM 丰富或可以在准备好时通知用户的报告。

建议：将近线工作放在具有明确状态状态的队列后面。根据提供商的支持和截止日期，可以小批量运行它，也可以以较低优先级的同步工作线程运行。该通道受益于作业 ID、网络钩子和用户可见的进度。

通道 3：最多可等待 24 小时的离线批量请求

这是主要的成本优化通道。好的候选人包括：

• 大规模评估；
• 数据集标签；
• 目录或 CRM 丰富；
• 每晚总结；
• 合规审核队列；
• 嵌入回填；
• 审核扫荡；
• 定期生成报告；
• 在索引或发布之前对内容进行预处理。

事实：主要提供商现在为合适的工作负载提供异步批处理 API。 OpenAI 的 Batch API 从上传的文件中读取请求，将结果写入输出文件，并在 24 小时内完成处理。 OpenAI 表示，与同步 API 相比，支持的 Batch API 使用可享受 50% 的成本折扣。 Anthropic 的 Message Batches API 专为大量消息请求、异步处理、更高的吞吐量和降低 50% 的成本而设计。 Google 的 Gemini Batch API 专为大容量异步请求而设计，成本仅为标准成本的 50%，目标周转时间为 24 小时。

权衡：“长达 24 小时”非常适合回填和评估，但对于交互式工作流程来说是不可接受的。批处理是一种调度策略，而不是同步推理的通用替代品。

将批处理路径设计为作业生命周期

要避免的实现错误是将批处理视为单个 API 调用。它是一个生命周期：接受工作、验证它、保留它、提交它、轮询它、协调它并公开结果。

参考架构

1. 接受规范化请求：尽可能使请求格式接近您现有的 OpenAI 兼容 API 格式。添加元数据，例如项目、团队、客户、幂等密钥、请求的截止日期和成本中心。
2. 对工作负载进行分类：将请求分配到实时、近线或离线批次。这应该是基于策略的，而不是隐藏在应用程序代码中。
3. 创建作业 ID：立即返回近线和离线工作的作业标识符。
4. 验证兼容性：检查所选提供商和模型是否支持请求的端点、模式、文件大小、工具、响应格式和其他功能的批次。
5. 保留请求行：存储规范化的 JSONL 行或特定于提供商的负载。包含用于协调的稳定行 ID。
6. 提交批次：根据提供商限制和作业大小上传请求文件或内联批次负载。
7. 投票状态：跟踪提供商状态，例如正在验证、正在进行、已完成、失败、已过期、正在取消和已取消（如果适用）。
8. 存储输出行：写入成功的响应、行级错误、令牌使用情况、缓存的令牌计数（如果有）以及提供商标识符。
9. 通知消费者：公开检索端点、网络钩子、仪表板通知或 Telegram 警报。
10. 协调计费：将成本归因于原始项目、团队、客户、API 密钥和作业 ID。

此模式使应用程序保持简单。产品团队提交工作并接收工作状态。网关或编排层处理提供程序差异、批处理文件、重试和记帐。

使用明确的作业状态

定义内部状态，即使每个提供者使用不同的名称：

• 已排队：接受但未提交；
• validating：提供商或网关正在检查文件；
• 正在运行：已提交并正在处理；
• 已完成：收集所有可用结果；
• completed_with_errors：某些行验证或执行失败；
• 已过期：在所有行完成之前已过了截止日期；
• 已取消：被用户、系统或策略停止；
• 失败：需要干预的作业级别失败。

事实：OpenAI 记录批次状态，包括验证、失败、进行中、已完成、过期、取消和已取消。它还指出，如果批次过期，已完成的工作将被退回并收费，而剩余的工作将被取消。

建议：永远不要认为批处理作业是全有或全无。从一开始就构建行级状态处理。

计算故障后的节省和开销

对于大多数团队来说，简单的节省模型就足够了：

baseline_cost = synchronous_input_cost + synchronous_output_cost
批量成本 = 折扣批量输入成本 + 折扣批量输出成本
调整后的批量成本 = 批量成本 + 编排成本 + 存储成本 + 重新运行成本
估计节省=基线成本-调整批次成本

然后按工作负载计算此值，而不是全局计算。每晚评估套件可以节省大量成本。包含许多格式错误的行、紧急回退或重复重新运行的近线工作流程可能会节省低于预期的费用。

至少跟踪以下指标：

• 同步与批量代币支出；
• 按模型划分的输入和输出标记；
• 批量作业计数和每个作业的平均行数；
• 行级故障率；
• 过期工作率；
• 重新运行成本；
• 回退同步成本；
• 按团队、项目、关键、客户和合作伙伴帐户划分的成本。

建议：将自动同步回退视为例外，而不是默认情况。它可以保护最后期限，但如果过度使用，它可能会消除预期的节省。添加诸如“仅当业务截止日期在两小时内并且作业尚未开始时才回退”的策略。

为重复的长前缀添加提示缓存

批处理降低了合格工作的单价。当提供程序行为支持时，提示缓存可降低重复长提示的有效成本和延迟。

事实：OpenAI 提示缓存会自动应用于受支持模型上超过 1,024 个令牌的提示，缓存之前计算的最长前缀，并在 API 使用详细信息中报告 cached_tokens。 OpenAI 表示，提示缓存通常会在闲置 5 到 10 分钟后被清除，并在上次使用后一小时内删除，并且提示缓存不会在组织之间共享。

实现模式很简单：首先放置稳定内容，最后放置易失性内容。

更好的缓存提示结构

系统说明
稳定的政策文本
稳定的输出模式
稳定的例子
可重用的参考上下文
---
动态记录特定输入
动态用户或行元数据

例如，目录丰富作业可能会在 50,000 种产品中重复使用相同的分类法、输出架构、品牌规则和示例。每行仅更改产品标题、描述和属性。首先放置可重用前缀可以让提供者更好地在支持的情况下重用缓存计算。

权衡：缓存不是永久存储，不应被视为有保证。缓存窗口、隔离、最小提示长度和报告因提供商而异。衡量缓存的令牌而不是假设节省。

提交前验证提供商支持

批处理 API 不同。网关应在提交作业之前验证资格。

事实：OpenAI Batch API 不支持流式传输，并且具有单独的批处理速率限制。 Anthropic 文档批次限制包括 100,000 个请求或 256 MB 批次大小限制、24 小时到期、29 天结果可用性、速率限制以及批次可能稍微超出配置的工作区支出限制的可能性。 Google 支持 20 MB 以下较小作业的内联批处理请求，以及较大批处理请求的 JSONL 输入文件。

使用兼容性检查表：

• 所请求的模型是否可以通过该提供商的批处理 API 获得？
• 端点是否受支持？
• 请求是否需要流式传输？如果是，则拒绝该批次。
• 它是否使用必须立即发生的工具或副作用？
• 批处理文件是否超出了提供商的限制？
• 预期结果在提供商的完成窗口内仍然有用吗？
• 输出的可用时间是否足以让下游系统检索它们？
• 工作负载能否容忍部分完成？

建议：尽早失败验证，并有明确的原因。被拒绝的批次候选者比过期或畸形且必须稍后返工的作业要便宜。

为团队、机构和合作伙伴提供保障

批处理系统可以悄悄地花费很多钱，因为它们在后台处理大文件。在广泛推出之前添加控件：

• 每团队批量预算：单独的线上和线下支出限制。
• 最大文件大小和行数：强制执行提供商限制和您自己的操作限制。
• 死信队列：保留带有验证错误的无效行以供审核。
• 幂等密钥：防止意外重新提交导致重复收费。
• PII 审核：批处理文件可能会产生新的数据保留和隐私义务。
• 保留策略：定义请求文件、输出文件和日志的存储时间。
• 通知政策：当任务失败、过期或超出预算时提醒所有者。
• 归属：记录项目、团队、客户、API 密钥、模型、提供商、作业 ID 和行 ID。

对于代理机构和经销商来说，归因尤其重要。如果一个合作伙伴为许多客户运行丰富或评估作业，系统应报告每个客户和每个作业的成本，而不仅仅是每个提供商发票的成本。

这如何映射到 AI API 网关

AI API 网关是实现这一点的自然场所，因为它已经位于应用程序和模型提供商之间。该网关可以为开发人员保留兼容 OpenAI 的 API 接口，同时在其背后添加成本感知调度。

有用的网关功能包括：

• 统一计费：在一个位置比较同步、批量、缓存和后备支出。
• AI 使用情况分析：按模型、提供商、端点、团队、项目和 API 密钥细分使用情况。
• 团队控制：为交互式工作负载和离线工作负载设置单独的预算。
• API 密钥归属：识别创建每项作业的服务或客户。
• 状态通知：在批处理作业完成、失败、过期或接近截止日期时发送警报。
• 合作伙伴 API 工作流程：让代理机构或经销商代表客户创建工作并检索结果，同时保留客户级会计。

预测：更多团队将通过调度策略来管理 LLM 成本，而不仅仅是模型替换。随着供应商之间的批量支持日趋成熟，获胜的架构将根据紧迫性、功能兼容性和会计要求进行路由，然后再根据型号价格进行路由。

实施清单

• 导出 30 天的 LLM API 使用情况。
• 将每个工作负载分类为实时、近线或离线。
• 选择一个具有明确所有权和宽限期限的离线工作负载。
• 验证提供商批量支持所需的端点和模型。
• 定义内部作业状态和行级状态。
• 添加幂等键、作业 ID 和每行 ID。
• 通过保留控制来存储规范化的请求和响应记录。
• 在功能标记后面提交第一批。
• 衡量同步基准成本与调整后的批次成本。
• 重组重复的长提示，将稳定的前缀放在第一位。
• 跟踪缓存的令牌、失败的行、过期的作业和回退支出。
• 仅在分析中显示节省和运营行为后才进行扩展。

可行的结论

不要通过要求每个团队使用更便宜的模型来开始 AI API 成本控制。首先将紧急工作与可以等待的工作分开。保持交互请求同步。当提供商支持和业务截止日期合适时，将评估、丰富、标记、回填、审核扫描和报告移至批处理。结构重复长提示进行缓存。然后衡量故障、重新运行、存储和回退成本后的实际节省。

最好的实现是故意无聊的：作业 ID、验证、行级状态、预算、使用情况分析和明确的所有权。该运营层将提供商折扣转化为可靠的节省。

相关阅读

• API 密钥归属和团队支出控制
• LLM API 的路由、重试和回退策略
• 相关 Model Gate 实现说明