如何通过批处理降低 LLM API 成本而不中断操作

许多团队为 LLM 工作负载支付过高的费用，因为每个请求都经过相同的同步路径。对于聊天、代理循环、面向用户的操作以及需要立即答复的决策来说，这是正确的模式。对于评估、文档丰富、分类回填、嵌入刷新、夜间质量检查、合规性扫描和可以等待的报告作业来说，这通常是错误的模式。

困难的部分不是决定批量折扣是否有吸引力。困难的部分是在不失去操作控制的情况下将工作转移到异步处理中。批处理改变了系统的形态：请求变成作业，失败稍后到达，结果可能不完整，成本归因取决于协调而不是立即响应元数据。

本指南将事实、建议和预测分开，以便团队可以做出实际的实施决策，而无需将批处理视为同步 API 的通用替代品。

关于 LLM 批处理 API 的事实真相

一些主要模型提供商现在提供用于大批量异步工作的批处理 API。具体格式和限制有所不同，但商业模式相似：提交多个请求，等待异步处理，然后稍后检索结果。

• 事实： OpenAI 记录大型异步批次的批次 API，并在 24 小时窗口内返回完成结果并享受 50% 的折扣。其记录的支持端点包括响应、聊天完成、嵌入、完成和审核，并上传 JSONL 输入文件进行处理。
• 事实： Anthropic 记录大容量异步消息请求的消息批次，成本降低 50%，吞吐量提高。其文档称，大多数批次在不到一小时内完成，并且该模式适合不需要立即响应的情况。
• 事实： Anthropic 还记录了消息批次的单独速率限制行为，包括批次端点的限制以及可以同时位于处理队列中的批次请求的数量。
• 事实： Google记录了以 50% 标准成本处理大量异步请求的 Gemini 批次 API，其定价文档将批次 API 列为降低 50% 成本的功能。
• 事实： Amazon Bedrock 模型调用日志记录可以收集支持的运行时调用的请求数据、响应数据和元数据，并传送到 CloudWatch Logs 和/或 S3。记录的字段可以包括 requestId、操作、modelId、requestMetadata、输入令牌计数和输出令牌计数，这些对于协调很有用。

这些事实支持明确的建议：在工作负载可以容忍延迟完成且较低单位成本的业务价值超过异步执行的操作复杂性的情况下，使用批处理。

不要从提供程序开始API

常见的实施错误是将应用程序代码直接绑定到提供商的批处理文件格式或状态模型。这适用于原型，但当团队添加第二个提供商、更改模型或需要跨同步和异步流量的一致报告时，它会产生可避免的迁移成本。

更好的起点是内部批处理作业抽象。无需详细说明，但应规范您的平台所需的操作字段，无论提供商如何。

最小批处理作业字段

• job_id: 批处理作业的内部标识符。
• provider: 选择的提供商执行。
• provider_batch_id： 提交后的外部批次标识符。
• workflow： 业务工作流程，例如 eval_run、embedding_refresh、doc_enrichment 或 qa_scan。
• team_id 或customer_id: 配额、报告和费用分配的责任所有者。
• model: 请求的模型或模型政策。
• endpoint: 提供程序端点类型，例如聊天、响应、嵌入、审核或消息。
• submitted_at 和 deadline_at: SLA 处理所需的时间戳。
• 状态： 规范化状态，例如已排队、已提交、正在处理、已完成、completed_with_errors、失败、已取消或已过期。
• input_uri 和result_uri: 指向持久输入和输出工件的指针。
• item_count、success_count、failure_count: 作业级协调总计。
• input_tokens 和 output_tokens: 之后实现的使用情况处理。
• estimated_cost 和 realized_cost: 提交时间估算和调节后成本。
• cost_basis: 使用的定价规则，包括是否应用批量折扣。

此抽象为组织的其他部分提供一份合同。仍可以存储特定于提供商的字段以供调试，但它们不应成为每个应用团队都必须学习的界面。

在路由之前按 SLA 对工作负载进行分类

批处理应由服务级别期望驱动，而不是由减少支出的总体愿望驱动。简单的路由策略比聪明的路由策略更容易操作。

交互式类

交互式请求是面向用户的或对时间敏感的。示例包括聊天用户体验、需要工具调用的代理循环、操作员等待的支持工作流程、欺诈或付款决策，以及延迟部分输出比没有输出更糟糕的任何工作流程。这些应该保持同步，除非产品明确改变其用户体验。

