KSampler (SPD LoRA / auto-schedule)

This is a narrow, specific node, and it's worth being upfront about that: it's for people using a LoRA specifically trained by the SPD trajectory-adapter workflow (the pack's companion training pipeline calls this make exp-spd), not a general-purpose LoRA loader. If that's not what you have, use the regular KSampler (Spectrum + SPD / SPEED) node with a stock LoraLoader in front of it instead.

What makes an SPD-trained LoRA different

The regular SPEED sampler runs a low-resolution prefix, then hands off to full resolution at a manually chosen spd_scale/spd_sigma. An SPD-trained LoRA was fine-tuned for a specific resolution ramp, and that schedule is baked into the file's own safetensors metadata (ss_spd_stages / ss_spd_transition_sigmas). This node reads that metadata and drives the sampler automatically - no manual scale/sigma tuning, because the inference geometry already matches what the adapter was trained on. It also honors multi-stage schedules (say, three resolution tiers instead of one low-to-full jump), which the base SPD node's split_mode = single can't express at all - it spectral-expands at each handoff in turn and only arms Spectrum's block-caching once the trajectory reaches full resolution.

Inputs and outputs

Standard KSampler surface (model, seed, steps, cfg, sampler_name, scheduler, positive, negative, latent_image, denoise) plus:

• lora_name - dropdown of LoRAs in your loras/ folder. There are no schedule knobs here by design; the schedule comes from the file itself.
• lora_strength (default 1.0) - the usual LoRA weight multiplier applied to the model.
• adaptive_smc_alpha - same detail-recovery CFG combine as the other Spectrum samplers.

Output is LATENT.

Like its non-LoRA sibling, this sampler is Euler-only - the sigma re-spacing that drives the resolution handoffs needs it, and other choices in sampler_name are ignored with a warning.

What if the LoRA isn't actually SPD-trained

Pick a normal style or character LoRA here by mistake and nothing breaks - it just won't have ss_spd_stages metadata. In that case the node falls back to the validated single-handoff schedule (spd_scale = 0.5, spd_sigma = 0.7) with a warning, which is exactly what the plain SPEED sampler defaults to. So the worst case is "behaves like the regular SPD node," not a crash.

Stacking other LoRAs or mod guidance

This node applies exactly one LoRA - the SPD-trained one. If you want a style LoRA or Anima's modulation guidance in the same graph, chain a stock LoraLoader or the Anima Mod Guidance patcher onto the model input before this node; it doesn't compose additional adapters on its own.

Installing it

ComfyUI Manager - search SpectrumKSampler, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/sorryhyun/ComfyUI-Spectrum-KSampler

Restart. This node has no auto-downloaded weights of its own - it only reads whatever LoRA file you already have.

Common issues & troubleshooting

lora_name dropdown is empty. You don't have any files in ComfyUI's loras/ directory yet - this node doesn't ship a default one, since SPD LoRAs are trained per-checkpoint via the companion anima_lora pipeline. Train or download one, drop it in models/loras/, and restart or refresh.

Chose a sampler other than Euler and it seemed to ignore me. Correct behavior - the resolution handoffs require Euler's fixed step structure, so anything else is overridden with a logged warning.

Not sure if your LoRA actually has schedule metadata. If it doesn't, you'll get the single-handoff fallback silently (aside from the console warning) - visually it should look identical to running the base SPD node at its defaults, so there's no broken output, just no multi-stage benefit.