Analyzing and Improving Training-Free Fast Sampling of Text-to-Image Diffusion Models¶

Conference: ECCV2026
Paper: Official paper page
PDF: Full paper
Code: https://github.com/zju-pi/TORS
Area: Image Generation
Keywords: Training-free sampling, time scheduling, trajectory geometry, curvature and torsion, feature caching

TL;DR¶

TORS identifies the outer time schedule as the main bottleneck in few-step diffusion generation and places sampling times by equally partitioning the total rotation of projected three-dimensional trajectories, improving 10-step Flux.1-Dev Image Reward from 0.71 to 0.97 without matching the 50-step baseline on every metric.

Background & Motivation¶

Text-to-image inference cost depends not only on network size but also on how often the network must be evaluated. Distillation can reduce the number of evaluations but requires additional training; training-free approaches instead modify numerical solvers, rearrange sampling times, or cache intermediate network features. These approaches have often been evaluated separately, obscuring a practical question: under the same budget of actual computation, do gains primarily come from integration formulas, time allocation, or skipping some network modules?

The paper studies these approaches in a unified framework and finds that the outer time schedule has the largest effect on few-step image quality. Higher-order solvers usually offer modest gains, whereas caching benefits vary across models. Crucially, uniform timing does not make every step equally easy: Flux.1-Dev image structure continues to change as more sampling steps are added and only stabilizes at around 30 steps. If the early trajectory segments that establish structure bend and twist more rapidly, uniform time intervals allocate too little computation to them.

The authors therefore examine trajectories rather than dividing time uniformly. Across 100 trajectories with 100 steps each, the top three principal components explain over 99% of the variance on average, allowing the high-dimensional generation process to be approximately studied in three dimensions. Core idea: characterize geometric change jointly through curvature and torsion, and assign the same accumulated total rotation to every sampling interval so that rapidly changing regions automatically receive denser time points.

Method¶

Overall Architecture¶

TORS takes offline model sampling trajectories and a desired deployment step count as input, and outputs time points that can be used directly by the existing sampler. It neither changes model weights nor recomputes trajectory geometry for every generated image: trajectory geometry profiling first estimates average curvature and torsion, equal-total-rotation scheduling then produces schedules for different step counts, and the existing solver generates images along those time points.

The unified design space is an analytical framework for identifying the optimization target, not an additional inference network. The scheduling pipeline has two core components, corresponding to the two designs below; the solver and optional cache remain independently replaceable.

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    A["Offline high-step trajectories"] --> B["Trajectory Geometry Profiling"]
    B --> C["Equal-Total-Rotation Scheduling"]
    D["Target sampling step count"] --> C
    C --> E["Existing solver<br/>and optional feature cache"]
    F["Text and initial noise"] --> E
    E --> G["Generated image"]

Key Designs¶

1. Trajectory Geometry Profiling: locating few-step difficulty in bending and twisting

First consider how the paper isolates the effect of scheduling. Its unified framework has five dimensions: solver, outer schedule, inner schedule, cache object, and feature predictor. The outer schedule specifies when to update the state; the inner schedule decides whether a time point performs actual computation or reuses features. Cache objects can be the complete velocity, the residual of all Transformer blocks, individual block residuals, or attention and MLP operation residuals. The feature predictor either directly reuses historical features or extrapolates current features from historical changes. These choices affect different sources of error and overhead, so they should not all be conflated with reducing the step count.

For comparison, the analysis uses 20 scheduled steps and a compute-reuse cycle length of 2, keeping the number of full compute steps at 10. Defaults are Euler, a uniform outer schedule, block caching, and first-order direct reuse; higher-order feature prediction uses TaylorSeers. A warm-up strategy that reallocates computation toward the beginning helps, whereas reallocating it toward the end hurts. This establishes the importance of early temporal resolution. Reusing the complete velocity is equivalent to removing reuse steps from the outer schedule, which also explains why more scheduled steps do not necessarily mean more useful computation.

The authors then apply PCA to high-step trajectories and describe each trajectory through its top three principal components. An average explained variance above 99% supports this geometric approximation, but does not imply that the projection preserves every generation-relevant error. Arc-length parameterization separates the shape of a projected curve from the speed at which it is traversed: moving faster or slower along the same geometric path should not change its intrinsic bending.

In the Frenet-Serret frame, the tangent indicates the direction of motion, the normal indicates bending, and the binormal completes the orthonormal coordinate frame. Curvature measures how rapidly the tangent changes; torsion measures how rapidly the curve leaves its current osculating plane. Curvature alone misses twisting into the third dimension, which may not be negligible when sampling uses a small number of large steps.

Default profiling randomly samples MS-COCO prompts, generates 100 trajectories with 100 steps each, and estimates average curvature and torsion on a fine-grained arc-length grid. The cached main text specifies this process, but does not contain the referenced Algorithm 1 or appendices. Curve fitting, discrete differentiation, smoothing, and handling of nearly degenerate trajectories therefore cannot be fully reproduced from this cache, and are not invented here.

2. Equal-Total-Rotation Scheduling: assigning similar geometric change to each step

