LiquidAI LFM-2-350M Loader

This is the boring half of the LFM2 pack, and that's a compliment. Loader nodes are plumbing - you wire them, they sit there, you never think about them again. The interesting bit here is that the plumbing is genuinely clever: it downloads a tiny 350M language model from HuggingFace on first run, runs it fully local (no API, no key, nothing leaves your machine), and quietly repairs the _orig_mod. weight-prefix mess that torch.compile() leaves behind when someone saves a fine-tune.

The model itself is the point of the pack. marduk191 - the same handle behind several FluxD-derived gguf checkpoints floating around the community - fine-tuned LiquidAI's LFM2-350M on 60,000 description-to-prompt pairs so it can rewrite a lazy one-liner into the kind of detailed, lighting-and-camera-spec prompt that Z-Image Turbo rewards. Modern models like Z-Image read your prompt as an instruction through an LLM text encoder, not as a bag of tags, and rich natural-language prompts are exactly what they answer well to. The Loader just gets that model into VRAM so the LFM2Generator can do the writing.

How it works

Under the hood it's plain transformers: AutoTokenizer and AutoModelForCausalLM with trust_remote_code=True, loaded to CPU first (low_cpu_mem_usage=True) and then moved to whatever device you picked. The star move is the weight-key fix. Fine-tunes saved with torch.compile() carry an _orig_mod. prefix on every key, which breaks normal loading. The node inspects the safetensors keys, strips the prefix, and loads with strict=False - it does this for local checkpoints and for the HuggingFace download, so you don't have to re-save anything yourself.

Inputs that matter

You'll realistically touch three things:

• repo_id - the HuggingFace repo, defaulting to marduk191/lfm2-350m-dp-marduk191. Leave it unless you're pulling a different base.
• precision - bf16 by default. On pre-Ampere GPUs or on CPU, bf16 is a bad idea; drop to fp16 or fp32.
• local_path - optional, and it overrides repo_id when the path exists. Point this at a checkpoint you fine-tuned (the _orig_mod. fix is exactly for that case). If the path doesn't exist, the node silently falls back to HuggingFace - the console log tells you which it loaded.

There's also device (cuda/cpu). CPU works, this model is tiny, but it's slow - treat it as a smoke test.

Outputs and where they go

Two outputs: model (type LFM2_MODEL) and tokenizer (type LFM2_TOKENIZER). These are custom types that only plug into the pack's own Generator - you can't feed them into anything else, so the Loader is always paired with the Generator.

Installation

The whole pack installs in one step:

cd ComfyUI/custom_nodes
git clone https://github.com/marduk191/ComfyUI_LFM2-350M.git
cd ComfyUI_LFM2-350M
pip install -r requirements.txt

Then restart ComfyUI. ComfyUI Manager finds it too - search for ComfyUI_LFM2-350M. The requirements are modest: transformers, torch, accelerate, safetensors - nothing that fights your existing install, and no extra model files to hunt down because the checkpoint streams down from HuggingFace on first run.

Common issues

• First load looks broken - the console spams LFM2 Debug - lines while it downloads and inspects weights. That's normal, not an error; the download is the long part.
• bf16 load fails - your GPU predates Ampere (no bf16 support) or you're on CPU. Switch precision to fp16/fp32.
• Missing/unexpected key warnings - expected with strict=False; the node logs the counts so you can sanity-check that a big missing_keys number isn't a wrong-architecture checkpoint.
• It loaded the wrong model - you typed a local_path that doesn't exist. The console line Loading LFM2 model from Hugging Face: tells you it fell through to repo_id.