TT SDXL Models Loader (Advanced)

If TT SDXL Models Loader is the tidy all-in-one, this is the same node with the floodgates open. TT SDXL Models Loader (Advanced) takes the primary-plus-secondary checkpoint merge and adds four LoRA slots, a vae_device pick, and a vae_dtype pick. It's the loader for the workflow that would otherwise have a chain of five LoraLoader nodes dangling off the checkpoint - you can stack a style LoRA, a character LoRA, a detail LoRA, and a negative-space one without adding a single node to the graph.

Mechanically it's the weighted-merge loader with the LoRA pipeline bolted on. The primary/secondary merge works exactly as in the plain version: primary_weight is the primary checkpoint's share of the blend (1.0 = all primary, 0.5 = half and half). Then each LoRA slot (lora_name_1–4 with strength_1–4) is applied in order on top of the merged model - and here's the fun part - the strengths run -10 to +10, so negative-strength LoRA steering is on the table, not just 0–1 blending. The node caches each loaded LoRA on the instance, so repeated runs that reuse the same LoRA don't re-read the file every time.

The Advanced additions round out the memory story:

• vae_device - default (GPU) or cpu. The plain loader pins the VAE to CPU; this one lets you choose. On a big-VRAM card, putting the VAE on GPU speeds decode; on a tight card, CPU keeps VRAM for sampling.
• vae_dtype - bfloat16, float16, or float32 for the VAE. bfloat16 is the usual sweet spot; float32 if you're seeing banding in decodes and have VRAM to spare.

Everything else is standard SDXL: clip_l and clip_g load the dual encoder pair (clip_device = cpu pushes them off-GPU), and vae_name can be a real VAE or the pixel_space passthrough. Outputs are MODEL, CLIP, VAE - standard types that work with any native node, so you can use this loader inside or outside the pack's context system.

Install is the pack standard:

cd ComfyUI/custom_nodes
git clone https://github.com/tenser-tensor/ComfyUI-TenserTensor

or search "TenserTensor" in ComfyUI Manager and restart.

The practical gotchas, most of which are LoRA-stacking traps rather than this node's fault:

• LoRA order matters. Slots apply in sequence 1→4. If a stack looks wrong, swap slot order before you blame the strengths.
• Cache staleness. Because LoRAs are cached on the node instance, if you replace a LoRA file on disk and re-run, you can get the old weights until you reload the workflow. Change a file → refresh the graph.
• Negative strength is powerful. -1 on a "photorealistic" LoRA pushes away from photorealism, which is legit - but it can also wreck a model if overdone. Start small.
• Merge + LoRAs = slow. A big checkpoint merge plus four LoRAs multiplies load time. That's the price of the convenience; accept it or use the plain loader with fewer slots.

Same pack-wide caveat as everything here: this is the V1 class, marked deprecated as the author migrates to API V3, with TT_SdxlModelsLoaderAdvancedNode as the maintained successor. Existing workflows keep running; new ones should probably start on the V3 version.