延迟类

延迟的工作流程可以等待，而不会影响用户或业务流程。示例包括离线评估、文档标记、分类回填、嵌入刷新、历史审核、夜间 QA 检查和报告生成。这些是提供程序批量 API 的最佳候选者。

边界类

某些工作负载并不是真正的交互式，但它们仍然有截止日期。例如，客户导入的文档可能需要在 20 分钟内而不是立即进行充实。对于这些，请使用带有截止日期的内部队列。如果作业在截止日期附近仍待处理，则可以根据策略将其提升为同步处理、取消或重新路由。

这就是 AI API 成本控制 成为基础设施问题而不是定价活动的地方。系统需要在同一位置实现路由策略、截止日期感知、记帐和可观察性。

对每个项目使用稳定的请求 ID

批处理作业失败的方式比同步调用的方式更多。提供者可能会拒绝该文件。作业完成时可能会出现项目级错误。重试可能会重新提交部分成功的工作。在写入一些结果后但在将作业标记为完成之前，提取过程可能会崩溃。

最重要的保护是每个项目的稳定请求密钥。此密钥应根据您自己的数据确定，而不是在提交时随机生成。

例如，文档丰富请求密钥可能是：

doc_enrichment:v3:customer_812:document_9912:section_04:model_policy_standard

嵌入刷新密钥可能是：

embedding_refresh:v2:workspace_44:asset_2107:chunk_18:embedding_model_small

该密钥应包括工作流程、版本、租户边界、源记录、项目边界以及相关的模型或模型政策。这允许下游写入是幂等的。如果两次收到相同的结果，数据库可以通过 request_key 更新插入，而不是创建重复行或重复计数使用。

显式设计状态机

提供程序状态不同，因此内部状态机应该小且耐用。实际版本如下所示：

• 已创建： 作业在内部存在，但尚未打包。
• 已验证： 输入记录已通过架构和资格检查。
• 已提交： 提供程序接受了批次提交。
• 处理： 提供程序已启动或排队执行。
• 已完成： 所有项目均达到成功的最终状态。
• completed_with_errors： 作业已完成，但某些项目失败并需要审核或重播。
• 失败： 作业在提供程序或编排层失败。
• 取消： 系统或操作员在完成之前停止了作业。
• 过期： 作业错过了截止日期，并且不应在未完成的情况下写入正常结果查看。

每个转换都应仅在事件表中追加。当作业错过截止日期或下游系统对记录是否已处理有争议时，这可以为运营团队提供审核跟踪。

将调节构建为一流的工作流程

提交只是系统的一半。The expensive operational bugs usually appear during result ingestion.

A reconciliation worker should do five things every time it processes a completed batch:

1. Load the original manifest of submitted request keys.
2. Load provider results from output files, result endpoints, or provider logs.
3. Map every provider result back to exactly one internal request key.
4. Write successful results idempotently to the destination system.
5. Emit terminal records for failures, missing items, token counts, and realized cost.

The reconciliation process should verify that every submitted item has a terminal state.缺失的结果不应悄无声息地消失。 Mark them as missing, failed, or retryable according to the provider response and your policy.

Cost attribution should also happen here. Submission-time estimates are useful for budget checks, but realized cost should be derived from actual token counts, provider output, billing exports, or invocation logs where available. This avoids a recurring problem: teams report estimated savings while the finance ledger later shows a different number.

Handle partial failures without replaying everything

Batch systems must assume partial failure.对于 2% 的记录，提示架构可能会失败。请求的子集可能会达到长度限制。某些输入可能违反审核或内容政策。 A result file may contain valid output for most items and structured errors for the rest.

The correct response is usually not to replay the entire batch.仅将失败或丢失的请求密钥重播到新作业中，并使用 parent_job_id 和 retry_attempt。这可以限制成本、减少重复写入并保持原始作业的审核跟踪完整。

有用的重试记录包括：

• request_key
• parent_job_id
• retry_attempt
• original_error_code
• retry_reason
• new_job_id
• final_status

执行不会自动重试所有错误。暂时的提供程序故障、队列超时和可恢复的传输问题可能是可重试的。 Prompt validation failures, schema mismatches, and unsupported input size errors usually require a fix before replay.

