Data Parallel Conditioning List
The Data Parallel Conditioning List
- positive_0
- negative_0
- positive_1
- negative_1
- positive_2
- negative_2
- positive_3
- negative_3
- positive_4
- negative_4
- positive_5
- negative_5
- positive_6
- negative_6
- positive_7
- negative_7
- positive
- negative
If you've built a Data Parallel workflow in Raylight, you've already accepted the core deal: every GPU runs the same full sequence, independently, at the same time. That's throughput - N generations per run instead of one. The obvious next question is the one DPConditioningList exists to answer: why should those N generations all use the same prompt?
It's the "Multi-Prompt DP" node (added by avtc, per the changelog). It gathers up to eight positive/negative conditioning pairs into one list, then hands that list to a Data Parallel sampler so each GPU denoises toward its own text. Think of it as the DP replacement for the boring single CLIPTextEncode → sampler wiring.
The inputs that matter. positive_0 and negative_0 are required - that's your baseline prompt pair. The other seven slots (positive_1 through positive_7, negative_1 through negative_7) are optional, and here's the behavior that will trip you up if you don't expect it: any empty slot silently inherits slot 0's conditioning. The node always emits a full eight-entry list; it just backfills the gaps with positive_0/negative_0 under the hood.
That backfill is actually convenient. You can leave six slots empty, fill two, and on a 3-GPU box you get GPU 0 on your base prompt, GPU 1 on your variant, GPU 2 on the base prompt again. Or fill all eight and treat it as a prompt sweep. Just don't assume an empty slot means "skip this GPU" - it means "reuse slot 0."
Both outputs - positive and negative - are CONDITIONING lists, and they feed the matching inputs on DPKSamplerAdvanced (or the DP custom samplers). That's really the whole wiring story: list out, sampler in.
How it fits the wider workflow. Data Parallel mode in Raylight requires your RayInitializer to have Ulysses and Ring degrees at 0 (that's what tells the cluster to run whole sequences per GPU rather than splitting them). Once that's set, this node is what makes DP worth running instead of just queueing four jobs yourself - one queue, four prompts, no babysitting.
Install. It ships with the whole pack, so you install Raylight once:
ComfyUI Manager → search "raylight" → Install
or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/komikndr/raylight
cd raylight
pip install -r requirements.txt
Then restart ComfyUI. No model files to download for this node; the real install weight is the pack's xfuser dependency, and on Windows the README is blunt that stock PyTorch won't cut it - WSL2 is the supported path. Full gotchas live in the DPKSamplerAdvanced article, since that's where they bite.
The one genuinely confusing bit is the count mismatch: you've got 8 slots and probably 2 GPUs. That's fine - unused slots inherit slot 0. The trap is the reverse: thinking you filled 4 prompts when the list silently carries 8, so a 4-GPU run uses all four correctly but you've no idea which prompt landed where until you label your outputs. Trust the slot order, fill what you use.
Inputs (16)
| Name | Type | Default | Description |
|---|---|---|---|
| positive_0 | CONDITIONING | — | |
| negative_0 | CONDITIONING | — | |
| positive_1opt | CONDITIONING | — | |
| negative_1opt | CONDITIONING | — | |
| positive_2opt | CONDITIONING | — | |
| negative_2opt | CONDITIONING | — | |
| positive_3opt | CONDITIONING | — | |
| negative_3opt | CONDITIONING | — | |
| positive_4opt | CONDITIONING | — | |
| negative_4opt | CONDITIONING | — | |
| positive_5opt | CONDITIONING | — | |
| negative_5opt | CONDITIONING | — | |
| positive_6opt | CONDITIONING | — | |
| negative_6opt | CONDITIONING | — | |
| positive_7opt | CONDITIONING | — | |
| negative_7opt | CONDITIONING | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| positive | CONDITIONING | — |
| negative | CONDITIONING | — |