ComfyUI-MultiGPU: DisTorch Virtual VRAM for UNet, CLIP and VAE Placement
This custom_node for ComfyUI adds one-click "Virtual VRAM" for any UNet and CLIP loader as well MultiGPU integration in WanVideoWrapper, managing the offload/Block Swap of layers to DRAM *or* VRAM to maximize the latent space of your card. Also includes nodes for directly loading entire components (UNet, CLIP, VAE) onto the device you choose
At a glance
- What is it?
- ComfyUI-MultiGPU adds MultiGPU loader nodes and DisTorch allocation to ComfyUI, moving model layers to DRAM or a second GPU so the compute card keeps its VRAM for latent work. Here is what the repository documents, and where it stops.
- Who is it for?
- Adopt ComfyUI-MultiGPU if you run ComfyUI with a second CUDA device or spare system RAM and you are hitting VRAM ceilings on large UNet or video models; the DisTorch2 bytes mode gives you a deterministic string to describe where each shard lives. Do not adopt it if you expect parallel execution across GPUs: the README states workflow steps still execute sequentially, and the gain is memory placement, not throughput.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 134 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What ComfyUI-MultiGPU is for, and who actually needs it
ComfyUI loads a checkpoint, a CLIP text encoder and a VAE, and by default they all land on one CUDA device. On a card with limited VRAM, the interesting consequence is not speed but ceiling: the model occupies memory that latent processing and video frames would otherwise use. ComfyUI-MultiGPU exists to move the static parts of that stack off the compute card. The README describes the goal as freeing "almost all of your GPU for what matters: Maximum latent space processing."
The intended user is someone with more than one memory pool: system DRAM, a second CUDA card, or both. The README is explicit that this is memory management, not parallel processing. Workflow steps still execute sequentially. Performance gains, where they exist, come from avoiding repeated model loading and unloading when VRAM is tight. Capability gains come from offloading as much of the VAE, CLIP or UNet as possible so the compute device can hold longer videos or more concurrent images.
That framing matters for expectations. If you have a single GPU and no spare RAM, the extension gives you a way to trade speed for headroom, which can still be the difference between a workflow running and failing, but it is not a throughput feature. If you have a second card sitting idle, it is a way to put that card to work holding weights.
How DisTorch2 places model shards across devices
The extension ships MultiGPU variants of the standard ComfyUI loader nodes. Each one keeps the behavior of its original counterpart and adds a device parameter naming the GPU to use. The README lists CheckpointLoaderSimpleMultiGPU, CheckpointLoaderAdvancedMultiGPU and their DisTorch2 counterparts, plus loader nodes for UNet, CLIP and VAE so an entire component can be pinned to a chosen device.
DisTorch, short for distributed torch, is the allocation layer. In Normal Mode, a single virtual_vram_gb slider picks one donor device, typically system RAM, and the more virtual VRAM you request, the more of the model is pushed there. Expert Mode replaces the slider with a text string describing the split. Three syntaxes are documented. Bytes mode, which the README recommends, is modeled on Hugging Face's device_map: you name a device and an amount, and a wildcard assigns the remainder. Ratio mode follows llama.cpp's tensor_split, taking percentages. Fraction mode, the original, allocates by a fraction of each device's total VRAM. The README notes that with the new allocation you can offload all of the model and still run compute on your CUDA device.
The README also claims up to 10 percent faster GGUF inference with DisTorch2 versus DisTorch1. That is a claim from the project, not an independent measurement, and the README does not state the hardware or model it was measured on.
Installing ComfyUI-MultiGPU and running a first offloaded load
The README prefers ComfyUI-Manager. Search for ComfyUI-MultiGPU in the node list and follow the installation instructions there. For a manual install, clone the repository inside ComfyUI's custom_nodes directory, then restart ComfyUI so the new nodes register.
cd ComfyUI/custom_nodes
git clone https://github.com/pollockjj/ComfyUI-MultiGPUAfter the restart, the extension creates MultiGPU versions of the loader nodes it detects. In the node search, look for CheckpointLoaderSimpleDisTorch2MultiGPU or CheckpointLoaderAdvancedDisTorch2MultiGPU rather than the stock loaders. The device widget on the node is where you name the target device.
For a first run, leave Expert Mode off and set a virtual_vram_gb value that frees the amount you need. The README's own example of the bytes string, for readers who switch to Expert Mode, is a device, an amount, then a wildcard for the remainder:
cuda:0,2.5gb;cpu,*With that string the first 2.50 GB of the model is placed on cuda:0 and the rest on the CPU. The repository also ships example_workflows, which is the fastest way to see a working graph before wiring your own. If the node list shows nothing after a restart, the README offers no troubleshooting section, so the practical check is the ComfyUI console output at startup.
The WanVideoWrapper nodes and what they add
Beyond the generic loaders, the extension carries bespoke integration for WanVideoWrapper, described in the README as tightly integrated and stable, with eight dedicated MultiGPU nodes. The repository has a wanvideo.py at the top level, and the pyproject description calls out "bespoke MultiGPU support for WanVideoWrapper and other custom nodes."
For video work this is the part that matters most. Video generation is where VRAM pressure is worst, because the latent tensor grows with frame count, and it is exactly the case where moving weights to DRAM buys you something you cannot get any other way: more frames in one pass. The eight nodes are the project's answer to that, rather than a generic wrapper.
The README does not document per-node behavior for those eight nodes in the text available, so the node documentation under web/docs is where the parameter detail lives. Treat the WanVideoWrapper path as the more specialized, less generic surface of the extension.
Where ComfyUI-MultiGPU is the wrong tool
The clearest limitation is stated by the project itself: this does not make ComfyUI run steps in parallel. If your goal is to cut wall-clock time by splitting one sampling step across two GPUs, this extension does not do that, and the README says so directly. The benefit is memory placement.
The second constraint is the donor device. Offloading to system DRAM means the weights live somewhere with far lower bandwidth than VRAM, and the model still has to be read during compute. The README frames the trade as shifting from on-device speed to open-device latent space capability, which is an honest way of saying you are paying in speed for headroom. A workflow that already fits comfortably in VRAM has nothing to gain and may lose time.
The third is build coupling. The README states that on current ComfyUI builds with DynamicVRAM/comfy-aimdo enabled, MultiGPU keeps DynamicVRAM active on CUDA devices that comfy-aimdo has initialized and falls back to legacy model patching for off-grid MultiGPU CUDA devices, preserving placement on something like cuda:1 when comfy-aimdo only initialized the primary device. That is careful engineering, but it also means behavior depends on which ComfyUI build you are on. The README does not document a rollback path or a version compatibility table, so pinning a known-good ComfyUI revision is on you.
How it differs from Accelerate device_map and llama.cpp tensor_split
The closest conceptual alternative is Hugging Face Accelerate's device_map, which the README itself cites as the inspiration for bytes mode. Accelerate is a general PyTorch utility for loading a model with a plan across devices; it is used from Python, by people writing their own inference scripts, and it knows nothing about ComfyUI's node graph or its model management. ComfyUI-MultiGPU is the opposite shape: a ComfyUI extension that plugs into the existing loader nodes and model_management_mgpu.py, so the placement decision is made in the graph rather than in a script. If you are not writing Python around ComfyUI, Accelerate is not a substitute for this.
On the llama.cpp side, the README points to tensor_split as the model for ratio mode. llama.cpp is a C++ inference engine with its own GGUF loader and its own flags; it does not run ComfyUI graphs. The overlap is only the idea of expressing a split as proportions. The difference is that ComfyUI-MultiGPU has to patch ComfyUI's model loading to honor that split, which is why the DynamicVRAM note above exists at all.
A third comparison is the manual route: two ComfyUI processes, one per GPU, each loading a different model. That gives you real concurrency but splits the graph, and it is a different architecture from a single graph with distributed weights.
Maintenance, licence and the upgrade cost
The repository is not archived, and the last push was on 2026-05-08. The pyproject.toml declares version 2.6.4, and the README is written as documentation for the v2 DisTorch2 line, so the project has a versioned surface you can pin against. There are no releases retrieved, which means the practical upgrade path is pulling the repository rather than watching a release feed.
The licence is GPL-3.0, declared in pyproject.toml as license = {file = "LICENSE"}. For most ComfyUI users that is unremarkable: you are running the node in your own install. It matters if you plan to redistribute a bundle that includes these files or link them into a differently licensed product, because GPL-3.0 carries copyleft obligations. That is a question for your own counsel, not something this article can settle.
Upgrade cost is concentrated in the ComfyUI coupling described earlier. Because the extension patches model loading and interacts with DynamicVRAM/comfy-aimdo, a ComfyUI update can change the behavior of your placement without any change on the MultiGPU side. The README documents the current interaction but no compatibility matrix, so the safe practice is to record the ComfyUI revision and the extension version together before upgrading either.
Editorial conclusion
Adopt ComfyUI-MultiGPU if you run ComfyUI with a second CUDA device or spare system RAM and you are hitting VRAM ceilings on large UNet or video models; the DisTorch2 bytes mode gives you a deterministic string to describe where each shard lives. Do not adopt it if you expect parallel execution across GPUs: the README states workflow steps still execute sequentially, and the gain is memory placement, not throughput. Before trusting it, install it, load one checkpoint through a MultiGPU loader, and confirm the node list reports the device you set; then check your ComfyUI build against the DynamicVRAM/comfy-aimdo note, because on current builds the extension keeps DynamicVRAM active only on devices comfy-aimdo initialized and falls back to legacy model patching elsewhere.
Frequently asked questions
Can ComfyUI use multi-GPU with ComfyUI-MultiGPU?
Yes, in the sense that components can be loaded across devices you specify. The README is explicit that workflow steps still execute sequentially and that the extension enhances memory management rather than parallel processing.
What is the point of having multiple GPUs with ComfyUI-MultiGPU?
The README frames the benefit as moving the static parts of the model, the UNet, CLIP or VAE, off the compute card so its VRAM is free for latent space, longer videos or more concurrent images. A second card can act as a donor device holding part of the model.
What does it mean when my PC says multiple GPUs installed, for a ComfyUI-MultiGPU setup?
For this extension it means you have more than one device you can name in the device parameter or in a DisTorch allocation string, such as cuda:0, cuda:1 or cpu. The README's bytes example places part of the model on cuda:0 and the remainder on the CPU.
Can PyTorch be used with multiple GPUs in ComfyUI-MultiGPU?
The extension is built on PyTorch and uses device strings like cuda:0 and cuda:1 in its allocation syntax. The README does not describe a separate PyTorch multi-GPU API; it describes placement of model shards across the devices you name.
Community notes