☁️BizyAir Nunchaku FLUX.1 LoRA Loader

First, the thing nobody tells you when this node shows up in your workflow: this is not MIT-HAN-Lab's Nunchaku. The real Nunchaku (mit-han-lab/ComfyUI-nunchaku) is a local inference engine that runs 4-bit quantized (SVDQuant) Flux models on your own GPU - the whole point is cutting VRAM and speeding up inference without leaving your machine. BizyAir's "Nunchaku" nodes borrow the same branding and the same idea - apply LoRAs to a quantized Flux - but they run on SiliconFlow's cloud servers, not yours. There's even a documented mix-up: people following a Nunchaku tutorial had ComfyUI Manager auto-install BizyAir instead of the real package, because an older node-registry mapping pointed the missing Nunchaku* node names at the wrong pack. Comfy Org fixed the mapping, but older workflow files and video tutorials still trigger it - if you searched for Nunchaku and got BizyAir, that's why.

With that cleared up: what this node actually does is standard LoRA math, just executed remotely. LoRAs adjust how the diffusion model denoises - style, subject, a specific look - without retraining the whole checkpoint, and you can chain several of these loaders to stack LoRAs.

The inputs and outputs that matter

• model (BIZYAIR_MODEL) - the Nunchaku-quantized Flux model coming from an upstream BizyAir Nunchaku loader. Note the type: BIZYAIR_MODEL, not plain MODEL. You can't feed this a locally-loaded checkpoint, and a local KSampler can't read what comes out of it - this whole chain has to stay inside BizyAir nodes.
• lora_name - pick from BizyAir's hosted LoRA list, not your local models/loras folder.
• lora_strength - default 1, and the slider goes from -100 to 100. Don't read that range as an invitation; in practice LoRA strength behaves the same way it does everywhere else, and most people stay somewhere between -2 and 2. The wide range is just the node not clamping you.
• model_version_id - a string field, empty by default. This looks like an internal identifier BizyAir uses to pin a specific LoRA version server-side rather than something you're expected to type into by hand for routine use.

Output is a modified BIZYAIR_MODEL, ready to feed into the next node in the chain - another LoRA loader, a sampler, or (if you're doing identity work) a PuLID apply node.

Installing it

ComfyUI Manager: search BizyAir, install, restart - or by hand:

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

Then restart ComfyUI, and set your BizyAir API key on first use (the README is explicit that this step is required - the node fails silently at execution time without it, not at install time).

Where people get burned

Beyond the naming confusion above, the recurring practical trap is mixing BizyAir's cloud pipeline with local nodes mid-graph. Because everything here runs on BIZYAIR_MODEL/BIZYAIR_CLIP/BIZYAIR_CONDITIONING types instead of ComfyUI's standard ones, you can't drop a stock LoraLoader or KSampler into the middle of a BizyAir Nunchaku chain - the sockets simply won't connect. Build the whole Nunchaku→LoRA→sampler segment out of BizyAir nodes, and only hand off to local nodes at the very end (or the very start) where the types are plain IMAGE/LATENT.

If you genuinely want local 4-bit Flux inference - no cloud, no credits, your own GPU doing the quantized math - that's the real mit-han-lab/ComfyUI-nunchaku package, and it's a separate install with its own .whl dependency, not something you get by clicking through BizyAir. Know which one you actually wanted before you start debugging the wrong one.