🎩SegMoE Model Loader

This is the node that makes the rest of the pack possible, and it hides a few surprises behind a single text box. 🎩SegMoE Model Loader pulls in a SegMoE model - a Mixture-of-Experts diffusion model from Segmind, the folks behind SSD-1B - and hands it to the pack's Generation node as a pipe. If you've never heard of SegMoE, here's the one-paragraph version: instead of merging checkpoints the usual way (averaging weights and hoping for the best), SegMoE keeps several full models around as "experts" and a router inside the UNet decides which expert handles each token as it denoises. Two models working at once, in a single pass, no training involved. The catch is that what you get out is not a ComfyUI checkpoint. It's a complete diffusers pipeline, and this loader is the only thing that understands it.

What you actually do

The node has exactly one input, config_or_path, and it ships pre-filled with segmind/SegMoE-4x2-v0. That's a Hugging Face model id, and here's the nice part: you don't download anything by hand. On first use the node calls diffusers' download machinery, pulls the whole model into your HF cache, and builds the pipeline. Three supported cards, straight from the author:

• segmind/SegMoE-4x2-v0 - SDXL, four experts, two active per token (the default)
• segmind/SegMoE-2x1-v0 - SDXL, two experts, one active per token
• segmind/SegMoE-sd-4x2-v0 - the SD 1.5 build of the four-expert version

The 4x2 / 2x1 naming is the expert count and how many of them get routed per token. The sd- one matters if you're VRAM-poor, because the SDXL cards are the hungry ones.

The config_or_path field is more flexible than it looks. Point it at a local directory or a YAML config and the underlying SegMoE pipeline will happily build a custom MoE from your own base model plus expert checkpoints and LoRAs - that's the framework's DIY path. Through the node's single text box it works, but the ready-made HF cards are where you should start.

The pipe output is a lie (kind of)

The output is typed MODEL, named pipe. Don't be fooled: it is not the normal ComfyUI model you feed to a KSampler. It's a full DiffusersPipeline object - text encoder, UNet, VAE, scheduler and all - smuggled through a MODEL socket. The only node it plugs into is the pack's 🎩SegMoE Generation node, which expects the same type. Try to wire it into anything else and ComfyUI will either refuse or silently do nothing. This is a self-contained island, not a citizen of the graph, and it's worth knowing that going in.

Install and the real cost

Install is the standard dance:

cd ComfyUI/custom_nodes
git clone https://github.com/ZHO-ZHO-ZHO/ComfyUI-SegMoE.git
cd ComfyUI-SegMoE
pip install -r requirements.txt

Restart ComfyUI and you're set. The requirements.txt is a single line - diffusers - because torch, numpy, PIL and friends come from ComfyUI's own environment. ComfyUI Manager support is listed as "on the way" in the README, so don't count on the Manager search finding it yet; the git clone is the reliable route.

Now the part nobody likes: the README recommends more than 20 GB of VRAM, and that's not paranoia. The loader builds the entire pipeline and loads it onto CUDA at fp16 with no offloading or sequential loading - a whole SDXL pipeline plus a stack of expert weights, resident at once. People have run the 4x2 on less (Segmind's own numbers suggest ~7 GB for the model itself), but you're gambling. First load also downloads several gigabytes into the HF cache, so have both disk and bandwidth. When it's up, it's a two-node workflow: loader → Generation → image.