Performance Timers

After every generation, SD.Next prints a performance line below the image and in the server log that breaks down where the time went:

Time: 5.52s | total 8.57 pipeline 3.60 decode 1.80 onload 1.02 prompt 0.77 preview 0.76 move 0.46 | GPU 11238 MB 46% | RAM 15.73 GB 24%

• First number is the wall-clock duration of the inference, including UI overhead of all stages
• The middle section lists per-stage timers, sorted by duration
• Stages taking less than 0.25 sec are hidden
• GPU and RAM show peak memory usage for the run

Reading this line is the fastest way to find out why a generation is slow and which setting to tune

Stage reference

Model execution

Timer	Meaning	Note
pipeline	The main denoising loop: UNet or DiT/transformer forward passes for each step	This is the core compute of the generation
hires	Second-pass processing when HiRes fix is enabled
refine	Refiner pass when a refiner model is enabled
decode	The final decode stage: turning latents into the output image, including image post-processing
vae	Time spent inside actual VAE encode/decode calls, e.g. encoding the input image for img2img/inpaint	Overlaps with decode on the output side
te	Text encoder forward pass: turning the parsed prompt into conditioning tensors
prompt	Prompt parse and text-encode: attention syntax, prompt scheduling and building the embeddings	Overlaps with te
lora	Loading, applying and removing LoRA weights	See LoRA for the performance impact of different LoRA modes

Memory management

Timer	Meaning	Note
sync	GPU synchronization time: waiting for GPU to finish one task before moving to the next one	can be (unsafe) disabled in Settings -> Backend Settings
onload	Moving model components from RAM to VRAM when offloading is active	See Offload
offload	Moving model components from VRAM back to RAM	See Offload
move	Module component forced device moves	Used by legacy pipelines only, modern models report onload/offload instead
gc	Garbage collection: clearing unused RAM and VRAM between stages

Everything else

Timer	Meaning	Note
preview	Generating live previews during sampling	Runs asynchronously on a separate thread, so it only partially adds to wall-clock time
callback	Per-step callbacks executed during sampling
init	Pipeline and sampler initialization
prepare, pre	Applying processing modifiers (IP-Adapter, HiDiffusion, PAG, etc.) before the run
post	Unapplying processing modifiers and post-processing after the run
process	Overall per-batch processing wrapper	overlaps with the stages above
validate	Validating decoded samples and converting them to image format
proc	Running Control input processors (canny, depth, pose, etc.) on the input image

Note

Video models (LTX, FramePack) report their own stage timers such as base, upsample, sample, encode and vision which follow the same principle: each named stage is the time spent in that part of the video pipeline.

What to tune

• High pipeline: this is the actual model compute. Fewer steps, a faster sampler, quantization, or model compile. See Performance Tuning
• High onload/offload/move: model parts are being shuffled between RAM and VRAM every generation. If you have VRAM headroom, raise the offload low watermark or exempt specific model/module types from offloading in Settings -> Models & Loading. Note that offloading exists for a reason: workflows that spike VRAM usage, such as HiRes to a much higher resolution, need that headroom for decode. See Offload
• High decode/vae: consider a faster VAE, or check whether VAE tiling/slicing is enabled unnecessarily on a high-VRAM system. See VAE
• High lora: LoRA apply cost depends heavily on LoRA type and mode; see the measurements in Offload
• High te/prompt: large text encoders (T5, LLMs) are expensive; offloading them adds onload cost on every prompt change. Reusing the same prompt avoids re-encoding