Curvature and torsion describe two different changes, but deployment requires a concrete timetable. The authors use the Darboux vector to describe rotation of the entire orthonormal frame. Its magnitude is the square root of the sum of squared curvature and torsion; integrating this magnitude over arc length yields total rotation. The expression below follows the explicit prose definition of this magnitude and the equal-partition rule. The plus sign in cached Equation (7) is damaged by extraction, so the corrupted text is not interpreted as multiplication.

\[ \Theta_{[s_a,s_b]}=\int_{s_a}^{s_b}\sqrt{\kappa(s)^2+\tau(s)^2}\,\mathrm{d}s, \qquad \Theta_{[s_j,s_{j+1}]}=\frac{\Theta_{[0,S]}}{N}. \]

Here \(\kappa(s)\) and \(\tau(s)\) are the geometric statistics described above, \(S\) is the total arc length of the statistical curve, and \(N\) is the target number of sampling intervals. Operationally, this selects equally spaced quantiles of accumulated rotation and maps the resulting arc-length boundaries back to time. A region with high curvature or torsion accumulates rotation faster and therefore receives shorter steps; a geometrically quieter region can be crossed with larger steps. Generation still proceeds from noise at time 1 toward data at time 0: total rotation, rather than time itself, is partitioned equally.

Why include both quantities? The paper's local-error argument separates the leading geometric error of Euler steps into a second-order normal bending term and a third-order binormal term involving curvature multiplied by torsion. As step size approaches zero, the higher-order term is easier to neglect. In few-step sampling, however, the step size is not small and twisting can matter in practice. Total rotation combines both changes into a scalar for computation allocation. This argument discards subdominant terms, so it should not be treated as a proof of globally optimal error for arbitrary models or solvers.

Because TORS modifies the outer schedule, its interface is separate from higher-order solvers, inner compute-reuse strategies, and feature predictors. Compatibility does not mean every combination improves performance: the paper finds that a feature predictor may help one model while consistently degrading another, whereas gains from improving the outer schedule are more stable.

A Worked Example¶

Consider deploying Flux.1-Dev with 10 steps. First generate 100 offline trajectories, each with 100 steps, and establish average geometric statistics. For a 10-step schedule, split total rotation into 10 equal portions, select the arc-length boundaries, and map them to time points. For a new prompt and fresh noise, use the original network with these time points directly, without rerunning high-step profiling for this image.

The additional expense occurs during schedule construction. If the target later changes to 20 steps, the same geometric statistics can be repartitioned without updating weights or collecting new trajectories solely because the step count changed. The paper also transfers the Flux schedule directly to LoRA variants, Qwen-Image, and Flux.1-Kontext. These are evaluated transfer cases, not a guarantee across all architectures.

Loss & Training¶

TORS introduces no training loss, performs no backpropagation, and does not fine-tune the generator. Default profiling costs approximately 3 A6000 GPU hours for Flux.1-Dev and 1 A6000 GPU hour for Stable Diffusion 3.5 medium. Once statistics are available, constructing schedules for arbitrary target step counts has negligible overhead. Training-free therefore does not mean free of offline computation.

The main experiments default to guidance scale 7 and use up to 4 NVIDIA RTX A6000 GPUs. As an additional comparison, the authors use Bayesian optimization to search a parameterized schedule, obtaining \(\alpha=6.23\), \(\beta=1.34\), and \(p=0.18\) after 1000 search iterations. This is a separate comparison experiment, not a required TORS training stage. Cached Figure 6 does not provide a complete set of precisely readable values, so only the main-text claim that TORS approaches the searched schedule in Image Reward is retained; no numerical gap is invented.

Key Experimental Results¶

Main Results¶

The following table selects DrawBench results from the paper's Table 1. IR denotes Image Reward, CS denotes CLIP Score, AS denotes Aesthetic Score, and HPSv2 denotes Human Preference Score v2; higher is better for all four. The 10-step acceleration methods follow the paper's compute-budget convention, which does not imply identical end-to-end latency across methods.

Model	Method	Compute steps	IR	CS	AS	HPSv2
Flux.1-Dev	Baseline	50	0.96	30.61	5.73	30.15
Flux.1-Dev	Baseline	10	0.71	30.08	5.53	27.70
Flux.1-Dev	TaylorSeers	10	0.77	30.38	5.58	28.19
Flux.1-Dev	UniPC	10	0.78	30.41	5.58	28.16
Flux.1-Dev	GITS	10	0.90	30.53	5.65	29.13
Flux.1-Dev	TORS	10	0.97	30.97	5.71	29.30
SD 3.5 medium	Baseline	50	0.97	33.26	5.37	28.64
SD 3.5 medium	Baseline	10	0.55	32.77	5.23	25.31
SD 3.5 medium	TaylorSeers	10	0.54	32.73	5.22	25.25
SD 3.5 medium	UniPC	10	0.69	32.88	5.29	26.43
SD 3.5 medium	GITS	10	0.75	32.72	5.25	25.89
SD 3.5 medium	TORS	10	0.86	33.13	5.33	26.90

