通过批处理作业和提示缓存降低 LLM API 成本：实用手册
针对延迟容忍工作负载的 AI API 成本控制实用指南：对流量进行分类、将符合条件的作业移至批处理 API、使用提示缓存并保持计费易于理解。
许多团队为 LLM API 支付过高的费用，因为他们通过相同的同步路径发送每个请求。这适用于聊天、编码助理、支持代理、支付流程以及等待用户的任何内容。对于评估、标记、充实、审核扫描、嵌入回填、夜间报告和内容预处理来说，这是一种浪费。
实际问题不是“哪种型号最便宜？”它是：哪些工作实际上需要立即响应，哪些工作可以等待？一旦您回答了这个问题，AI API成本控制就变成了一个工程工作流程：对流量进行分类，将延迟容忍作业发送到支持的批处理，构建重复的缓存提示，并衡量失败、重试和运营开销后的实际节省。
首先按工作负载而非模型进行成本审核
在更改架构之前，导出最近 API 使用情况的示例并按工作负载对其进行分组。有用的审核表应包括：
- 端点和模型：聊天完成、响应、嵌入、审核或特定于提供商的端点。
- 平均输入和输出标记：将长提示与短分类任务分开。
- 提示形状：稳定的系统指令、可重用的示例、架构、检索上下文和动态用户数据。
- 延迟时间要求：秒、分钟、小时或下一个工作日。
- 用户可见性：是否有人正在等待结果。
- 重试和失败率：格式错误的请求、验证失败、提供程序超时、过期作业和重复提交。
- 所有权：项目、团队、客户、API密钥或合作伙伴帐户。
- 业务 SLA：结果仍然有用的最晚时间。
此审核通常会发现“LLM 流量”不是一种工作负载。它是交互式产品功能、内部自动化、报告、数据准备和质量评估的组合。将它们视为一个成本中心隐藏着最简单的节省方法。
使用三通道工作负载分类器
简单的分类器可以防止团队将错误的流量转移到批次中，然后因未达到预期而感到惊讶。
通道 1：实时交互式请求
保持这些同步。它们包括聊天用户体验、副驾驶、支持代理、人机交互审查、实时搜索或检索流程以及具有直接副作用的工具调用。如果用户正在等待，则延迟会消除更便宜的响应的价值。
建议：通过模型选择、提示修剪、速率限制管理、缓存（如果适用）和仔细重试来优化此通道。除非产品明确将其呈现为后台任务，否则请勿将其发送到 24 小时批处理队列。
通道 2：可能等待几分钟的近线请求
这些作业不需要阻止页面加载，但它们可能仍具有同一会话或同一小时的期望。示例包括上传后文档分析、表单提交后的 CRM 丰富或可以在准备就绪时通知用户的报告。
建议：将近线工作放置在具有明确状态状态的队列后面。根据提供商的支持和截止日期，可以小批量运行它，也可以以较低优先级的同步工作线程运行。该通道受益于作业 ID、网络钩子和用户可见的进度。
通道 3：最多可等待 24 小时的离线批量请求
这是主要的成本优化通道。好的候选人包括：
- 大规模评估；
- 数据集标签；
- 目录或 CRM 丰富；
- 每晚总结；
- 合规审核队列；
- 嵌入回填；
- 审核扫荡；
- 定期生成报告；
- 在索引或发布之前对内容进行预处理。
事实： 主要提供商现在为合适的工作负载提供异步批处理 API。 OpenAI 的批次 API 从上传的文件中读取请求，将结果写入输出文件，并目标在 24 小时内处理。 OpenAI 声明与同步 API 相比，支持的批次 API 使用可享受 50% 的成本折扣。 Anthropic 的消息批次 API 专为大量消息请求、异步处理、更高的吞吐量和降低 50% 的成本而设计。 Google 的 Gemini 批次 API 专为大容量异步请求而设计，费用为标准成本的 50%，目标周转时间为 24 小时。
权衡：“最长 24 小时”非常适合回填和评估，但对于交互式工作流程来说是不可接受的。批处理是一种调度策略，而不是同步推理的通用替代品。
将批处理路径设计为作业生命周期
要避免的实现错误是将批处理视为单个 API 调用。这是一个生命周期：接受工作、验证它、保留它、提交它、轮询它、协调它并公开结果。
参考架构
- 接受规范化请求：尽可能使请求格式接近您现有的OpenAI兼容的API格式。添加元数据，例如项目、团队、客户、幂等密钥、请求的截止日期和成本中心。
- 对工作负载进行分类：将请求分配给实时、近线或离线批次。这应该基于策略，而不是隐藏在应用程序代码中。
- 创建作业 ID：立即返回近线和离线工作的作业标识符。
- 验证兼容性：检查所选提供程序和模型是否支持所请求端点、模式、文件大小、工具、响应格式和其他功能的批次。
- 保留请求行：存储规范化的 JSONL 行或提供商特定的负载。包含用于协调的稳定行 ID。
- 提交批次：根据提供商限制和作业大小上传请求文件或内联批次负载。
- 投票状态：跟踪提供程序状态，例如验证、进行中、已完成、失败、过期、取消和已取消（如果适用）。
- 存储输出行：写入成功响应、行级错误、令牌使用情况、缓存令牌计数（如果可用）以及提供程序标识符。
- 通知消费者：公开检索端点、网络钩子、信息中心通知或Telegram警报。
- 协调结算：将成本归因于原始项目、团队、客户、API 键和作业 ID。
此模式使应用程序保持简单。产品团队提交工作并接收工作状态。网关或编排层处理提供商差异、批处理文件、重试和记帐。
使用明确的作业状态
定义内部状态，即使每个提供程序使用不同的名称：
queued：已接受但未提交；validating：提供商或网关正在检查文件；running：已提交并正在处理；completed：收集所有可用结果；completed_with_errors：某些行验证或执行失败；expired：截止日期已过，所有行均未完成；cancelled：被用户、系统或策略停止；failed：需要干预的作业级别故障。
事实： OpenAI 记录批次状态，包括验证、失败、in_progress、已完成、过期、取消和已取消。它还指出，如果批次过期，已完成的工作将被退回并收取费用，而剩余的工作将被取消。
建议：永远不要假设批处理作业是全有或全无。从一开始就构建行级状态处理。
计算故障后节省的费用和开销
简单的节省模式对于大多数团队来说就足够了：
baseline_cost = synchronous_input_cost + synchronous_output_cost
batch_cost = discounted_batch_input_cost + discounted_batch_output_cost
adjusted_batch_cost = batch_cost + orchestration_cost + storage_cost + rerun_cost
estimated_savings = baseline_cost - adjusted_batch_cost然后按工作负载计算此值，而不是全局计算。每晚评估套件可以节省大量成本。包含许多格式错误的行、紧急回退或重复重新运行的近线工作流程可能节省的时间低于预期。
至少跟踪以下指标：
- 同步与批量令牌支出；
- 按模型划分的输入和输出标记；
- 批量作业计数和每个作业的平均行数；
- 行级故障率；
- 过期作业率；
- 重新运行成本；
- 回退同步成本；
- 按团队、项目、关键、客户和合作伙伴帐户划分的成本。
建议：将自动同步回退视为例外，而不是默认情况。它可以保护最后期限，但如果过度使用，它可能会消除预期的节省。添加政策，例如“仅当业务截止日期在两小时内并且作业尚未开始时才回退。”
为重复的长前缀添加提示缓存
批处理降低了合格工作的单价。当提供程序行为支持时，提示缓存可降低重复长提示的有效成本和延迟。
事实： OpenAI 提示缓存会自动应用于受支持模型上长度超过 1,024 个令牌的提示，缓存之前计算的最长前缀，并在 API 使用详细信息中报告 cached_tokens。 OpenAI 表示提示缓存通常会在闲置 5 到 10 分钟后清除，并在上次使用后一小时内删除，并且提示缓存不会在组织之间共享。
实现模式很简单：首先放置稳定内容，最后放置易失性内容。
更好的缓存提示结构
System instructions
Stable policy text
Stable output schema
Stable examples
Reusable reference context
---
Dynamic record-specific input
Dynamic user or row metadata例如，目录丰富作业可能会在 50,000 种产品中重复使用相同的分类法、输出架构、品牌规则和示例。每行仅更改产品标题、描述和属性。首先放置可重用前缀可以让提供程序更好地在支持的情况下重用缓存计算。
权衡：缓存不是永久存储，不应被视为有保证。缓存窗口、隔离、最小提示长度和报告因提供商而异。衡量缓存的令牌而不是假设节省。
提交前验证提供商支持
批量 API 有所不同。网关应在提交作业之前验证资格。
事实： OpenAI批次 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、验证、行级状态、预算、使用情况分析和明确的所有权。该运营层将提供商折扣转化为可靠的节省。