In traditional HPC and ML systems all nodes that are part of a job are started simultaneously (as you implied in your question) and the job gets dispatched (by a scheduler) once all nodes are ready to execute. The set of nodes that are part of a job are usually called a “gang”.
TorchElastic is designed in a way to handle systems that do not form a gang. Those systems are usually meant to run traditional distributed applications where the scheduler has no concept of forming a gang of nodes (e.g. the scheduler simply starts executing the job on a node the moment the node becomes available). Since you have no formal gang you have to have some form of mechanism to simulate a gang (a “pseudo-gang”) and dispatch the job at some point in time after the user requested it. This is where the minimum and maximum number of nodes come into play. You basically tell TorchElastic that it should wait until at least min number of nodes become available to execute a job, but that ideally you want it to have max number of jobs for the execution. Once TorchElastic reaches min number of nodes, it sets an internal “lastcall” timer and continues accepting new nodes until the timer expires or the max number of nodes is reached. At that point TorchElastic dispatches the job on all participant nodes. In summary TorchElastic has a built-in capability to form a gang even when run on systems that has no such concept.
In your particular case (and in most cases) setting minimum and maximum number of nodes to the same value is the way to go. They become relevant in non-traditional execution environments as I described above.