效率工程：通过多请求合并与批处理将 Gemini 3.5 吞吐提升 3 倍

通过批处理将大模型 API 的吞吐量提升数倍，核心原理在于重构请求的提交方式：从单次推理转变为批量推理。每一次独立的 API 请求，模型都需要重复加载系统指令并初始化注意力机制，这带来了不小的固定计算开销。而批处理能将多个任务合并为一次推理，让模型在同一个上下文中并行处理，从而摊薄单次任务的成本。

在正式调整架构之前，建议先在 KULAAI（dl.877ai.cn） 等聚合平台上做一轮基准测试，对比 Gemini 3.5 在单请求与批量请求下的延迟与成本差异。平台集齐了主流大模型且国内网络可用，能帮你快速建立性能基线，避免闭门造车。

一、异步合并：将串行等待转化为并行计算

实现吞吐量提升的第一步，是重构应用层的请求提交架构。传统的同步阻塞模式会让应用在等待上一个请求返回时完全空闲。我们需要将客户端代码全面改造为异步非阻塞模型，使它可以连续发起多个请求而不必等待响应，并将这些请求暂存在一个收集器中。

当收集器中的请求达到预设的时间窗口或数量阈值时，便将这些独立的提示词合并成一个数组，一次性提交给模型 API。例如，不再发送单一任务，而是将若干个不同提示词打包进一个请求体中同时处理。理想情况下，这个策略能将总耗时从若干次请求的延迟之和压缩到接近一次请求的延迟。但在实践中，高并发异步需要留意客户端的连接池上限，避免因通道拥挤导致请求排队甚至被拒绝。

二、精细拼接：在单个请求内榨取 Token 效率

当多个任务共享完全相同的系统指令与业务规则时，可以在单个 Prompt 内进行更高阶的合并处理。在这种模式下，多个用户问题被拼接在一起，模型会按顺序逐一作答，并在答案之间插入清晰的分隔符。这样一来，需要重复消耗的“指令 Token”仅需付费一次。

由于合并后的输入和输出长度都成倍增加，需要警惕单次请求的超时限制。建议在服务端为这类合并请求设置更长的超时时间（如 120 秒）。为了容错，可以在应用中预设降级逻辑：如果个别任务因格式错误解析失败，可以对分隔后的结果单独进行重试，而不必废弃整批成果。

三、精确配对：利用模型原生批处理特性

大模型的推理服务端本身就是为高并发设计的。通过调用模型原生的批处理接口，可以将大量任务以文件形式上传到云端，交由服务端在后台异步处理。这是性价比极高的方案，部分厂商对此类任务的计费甚至会有折扣，因为它能高效地填充 GPU 空闲资源。

这种模式的适用场景主要是一批独立的任务，彼此之间没有依赖关系。例如，数据集标注、离线报告生成等。但它不适合在线实时交互，因为任务从提交到完成的处理周期通常在分钟级甚至小时级。

四、核心权衡：延迟、成本与容错

无论采用何种批处理方案，都需要在延迟与成本之间做出权衡。批处理窗口越长、积攒的任务越多，节省的成本就越多，但早期提交的任务等待时间也越长。为此，可以设定“强制刷新”机制，确保窗口不会无限期等待。

同时，为了保障吞吐稳定，需要实现主动队列管理。为批处理进程设置独立的并发池，并适当限制并发数，避免突发大流量导致网关超限。针对不同类型的任务，可以设定优先级，高优任务即时处理，低优任务进入排队或离线批处理队列。

最后，如果单个请求内的某个子任务执行失败，应具备优雅的容错机制。将大请求的返回结果按分隔符解析，对单个子任务的格式异常做标记或重试，不让个别失败拖垮整批产出。

通过异步合并、精细拼接与离线配对这三层手段，可以有效压榨 Gemini 3.5 的吞吐上限。关键在于合理设计批处理窗口，并在系统的各个层面加入延迟控制、容错机制和降级方案，确保业务在享受数倍吞吐提升的同时，依然稳定可靠。