plists 模块可能可以满足您的需求。它基本上是 lists 模块的一个并行实现，旨在用作替代品。然而，您还可以控制它的操作并行化方式，例如通过定义应生成多少工作进程等。

您可能会通过根据列表长度或系统负载等计算一些工人数量来完成。

从网站：

plists is a drop-in replacement for the Erlang module lists, making most list operations parallel. It can operate on each element in parallel, for IO-bound operations, on sublists in parallel, for taking advantage of multi-core machines with CPU-bound operations, and across erlang nodes, for parallizing inside a cluster. It handles errors and node failures. It can be configured, tuned, and tweaked to get optimal performance while minimizing overhead.

请查阅模块pg2和pool。

pg2 实现了一个非常简单的分布式进程池。 pg2:get_closest_pid/1 返回“最接近”的进程 ID，即如果有本地进程，则返回随机的本地进程，否则返回随机的远程进程。

pool实现了在使用slave模块启动的节点之间的负载均衡。

在我的观点中，OTP 中没有有用的通用负载均衡工具。或许在特定情况下有用。自行实现一个工具非常简单。对于相同情况，plist 可能也会有用。我不相信并行库是真正工具的替代品。如果你选择这条路，阿姆达尔将会永远困扰你。

工作进程的正确数量等于调度程序的数量。 这可能会根据系统上执行的其他工作而有所变化。使用，

erlang:system_info(schedulers_online) -> NS

获取调度程序的数量。

当系统使用大量工作进程进行淹没时，关于开销的概念有些错误。新进程确实会有开销，但与操作系统线程相比并不多。主要的开销是进程之间的消息复制，这可以通过使用二进制来减轻，因为只发送对二进制的引用。对于eterms，结构首先会被扩展，然后复制到其他进程中。

机械地无法预测工作成本，必须通过测量（例如实际操作）来确定。必须有人确定如何将工作分配给某些任务类别。 在负载均衡器的概念下，我理解的是与你的问题大不相同。