MiniMax-H3 creates full-clip FP32 temporaries after VAE decoding #15119

The MiniMax-H3 decode block converts the entire decoded video to FP32 before applying the pixel mean/std and clamp, even when the requested output is NumPy or PIL and will ultimately be on the CPU.

The code is still present at decoders.py:193. Each FP32 intermediate scales with the full clip rather than a small frame batch. This can add substantial device-memory pressure after VAE decoding has already completed.

This CPU-only snippet isolates the allocation in that expression; it does not reproduce a CUDA OOM:

import torch

video = torch.zeros((2, 3, 22, 8, 8), dtype=torch.float16)
mean = torch.tensor([0.485, 0.456, 0.406]).view(1, 3, 1, 1, 1)
std = torch.tensor([0.229, 0.224, 0.225]).view(1, 3, 1, 1, 1)

restored = (video.float() * std + mean).clamp(0, 1)
print(restored.dtype, restored.untyped_storage().nbytes())
# torch.float32 33792

For a (1, 3, 345, 768, 1344) clip, a single full-clip FP32 allocation is about 3.98 GiB, before accounting for other live tensors. A bounded temporal conversion could avoid full-clip FP32 intermediates while keeping the existing pixel arithmetic and processor behavior. Tensor output would still need its full final allocation on the requested device.

The existing PR #15070 implements that approach. Its tiny-VAE CPU checks preserve NumPy/PIL/tensor outputs; they do not establish CUDA peak memory, full-size OOM avoidance, offload compatibility, or performance. This issue records the problem and proposed scope; maintainer coordination is still pending.

Environment for the recorded CPU checks: PyTorch 2.14.0, no CUDA, Diffusers source base b800f828f3951c4d206e154411bcbfa693cd322e. The relevant decoder blob is unchanged on current main aaf57d03a3edfbd9de457d2872417a92f149a91d. AI assistance was used to investigate and document this issue.