MiniMax H3 uses 256x256 tiling by default during vae decode, why?

[ProbablyMartian]

I run sd-cli with MiniMax H3 workflow (as described in SD docs), without --vae-tiling but I still see in bash Linux terminal:

VAE decode tile size 256x256 (16x16 latent).

Why? I have noted VAE decode uses only ~7GB VRAM, I want to run non-tiled hoping it will speed up a lot. With 4 steps LoRA VAE decode takes ~35% of total time (if diffusion part fits in VRAM) - significant chunk.

I have tried to manually increase tile to 512 (--vae-tile-size), but that added artifacts in the video (IIRC it became "tiled" with 16 pixels tile size).

[Medamineelkhattabi]

It's intentional, and no flag turns it off for the original MiniMax-H3 video VAE. resolve_original_tiling_params always sets enabled = true and uses 256 px tiles (16x16 latent) with 0.25 overlap unless you pass a size (minimax_h3_vae.hpp#L722-L739). The reference does the same: diffusers says H3 "was released with tiling enabled" (L523-L525).

Your 512 artifacts aren't a unit mix-up: --vae-tile-size 512 means 512x512 pixels (32 latent). The decoder is a ViT that turns each latent token into a 16x16 pixel patch, and its RoPE positions are normalized to the tile, (h + 0.5) / height (L997-L1002). Any tile that isn't 16 tokens wide changes the spacing it sees, and the error lands on the 16 px patch edges. #2310 (open) measures this at 128, 384, 512 px and full frame. Full frame saved only about 1 s of decode there.

For a whole-clip decode that's also faster, use Sol-H3-VAE (master-1086 or newer, docs):

--vae minimax_h3_sol_vae_int8_convrot.safetensors

Don't pass --vae-tiling, and the tile log line goes away. Its RoPE is window-local (16-token windows), so frame size doesn't matter. #2317 reports at 864x480, 56 frames: original FP16 8.37 s / 6.53 GiB peak, Sol INT8 2.98 s / 6.70 GiB. On OOM, sd.cpp retries with temporal tiling first.

Adding --vae-tiling to the original VAE only raises overlap to 0.5, which means more tiles.