Optimize a FLUX graph after it reliably saves an image. The useful change is one that improves your actual bottleneck while preserving the output your task needs. This guide shows how to compare quantization, offloading, decoding and optional caching without turning one result into a universal speed claim.
The cover is an illustration. FluxDraw does not supply measured percentage gains for these configurations here. For initial installation use the local setup guide; for a job that fails to complete use FLUX error diagnosis.
Visual guide: Optimize the stage that actually costs time
How to use this map
- Record complete wall time, dimensions, batch size, seed and model files. State whether model loading is included before comparing runs.
- Use the error or timing boundary to select the experiment: quantization for compatible inference, offloading for memory allocation, or tiling for decode pressure.
- Keep the original graph and output. An optimization that changes numeric precision or caching can also change the image; do not judge it by time alone.
- Repeat the same test after warm-up and record variation. Keep an optimization only when it still meets the image requirement and the measured bottleneck improves.
Stop and check: Do not stack several changes before measuring. If a result fails, restore the baseline and test the last change separately.
Next practical guides: FLUX on a 6GB GPU: ComfyUI Memory Diagnosis and Setup Checks · FLUX vs SDXL in ComfyUI: Test Plan and Comparison Scorecard
Implementation reference: Official ComfyUI FLUX setup. Use the matching version-specific example alongside this editorial map.
Define what you want to improve
Choose one objective: fit a job that fails, reduce repeat-generation time, lower peak GPU allocation or improve the number of acceptable images per session. These objectives can conflict. Offloading may help memory while adding transfer time; a cache may reduce work while changing the output.
| Observed bottleneck | Candidate to inspect | What to measure |
|---|---|---|
| Long model loading | Storage, model representation and graph changes | Cold load separately from repeat jobs |
| Encoder pressure | Text-encoder variant and placement | Encoding time and memory |
| Sampling pressure | Resolution, batch, precision and supported attention | Sampler time, peak memory and output quality |
| Decode pressure | VAE and supported tiling | Decode time, allocation and seams |
| Unusable output | Accuracy changes introduced by an optimization | Acceptance criteria rather than speed alone |
Save the baseline and timing boundary
- Save the working workflow JSON and an output image.
- Record model files, encoders, VAE, prompt, seed, dimensions and batch.
- Record GPU, RAM, driver, ComfyUI version and custom-node versions.
- State whether timing includes loading, text encoding, sampling, decoding and disk save.
- Keep cold-start and repeated-run measurements separate.
- Retain individual results so variation is visible.
If the next run reuses already loaded weights or cached node output, it may not be comparable with the first run. Make cache and load state part of the measurement record.
Compare quantization as a different configuration
Quantization changes the model representation and requires compatible loading. Check the source project for the specific format. Keep the original and quantized graphs separate so you can attribute changed output or allocation to the representation rather than an accidental graph change.
Use matching prompts and compare fine details, embedded lettering and complex object relationships. Keep failures as well as appealing examples. A lower file size does not predict peak memory for the complete graph, which also contains encoders, latents, attention and decoding.
Evaluate offloading with system memory in view
Offloading can move memory pressure from the GPU to host memory and transfers. Record both available system RAM and GPU usage. Compare end-to-end time, not only a sampling counter.
Try the default memory behavior of your installed release first. If you change a supported launch option, write down the exact option and rerun the same job. Avoid copying a long bundle of flags whose combined effect you cannot isolate.
Use VAE tiling for a decode question
If sampling finishes but decode fails, supported tiled decoding is a candidate to test. Keep other settings fixed. Compare the saved image for tile boundaries, color shifts and local detail changes, then measure decode time and memory separately.
Tiled decoding and tiled diffusion are different interventions. A decode setting should not be described as a universal reduction in the sampling stage’s memory.
Attention changes need environment compatibility
Supported attention implementations depend on the ComfyUI, PyTorch, device and extension combination. Use the official ComfyUI project for current support and installation guidance. Do not assume a percentage gain quoted for another GPU applies to yours.
If testing an optional backend, keep the ordinary working environment available. Verify the intended implementation is active and compare the full job with the same input. A successful dependency installation alone does not prove the graph used it.
Treat TeaCache as an output-changing experiment
The ComfyUI-TeaCache maintainer’s repository is the source for its supported models and node setup. Use instructions for the installed release and exact model. Do not transplant a threshold from another model or promise unchanged typography at a particular setting.
Save cache-off and cache-on outputs with matching input settings. Review the details that matter to your task, and include rejected results in the comparison. Start with the maintainer’s documented configuration and change one cache setting at a time. If output differences exceed your tolerance, disable the cache for that task.
Keep a compact comparison log
Configuration ID:
Baseline workflow and model files:
One change being tested:
Input, seed, size, batch and sampling settings:
Cold/warm state:
Timing boundary:
Individual run times and memory observations:
Output files and quality checks:
Failures:
Keep / revert / needs another test:When publishing the comparison, state the sample size and hardware. If you did not measure peak memory, say so. If a result only covers one prompt or image size, limit the conclusion to that experiment.
Keep only changes that meet the task
Compare accepted output, time and stability together. A lower memory peak can be useful even if the job slows down; a faster sampler can be less useful if it damages every second result. Decide against the objective you defined at the start.
For a constrained card, use the 6GB diagnosis plan. For evaluating delivered-image cost and review effort, see the production decision guide. These questions require their own evidence.
