批量推理的快与慢：不能一概而论

批量推理的快与慢：不能一概而论

最近在做一个用到大模型 API 的项目，需求并不复杂：从网页正文里提取关键词，识别品牌名及其别名，再判定文章对该品牌的情感倾向——正面或负面。这类语义理解与情感分析正是大模型所擅长的，并不需要深度推理。

任务简单，但量不小。最朴素的场景，一百来篇文章。逐条调用 API，或常规并发调用，要么触发频率限制，要么整体吞吐太慢。

一番调研后发现，像火山引擎这类平台，除了单条调用的 API，还提供「在线推理」与「批量推理」两种方式。批量推理又分两种模式：批量推理任务，处理静态存储的数据；类在线推理方式的接入点，处理动态数据。我的场景是成批的网页文章，属于前者。此前未曾用过，研究下来发现它恰好适配——提示词几乎不变，变化的只是输入数据。

一、为什么快？

批量推理与我原先的设想不同。我曾以为批量只是把请求堆在一起发送，其实不然——它真正的优势在于：当所有请求共享同一套提示词、只有数据内容在变时，服务端的缓存命中率极高。

官方的说法更直接：输入输出单价为在线推理的 50%，命中缓存后输入单价还能再降 60%——缓存红利不只是速度，也是成本。配额上默认 100 亿 token/天，支持工单提额，且得益于灵活的调度策略，高峰期仍能保持可观的处理速率。

我将 300 篇文章一次提交，本已做好等待的准备，结果一两分钟便返回——超出预期。

这个接口在使用时有几个要点：

• 极高的并发。以异步 IO 方式调用，5 万并发亦可承载。前提是解除本地的并发限制，避免客户端自身成为瓶颈。
• 超长的超时设置。数千条请求在服务端并行处理需要时间，超时宜设长——24 小时的超时并不罕见，也是批量任务的常态。
• 429 的指数退避重试。服务端过载会返回 429，不应硬性重试，而以指数退避策略等待其恢复后再发。

值得一提的是改造门槛：Batch Chat 接口的参数与普通 Chat 接口一致，只需关注超时与并发策略即可切换，无需改动业务逻辑——这也是我能快速上手的原因。

返回后一次性取回批量结果。整个过程，几分钟即可完成。

二、换个深度推理模型，结果截然不同

就在我以为找到了理想方案时，今天又试了一次——这次换用了深度思考的 doubao-seed-2-1-pro，且正值周日。几乎相同的场景，表现却截然不同。

此前在 doubao-seed-2.0-mini 这类轻量模型下，几分钟即可完成；这次换上深度推理的 doubao-seed-2-1-pro，几乎无法推进。

官方文档中所述的「等待与排队」并非虚言。在不拥挤的模型上，排队几乎不存在；但在较为拥挤的、或思考深度更高的模型上，批量推理的快法便失效——上千条请求进入队列，深度推理本身较慢，越深越慢，堆积只会加剧。

但这一次的慢，究竟该归咎于 doubao-seed-2-1-pro 本身推理更深、更慢，还是周日平台容量紧张、排队加剧，单凭一次对比难以分清。

结论：不能一概而论

批量推理的快慢，不能只看接口。doubao-seed-2.0-mini 上又快又稳，doubao-seed-2-1-pro 上几乎跑不动——但这并不意味着「深度推理模型就不该用批量」。深度推理的适用场景与真实效果，需要自己去交叉验证：有时瓶颈在模型自身的推理深度与速度，有时则在平台的并发容量与排队状况，二者交织，不能一概而论。

接口提供了高并发、长超时、指数退避这些手段，平台也给了低单价、高配额与灵活调度，但最终跑得快不快，是模型、平台容量、时段共同决定的——三者的组合，只有实测才说得清。

参考链接：火山引擎 · 批量推理