BAGEL Model Loader (Deprecated)

If you've landed here, you already found BAGEL and you're trying to figure out how much VRAM it's going to eat. The BAGEL Model Loader is the first node in every workflow from this pack, and it's where the real decisions happen before you ever write a prompt. There's no way around it: BAGEL is a 14B-parameter model (7B active) from ByteDance Seed, released open under Apache 2.0 back in May 2025. That release is genuinely rare - BAGEL is the one open-source label on ByteDance's own Seed model listing, with the whole Seedream and Seedance lines staying API-only. So yes, it's a big download, and the loader is the node that decides which flavor you get.

What the loader actually does

BAGEL uses a Mixture-of-Transformer-Experts (MoT) architecture - a hybrid where the same transformer backbone handles both text understanding and image generation. That's why one model can do text-to-image, image editing, and image understanding, and why the pack ships a single shared loader instead of per-task model nodes. The loader hands every other BAGEL node a BAGEL_MODEL object, which is exactly the type those nodes expect on their model input. No loader, no nothing - the rest of the graph is just decoration without it.

It's worth knowing the two things this loader is not. It's not a checkpoint hoarder you manage by hand - you pick a model and it does the heavy lifting. And the model output isn't a standard ComfyUI checkpoint you can feed to a regular sampler; it only wires into the other BAGEL nodes.

The two inputs that matter

Only two required inputs, and they're both dropdowns:

• model_repo_id - pick your model: ByteDance-Seed/BAGEL-7B-MoT (the standard model) or DFloat11/BAGEL-7B-MoT-DF11 (pre-quantized). The tooltip says it plainly: the standard model supports quantization, the DFloat11 one is already quantized.
• quantization_mode - BF16 (standard), NF4 (4-bit), INT8 (8-bit), or FP8 (float8). This only applies to the ByteDance model; the DF11 variant skips re-quantization entirely.

Where people get burned: picking NF4 or INT8 on the standard model without bitsandbytes installed, or trying to quantize the DF11 model as if it were raw weights. It isn't. The pack remembers that - DFloat11 versions do not get quantized again - but you'll hit a hard error if the dfloat11 dependency isn't there.

VRAM reality, straight from the README

The README's numbers are the honest version: BF16 wants roughly 80GB and is really a multi-GPU affair. NF4 lands around 12–32GB, INT8 around 22–32GB, and the DF11 model squeezes into a single 24GB card at about 22GB. On an RTX 4090 the pack quotes 154 seconds for a 1024×1024 DF11 generation versus 483 seconds for the full BF16 model - so DF11 isn't just smaller, it's three times faster on one GPU. If you have a 24GB card, that's your answer.

Installing it

The loader comes with the whole pack, so you install it once:

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

Or search "ComfyUI-BAGEL" in ComfyUI Manager and hit install - same result, no terminal. Restart ComfyUI either way. The base requirements.txt pulls decord, einops, huggingface_hub, matplotlib, opencv-python, pyarrow, and accelerate. The extras are the trap: bitsandbytes for NF4/INT8, dfloat11 (CUDA + cupy, only needed for the DF11 model), and flash_attn, which builds from source on some platforms and is the single most common install failure in this pack's threads. The pack will auto-download the model you pick into models/bagel/ on first use if you let it; the manual fallback is a git lfs clone of the same repo into that folder.

Troubleshooting

Two things dominate the support threads. The NameError: 'Qwen2Config' is not defined crash is the big one - the README points it at environment/dependency issues and suggests installing flash-attention and triton (prebuilt wheels exist for Windows; see the pack's issue tracker). The other is flash-attn failing to build from source on newer Python - several users report clean installs on Python 3.10.x, so if you're on 3.12 or 3.13 and the build explodes, a dedicated 3.10 environment is the pragmatic fix. A bare NameError with no other context almost always traces back to one of those two.

Once the loader is green, your graph is armed. Wire that model output into whichever BAGEL node does your actual job and start burning tokens.