️Anima模型烧录器
Freeze a LoRA into your Anima checkpoint
- lora_stack
- MODEL
- CLIP
- VAE
SeparateModelMixerDictFuser (displayed as "️Anima模型烧录器" - "Anima Model Burner") is the Anima-specific member of ComfyUI-FastTool's LoRA-baking family. Where the SDXL mixer takes a single checkpoint, this one hands you separate dropdowns for the Anima base model, its CLIP, and its VAE - hence the "Separate" in the class name - and bakes a LoRA stack into them. The README says it outright: usage is exactly the same as the 【SDXL】Model Mixer, and its reason to exist is that running Anima with LoRAs eats VRAM, so baking frees it.
Context matters here. Anima (Circlestone Labs, on NVIDIA's Cosmos-Predict2 backbone) is the 2B anime DiT that made people actually leave SDXL anime: Qwen3-0.6B text encoder, Qwen-Image VAE, and the prompt comprehension to mix natural language with Danbooru tags. It's also slow for its size, wants 30-50 steps, and - relevant here - has no ControlNet. So when Anima shows up in a workflow, the economics are different than SDXL: you're already paying a per-step cost, and a LoRA patch multiplying through a 2B DiT at runtime is extra weight on every one of those steps. Baking the LoRA in once, at whatever precision you choose, is how you stop paying it per image. It's the same "bake to redistribute" pattern the SDXL mixer uses, aimed squarely at the 8-12GB cards this pack targets.
Inputs and outputs
model,clip,vae- three dropdowns over yourcheckpoints,clip, andvaefolders. For Anima that means the Anima base (or an Anima fine-tune like WAI-ANIMA), the matching Qwen3 CLIP, and the Qwen-Image VAE.lora_stack(optional) - the pack'sMultiLoRAStackoutput. Same rule as the SDXL mixer: only LoRAs with nonzero strength get baked, "None" entries are skipped.save_dtype-auto, or forcefloat16/bfloat16/float32. On a tight card,float16orbfloat16are the sane choices;float32if you're baking a file to distribute and want zero precision loss.device-auto,cpu,cuda, ornpu. This one is worth knowing about: if baking OOMs on GPU, dropping tocpuworks but is slow. Thenpuoption is a hint at the author's Chinese-market audience, where Ascend NPUs are a real target.
Outputs are MODEL, CLIP, VAE - the baked trio. Wire them into sampling, or save them out so the LoRA (and its load time) disappears from your workflow forever.
Install
Same pack, same install - ComfyUI Manager search "FastTool", or:
cd ComfyUI/custom_nodes
git clone https://github.com/Fengxiaoxiao-001/ComfyUI-FastTool.git
Restart. No extra Python deps; the pack's pyproject.toml declares none.
Where people get burned
- It bakes, it doesn't merge. You get a model with the LoRA's weights physically folded in - you lose the ability to dial that LoRA's strength per image afterward. Settle the look first, then bake.
- Anima licensing. Anima's CircleStone non-commercial license restricts the weights, not the outputs, and v1.2 lets individuals sell derivative finetunes and LoRAs - but a baked model is a derivative of the base and your LoRA. If you're baking to redistribute, check both licenses before you do.
- The README's Anima Adapter story is ahead of the build. It documents an Adapter stack and style-embedding workflow that are commented out in the current
__init__.py. This baker and the Mutation variant are what actually ship. - VRAM still matters during baking. The node unloads everything and empties the cache first, but a full Anima model staged for baking is heavy. If it OOMs, go
float16+device=cpu, or bake fewer LoRAs at once.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| model | COMBO | 0 options: | |
| clip | COMBO | 0 options: | |
| vae | COMBO | 0 options: | |
| lora_stackopt | LORA_STACK | — | |
| save_dtypeopt | COMBO | auto | 4 options: auto, float16, bfloat16, float32 |
| deviceopt | COMBO | auto | 4 options: auto, cpu, cuda, npu |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |
| CLIP | CLIP | — |
| VAE | VAE | — |