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