多人同时请求摘要，BentoML 可以在服务端把输入合成批次

几个用户同时要求摘要，模型往往可以一次处理一组文本，客户端却不一定能等大家一起提交。BentoML 的 adaptive batching，处理的正是这处差异：应用各自发送请求，服务端再收集成适合模型处理的批次。

它适合已有推理代码、准备提供在线接口的开发者。最终要接通的是独立请求、模型批输入和逐项结果，而不只是把一个 Python 函数换成网址。

凑一批，由服务里的调度器负责

官方说明把两个概念分开：batch window 是等待收集输入的时间，batch size 是单批规模。dispatcher 在服务端收集请求，达到条件后交给模型。

因此，低流量时和高流量时不必一直采用同一种固定等待。算法会根据近期请求和处理时间调整，但仍受开发者设置的范围约束。合批不是无限排队，也不是每来一个用户就立刻独占一次模型运行。

默认没有开启这项功能。开发者需要为合适的接口声明 batchable，而模型实现也必须真正能够处理一组输入。

文档用 Summarization 展示：summarize 接收 list[str]，调用模型处理这组文本，再返回每项 summary_text 组成的列表。列表不是为了让界面看起来整齐，而是模型和调度器之间的批量约定。

如果一次请求还有图片路径、阈值等多个参数，指南建议先组合成 Pydantic 对象，再把这些对象组成列表；还需要一个包装服务接收客户端的单个请求，转交内部的批处理接口。那份图片例子只原样返回路径，用于演示参数组织，并不是已完成的视觉模型推理。

批内请求顺序也不能作为业务上的到达顺序保证。应用仍应保留自己的记录身份，模型函数则要确保每个输入与相应输出一致，别在处理中只留下无法关联的一组文本。

max_batch_size 限制单批上限，max_latency_ms 则控制批处理延迟范围。只追求更大批次，可能让交互等待变长；资源不够，也可能无法及时处理。

官方文档说明，服务处理不过来并超过延迟限制时，可以返回503。这意味着客户端还需要理解过载状态；合批是一种调度方式，不是把资源不足问题自动抹掉。

BentoML 的入门材料还展示将服务打包为 Bento，再生成容器镜像。框架采用 Apache-2.0，模型权重和部署资源分别判断。对摘要、嵌入等可批处理功能，值得观察的结果是：用户保持自己的请求方式，服务能否用有边界的等待，把这些请求更合适地交给模型。