On Flux.1-Dev, TORS improves over the equal-budget baseline by 0.26 IR and 1.60 HPSv2, and over GITS by 0.07 IR and 0.17 HPSv2. Relative to the 50-step baseline, IR is slightly higher but HPSv2 remains lower by 0.85, so approaching 50-step quality does not mean universally lossless acceleration. On SD 3.5 medium, TORS improves over the 10-step baseline by 0.31 IR and 1.59 HPSv2, while again not matching every 50-step metric.

In the paper's Table 2, overall GenEval scores are 0.65 for the 50-step baseline, 0.57 for the 10-step baseline, and 0.67 for 10-step TORS. TORS scores 0.49 on attribute binding, above the two baselines' 0.41 and 0.28; its counting score is 0.67, still below the 50-step baseline's 0.69. A better aggregate score does not imply superiority on every capability.

Ablation Study¶

The following results come from Table 5(b)(c) and vary the profiling configuration used to construct the schedule; final evaluation remains few-step Flux generation. Sample count and the step count of each profiling trajectory are varied separately. The latter must not be mistaken for the deployment sampling step count.

Varied factor	Profiling configuration	IR	HPSv2
Trajectory sample count	25 trajectories	0.96	29.41
Trajectory sample count	50 trajectories	0.96	29.43
Trajectory sample count	75 trajectories	0.95	29.37
Trajectory sample count	100 trajectories	0.97	29.30
Steps per trajectory	25 steps	0.81	28.23
Steps per trajectory	50 steps	0.91	28.61
Steps per trajectory	75 steps	0.94	29.03
Steps per trajectory	100 steps	0.97	29.30

Key Findings¶

More samples are not automatically better: results from 25 to 100 trajectories are close and non-monotonic. By contrast, increasing each profiling trajectory from 25 to 100 steps raises IR from 0.81 to 0.97 and HPSv2 from 28.23 to 29.30, indicating the importance of accurate geometric sampling.
On transfer to Qwen-Image, 10-step HPSv2 improves from 27.10 to 29.28 but remains below that model's 50-step score of 30.80. This supports transfer gains under a limited budget, not full equivalence to reference generation.
Caching should not be judged by evaluation count alone: in the paper's Flux analysis, velocity caching takes 9.85 seconds and 36.32 GB of VRAM, whereas operation caching adds 6% to 14% latency and uses 38.48 to 42.78 GB. Finer-grained reuse is not inherently a free improvement.

Highlights & Insights¶

Separating when to compute from how to integrate and what to reuse helps avoid over-optimizing a local component. For an existing sampler, examining time-budget allocation may be more valuable than immediately adopting a more complex solver.
Total rotation combines tangent bending with twisting out of the osculating plane, explaining why curvature alone may be insufficient. It provides actionable scheduling statistics without adding another predictor that needs training.
Reusing one profiling run across target step counts reduces deployment tuning cost. The ablation suggests prioritizing sufficiently dense individual trajectories before deciding whether more prompts are necessary.

Limitations & Future Work¶

The paper explicitly finds that too few profiling steps are harmful, and offline cost is real. Small deployments or frequent model changes require a separate assessment of whether subsequent inference savings amortize approximately 3 or 1 A6000 GPU hours.
At the level of assumptions, high PCA explained variance does not guarantee that discarded directions are semantically irrelevant; average geometry is also not adapted to each prompt. Complex compositions, rare prompts, and different resolutions deserve further boundary testing.
At the level of theoretical scope, total rotation is a geometrically motivated discretization indicator, but the cache does not establish a global optimum for every solver or provide fully readable compatibility-heatmap values. The finding that the outer schedule matters most should not become a universal law for all models and budgets.
At the level of reproducibility, the current cache omits the appendices and Algorithm 1. Implementing the method still requires checking geometric estimation, arc-length alignment, and time mapping. This note reports only mechanisms and tables supported by the main text, without supplying unknown implementation details.

vs GITS: GITS approximates global truncation error by accumulating local errors and searches schedules through dynamic programming; TORS directly partitions total rotation using curvature and torsion of projected trajectories. Both identify outer time allocation as a valuable target, but use different criteria.
vs DPM-Solver / UniPC: These primarily change numerical updates, using historical velocities or predictor-corrector mechanisms to improve integration accuracy; TORS changes time points and can therefore be combined with them. Combination gains still need evaluation against actual computation and latency.
vs FORA / TaylorSeers: These reuse or predict intermediate features to avoid some network computation; TORS does not require such caches. The paper's model-dependent results highlight that feature smoothness and trajectory geometry require separate empirical validation and cannot substitute for one another.

Rating¶

Novelty: 4/5. Joint curvature-and-torsion scheduling following a unified analysis is more explanatory than manually densifying early steps, but builds on prior trajectory-geometry research.
Experimental Thoroughness: 4/5. Covers two main models, GenEval, profiling ablations, model transfer, and image editing; the current cache lacks appendices and fully readable details for every figure.
Writing Quality: 4/5. The progression from design-space analysis to geometric observations and scheduling is clear; the local-error approximation should not be mistaken for a strict global guarantee.
Value: 4/5. Reusable schedules without weight updates are useful for deployment, subject to offline profiling costs and remaining gaps to high-step baselines on some metrics.