优化 Serverless AI API 上的批量处理

如果你的 AI 任务不需要即时返回答案，批量处理往往是更好的选择。 我会用它把 API 成本削减约 50%，让后台工作远离实时流量，并在不把所有内容塞进一个 serverless 函数的前提下，处理海量文本、图像、音频或视频负载。

简短版本如下：

• 我会用 队列、无状态工作节点和对象存储，而不是一个长时间运行的函数。

• 对许多 LLM 任务，我会从 每批 100 到 500 个条目 起步，然后对媒体密集型工作缩小批量大小。

• 我会把每个工作节点的函数内并发上限设在约 5 到 10 个请求，并关注 每分钟 token 数，而不只是请求数量。

• 我会 每 10 到 50 个条目设一个检查点、做 3 到 5 次重试、采用 指数退避，并配一个 死信队列。

• 我会用像 job_id:item_id 这样稳定的键让每个条目 幂等，并使用确定性的输出路径。

• 我会跟踪 每分钟条目数、批处理时长、重试率、错误率，以及以美元计的每批成本。

• 我会先用 10 到 50 个条目的小规模试运行 来测试新任务，再进行扩展。

核心思路很简单：批量 AI 流水线在我围绕各种限制先行设计时效果最好。Serverless 的超时、内存上限、负载大小限制和供应商限流，都会共同影响批量大小、扇出、重试和存储模式。

对于多模型工作流，我还会让 API 层保持简单。当一条流水线需要在 500+ 模型 之间为文本、图像和视频任务做路由，又不想在每个工作节点里塞进独立的供应商逻辑时，像 APIMart 这样的统一服务会很有帮助。

最重要的不是原始速度。而是吞吐量、重试安全性以及每次运行的成本控制。

Serverless AI 推理：可扩展、高性价比的模型服务详解 | Uplatz

如何设计可扩展的 Serverless 批处理流水线

这些限制会促使你走向一套由队列支撑的架构。

核心流水线组件与数据流

一条可扩展的批处理流水线由四部分组成：一个 生产者、一个 持久化消息队列、一个 工作节点池 和一个 结果存储。

基本流程是这样的：生产者把大负载上传到对象存储，然后把一个轻量级任务放上队列。工作节点拉取该任务，获取负载，调用 AI API，保存结果，然后才确认消息。最后这一步很关键。如果工作节点在任务进行到一半时崩溃，未被确认的消息会重新出现，好让另一个工作节点重试它 ^[6][7]。

如果某个任务太大，无法在函数超时之前完成，就把数据集切分成更小的批次，并通过一个长期运行的编排器把工作扇出到多个并行工作节点。

一旦这套基础流程跑通，下一步就是按模态和运行时对任务进行路由。

何时按模态拆分工作流

当负载大小或处理时间发生显著变化时，就使用独立的队列。并非每个 AI 任务都该待在同一个工作节点池里。文本分类可能每个条目只需几秒。而繁重的媒体任务可能要运行好几分钟。把两者放进同一个池，超时行为很快就会变得一团糟 ^[4][7]。

更好的做法是按运行时和负载大小拆分队列，而不仅仅按文件类型。按事件类型路由任务。例如，把 PDF、图像、音频和视频用事件过滤器分别送入不同的队列和工作节点池。这能让重试保持隔离，并防止一种工作负载堵塞另一种 ^[8]。

用 APIMart 作为统一的 AI API 层

当一条流水线要处理文本、图像和视频任务时，同时应付多个独立的供应商集成可能会变成一场维护噩梦 ^[2][6]。APIMart 用一个 API 就能让你访问超过 500 个 AI 模型，包括像 GPT-5 和 Claude 这样的语言模型、图像模型，以及像 Sora 和 Kling V3 这样的视频模型。

这意味着工作节点函数可以在不同的任务类型间保持无状态且一致。当流水线的不同阶段需要不同模型时，它也很有帮助，因为认证、速率限制和重试逻辑全都藏在一个集成点后面。

如何选择合适的批量大小和并行模型

一旦流水线架构确定下来，下一个决定在理论上很简单，但实践中却很容易搞砸：每个工作节点一次该处理多少工作，又该有多少个请求并行运行？

如果批次太小，你会在开销上浪费算力。如果批次太大，失败会变得代价高昂，因为重试发生得很晚，而且要重做太多工作。最佳平衡点通常来自于对运行时、内存占用和重试成本的权衡。

在运行时、内存与重试之间权衡批量大小

对大多数 LLM 工作负载来说，每批 100–500 个条目 是一个稳妥的起始区间。它足够大，能把编排开销分摊到更多工作上，但又足够小，一次失败不会逼你重跑一大块。

