批处理 API:作为行业标准的五折优惠

批处理 API:作为行业标准的五折优惠

本节摘要:每个主要厂商都提供带 50% 折扣、约 24 小时周转的异步批处理 API。OpenAI、Anthropic、Google,以及大多数推理平台(Fireworks 批处理层、Together batch)都实现了同一模式。把批处理与提示缓存叠加,夜间流水线能降到同步未缓存成本的约 10%。规则简单到残酷:不是交互的,就该走批处理。内容生成流水线、文档分类、数据抽取、报告生成、批量标注、目录打标——任何能容忍 24 小时延迟的工作负载,在迁到批处理前都是把账单留在桌上。2026 的生产模式是把每个新 LLM 工作负载分进三条道:交互(同步 + 缓存)、半交互(异步队列 + 回落)、批处理(夜间、缓存输入叠加)。最浪费的是那些「装作交互、其实能容忍几分钟延迟」的工作负载。

对应原课程:Phase 17 · Lesson 15 · 15-batch-apis(原英文 phases/17-infrastructure-and-production/15-batch-apis/docs/en.md)。

学习目标

阅读完本节,你应当能够:

1. 说出三大厂商的批处理 API(OpenAI、Anthropic、Google)及共同的 50% 折扣 + 24 小时周转保证。
2. 算出在夜间分类工作负载上叠加批处理 + 缓存输入的成本,对比同步未缓存基线。
3. 把工作负载分进交互/半交互/批处理三道,并论证分道。
4. 点名两个陷阱:部分交互性(用户期待快于 24 小时)与输出 schema 漂移(各厂商批处理文件格式不同)。

一、问题与直觉

你的团队上线了一条夜间报告生成流水线。5 万份文档,各做摘要,聚类摘要,起草高管简报。同步跑要 4 小时,每晚 2000 美元。你听说了批处理 API。

批处理给你五折。你还在系统提示(5 万调用共享)上开了提示缓存。叠加后,账单降到每晚约 180 美元——基线的约 9%。同一流水线,三处配置改动。

批处理是 LLM 成本工具箱里最便宜却没人拉的杠杆。原因多是组织性的:团队想着「实时」,实际 SLA 是「明早前」。本节就是讲别把 90% 账单留在桌上。

二、核心概念

三大批处理 API

OpenAI Batch API:上传 JSONL 文件含请求列表。承诺 24 小时周转(实践常 2~8 小时)。输入输出 token 五折。/v1/batches 端点。可缓存输入还叠加缓存输入定价。

Anthropic Message Batches:JSONL 上传。24 小时周转。五折。支持 cache_control——缓存写显式,读在批处理内自动。

Google Vertex AI Batch Prediction:BigQuery 或 GCS 输入。Gemini 类似五折。与 Vertex 流水线集成。

语义:异步,不是慢

批处理是「我承诺 24 小时内返回」——不是「这会花 24 小时」。典型 P50 是 2~6 小时。厂商在你批处理时调度到 off-peak 窗口,GPU 库存利用率不高。

与缓存叠加

5 万文档摘要 + 同一 4K token 系统提示:

• 同步未缓存:50000 ×(input × 4000 + output × 200)全价。
• 同步缓存:系统提示首次写后缓存;余下 49999 次输入便宜 10 倍。
• 批处理缓存:以上全部,再加读写各五折。

叠加:批处理 + 缓存 ≈ 同步未缓存账单的 10%。任何夜间跑、有共享系统提示的工作负载都该用。

工作负载分道

交互 —— 用户等响应。TTFT 关键。同步调用 + 提示缓存。不能批。

半交互 —— 用户提交任务,几分钟回来查。异步队列 + 批处理不可用时回落同步。想中等量 RAG 索引。

批处理 —— 用户期待「明早」或「下小时」结果。内容流水线、规模化分类、离线分析。永远批处理、永远叠缓存。

常见错误:因为流水线是生产级就全归交互。生产不是延迟规格——SLA 才是。

部分交互性陷阱

有些特性看着交互,其实能忍 5~10 分钟。例:夜间客户健康报告带「刷新」按钮。用户点刷新,等 10 分钟没问题。团队做成同步,50 个并发刷新的成本是「批处理后邮件投递」的 10 倍。

要问的问题:「24 小时对这个用户意味着什么?」若答「他们不会注意到」,就批。

输出 schema 陷阱

批处理文件格式各厂商不同:

• OpenAI:JSONL,一行一请求。
• Anthropic:JSONL,一行一消息;响应格式内嵌。
• Vertex:BigQuery 表或 GCS 前缀带 TFRecord。

