批量推理这件事过去一年在圈子里被讨论得越来越多。原因很直接大家手里的任务从偶尔调一次模型变成了每天要跑几万条数据比如给商品描述打标签、批量翻译用户评论、对历史工单做意图分类、给内容库生成摘要。这些活儿有个共同点——不要求实时返回但量大、重复、成本敏感。OpenRouter 推出 Batch API 并且给出半价本质上就是冲着这类场景来的。它把能等的任务和要快的任务分开定价让愿意把请求攒起来一起提交的人用一半的钱办同样的事。这篇内容我会围绕这个 Batch API 展开讲清楚它适合谁、背后的计费逻辑是怎么回事、怎么接入、批量任务在工程上要注意哪些坑以及我自己在跑批处理时踩过的那些教训。不管你是刚接触 OpenRouter 的新手还是已经在用它跑线上业务的开发者应该都能从里面找到能直接抄作业的部分。1. 先搞清楚 Batch API 到底解决的是哪类问题1.1 实时推理和批量推理的成本差在哪要理解半价这件事得先明白为什么批量能便宜。实时推理的请求是来了就得算服务方必须预留足够的算力随时待命峰值来了要能扛住低谷时这些算力又闲着。这种模式对基础设施的要求高成本自然摊在每一次调用上。而批量推理不一样请求先攒着服务方可以在算力空闲的时段集中处理调度上更从容资源利用率能拉高不少。省下来的这部分平台愿意让利给用户就形成了半价的空间。这个逻辑其实和快递很像。你寄一件东西要求次日达走的是航空加急贵你把一批货攒起来走陆运专线慢两三天但单价低一大截。Batch API 就是那个陆运专线它不承诺秒回但承诺便宜。所以判断一个任务适不适合走 Batch核心就一句话这个结果我能不能等。能等就走 Batch不能等老老实实走实时接口。1.2 哪些任务天生适合走批量我梳理了一下自己手头跑过的任务适合 Batch 的大致有这么几类。第一类是离线数据加工比如把几万条历史评论做情感分类、给一批文章生成关键词、对用户反馈做主题聚类的前置打标。这些数据本来就是存量早几小时晚几小时出结果没人催。第二类是周期性报表和摘要比如每天凌晨把前一天的运营数据汇总成一段自然语言总结这种任务天然就是批量的节奏。第三类是内容生产流水线比如给一个商品库批量生成卖点文案、给视频库批量生成标题和简介量大且可以排队。反过来对话式交互、实时搜索增强、需要根据上一步结果决定下一步的 Agent 流程这些都不适合 Batch。因为它们的下一步依赖上一步的即时输出你没法把整条链路攒起来一起提交。我见过有人试图把多轮对话塞进 Batch结果就是体验直接崩掉用户等半天没反应。所以选型的第一道门槛永远是这个任务的结果有没有人在实时等。1.3 半价背后的账怎么算才不亏半价听起来很香但不是所有任务都值得为了省钱去改架构。我一般会算一笔账假设一个任务每天要跑 10 万次调用实时接口每次成本是 XBatch 是 0.5X那一天省下来就是 5 万乘 X。如果这个任务本身对延迟不敏感改造成本又低那这笔账非常划算。但如果改造要引入一套任务队列、结果回写、失败重试的完整链路而任务量只有几百次那省下的钱可能还不够你调试的时间成本。还有一个容易被忽略的点Batch 的计费通常和实时是分开统计的你要确认自己的用量统计口径别到时候对不上账。另外半价是针对 token 计费的部分如果平台还有其他附加费用得单独看清楚。我的建议是先拿一个中等规模的任务做试点跑一轮把实际账单和预估对一遍确认没问题再全量迁移。2. OpenRouter 的 Batch 接口在工程上怎么接2.1 提交任务前要准备的东西接入 Batch 之前有几样东西得先备齐。首先是API Key这个在 OpenRouter 的控制台里生成生成后要妥善保存因为它只完整显示一次。其次是确认你要用的模型是否支持 Batch不是所有模型都开放批量通道这个在模型列表里会有标注。第三是准备好你的请求数据通常是一个 JSONL 文件每一行是一个独立的请求对象包含模型、消息体、以及一个自定义的标识字段方便你后面把结果和原始请求对应起来。这里有个细节很多人第一次会踩JSONL 里每一行的结构必须严格符合接口要求多一个字段少一个字段都可能整批失败。我一般会先写一个小脚本把要提交的数据做一遍校验确认每行的字段名、类型、嵌套结构都对再正式提交。别嫌这一步麻烦批量任务一旦提交失败排查起来比单条请求痛苦得多因为你面对的是几万行数据。2.2 一个可复用的提交脚本长什么样下面这个脚本是我自己常用的模板用 Python 写的核心逻辑就是读数据、拼 JSONL、提交、拿任务 ID。你可以根据自己的字段做调整。import json import requests API_KEY 你的_openrouter_api_key BASE_URL https://openrouter.ai/api/v1 def build_jsonl(records, model, out_path): with open(out_path, w, encodingutf-8) as f: for idx, rec in enumerate(records): payload { custom_id: ftask-{idx}, method: POST, url: /chat/completions, body: { model: model, messages: [ {role: user, content: rec[prompt]} ] } } f.write(json.dumps(payload, ensure_asciiFalse) \n) def submit_batch(jsonl_path): headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } with open(jsonl_path, rb) as f: files {file: f} resp requests.post( f{BASE_URL}/batches, headersheaders, filesfiles ) return resp.json() if __name__ __main__: records [{prompt: 给这条评论打情感标签物流很快包装完好}] build_jsonl(records, openai/gpt-4o-mini, batch_input.jsonl) result submit_batch(batch_input.jsonl) print(result)这段代码里custom_id是关键它是你后面把结果对回原始数据的唯一凭据。我习惯用业务主键加序号的方式命名比如order-10086这样结果回来一眼就知道对应哪条业务数据。提交成功后你会拿到一个 batch 的 ID后面查状态、取结果都靠它。2.3 轮询状态和取回结果的正确姿势提交完不是就完事了你得盯着任务状态。Batch 任务一般会经历几个阶段已提交、处理中、已完成、部分失败。我通常写一个轮询函数每隔一段时间查一次状态直到任务进入终态。import time def poll_batch(batch_id, interval60): headers {Authorization: fBearer {API_KEY}} while True: resp requests.get( f{BASE_URL}/batches/{batch_id}, headersheaders ) data resp.json() status data.get(status) print(f当前状态: {status}) if status in (completed, failed, cancelled): return data time.sleep(interval)轮询间隔别设太短我一般用 60 秒起步。设太短纯属浪费请求而且对平台也不友好。任务完成后结果通常是一个可下载的文件里面每行对应一个请求的输出同样带custom_id。取回后第一件事就是按 custom_id 做一次完整性校验确认提交了多少条、回来了多少条、有没有失败的。这一步能帮你及早发现数据丢失的问题。3. 批量任务里那些不写文档但会咬人的坑3.1 单条失败拖垮整批的错觉很多人以为 Batch 是要么全成要么全败其实不是。批量任务通常是逐条独立处理的某一条因为内容违规、超长、格式问题失败了不会影响其他条。但问题在于如果你不主动检查失败项很容易以为整批都成功了。我就吃过这个亏一批 5000 条的任务跑完看着状态是 completed结果导数据的时候发现少了 37 条全是内容触发了安全过滤的。所以我的习惯是结果文件取回来后一定要做一次成功/失败的分组统计把失败项单独捞出来看看是偶发问题还是系统性问题。如果是偶发重试一遍通常就好如果是系统性的比如某个字段格式不对那就得回去改数据重新提交。3.2 超长输入和 token 上限的隐形墙批量任务里最容易翻车的就是输入超长。实时请求时超长会立刻报错你能马上发现但批量任务里超长的条目可能被静默截断或者直接标记失败而你如果不逐条核对根本发现不了。我建议在构建 JSONL 之前先对每条输入做一次 token 估算超过模型上限的直接截断或拆分别指望平台帮你兜底。估算 token 有个粗略办法英文大约 4 个字符一个 token中文大约 1.5 到 2 个字符一个 token。这个不准但用来做初筛足够了。要精确的话用对应模型的 tokenizer 跑一遍。我一般会在预处理阶段就把超长的挑出来要么截断要么单独走实时接口处理避免污染整批任务。3.3 结果顺序和原始数据对不上怎么办Batch 的结果不保证按提交顺序返回这是很多人第一次用会懵的地方。你以为第 1 行对应第 1 条结果发现顺序是乱的。解决办法只有一个永远用 custom_id 做关联不要依赖行号。我在处理结果时会先把结果文件读成一个字典key 是 custom_idvalue 是输出内容然后再遍历原始数据按 custom_id 去查。这样无论顺序怎么变都能准确对上。这个习惯看起来简单但能省掉大量对账的麻烦。我见过有人图省事直接用行号对应结果数据错位整批结果作废只能重跑白白浪费了时间和额度。4. 把 Batch 用出性价比的几个实战策略4.1 任务分片别把鸡蛋放一个篮子一次提交几万条听起来很爽但风险也集中。如果这一批因为某个系统性问题失败了你损失的是整批的时间和额度。我的做法是把大任务拆成中等大小的分片比如每片 2000 到 5000 条分批提交。这样即使某一片出问题影响范围可控重跑成本也低。而且分片提交还有个好处你可以先提交第一片确认整条链路跑通、结果符合预期再提交剩下的避免一次性踩坑。分片的大小没有绝对标准我的经验是看任务的总量和你的容错要求。总量大、容错要求高就分小一点总量小、追求效率就分大一点。关键是别一次性梭哈。4.2 用 custom_id 设计一套可追溯的命名规则前面反复提到 custom_id这里展开讲讲怎么设计命名规则。我的习惯是业务标识加时间戳加序号比如comment-20240520-0001。这样有几个好处一是能直接看出这条数据属于哪个业务、哪个批次二是排序方便三是出问题时能快速定位。如果你的业务有多个数据源还可以在命名里带上来源标识比如srcA-comment-0001。命名规则一旦定下来就要在整条链路里保持一致从构建输入到解析结果都用同一套。别中途换规则否则对账的时候你会想哭。4.3 失败重试要带退避别硬刚批量任务里失败重试是常态但重试策略很讲究。我的做法是指数退避加重试上限第一次失败等 30 秒重试第二次等 2 分钟第三次等 5 分钟最多重试三次。超过三次还失败的单独记录下来人工处理。千万别写个死循环疯狂重试那样既浪费额度又可能触发平台的限流。还有一点重试的时候要只重试失败的那些条目不要把整批重新提交。这要求你在解析结果时就把失败项单独存下来重试时用这些失败项重新构建一个小的 JSONL 提交。这样既省额度又快。4.4 成本监控半价也要盯着账单半价不等于免费量大了照样烧钱。我建议给 Batch 任务单独做一套用量监控记录每批提交了多少条、消耗了多少 token、实际花了多少钱。这样你能清楚地看到半价到底省了多少也能及时发现异常。比如某天用量突然翻倍可能是某个任务重复提交了或者数据源出了问题导致条数暴涨。监控的粒度不用太细按天或按批统计就够。关键是有一个基线能让你在异常时第一时间察觉。我自己是用一个简单的表格记录每批任务跑完就填一行时间长了就能看出规律。5. 从实时迁移到批量一次真实的改造复盘5.1 改造前的状态和痛点我之前有个任务是给用户提交的反馈做自动分类每天大概两万条。一开始走的是实时接口一条一条调代码简单但成本高而且高峰期经常遇到限流得加各种重试和排队逻辑。最头疼的是这个任务其实对延迟完全不敏感——反馈分类的结果是给运营看的晚几个小时出完全没影响。但当时图省事就一直用实时接口硬扛。后来算了一笔账发现光这一个任务每个月的调用成本就占了整个项目的大头。而且因为限流代码里堆了一堆重试逻辑维护起来很烦。这时候正好看到 Batch API 的消息就决定改造。5.2 改造过程中的三个关键决策改造过程中我做了三个关键决策。第一个是把任务从实时触发改成定时批量每天凌晨把前一天积累的反馈捞出来一次性提交。这个改动让整个流程简单了很多不用再处理并发和限流。第二个是引入分片机制把两万条拆成每片 4000 条分五批提交避免单批过大。第三个是建立结果回写和失败重试的闭环结果回来后自动写回数据库失败的条目进入重试队列。这三个决策里最花时间的是第三个。因为要保证数据不丢不重得设计好状态机待处理、处理中、已完成、失败待重试。状态流转要清晰否则很容易出现重复处理或者漏处理。我在这上面调了两天才跑顺。5.3 改造后的实际收益和遗留问题改造完成后成本直接降了一半这是最直观的收益。其次是代码简单了不用再维护那套复杂的重试和限流逻辑。第三是稳定性提升了因为批量任务不赶时间偶尔的失败重试对整体没影响。但也不是没有遗留问题。最大的问题是结果延迟从原来的分钟级变成了小时级。虽然业务上能接受但偶尔运营会问今天的分类怎么还没出来得解释一下。另外就是调试变麻烦了实时接口出问题能马上看到批量任务出问题得等整批跑完才知道。所以我现在养成了一个习惯每次改完逻辑先拿一小批数据试跑确认没问题再全量。6. 关于 OpenRouter 使用的一些零散经验6.1 密钥管理和额度充值的注意事项OpenRouter 的 API Key 是访问的凭据管理上要上心。我的做法是按项目或按环境分配不同的 Key比如开发环境一个、生产环境一个这样出问题时能快速定位是哪个环节的调用。Key 不要硬编码在代码里用环境变量或者配置中心管理。如果不小心泄露了第一时间去控制台吊销重新生成。关于充值OpenRouter 支持多种支付方式具体以官方控制台显示的为准。我一般会设置一个额度预警用量接近阈值时收到提醒避免任务跑到一半因为额度不足中断。批量任务尤其要注意这点因为一批提交下去消耗的额度是集中发生的不像实时调用那样平缓。6.2 模型选择不是越贵越好跑批量任务时模型选择很关键。我的原则是先用便宜模型试效果不够再升级。很多分类、打标、摘要类的任务小模型完全够用没必要上最贵的大模型。比如给评论打情感标签一个小模型就能做到很高的准确率成本却只有大模型的零头。批量场景下模型单价乘以巨大的调用量差距会被放大得很明显。当然也不是一味图便宜。如果任务对质量要求高比如生成面向用户的文案那该用好的模型就用。我的做法是先用小模型跑一批人工抽检质量如果达标就用不达标再换。这样能在质量和成本之间找到平衡点。6.3 国内访问和网络环境的现实考量关于访问OpenRouter 是一个在线服务使用它需要稳定的网络环境。我的经验是批量任务对网络的稳定性要求比实时任务低一些因为提交和取结果是两个独立的动作中间断了可以重来。但提交那一下和取结果那一下网络得通。所以我会把提交和取结果的逻辑做得健壮一些加上超时和重试避免因为偶发的网络波动导致任务失败。另外批量任务的文件可能比较大上传和下载都要考虑带宽。如果文件特别大可以考虑压缩后再传或者分片处理。我一般会把 JSONL 文件控制在几十兆以内太大了上传容易超时。6.4 一个容易被忽略的点结果的可复现性最后说一个容易被忽略但很重要的点批量任务的结果要可复现。什么意思呢就是你要记录清楚每一批任务用的什么模型、什么参数、什么时间提交的。因为模型是会更新的同样的输入今天跑和一个月后跑结果可能不一样。如果你不记录这些元信息后面想复现或者对比就无从下手。我的做法是在每批任务的记录里除了 custom_id还存一份元数据模型名、温度参数、提交时间、批次 ID。这样任何时候都能追溯这批结果是怎么来的。对于需要长期维护的项目这个习惯能帮你省掉很多扯皮。批量推理这件事说到底是一个用时间换成本的取舍。OpenRouter 的 Batch API 把半价摆在那里但要不要用、怎么用取决于你的任务特性和工程能力。我的体会是只要任务能等、量大、逻辑相对独立批量就是划算的反之如果任务对延迟敏感、链路复杂、量又不大那老老实实用实时接口反而更省心。工具是死的场景是活的想清楚自己的需求再动手比盲目追新要靠谱得多。
