Load Checkpoint (MultiGPU Debug)
The loader that smoke-tests your GPUs before committing to a real model
- model
- clip
- vae
- test_image
- status
Load Checkpoint (MultiGPU Debug) is the diagnostic twin of Load Checkpoint (MultiGPU) - same loader, same sharding logic, but with three extra tools bolted on: test_mode, log_vram_snapshot, and two extra outputs (test_image, status). This is the version the pack's USER_GUIDE tells you to use first, and for once that advice is right: it de-risks the setup before you point it at a 20GB+ model.
The smoke test
Flip test_mode on (or pick the test_mode entry in the ckpt_name dropdown - same thing) and the loader skips loading entirely. Instead it runs a synthetic test that creates a tensor on every selected GPU, verifies each tensor is actually resident on the card it claims, and checks basic allocation. All GPUs pass → you get a hot-pink "✓ MultiGPU Success!" image and a status line listing each card's memory usage. Any failure → a gray image naming the dead cards.
This is genuinely the right way to first-run a multi-GPU box. It tells you whether CUDA sees all your cards and whether they can all allocate memory before you burn five minutes loading a checkpoint that then dies on a bad card.
The VRAM snapshot
log_vram_snapshot appends per-GPU VRAM readings (in GB) before and after the shard layout is applied, straight into the status. That's the before/after evidence you want when a load says "multi-GPU active" but only one card's VRAM actually moved.
Outputs
model, clip, vae like the production loader, plus test_image (IMAGE - the pink/gray smoke-test result or a colored load-status image) and status (STRING - the full diagnostic report). In test mode you also get real dummy CLIP/VAE objects, so a downstream graph won't error even though nothing real was loaded.
Inputs
Same as the production loader (ckpt_name, num_gpus, gpu_ids, clip_name1/2, clip_loader_type, vae_name, safety_ok), plus test_mode and log_vram_snapshot. When safety_ok is false the loader refuses to run - that's the Hardware Validator gate doing its job.
Installing it
Part of Comfy-MultiGPU-Loader. ComfyUI Manager search "Comfy-MultiGPU-Loader", or:
cd ComfyUI/custom_nodes
git clone https://github.com/AngelCookiesLab/Comfy-MultiGPU-Loader
pip install -r requirements.txt
Restart, find it under MultiGPU/Debug.
The workflow the author actually wants you to run
Use the debug loader with log_vram_snapshot, pair it with the debug sampler, and feed statuses to a display node to get everything into comfyui.log. Once the graph behaves, swap to the non-debug loader for production. Remember the state of play: sunset project, GPL-3.0, as-is, no active support - and only Flux Dev Full fp32 was verified on multi-GPU, so treat this as "promising experiment," not a product.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| ckpt_name | COMBO | test_mode | Checkpoint to load from ComfyUI models/checkpoints. |
| num_gpus | COMBO | 2 | How many GPUs to allocate (use Auto for all available). |
| test_mode | BOOLEAN | false | Run synthetic smoke test instead of loading real models. |
| gpu_idsopt | STRING | 0,1,2,3 | Comma separated GPU indices in execution order. |
| clip_name1opt | COMBO | <auto> | Primary text encoder file (leave <auto> to use checkpoint embedded CLIP). |
| clip_name2opt | COMBO | <auto> | Secondary/paired text encoder file. |
| clip_loader_typeopt | COMBO | auto | Decoder profile for dual-CLIP loader. |
| vae_nameopt | COMBO | <auto> | External VAE to use when checkpoint does not bundle one. |
| log_vram_snapshotopt | BOOLEAN | false | Record per-GPU VRAM usage before/after layout for troubleshooting. |
| safety_okopt | BOOLEAN | true | Connect to Hardware Validator; loading aborts when false. |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |
| clip | CLIP | — |
| vae | VAE | — |
| test_image | IMAGE | — |
| status | STRING | — |