mineru-api 2.6.8 多文件上传和多次单文件上传选哪一种？

[Charles7c]

大佬，我们的业务场景中，需要上传多个文件进行 mineru 解析，请问采用多文件上传和多次单文件上传（循环）哪一种效率更高？
另外，我们也涉及多用户，如果多用户场景，可以通过什么参数控制 mineru-api 的并发？

配置：arm + Ascend 910B2 * 1

[Charles7c]

@dosubot

[dosubot[bot]]

mineru-api 2.6.8 支持多文件一次上传（/file_parse 接口，files 参数为 List[UploadFile]），服务端会依次处理每个文件并聚合结果。多文件上传和多次单文件上传（循环）在服务端本质上都是串行处理，区别主要在于网络和请求管理：多文件上传减少了 HTTP 连接数和握手开销，通常更高效，推荐优先使用。

并发控制方面，mineru-api 通过环境变量 MINERU_API_MAX_CONCURRENT_REQUESTS（或 CLI 参数 mineru_api_max_concurrent_requests）限制 API 层最大并发请求数，超出会返回 503。建议根据显存和内存实际情况合理设置，避免 OOM 或 502 错误。批量推理相关参数如 MINERU_MIN_BATCH_INFERENCE_SIZE、rec_batch_num 也可通过环境变量调整，提升吞吐量但需注意内存压力[API实现细节][并发与资源管理建议]。

多用户/高并发场景下，建议采用多进程/多 worker，每个进程独立初始化模型和 CUDA 上下文，避免多线程并发访问同一模型导致崩溃。高并发或大文件处理时，建议降低 mem-fraction-static（如 0.3~0.4），定期重启服务释放底层资源，并监控系统日志（dmesg、docker logs）排查 OOM 或进程被 kill 的情况[并发与资源管理建议][多线程风险说明]。

ARM + Ascend 910B2 环境下，原则同上，重点关注显存/内存瓶颈和单 worker 资源分配，合理设置并发和批量参数，避免单进程资源占用过高导致服务不稳定。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[Charles7c]

mineru-api 2.6.8 支持多文件一次上传（/file_parse 接口，files 参数为 List[UploadFile]），服务端会依次处理每个文件并聚合结果。多文件上传和多次单文件上传（循环）在服务端本质上都是串行处理，区别主要在于网络和请求管理：多文件上传减少了 HTTP 连接数和握手开销，通常更高效，推荐优先使用。

并发控制方面，mineru-api 通过环境变量 MINERU_API_MAX_CONCURRENT_REQUESTS（或 CLI 参数 mineru_api_max_concurrent_requests）限制 API 层最大并发请求数，超出会返回 503。建议根据显存和内存实际情况合理设置，避免 OOM 或 502 错误。批量推理相关参数如 MINERU_MIN_BATCH_INFERENCE_SIZE、rec_batch_num 也可通过环境变量调整，提升吞吐量但需注意内存压力[API实现细节][并发与资源管理建议]。

多用户/高并发场景下，建议采用多进程/多 worker，每个进程独立初始化模型和 CUDA 上下文，避免多线程并发访问同一模型导致崩溃。高并发或大文件处理时，建议降低 mem-fraction-static（如 0.3~0.4），定期重启服务释放底层资源，并监控系统日志（dmesg、docker logs）排查 OOM 或进程被 kill 的情况[并发与资源管理建议][多线程风险说明]。

ARM + Ascend 910B2 环境下，原则同上，重点关注显存/内存瓶颈和单 worker 资源分配，合理设置并发和批量参数，避免单进程资源占用过高导致服务不稳定。

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

   

帮我定义一个合适的配置