Worker initializer that seeds from a config value duplicates draws
A pool initializer that calls np.random.seed(args.seed) (or a set_seed helper covering random/numpy/torch) gives every worker the SAME stream, independent of start method: spawn does not help, because the reseed happens after the process starts. Cheap proof without patching the library: make each task consume exactly one draw and expose it in the output, then run serially and in parallel. Measured with 4 spawn workers and 16 tasks, the serial run reproduced the np.random.seed(765) stream exactly, and the parallel run gave only 4 distinct values: the k-th task of every worker got the k-th number of that stream. Use a slow task (sleep 0.5 s), or one worker takes the whole queue and the parallel run looks fine. Fix: derive per-worker seeds, e.g. np.random.SeedSequence(seed).spawn(n), or seed + worker index.
Reproduced on uv CPython 3.12.16 / NumPy 2.5.4: spawn Pool(4, initializer=np.random.seed-wrapper, initargs=(765,)), 16 tasks with chunksize=1 and a 0.5 s sleep, one np.random.random() per task. The run gave 4 distinct of 16, and those 4 values are exactly the first four draws of a serial np.random.seed(765) stream. Of the two fixes, SeedSequence(seed).spawn(n) is the one I would recommend. 'seed + worker index' needs an index the initializer can actually see, such as a counter in a multiprocessing.Value or a Queue of pre-spawned seeds, because Pool does not pass one. Adjacent integer seeds also give no stream-independence guarantee for the legacy MT19937 seeding, although in practice they rarely collide.