ZML_变量_随机种子
Fixed, incrementing, or random — seeds for every parallel run, from one node
- 输入变量包
- 输出变量包
If you've been burned by control_after_generate - and the KB's plumbing essay says almost everyone has - this node is the subworkflow version of finally getting control over your seeds. ZML_变量_随机种子 decides what seed each parallel run of a subworkflow gets, and unlike the native widget you get an explicit choice: every run gets the same seed, each run steps forward by one, or every run rolls a fresh random number.
The mechanism is the standard parallel-variable contract. You set a seed, pick a mode, give it a placeholder name, and feed the bundle into ZML_ParallelJsonContainer. On run index:
- 固定 (fixed) - always the seed you typed.
- 递增 (increment) -
seed + index, so run 1 is seed, run 2 is seed+1, etc. - 随机 (random) - a fresh
random.randintup to a 64-bit max, every single run.
The resolved number replaces every {{占位符}} marker in the API JSON workflow. From the source, a seed variable is just {"type": "seed", "start": ..., "mode": ...} riding in the VAR_BUNDLE - the container's resolve_variable handles all three modes before each task starts.
What you set
- 种子 - INT, default 0. The base seed.
- 模式 - the three-way dropdown above. This is the input that matters; it's the whole reason the node exists.
- 占位符 - STRING, default
随机种. The{{name}}marker in your JSON template. - 输入变量包 (optional) - chain onto other variable nodes so one container gets seed + text + ints in a single bundle.
Output: 输出变量包 (VAR_BUNDLE), the merged bundle.
When to reach for it
Fixed mode is for reproducing a look across parallel runs - you want 16 threads all starting from the same seed to compare something else (a LoRA, a text list). Increment is the "roll through seeds until something sticks" sweep, one seed per run, no repeats, and you can read the winning index off the status output. Random is for brute-force variety, the subworkflow equivalent of flipping control_after_generate to randomize.
The classic trap here is the same one as everywhere else in ComfyUI: make sure the node that actually consumes the seed is wired to this value and not its own baked-in widget, or you'll get 16 identical images and blame the wrong node. Also note the pack's subworkflow system only reliably parallelizes API-only or model-free logic - a sampler node in your JSON may still serialize on the GPU, so "16 parallel seeds" is 16 queued seeds, not 16 GPUs.
Install
One-time pack install: ComfyUI Manager → search ComfyUI-ZML-Image, or
cd ComfyUI/custom_nodes
git clone https://github.com/zml-w/ComfyUI-ZML-Image
then restart. No model files, no extra deps for this node, and English users should grab the README's translation patch - the UI is Chinese-first. The pack's 多线程子工作流.json reference workflow is the fastest way to see the whole variable system wired up correctly.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| 种子 | INT | 0 | — |
| 模式 | COMBO | 3 options: 固定, 递增, 随机 | |
| 占位符 | STRING | 随机种 | — |
| 输入变量包opt | VAR_BUNDLE | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| 输出变量包 | VAR_BUNDLE | — |