Ino Load Sampler Models

This is the flagship node of ComfyUI Ino Nodes, and it's ambitious: one node that takes a model config and downloads and loads everything you need to sample - the UNET, the CLIP(s), the VAE, and up to four LoRAs - then hands you ready-to-use model, clip, and vae outputs. If you've ever wanted to make a whole sampler setup a single JSON you can swap per job, this is the node that makes it real.

It's part of ComfyUI Ino Nodes (nobandegani/ComfyUI-InoNodes), the 125+-node V3-schema pack, and sits at the center of its InoSamplerHelper category - the config-driven pipeline the pack is built around.

How it works

The core input is model_config, a JSON string describing the model stack: it contains unet, clip1, clip2, and vae sub-configs (each describing what to download and from where - HTTP, S3, HuggingFace, or Civitai) plus the weight_type and whether to use a dual CLIP. You also feed up to four lora_1_config through lora_4_config strings. Here's the flow:

1. The node downloads each model file using the pack's Ino Handle Download Model logic (which fans out to the right downloader per source).
2. It loads the UNET via UNETLoader with the config's weight_type.
3. It loads CLIP - a DualCLIPLoader if use_dual_clip is set, otherwise a single CLIPLoader - with your chosen clip_device (default or cpu).
4. It loads the VAE via VAELoader.
5. It applies each LoRA config in sequence to both model and CLIP, collecting trigger words as it goes.

That's a lot of machinery behind one interface, which is exactly the point: the pack is selling "a model is a JSON, not a pile of dropdowns."

Outputs: success, message, model (MODEL), clip (CLIP), vae (VAE), lora_applied (boolean - did any LoRA actually apply?), and trigger_words (STRING - concatenated trigger words from the applied LoRAs, which you can inject into your prompt). Wire model/clip/vae straight into your conditioning and sampler nodes.

What to watch

• The configs are the whole ballgame. A malformed model_config JSON fails early with a clear message, but a wrong config (bad URL, wrong weight type) can waste a download. Build configs with the pack's config-creation nodes so the JSON is right.
• It downloads first, every time. Each run can hit the network unless the download logic is cached. That's the price of self-contained configs - and a reason to keep configs stable across runs.
• LoRA configs are optional. Wire in empty strings for LoRA slots you don't need; lora_applied tells you whether any actually landed.
• This is a niche, config-driven workflow. There's essentially no community chatter about this pack on Reddit, so you're learning the JSON format from the README and the pack's own config nodes. Worth it if you want reproducible, file-based model setups; overkill if you pick your models once and never change them.

Installing it

ComfyUI Ino Nodes installs like any custom node pack:

• ComfyUI Manager (easiest): search for "ComfyUI Ino Nodes", install, restart.
• Manual:

  cd ComfyUI/custom_nodes
  git clone https://github.com/nobandegani/ComfyUI-InoNodes.git
  cd ComfyUI-InoNodes
  pip install -r requirements.txt

  Then restart ComfyUI.

Requires inopyutils, huggingface_hub, and hf_xet (both pulled in by the pack's requirements) plus a current ComfyUI. Heavy for a single node, but then again - it's not a single node, it's a whole sampler bootstrap in one box.