重试让这一点很容易想象。如果一个工作节点在一个庞大批次快结束时崩溃，你可能得把所有工作重做一遍。这就是为什么每完成 10–50 个 就设一个检查点会有帮助，这样一次崩溃只需重做一小片工作 ^[2][11]。

媒体密集型任务通常需要比纯文本任务更小的批次，因为每个响应都更大 ^[1]。

对不均衡的工作负载使用动态批处理

固定批量大小在纸面上听起来很整洁。但在生产环境里，它们常常崩溃。

流量会变化。一次通宵的批量运行可能会推送 每分钟数千个条目，而白天的流量可能来得很慢。一个固定的批量大小无法很好地应对这两种情况。

动态批处理通过在以下任一情况发生时发送一个批次来应对这个问题：

• 批次达到设定的大小

• 设定的等待窗口到期

一种常见的设置是 最大批量大小 加上 最大等待时间，比如 5 秒 ^[9][1]。在繁忙时段，大小上限被反复触发，从而保持高吞吐。在较慢时段，计时器会启动，让条目不至于一直堆在队列里。

你还可以把多个条目打包进一个提示词，把系统提示词的开销分摊到更多工作上 ^[10]。

在每个函数内部并发地发起 API 调用

一旦批量大小确定，下一步就是控制每个函数内部的并行调用。

大部分延迟通常来自等待网络响应，而不是本地计算。所以异步并发往往是合适的选择。一次发出多个请求，然后让事件循环去处理等待。

关键的部分是上限。用信号量把函数内并发限制住。一个 5–10 个并发请求 的池是一个合理的起点 ^[9][11]。再往上推得太高，你可能会撞上供应商的速率限制。

对于 LLM API，主要限制往往是 每分钟 token 数，而不是原始请求数量。所以要在一个滚动的 60 秒窗口 内跟踪 token 用量，并在供应商替你动手之前先自行限流 ^[10]。这道防线很重要，因为否则一个工作节点就可能吃光内存，或者触发整条流水线的限流。

用能达到你吞吐目标、又不会让重试成本爆炸的最简单方案。

如何在规模化时让批处理工作流保持可靠与可观测

把批量大小和并发调对只是工作的一半。随着量级增长，更棘手的部分是在出问题时保证任务安全，并快速发现问题。

在不重跑全部内容的前提下处理部分失败

一条坏记录绝不该拖垮整个批次。 如果一个输入格式错误，或者一个请求超时，那次失败就应该被限制在局部。

在实践中，每个条目的处理逻辑都需要自己的错误处理。每处理完一个分块就写一个原子检查点，然后从上一个检查点恢复，而不是从头再来。如果一个条目在 3 到 5 次重试 之后仍然失败，就把它送进 死信队列（DLQ） 供人工审查，而不是无休止地重试。在每次重试之前使用 指数退避——例如先等 1s，再等 2s，然后 4s——以避免猛砸一个被限流的 API 端点 ^[12][1][13]。

一旦恢复机制是安全的，就去跟踪它发生的频率以及代价。

让每个批处理任务都幂等

只有当一次重复运行产生相同的结果时，重试才是安全的。

这在 serverless 平台上尤为重要，因为那里的瞬时错误常常会触发自动重试。没有幂等性，这些重试就可能导致重复写入或其他被重复执行的副作用。

解决办法很简单：构建一个稳定的幂等键，比如 job_id:item_id，而不是使用运行时的时间戳 ^[14][15]。然后使用 upsert，让重新处理一个条目时替换已有记录，而不是再创建一条。对于像 S3 这样基于文件的存储，使用与工作项参数绑定的确定性输出路径，这样重跑会覆盖同一个输出，而不是创建重复项 ^[2][13]。

你还应该把 队列可见性超时 设为至少预期 p99 处理时间的 3 倍。这能防止第二个工作节点去抢一个还在第一个工作节点上运行的任务 ^[2][13]。

跟踪每批的吞吐量、延迟和成本

你需要一些指标，来显示在负载之下批处理是否仍然合理。在批次层面，跟踪：

• 每分钟处理的条目数

• 平均批处理时长

• 每个条目的重试次数

• 错误率

• 以美元计的每批成本，基于输入和输出 token 总数 ^[12][1][2]

如果成功率跌破 95%，就设一个告警 ^[1]。

只重试失败的条目。仅对非关键的补全类任务使用跳过并记录的做法。

如何为生产工作负载削减成本并提升性能

识别主要的成本驱动因素

在削减成本之前，你需要看清钱都花在了哪里。

在一条 serverless AI 批处理流水线里，AI API 的 token 用量通常是最大的开支。批处理模式在两方面有帮助：它既削减 token 花费，又降低请求开销。实践中，批处理 API 的 token 成本比同步调用低约 50% ^[5][18]。

