Decorating bound methods in profiling utils breaks instance isolation

[ViktoriiaRomanova]

Describe the bug

Trying to profile the ltx2 pipeline encountered an error:

Root Cause: Interaction of Two Factors

When wrapping pipeline component methods (e.g., scheduler.step) using a decorator (annotate), the method is retrieved as a bound method:

diffusers/examples/profiling/profiling_utils.py

Lines 45 to 48 in 5063aa5

	method = getattr(component, method_name, None)
	if method is None:
	continue
	setattr(component, method_name, annotate(method, label))

The decorator then wraps this bound method, capturing its __self__ (the original scheduler instance) inside the closure.

As a result:

• The wrapped step becomes a plain function, not a descriptor.
• The original self is frozen inside the wrapper.

Later, when duplicating the scheduler (a peculiarity of the ltx2 pipeline):

diffusers/src/diffusers/pipelines/ltx2/pipeline_ltx2.py

Line 1172 in 5063aa5

audio_scheduler = copy.deepcopy(self.scheduler)

the wrapped function is copied as-is, including the captured reference to the original scheduler.

As a result: calling audio_scheduler.step(...) actually executes self.scheduler.step(...):

diffusers/src/diffusers/pipelines/ltx2/pipeline_ltx2.py

Lines 1402 to 1405 in 5063aa5

	latents = self.scheduler.step(noise_pred_video, t, latents, return_dict=False)[0]
	# NOTE: for now duplicate scheduler for audio latents in case self.scheduler sets internal state in
	# the step method (such as _step_index)
	audio_latents = audio_scheduler.step(noise_pred_audio, t, audio_latents, return_dict=False)[0]

This leads to:

• Shared internal state (_step_index) between supposedly independent schedulers
• Incorrect stepping behavior
• Index out-of-bounds errors during inference

The following shows debugger output from the first loop iteration, right after executing audio_scheduler.step():

The object ID inside both step calls matches the ID of self.scheduler:

Fix Proposal

Decorate the unbound function and rebind it:

    for component_name, method_name, label in annotations:
        component = getattr(pipe, component_name, None)
        if component is None:
            continue
        component_cls = type(component)
        method = getattr(component_cls, method_name, None)
        if method is None:
            continue
        setattr(component, method_name, annotate(method, label).__get__(component, component_cls))

I can open a PR if this solution is suitable.

Reproduction

Run ltx2 profiling for any number of steps:
python examples/profiling/profiling_pipelines.py --pipeline ltx2 --mode eager --num_steps 2

Logs

System Info

Diffusers version: 0.38.0.dev0

• Platform: Linux-6.8.0-84-generic-x86_64-with-glibc2.39
• Running on Google Colab?: No
• Python version: 3.12.3
• PyTorch version (GPU?): 2.10.0+cu128 (True)
• Flax version (CPU?/GPU?/TPU?): not installed (NA)
• Jax version: not installed
• JaxLib version: not installed
• Huggingface_hub version: 1.9.2
• Transformers version: 5.5.1
• Accelerate version: 1.13.0
• PEFT version: not installed
• Bitsandbytes version: not installed
• Safetensors version: 0.7.0
• xFormers version: not installed
• Accelerator: NVIDIA A100-SXM4-80GB, 81920 MiB

Who can help?

@sayakpaul, @dg845

[sayakpaul]

Is this particular to LTX2 because it has two schedulers?

[ViktoriiaRomanova]

Not specifically. The issue isn’t tied to LTX2 having two schedulers, but rather to the fact that the scheduler is deep-copied inside the __call__ method.

Decorating a bound method freezes the self state at decoration time. In addition, without proper rebinding, the <class 'method'> is turned into a plain <class 'function'>, losing its descriptor behaviour. This can lead to a range of issues, especially when instances are copied.

LTX2 just makes the problem more visible, but the underlying issue is general and can occur in any pipeline.

Is this particular to LTX2 because it has two schedulers?

[sayakpaul]

Not specifically. The issue isn’t tied to LTX2 having two schedulers, but rather to the fact that the scheduler is deep-copied inside the call method.

Which other pipelines have this pattern?

[ViktoriiaRomanova]

Under the same conditions (i.e., the scheduler is copied inside the pipeline’s __call__), I found the following pipelines that seem to follow this pattern:

• pipeline_ltx2_condition.py
• pipeline_ltx2_image2video.py
• pipeline_skyreels_v2_diffusion_forcing_i2v.py
• pipeline_skyreels_v2_diffusion_forcing_v2v.py
• pipeline_skyreels_v2_diffusion_forcing.py

Not specifically. The issue isn’t tied to LTX2 having two schedulers, but rather to the fact that the scheduler is deep-copied inside the call method.

Which other pipelines have this pattern?

[Akash504-ai]

Fixes #13462. This updates the profiling utilities to decorate the underlying function instead of the bound method and rebinds it to the instance, preserving descriptor behavior and preventing shared state after deepcopy.