☁️BizyAir Load Diffusion Model

If you've used ComfyUI's built-in "Load Diffusion Model" node, this one will feel immediately familiar - same idea, same dtype dropdown, same job. The difference is entirely about where the weights live: the native node loads a UNet-only checkpoint (no CLIP, no VAE bundled in, just the diffusion backbone) from your local models/unet folder; this one loads the same kind of checkpoint, except it's sitting on BizyAir's servers and you never touch the file.

That matters more than it sounds like for the checkpoints on this particular list - several of them are big. Full Flux dev/schnell checkpoints run in the multi-gigabyte range, and Wan 2.2's 14B variants are bigger still. Loading them without a local download is the entire value proposition here.

What's on the model list

Fifteen options as of this writing, spanning a genuinely wide range of architectures:

• shuttle-3.1-aesthetic.safetensors
• Wan2.2 T2V and I2V, both high-noise and low-noise 14B variants (fp8 scaled)
• flux1-dev-kontext_fp8_scaled.safetensors and a OneDiff-optimized Kontext variant
• Kolors (Kolors.safetensors and Kolors-Inpainting.safetensors)
• Flux schnell, Flux dev, and PixelWave's Flux dev finetune

Plus a few more beyond the sampled list in the schema. This is effectively BizyAir's "bring your own architecture" loader for anything that isn't wrapped in a more specific dedicated node elsewhere in the pack.

Inputs and outputs

• unet_name - pick your checkpoint from the list above.
• weight_dtype - default, fp8_e4m3fn, fp8_e5m2, or fp8_e4m3fn_fast. This is standard ComfyUI dtype terminology: default runs at whatever precision the checkpoint natively ships in, the fp8 options quantize down to 8-bit floating point to cut memory footprint roughly in half versus fp16, with a small, usually acceptable quality cost. fp8_e4m3fn and fp8_e5m2 differ in how they split precision between exponent and mantissa bits - e4m3fn is the more commonly recommended default of the two for diffusion models. fast variants trade a bit more accuracy for faster inference where hardware support allows it. Since inference happens on BizyAir's own GPUs, this mostly affects speed and BizyAir's internal resource use rather than your local VRAM - but it's still worth picking deliberately if you're chasing generation speed.

Output: BIZYAIR_MODEL - this feeds BizyAir's own sampler and apply nodes (things like BizyAir BasicGuider, BizyAir Apply InstantID, BizyAir Apply PuLID Flux), not ComfyUI's native MODEL type. Don't expect to wire this into a vanilla local KSampler.

How to install it

Ships with the full BizyAir pack.

ComfyUI Manager: search "BizyAir," Install, restart.

git clone:

cd ComfyUI/custom_nodes
git clone https://github.com/siliconflow/BizyAir.git

API key required before this loads anything, same as the whole pack.

Common issues

Output type doesn't connect to native ComfyUI nodes. This is the single most common point of confusion moving from local to BizyAir workflows: BIZYAIR_MODEL is not MODEL. If you're trying to mix a BizyAir-loaded model into an otherwise-local sampling chain, it won't connect - you need to stay inside BizyAir's own node family (its own guider, sampler, and conditioning nodes) for anything downstream of this loader.

Picking the wrong checkpoint for your conditioning nodes. Some of BizyAir's other nodes are architecture-specific - a PuLID-Flux pipeline expects a Flux checkpoint here, an InstantID pipeline expects SDXL. Loading, say, Kolors and then wiring it into an InstantID apply node will fail or produce garbage; match the checkpoint family to whatever conditioning/identity nodes you're building around it.

fp8 quality trade-offs are real but usually small. If you're chasing maximum fidelity and results look slightly softer than expected, try default dtype first before assuming something else in your graph is wrong.