[功能请求] 允许配置的并行块并发限制超过 20

功能请求: 提高或移除并行块批量大小的硬性上限(目前限制为 20) 当项目数超过此限制时,该块会自动回滚到串行批处理 – 每次处理 20 个项目,并在每个批处理完成后才开始下一个。 问题 20 的这一硬性上限对于不涉及 LLM 调用或外部 API 速率限制的用例来说是不必要的限制。例如: - 通过纯计算任务(数据转换、格式化、基于规则的路由、数学运算)处理 50–100 个项目 - 多个并行块(内部并行块)中,外部块分支为 N 个,每个内部块也同时运行 M 个任务 – 20 的限制在每个级别上都独立实施,导致复合的串行批处理,即使没有受到速率限制的资源参与。 - 所有并行任务都是自包含的函数块,不存在外部 I/O。 在这些情况下,20 项的上限强制实施了不必要的顺序等待,从而增加了总执行时间,而没有任何技术依据。 建议的解决方案 请考虑以下一种或多种方法: 1. 将默认上限从 20 提高到至少 50 或 100 2. 允许用户可配置的并发限制 – 让用户为每个并行块设置自己的 maxConcurrency 值(例如 1–200),以便根据实际工作负载和资源限制进行调整 3. 区分 LLM 和非 LLM 任务 – 仅在内部块中包含代理/LLM 节点时,才应用保守的默认值,对于纯计算任务则使用更高(或无限)的默认值 用例示例 以 20 为固定上限,即使硬件和平台没有真正的限制,也会导致多个串行批处理。 预期行为 用户应能够自由配置每个并行块的 maxConcurrency 值,或者至少具有明显更高的上限(50–100),以便非 LLM 并行工作负载能够以全速执行,而不存在人为瓶颈。 为什么这很重要 工作流程自动化平台的价值很大一部分来自真正的并行性。无论工作负载类型如何,将并发性上限限制在 20 都会损害对高吞吐量、非 LLM 并行处理的高级用户的核心价值主张。 感谢您考虑此改进!