Render-time metrics capture end-to-end performance during image/video generation. They span the full pipeline: prompt parsing and text encoding, denoising steps (UNet), VAE decode/encode, upscalers, control/conditioning modules (ControlNet, LoRA), safety filters, and I/O. In anime, comics, and style workflows, these metrics guide hardware sizing, cost control, and user experience targets (SLOs).

Use clear, reproducible definitions:

• End-to-end latency: wall-clock time from request accepted to asset ready. Report p50/p95/p99.
• Model latency: time spent in the denoising loop (sum of step times).
• Step time: ms per denoise step per image at a given resolution and batch size.
• Throughput: images/minute or frames/second at steady state under defined batch size.
• Warmup time: first-run overhead (model load, JIT/graph compile, cache prime).
• VAE time: encode/decode duration (and upscaler time if used).
• Pre/post time: prompt encode, safety checker, image I/O, tiling merges.
• Resource peaks: GPU VRAM peak, CPU RAM peak, GPU utilization (%), VRAM bandwidth if available.
• Cost per asset: (instance $/s × latency) ÷ batch_size.
• Stability: jitter and variance of latency (p95/p50 ratio), error rate, OOM count.
• Queue wait: time before work starts; separate from processing latency.
• Cache hit rate: e.g., text encoder cache when prompts repeat.

Adopt a consistent, reproducible process:

• Fix inputs: same seed, prompt, resolution, scheduler, steps, CFG, LoRAs/ControlNets.
• Warmup: run ≥3 warmup runs; exclude from stats.
• Synchronize GPU: call device sync around timers to avoid async skew.
• Sample size: collect ≥30 runs; report p50/p95/p99 and mean ± std.
• Isolate: measure sub-stages (encode, denoise, VAE, upscaler, I/O) with scoped timers.
• Environment: record GPU model, VRAM, driver, CUDA, framework (PyTorch/ONNX/TensorRT), model version, precision (fp16/bf16/int8), attention impl (xFormers/Flash).
• Noise control: pin power mode, disable background jobs, fix batch size.
• Report clearly: include units, batch size, and image size in metric names (e.g., “p95_latency_1024px_b1”).

Key factors and their typical impact:

• Resolution and tiling: quadratic cost growth with pixels; latent tiling reduces memory at merge cost.
• Steps and scheduler: fewer, higher-quality steps via efficient samplers (e.g., DPM++ 2M Karras) reduce latency.
• Model family/size: SDXL vs SD 1.5; larger UNet and text encoders increase step time.
• Conditioners: ControlNet(s), IP-Adapter, T2I-Adapter, and multiple LoRAs add compute and memory.
• Precision and kernels: fp16/bf16 vs fp32; xFormers/Flash Attention improves attention time.
• Batch size: boosts throughput; may increase single-request latency and VRAM use.
• VAE and upscaling: heavier VAEs and SR models (ESRGAN/Real-ESRGAN/4xAnime) add tail latency.
• CPU↔GPU transfers & I/O: decoding/encoding PNG/WebP, safety checks, network storage can dominate for small models.
• Graph compilers: ONNX/TensorRT reduce steady-state latency after warmup; include compile time separately.

Build apples-to-apples baselines per workload:

• Single image (anime key art): 768–1024px, b1, fp16, 20–30 steps, standard VAE.
• Comic page (multi-panel): 2048–4096px tiled; record tile size, overlap, merge time.
• Batch character sheets: b4–b16 at 768px; focus on throughput.
• Frame sequences (animatic): fixed prompt/seed sweep; report fps and drift in style consistency.

For each baseline, publish: hardware, model versions, samplers, steps, CFG, precision, batch size, caching, and any ControlNet/LoRA settings.

Practical wins with minimal quality loss:

• Sampler/step tuning: try DPM++ 2M Karras or UniPC; reduce steps 20–30% after visual check.
• Precision: use fp16/bf16, enable memory-efficient/Flash Attention.
• Graph optimization: export to ONNX/TensorRT for UNet and VAE; cache compiled engines.
• Batch smartly: increase batch for throughput; cap to avoid p95 latency spikes.
• Text encoder caching: reuse embeddings for repeated prompts/panels.
• VAE speed: use fast VAE or latent upscalers; enable VAE tiling for large pages.
• Control modules: prune unused ControlNets; choose lighter variants when possible.
• I/O: switch to optimized PNG/WebP encoders; async save and safety checks.
• Memory: enable pinned memory and avoid unnecessary host-device copies.
• Concurrency: right-size worker count to GPU; avoid context thrash.

Turn metrics into SLOs:

• Track p50/p95 latency, error rate, OOMs, queue time, GPU VRAM peak, and cost/asset.
• Break down by route: txt2img, img2img, inpaint, upscaling, ControlNet variants.
• Emit per-stage timings for fast triage (encoder, denoise, VAE, I/O).
• Alert on: p95 > threshold, VRAM > threshold, compile failures, cache miss rate spikes.
• Budgeting: tag jobs by project and compute SKU to watch $/asset vs target.

Include this minimal block with every benchmark:

• Hardware: GPU(s), VRAM, CPU, RAM, driver, CUDA.
• Software: framework, versions, attention impl, precision, graph compiler.
• Model setup: base model, VAE, samplers, steps, CFG, LoRAs/ControlNets.
• Inputs: resolution, batch, seed, prompt.
• Results: p50/p95/p99 latency, throughput, step time, VAE time, VRAM peak, cost/asset.
• Notes: warmup runs excluded/included, caching, tiling.

• Timing without GPU sync inflates performance.
• Comparing different resolutions/steps and calling it a fair test.
• Ignoring warmup/JIT compile time in user-facing latency.
• Over-batching to chase throughput, causing p95 spikes and OOMs.
• Forgetting VAE/upscaler and I/O in “end-to-end” metrics.
• Not pinning seeds/samplers—visual differences mask regressions.