Batch 批量接口机制对照：GLM、Kimi、Grok、Gemini 差在哪
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
四家的 Batch 都宣称「按低于标准价计费、不占实时限流」，但只要你真去写代码，会发现它们连「一个批次是什么」都没定义成同一个东西。 GLM 和 Kimi 是标准的 OpenAI 式文件流：传 JSONL、拿 file id、建任务、轮询状态、下载结果文件，状态枚举几乎一模一样。Grok 完全是另一套：批次是一个可以往里持续追加请求的容器，状态不是一个字符串而是一组计数器，结果可以边跑边分页取。Gemini 则允许把请求内联进一次调用，不必非得走文件。动手之前最该先确认的差异有三处：一个批次能不能混模型、混端点；超时之后已完成的部分算不算钱；结果文件的保存期和批次的过期时间是两回事。下面按你真正会写的操作顺序一段段过。
一、提交形态：文件式、内联式、容器式
GLM 的官方批处理文档只给了一条路：把请求写成 .jsonl，每行一个 JSON 对象，用文件接口上传且上传时 purpose 标记为 batch，再拿 input_file_id 去创建任务。
Kimi 的形态和 GLM 同源，同样是 JSONL 上传时 purpose 设为 batch，然后带着 input_file_id 创建任务。Kimi 还额外提供了控制台路径——在用户中心的项目管理里直接创建批任务、上传数据文件、下载输出，不用写代码；官方说明这条路径有用户层级门槛，具体层级以官方文档为准。
Grok 的设计是「先开容器，再往里塞」。你先 POST /v1/batches 创建一个批次拿到 batch_id，之后调用批次的 requests 接口把请求一批批加进去，每条请求带一个 batch_request_id。它也支持 JSONL 文件方式，但官方明确写了一句很关键的话：文件方式创建的批次在创建后就被封存，不能再通过追加接口往里加请求。也就是说 Grok 的两种提交方式不是同一个东西的两张皮，选了文件就放弃了增量追加能力。
Gemini 官方文档给的是内联与文件两选一：内联是把 GenerateContentRequest 对象列表直接放进 BatchGenerateContentRequest，官方说适合总请求体较小的批次，输出是 inlineResponse 对象列表；请求集较大时官方推荐 JSONL，通过 File API 上传，REST 走 resumable 协议。
二、结果怎么对回请求：四个字段四种叫法
批量任务最怕的就是结果回来对不上号。四家都提供了对账字段，但命名和约束不同：
- GLM：每行必须有
custom_id且文件内唯一，官方明说它的作用就是把结果和输入做匹配。 - Kimi：
custom_id、method、url、body四个字段全部必填，custom_id文件内唯一。 - Grok：字段叫
batch_request_id，不传的话平台会自动生成一个 UUID。官方建议用你自己的 ID，理由给得很实在——一是幂等性，二是方便把批次请求和你自己系统里的记录挂上钩。走 JSONL 时字段名回归custom_id，官方说明它映射到batch_request_id。 - Gemini：用用户自定义的
key，响应会用同名 key 标注回来。
差异看着小，但如果你写的是一层跨厂商封装，这里就是必须做映射的第一个点。
三、一个批次能装多杂：模型与端点的混用边界
这一条是四家规则差得最开的地方，而且限制都写在文件格式与创建参数上，属于提交之后由平台校验、校验不过整批直接被判失败的那一类——GLM 与 Kimi 的状态枚举里就专门有「校验中」和「校验未通过」两档，Grok 则写明只要文件里有一行不合法，整个批次会带着错误信息被取消。
GLM 的创建参数里 endpoint 是必填，官方说明目前支持 /v4/chat/completions；同时文件限制那节写死了一条：每个 batch 文件只能包含对单个模型的请求。
Kimi 更严：url 固定为 /v1/chat/completions，method 固定为 POST，所有行的 model 必须相同，一个批次只允许一个模型。还有一条容易忽略的坑——官方明确写了批量模型的 temperature、top_p、n、presence_penalty、frequency_penalty 不可修改，请勿在 body 中设置。你把实时调用的参数原样搬进 JSONL，就是在给自己埋雷。顺带一提，Kimi 的指南页和批量推理定价页给出的可用模型范围并不完全一致，动手前请以官方文档当前版本为准。
Grok 反过来，是唯一明说可以混的：JSONL 里可以混不同端点，每条请求独立路由，支持的 url 取值涵盖对话补全、responses、图像生成与编辑、视频生成编辑与扩展等多种（枚举以官方文档为准）。但它加了另一道闸：只有启用了批量的模型才被接受，不支持的模型会被直接拒绝。
Gemini 的限制最干脆——官方页首的注意事项写着 Batch API 目前仅适用于 generateContent。
四、状态机：一个字符串 vs 一组计数器
GLM 和 Kimi 用的是同一套状态枚举，字面几乎重合：validating（校验中）、failed（校验未通过）、in_progress（执行中）、finalizing（结果准备中）、completed（完成）、expired（未在期限内完成）、cancelling、cancelled。轮询代码就是判断这个字符串。
Grok 把状态拆成了两层。批级看的是 batch.state 里的一组计数器：num_requests、num_pending、num_success、num_error、num_cancelled；官方给的判完标准不是某个状态字符串，而是**num_pending 归零**。请求级另有一套 pending / succeeded / failed / cancelled，通过列出批次请求的接口拿到。
这个差异直接影响你的轮询逻辑：在 GLM 和 Kimi 那边，一个批次要么没好要么全好；在 Grok 那边，你天然能知道「跑完多少、错了多少」，做进度条不用自己数。
五、拉结果：等全批完成，还是边跑边取
GLM 完成后给两个文件 ID——output_file_id 装成功结果，error_file_id 装出错请求，官方要求分别下载。Kimi 同样是这两个字段。
Grok 明确写了结果可以在整批完成之前就取，单条请求一完成结果就可用。取的时候走分页，用 limit 控制每页大小、pagination_token 翻页，pagination_token 为空即到底。另外它提醒图像与视频结果返回的是带签名的 URL，会在一段时间后失效，官方要求拿到后尽快下载。
Gemini 的输出形态跟着提交形态走：内联提交拿到 inlineResponse 列表，JSONL 提交拿到的输出也是 JSONL，每行是一个响应对象或状态对象。
六、超时与过期：已经跑完的那部分算不算钱
这一节是真金白银，值得单独看。
GLM 的 completion_window 参数已被官方标为废弃，说明里写得很清楚：原有时间参数不再适用，改由系统按负载自动调整调度。真正要留意的是它的过期处理规则——批次未能及时完成会被标记为过期，未完成的请求被取消，但已完成的请求结果仍可通过文件取回，且这些请求消耗的费用需要照付。所以「任务过期」在 GLM 这里不等于「白跑一趟不花钱」。GLM 还有一个 auto_delete_input_file 开关控制是否自动删除原始批处理文件，以及一个 metadata 字段用来挂你自己的业务标识。
Kimi 的 completion_window 是创建任务时的必填参数，是一个时间窗字符串，任务没在窗口内完成就变成 expired。官方在扩展建议里给的取向是：数据量大就把窗口设长一点，较长的时间窗可以提高任务完成率。
Grok 用的是 expires_at：批次有过期时间，过期之后结果就取不到了，官方让你在查批次详情时留意这个字段。取消的语义也写明了——取消后 pending 的请求不再处理，但已完成的结果依然可取。
Gemini 侧，官方文档给出的是一个目标周转时间与「多数情况更快」的说明，具体时长以官方文档为准；至于批次过期后的计费归属，官方文档里没有找到相关说明。
顺带一提，GLM 还有个前置门槛和上面几家都不一样：官方要求调用 Batch API 之前必须完成实名认证（个人或企业），没认证就用不了。
七、限流：Batch 是另一本账，但不是没有账
四家的共同点是 Batch 不吃实时限流的额度，但各自新加的约束完全不同：
- GLM：官方说明 Batch 的并发限制与每个模型现有的并发限制是分开的，同时引入了单个批处理文件的请求数与体积上限、以及每个模型的最大排队限制；排队满了要等当前任务跑完再提交新的。文件本身也有数量上限和保留期，过期自动删除且无法恢复。
- Kimi：定价页写明 Batch API 不受实时并发限制，适合大批量任务。
- Grok：批量请求不计入 rate limits，但另有独立的批次创建速率上限、单条请求负载体积上限，以及团队维度的追加请求调用频次滚动限制（具体数值见官方文档）。
- Gemini：Batch 限流完全独立于非批量调用，另有并发作业数、输入文件大小、文件存储总量、每模型排队 token 数四类约束。
换句话说，「不占实时限流」不等于「随便压」。Grok 那条追加调用的滚动限制值得单独记一笔：官方写明它是团队维度的、在团队名下所有批次之间共享，所以你用多线程往不同批次里狂加请求，撞的不是模型限流而是这条。
八、国产新锐这边：MiniMax 与阶跃星辰没找到
MiniMax 与阶跃星辰的官方文档里，没有找到面向对话补全的 Batch 批量接口说明。MiniMax 文档中出现 batch 字样的地方是本地部署指南里 vLLM 的连续批处理与启动参数，跟平台侧的异步批量接口不是一回事。如果你的选型前提就是「必须有官方 Batch 通道」，这两家目前需要另行向官方确认。
九、还有一处只有一家写了：批量里的工具调用
Grok 的文档单列了一节讲批量场景下的工具使用：服务端工具（网页搜索、代码执行、MCP 等）在批量里的行为与实时 API 一致，在处理过程中执行、最终响应直接返回；客户端函数工具也支持，模型会在响应里返回 tool_calls 交给你离线处理，但多轮工具调用需要你把工具结果拼进对话后再提交一个新的批量请求。其余三家的批量文档里没有找到同类说明。
这对做 Agent 类离线任务的人很关键：多轮工具循环在批量模式下天然要被你拆成多个批次串起来，不能指望平台在批次内部帮你转圈。
收尾：选型前先问自己三个问题
第一，你的任务能不能拆成「同一个模型、同一个端点」？能，GLM 和 Kimi 的文件流最省事；不能，Grok 的混端点批次和边跑边取才有意义。
第二，你能不能接受「过期后已完成部分照付」？GLM 把这条写在明面上了，别等账单出来才发现。想把成本口径彻底捋一遍，可以对着 缓存与 Batch 的省钱路径对比 一起看，这两条省钱路的适用场景并不重叠。
第三，你的封装层准备抽象到哪一层？如果只抽「提交—轮询—取结果」三个动作，四家都能塞进去；一旦你想统一暴露进度百分比，就会发现只有 Grok 天然给了计数器，其余三家得靠状态字符串加自己记录的请求总数凑。
具体到每家的完整调用流程和踩坑点，可以接着看 GLM Batch API 使用流程、Kimi Batch API 指南要点 和 Grok Batch API 的容器式设计。提交之前，先把 JSONL 里的 model 和 url 两个字段各自去重扫一遍、确认 custom_id 在文件内不重复，这三下花不了几行代码，却正好卡住 GLM 与 Kimi 明确写死的那几条硬约束。