DreamX Creator Model Loader

DreamX-Creator 1.0 is a 7B joint audio-video generator from the DreamX team - Apache 2.0 weights, an arXiv report, the usual research-release shape. DreamX Creator Model Loader is the node that puts that 7B in VRAM as a ComfyUI MODEL, and it's the one loader in this pack that has a genuinely interesting engineering wart hiding inside it.

Two inputs, one output. model_root (default auto, i.e. this repo's checkpoints/ then ComfyUI/models/dreamx_creator/) and dtype (bfloat16 / float16 / float32, default bfloat16). Out comes model, which wires into DreamX AV Flow Shifts and then DreamX Multimodal Guider. That's the whole node.

The wart

ComfyUI's model patcher normally supports partial weight offload: it keeps some layers on the CPU and moves them as needed, using manual-cast ops that know how to hand activations across the boundary safely. Comfortable, memory-friendly, and completely wrong for this model.

DreamX vendors ordinary torch Linear and Conv modules from its own Diffusers-derived code. Those don't have ComfyUI's cast semantics glued on. Push them through generic partial offload and you can end up with CPU weights feeding CUDA activations - which either crashes or quietly produces garbage. So the pack doesn't allow it. The loader attaches a PREPARE_SAMPLING wrapper to the patcher that stamps force_full_load = True onto every sampling call, and the guider additionally calls load_models_gpu(..., force_full_load=True) before it samples.

The practical consequence: your 7B needs to actually fit. No partial-offload safety net, no block swap, no clever offloading. At bf16 that's roughly 14–15 GB of weights, plus activations. Real 24 GB cards run this near the ceiling once the text encoder and VAEs are also resident. If you're on 16 GB you can try fp16 or fp32 and make it worse; 12 GB is not happening.

dtype

Leave it at bfloat16 on any modern NVIDIA card. The float16 option exists and technically loads faster, but bf16's exponent range is why it's the default for every one of these 2026 flow-matching models; fp16 on a 7B video model is a hunt for NaNs you don't need to go on.

You don't need this node if you're using DreamX Creator Complete Loader, which gives you model, clip, vae and audio_vae in one go. Reach for the individual loaders when you want to mix and match - reusing a text encoder or a VAE you already loaded, or loading the Creator and the refiner in different graphs without re-walking a bundle.

Install

ComfyUI Manager → search DreamX Creator T8. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/Comfyui-DreamX-Creator-T8.git
cd Comfyui-DreamX-Creator-T8
python -m pip install -r requirements.txt

The requirements file is deliberately careful about one thing: it does not install or pin torch at all, on the grounds that ComfyUI supplies it. Everything else is normal research-release weight - diffusers 0.37.x, transformers 4.57.x, peft, accelerate, omegaconf, einops.

Weights are not in the repo. ~54 GB, 20 files:

python -m pip install -U huggingface_hub
hf download t8star/DreamX-Creator-Comfy --local-dir ComfyUI/models/dreamx_creator

The model root must directly contain creator/, audio_vae/, refiner/ and wan2.2_ti2v_5b/. Don't leave an extra DreamX-Creator-Comfy/ nesting level in there - model_root=auto fails on exactly that mistake, and the error message lists the paths it tried so you can see it.

Common issues

"Model root was not found", with a list of paths. The loader checks for creator/video_model/config.json specifically. Wrong nesting, or a partial download.

"Model root is incomplete" naming missing files. The loader validates all 14 required files up front. Good news: you find out in two seconds rather than after a 50 GB load.

OOM mid-sampling rather than at load. That's the full-load design, plus activations at your token budget. Drop target_spatial_tokens on DreamX First Frame AV Latent - the shipped quick-start profile uses 256 for a reason - and make sure the refiner isn't resident at the same time. Video VRAM floors are documented per-tier in troubleshooting.md; a 5B–7B joint A/V model is at the top of that curve, not the middle.

Worth knowing who packaged this: T8star is a ComfyUI workflow creator, known in the Wan scene for shipping ready-to-run graphs, not a research lab. That's the right lens for the whole pack - someone competent took a paper release and did the boring work of making it run inside ComfyUI's offload model. Where the docs and the code disagree, trust the code; the force_full_load behaviour is only visible there.