在 token 之后，serverless 计算时长往往是下一个大头，尤其是按 GPU 运行时间计费的视频和图像任务 ^[17]。存储和数据传输也可能悄悄找上门。如果你在跨区域搬运大文件，这些费用会很快累积起来。而在高风险工作流中，对低置信度输出进行人工审查，本身就可能变成一个主要的成本中心 ^[16]。

成本模式还会随模态而变化。文本工作负载基于 token，所以通常更容易预测。视频生成的方式不同：你是按输出的秒数计费的，这意味着片段长度会直接影响花费。一个 10 秒的片段就是比 5 秒的更贵。这正是执行调优在这里如此重要的原因。

调优内存、超时、包体积和写入模式

很多最好的节省来自朴素的执行调优，而不是花哨的技巧。

把客户端超时设为 60 秒或更长。以流式方式读写 JSONL 输入和输出，而不是一次性把大批数据加载进内存。这一个改动就能降低内存压力，让批处理任务不那么脆弱。只在 VRAM 是瓶颈时才使用量化 ^[5][18]。

这些都是小调整，但它们能在不改变任务本身的情况下削减浪费。

一旦内存使用和 I/O 处于不错的状态，下一个大杠杆就是模型选择。

让模型选择和批处理策略匹配业务目标

最大的成本杠杆是为任务挑选合适的模型。

像 GPT-5 或 Claude Opus 这样的前沿模型，用在复杂推理上是合理的。但对于分类或抽取，它们可能大材小用。一个更轻量的模型往往就够了。在许多流水线里，对大约 80% 的任务 使用更轻量的模型，把更重的模型留给另外 20%，可以把平均成本削减 70% 到 90% ^[18][19]。

一种简单的划分往往效果不错：

• 用更轻量的模型做抽取和分类

• 把更重的模型留给推理

• 根据任务复杂度调整批量大小

如果你需要把不同的任务类型路由到不同的模型，APIMart 用一个 API 就能覆盖超过 500 个模型。

在扩展之前，先跑一次 10 到 50 个条目的试运行 来测量每个条目的成本。这能让你在量级攀升之前，清晰地读到每个任务大概会花多少钱。

结论：改进批量 AI 工作流最简单的方式

一旦你的流水线、批量大小、可靠性检查和成本防线都设好了，扩展就会简单得多。扇出并行、大小合适的批次 和 严格的重试处理，是把一个缓慢的、顺序执行的任务变成可以在生产环境运行的东西的主要杠杆。

让失败保持在局部。让重试幂等。把预期结果与实际输出做对账。这就是当出问题时防止系统跑偏的那一部分。在这之后，成本通常会成为下一个限制。

以 每批运行的美元数 来跟踪花费，这样你就能把成本关联回每个任务，并揪出昂贵的异常值 ^[2]。用 10 到 50 个条目的试运行 开启新的工作负载，验证你的 每个条目的成本，然后在账算得通之后再扩展 ^[1][3]。

对大多数任务，应该让更小的模型来挑大梁。把更大的模型留给更复杂的生成工作。而如果一条批处理流水线要跨多种模态和模型类型运行，像 APIMart 这样的单一层可以通过一个 API 让路由保持简单。正是这种组合，让批量 AI 工作流在生产规模上更可预测。

常见问题

我该在什么时候用批量处理而不是实时 AI 调用？

对那些不处于用户关键路径、可以等上几分钟到几小时的工作，使用 批量处理。

它很适合像下面这样的离线任务：

• 大规模数据补全

• 文档分析

• 向量索引创建

• 定时报表

只有当有人正在另一端主动等待时，比如交互式聊天或实时问答，才使用 实时端点。

我该如何为我的工作负载选择合适的批量大小？

对于应用层批处理，从 50 到 100 个条目 起步。在很多情况下，最佳区间落在 100 到 500 之间。如果你使用供应商原生的批处理 API，可以做得大得多——有时单个批次多达 50,000 个请求。

目标是找到一个能在效率和失败隔离之间取得良好权衡的批量大小。你希望它足够小，让重试不至于太昂贵，但又足够大，能削减编排开销。

对于动态推理，根据 VRAM 限制 和你的 延迟目标 来调整批量大小。

我该如何在重试期间防止重复处理？

让你的流水线 幂等，这样再次处理同一个条目每次都会得到相同的结果。

使用一个稳定、不可变的幂等键。在运行任何工作之前，检查这个键是否已经被认领或处理过。然后使用 upsert 加上唯一约束来防止重复写入。

保留一份已处理文档 ID 的登记表也很有帮助。它给了你一个简单的办法，在重试或恢复运行时跳过已经完成的条目。