Control blast radius with batch size and versioning

Large batches can improve throughput and reduce orchestration overhead, but they also increase the cost of a bad prompt, wrong schema, or incorrect model selection. Smaller batches give faster feedback and lower blast radius, but they create more jobs to track.

A practical approach is progressive rollout:

1. Run a small validation batch with representative inputs.
2. Confirm schema validity, output quality, token range, and reconciliation behavior.
3. Increase batch size by workflow after the first successful run.
4. Keep prompt version, schema version, and model policy in the request key or manifest.
5. Stop automatically if failure rate, token usage, or output validation crosses a threshold.

This is especially important for backfills.如果回填处理数百万条记录且提示或输出格式出乎意料地冗长，那么即使有折扣，回填也可以快速创建大额帐单。

显示估计和实现的节省

批量折扣很有吸引力，但报告不应模糊估计值与实际值。

提交时，平台可以使用预期令牌计数、所选模型、商品计数和已知批量折扣规则显示估计成本。调节后，平台应根据实际令牌使用情况和提供商计费或使用数据显示已实现的成本。

有用的信息中心包括：

• 按工作流程和提供商列出的队列期限
• 最早的待处理作业
• 完成百分比
• 失败项目率
• 重试计数
• 已提交的预计成本
• 已核对的已实现成本
• 已获取的有效折扣
• 同步后备数量
• 接近截止日期的作业

这种区别还有助于财务和工程部门使用相同的语言。工程可以优化路由和重试；财务可以调节已实现的支出；产品团队可以了解哪些工作流程实际上受益于延迟处理。

实施建议

在将工作负载转为批处理之前，请使用以下清单。

资格清单

• 工作流程不需要立即面向用户的响应。
• 企业可以定义可接受的完成情况窗口。
• 每个项目都有一个稳定的请求密钥。
• 目标写入可以是幂等的。
• 部分结果是可接受且可协调的。
• 可以有选择地重试失败。
• 记录提示和架构版本。
• 使用可归因于团队、客户、产品或环境。
• 敏感负载日志记录已经过隐私和保留义务审核。

操作清单

• 将提供程序状态规范化到内部状态机中。
• 持久存储原始输入清单。
• 轮询或接收提供程序完成事件计划。
• 根据预期架构验证每个结果。
• 将提交的请求密钥与收到的终端状态进行比较。
• 仅在协调后发出使用记录。
• 将估算成本与实际成本分开。
• 有关队列寿命、失败项目率、缺失结果和截止日期的警报风险。
• 记录哪些工作负载必须保持同步。

明确权衡

建议：将批处理视为单独的执行类，而不是同步 API 路径背后的隐藏优化。团队应该知道工作流程何时延迟、适用的截止日期以及错过截止日期时会发生什么。

权衡：批处理 API 可以大幅降低令牌成本，但它们用排队、轮询、结果提取、延迟错误和更复杂的支持工作流程取代简单的请求响应行为。

权衡：提供程序批处理 API 并不相同。规范化的内部模型可降低应用程序的复杂性，但平台仍需要保留特定于提供商的标识符和错误以进行调试。

权衡：记录完整的提示和输出可以提高可审核性和协调性，但也会产生隐私、安全和数据保留义务。应根据需要对敏感内容进行分类、编辑或排除。

预测：更多 LLM 基础架构团队会将批量执行视为标准路由类，与同步调用、流式调用和后备路由并列。受益最多的团队将是那些尽早建立对账和成本会计的团队，而不是在财务或运营部门询问数字为何不匹配之后才添加它们。

可行的结论

批处理是降低延迟工作负载的 LLM 单位成本的最明确方法之一，但它应该作为一个操作系统来实施，而不仅仅是一个更便宜的端点。从工作负载资格、稳定的请求密钥、规范化的作业模型以及证明每个提交的项目都达到最终状态的协调工作流程开始。

保持交互式请求同步。将延迟的工作流程转移到提供商批处理 API，其中成本和完成窗口有意义。使用内部队列处理具有明确截止日期的边界工作负载。在提交时报告估计的节省，但根据实际使用情况调整已实现的成本。这种模式可以在不破坏下游记录、团队分类帐或 SLA 预期的情况下获取批量折扣。

相关阅读

• 每个团队的成本归因和调节