Hardware Validator (MultiGPU)
The sanity check that stops you from OOM-bricking a 60GB Flux load
- gpu_ids
- status
- ok
- status_image
This is the pack's own "safety rail," and it exists because the thing this pack does - sharding native fp32 safetensors checkpoints across GPUs - is exactly the kind of load that quietly eats a machine. The author's test case was Flux Dev 2 in FP32 at roughly 60GB. Before you ask six GPUs to swallow that, Hardware Validator (MultiGPU) checks your actual hardware against a profile and tells you, flatly, whether the load will fit. It's a MultiGPU/Safety node and it's the newest thing in the pack (added in 0.1.5).
How it works
It reads your real GPU inventory with torch.cuda.get_device_properties, sums total VRAM, checks per-GPU VRAM and GPU count, and compares against the selected profile. Four profiles are built in:
generic- no enforced limits, passes anything with a GPUsdxl- 24GB total, 8GB min per GPU, 1+ GPUflux-dev- 32GB total, 10GB per GPU, 2+ GPUsflux-dev2-fp32- 64GB total, 12GB per GPU, 6+ GPUs
The trap is hiding in plain sight: the default profile is flux-dev2-fp32, the most demanding one. On a 2×8GB rig that validator will fail by default - which is the point, but it reads as "node is broken" to a beginner. If you're running SDXL, switch the profile to sdxl.
The inputs that matter
profile- which requirement set to check against (defaultflux-dev2-fp32, see above).num_gpus- how many GPUs to validate;Autouses all available.gpu_ids- comma-separated allowed IDs (default0,1,2,3,4,5,6,7); IDs not present on the machine get filtered out.allow_overcommit- when true, a failed check becomes a ⚠️ warning instead of a ❌, andokstill comes back true. Only flip this when you know what you're doing.status_image- returns a colored pass/fail image (blue = OK, orange = failed) so you can see the result at a glance.
What it outputs and how you wire it
Four outputs: gpu_ids (the filtered, validated list of GPU indices), status (a full text report per GPU), ok (BOOLEAN), and status_image (IMAGE). The intended wiring, straight from the README:
Hardware Validator
gpu_ids ──────────► Loader.gpu_ids
ok ──────────► Loader.safety_ok
The loaders (Load Checkpoint and Load Flux variants) accept a safety_ok input and abort the load if it's false - that's the gate. The gpu_ids string also tells the loader which cards to actually use, in order.
Installing it
Part of Comfy-MultiGPU-Loader: ComfyUI Manager search, or git clone https://github.com/AngelCookiesLab/Comfy-MultiGPU-Loader into custom_nodes/, pip install -r requirements.txt, restart. It shows up under MultiGPU/Safety.
Honest caveats
The author's own changelog admits the validator "has not been tested a lot so stuff might be broken," so treat a pass as a good sign, not a guarantee. The profiles are rough floor-guesses, not measured footprints - VRAM needs depend on resolution, batch, and the exact model. And remember this pack is sunset/"as-is" with no active support. Still, as a pre-flight check before a multi-GPU load, it's the right instinct, and it's the one node in this pack that can save you from a hard lockup.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| profile | COMBO | flux-dev2-fp32 | Profile to validate against. |
| num_gpus | COMBO | Auto | How many GPUs to check (Auto uses all available). |
| gpu_idsopt | STRING | 0,1,2,3,4,5,6,7 | Comma-separated GPU IDs to allow. |
| allow_overcommitopt | BOOLEAN | false | If true, emit warning but still pass when below requirements. |
| status_imageopt | BOOLEAN | true | Return a colored status image when validation fails. |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| gpu_ids | STRING | — |
| status | STRING | — |
| ok | BOOLEAN | — |
| status_image | IMAGE | — |