☁️BizyAir NunchakuPulidLoader
The one-input node that starts a PuLID chain
- model
- BIZYAIR_MODEL
- BIZYAIR_PULID
There's not much to this node by design, and that's the point - it's plumbing, not a decision. Its job is to take a quantized Flux model you've already loaded and hand back two things: the model itself (unchanged, just passed through) and a PuLID handle that the next node in the chain, NunchakuPulidApply, needs to actually do anything with a reference face.
Why it exists as a separate node
ComfyUI's node graph likes to keep "load a thing" and "use a thing" as separate steps, and PuLID follows that pattern here: this loader prepares PuLID to run against your specific model, and a downstream apply node does the actual identity injection once you've also supplied a reference image. Splitting it this way means you can load PuLID once and, if your workflow calls for it, reuse the same loaded state across multiple apply calls rather than re-initializing it every time - though for most single-image workflows you'll just wire loader straight into apply and not think about it again.
The inputs and outputs that matter
model(BIZYAIR_MODEL) - the only input. This needs to be a nunchaku (quantized) Flux model from earlier in your chain, not a plain Flux checkpoint and not a model from BizyAir's non-Nunchaku PuLID path (BizyAir ships a separate, parallel PuLID pipeline for regular Flux models - the two aren't interchangeable, so make sure you're pulling from the Nunchaku side if that's the model you loaded).- Two outputs:
BIZYAIR_MODEL(the same model you fed in, unmodified - this is what continues on to your LoRA loaders or straight to PuLID apply) andBIZYAIR_PULID(the PuLID handle, which only plugs into a PuLID apply node).
That's the entire node. No strength dial, no reference image here - those live one step downstream, on the apply node.
Installing it
Through ComfyUI Manager: search BizyAir, click Install, restart. Or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/siliconflow/BizyAir.git
Restart, then set your BizyAir API key the first time you actually run a workflow - the README calls this out explicitly, and skipping it means every node in the chain, including this one, fails at execution rather than at load time.
Where people get burned
The mistake to watch for isn't in this node - it's upstream and downstream of it. Upstream: feed it a model that didn't come from a Nunchaku loader and it either errors on the type mismatch or, worse, silently produces something that doesn't act like PuLID because the model underneath was never quantized the way this loader expects. Downstream: this node's BIZYAIR_PULID output is a dead end on its own - it does nothing until it reaches an apply node with a reference image wired in. If your workflow "runs" but the output face looks completely unaffected by your reference photo, check that the PuLID output actually made it to an apply node and that the apply node has an image plugged into it, rather than assuming this loader is broken.
One more thing worth remembering given how this pack is structured: everything here speaks BIZYAIR_* types, not ComfyUI's standard MODEL/CONDITIONING. That's fine as long as your whole PuLID segment - model loader, PuLID loader, LoRA loaders if any, PuLID apply, sampler - stays inside BizyAir nodes. The moment you try to splice in a local node mid-chain, the sockets stop lining up.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| model | BIZYAIR_MODEL | The nunchaku model. |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| BIZYAIR_MODEL | BIZYAIR_MODEL | — |
| BIZYAIR_PULID | BIZYAIR_PULID | — |