简介
绝大部分 AI 应用里有两种调用：用户正在等结果的（实时），和用户根本不在场的（批量）。
批量那一类——给 10 万条评论打情感标签、从 5 万份合同里抽条款、把知识库全量重写成 Q&A、给历史工单做归因——如果还走实时 API，等于花全价买了一个你并不需要的低延迟。
Doubleword 就是为这一类工作负载做的推理 API：你提交一个批任务，平台在后台用高吞吐方式跑完，再把结果文件给你。价格通常是实时调用的零头。
为什么批处理会便宜这么多
GPU 利用率。实时调用的显存与算力必须为「随时可能到来的请求」预留，利用率常年只有一二成。批处理可以把请求攒够、连续打满显存，同样的卡能跑出数倍吞吐。
调度自由度。批任务不承诺延迟，平台可以在闲时、在便宜的卡上、用更激进的批大小（batch size）去跑。
无状态。不需要为每个请求维持长连接上下文，工程开销小。
这三条决定了：只要你的事能等，就不该付实时调用的钱。
典型用法
from openai import OpenAI
client = OpenAI(base_url="https://api.doubleword.ai/v1", api_key="YOUR_KEY")
# 1. 上传批量请求文件（JSONL，每行一个请求）
batch = client.batches.create(
input_file_id="file-abc123",
endpoint="/v1/chat/completions",
completion_window="24h",
)
# 2. 轮询状态，完成后下载结果
while client.batches.retrieve(batch.id).status not in ("completed", "failed"):
time.sleep(60)因为这个接口和 OpenAI 的 Batch API 形态一致，很多团队的做法是：开发期用实时接口调通逻辑，上线前把同一个函数切换到批处理客户端，业务代码零改动。
什么场景最适合
- 全量数据回填：给历史数据库里所有记录补一个 AI 字段
- 内容审核与分类：百万级 UGC 的批量打标
- 知识库重构：把旧文档批量改写成结构化问答
- 合成数据生产：为微调生成大批训练样本
- 离线评测：把同一批测试集跑过多个模型做对比
什么场景不合适
实时客服、Copilot 补全、语音 Agent——任何用户盯着屏幕等结果的场景，都不该走批处理。批处理的等待窗口是分钟到小时级。
选型建议
- 先算账：把你现在每月实时调用的 token 拆成「可离线」和「必须实时」两部分，前者通常是 60%–90%
- 验证兼容性：用 OpenAI SDK 打一个 100 条的小批次，确认返回结构与你的解析代码对齐
- 管好状态：批任务需要任务表（记录 batch id、文件 id、状态、失败行），不要只靠内存里的轮询
- 留降级路径：批处理平台偶发排队，关键链路要能回落到实时接口