跨厂商写「一个批处理客户端」意味着每厂商一套适配代码。宣传多厂商批处理的网关(Portkey、LiteLLM 部分层级)仍是薄包原始格式。

你该记住的数字

• 跨厂商批处理折扣:输入 + 输出统一五折。
• 周转 SLA:保证 24 小时,典型 P50 2~6 小时。
• 批处理 + 缓存输入叠加:约同步未缓存的 10%。
• 分道规则:24 小时延迟可接受就永远批处理。

三、从零实现:批处理 vs 同步成本模拟器

原课程 code/main.py 跨同步、同步+缓存、批处理、批处理+缓存,为 5 万文档工作负载算成本,报告美元与百分比节省。下面给最小可读骨架。

def pipeline_cost(num_docs, sys_tokens, out_tokens, fresh_in_per_m, out_per_m,
                  cached_in_per_m, mode="sync_uncached"):
    """估算一条文档处理流水线的成本。

    mode: 'sync_uncached' / 'sync_cached' / 'batch_uncached' / 'batch_cached'
    """
    cached = "cached" in mode
    batch = "batch" in mode
    in_rate = cached_in_per_m if cached else fresh_in_per_m
    discount = 0.5 if batch else 1.0
    in_cost = num_docs * sys_tokens * in_rate / 1e6 * discount
    out_cost = num_docs * out_tokens * out_per_m / 1e6 * discount
    return round(in_cost + out_cost, 2)


# 案例:5 万文档,4000 系统提示,200 输出
base = pipeline_cost(50000, 4000, 200, 3.0, 15.0, 0.30, "sync_uncached")
stacked = pipeline_cost(50000, 4000, 200, 3.0, 15.0, 0.30, "batch_cached")
print(f"同步未缓存 ${base} → 批处理+缓存 ${stacked} ({stacked/base*100:.0f}%)")
# 这正是『三处配置改动,账单降到 10%』的算术
​

💡 分道不是技术决策,是产品决策。拉着产品经理逐特性过一遍「这个真的需要 < 1 分钟吗?」,你会惊讶有多少能进批处理道——而每迁一个,成本就降一档。

四、框架对比:三大批处理 API 横向对照

心法:三家厂商模式一致(五折 + 24h),差异在文件格式。跨厂商要用网关(Portkey/LiteLLM)抹平,或写适配层。批处理 + 缓存叠加是夜间工作负载的默认。

五、可复用产物

本节产出 outputs/skill-batch-triager.md(原课程目录)。给定工作负载特性,它分进交互/半交互/批处理并估节省:

1. 分道判定:按 SLA(秒/分钟/小时)分道,带论证。
2. 成本对比:同步 vs 同步+缓存 vs 批处理 vs 批处理+缓存的美元与百分比。
3. 部分交互性审计:找出「装交互、能忍分钟」的特性。
4. schema 适配:各厂商批处理文件格式的适配清单。

六、练习

1. 跑通模拟器:运行 code/main.py。对 10 万文档、3K 系统提示、500 输出的流水线,算全栈(批处理 + 缓存)vs 同步基线的节省。

2. 真实产品分道:挑一个你熟悉的真实产品的三个特性,各分进交互/半交互/批处理。

3. 抱怨判断:某用户抱怨报告花了 3 小时。这是批处理误分道,还是合理交互?写出判定准则。

4. SLA 沟通:你的批处理 API 返回 SLA 是 24h 但 P99 是 20h。你如何向用户沟通?边界情况下下游系统行为是什么?

5. 盈亏平衡:在多长的共享前缀下,批处理 + 缓存变得比在你自己预留 GPU 上跑一整夜更便宜?

本节要点回顾

1. 批处理是行业标准:OpenAI/Anthropic/Google/推理平台都给五折 + 24h 周转。
2. 异步不是慢:24h 是保证,典型 P50 2~6 小时,调度到 off-peak。
3. 批处理 + 缓存叠加 ≈ 同步未缓存的 10%:夜间 + 共享系统提示就该用。
4. 三道分法:交互(同步+缓存)、半交互(异步+回落)、批处理(夜间+叠缓存)。
5. 生产 ≠ 延迟规格:SLA 才是,别因「生产级」就全归交互。
6. 部分交互性陷阱:能忍 5~10 分钟的特性做成同步是 10 倍浪费。
7. 输出 schema 各厂商不同:JSONL 细节(OpenAI/Anthropic)vs BigQuery/TFRecord(Vertex),跨厂商要适配。
8. 最省钱的杠杆没人拉:组织上以为「实时」,实际 SLA 是「明早前」。

下一节,我们看降本的另一块拼图——模型路由:如何用一个便宜的小模型处理大多数请求,只把难的交给前沿大模型,把平均成本砍掉一大截。