Alternative approaches considered

This PR uses an inline try/except guard at the top of each affected test. It works, but I wanted to flag two cleaner alternatives for your consideration:

1. @require_float8_support decorator (preferred)

Instead of repeating the same 4-line block across 5 tests, a reusable decorator in the test utilities would be more consistent with the existing @require_* pattern in diffusers:

def require_float8_support(test_func):
    @functools.wraps(test_func)
    def wrapper(*args, **kwargs):
        try:
            torch.zeros(1, device=torch_device).to(dtype=torch.float8_e4m3fn)
        except TypeError:
            raise unittest.SkipTest(f"Device {torch_device} does not support float8_e4m3fn")
        return test_func(*args, **kwargs)
    return wrapper

Each test then becomes:

@require_float8_support
def test_layerwise_casting_inference(self):
    ...

2. Guard in source code (enable_layerwise_casting)

A more complete fix would be to also add a check inside enable_layerwise_casting() itself, raising a clear ValueError when the device does not support the requested storage_dtype, rather than letting it crash deep inside the pipeline forward pass. The test-side skip would still be needed, but users calling the API directly would get a much better error message.

let me know which you prefer and I will update the PR. cc @pcuenca @DN6

Using the @skip_mps decorator is much cleaner and fits the existing test codebase conventions perfectly.
The only reason I initially went with the dynamic try/except check was to make it future-proof and device-agnostic (in case other accelerators/configurations also lack float8 casting support and trigger a similar TypeError). But since MPS is the primary backend experiencing this crash and @skip_mps is idiomatic for the suite, using it is definitely better.

u want me to update PR ?

Future-proof would xfailing those tests when torch_device == "mps". That way, if support is added in the future, xfail won't work anymore.

@sayakpaul
Since float8 support is a device capability (similar to bfloat16), would you prefer we xfail on MPS specifically to track when they add support, or use a generic @require_float8 decorator to skip on any unsupported device?

@sayakpaul
I have updated the PR to use @pytest.mark.xfail(condition=torch_device == "mps", reason="MPS does not support float8 casting.", strict=True) for all five affected layerwise casting tests instead of skipping them.

This way, if MPS adds float8 casting support in the future, the tests will unexpectedly pass (XPASS) and fail the suite, alerting us to remove the decorator.

Hi @sayakpaul,

The PR checks show 2 failing workflows on the CI:

1. Torch CUDA Tests (models):
   • TestAutoencoderVidTokMemory::test_group_offloading fails with a shape mismatch. This is because AutoencoderVidTok's forward returns a raw tensor instead of a single-element tuple (dec,) when return_dict=False (violating the standard Diffusers VAE return contract).
   • TestAutoencoderDCTraining::test_mixed_precision_training fails with cuDNN engine search errors ("GET was unable to find an engine...").
2. PyTorch Example CPU tests:
   • The unconditional image generation example test times out due to a blocking subprocess read under single-device CPU launch configurations.

I have tested and verified clean fixes for these locally (correcting AutoencoderVidTok's return type, adding a try-except skip guard for the DC mixed-precision test, and adding a timeout/single-process constraint to the example run helper).

Would you like me to push these fixes here to get the CI green for merge, or should we handle them in a separate PR?