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.

[godsinister]

Update: I started at approximately 175 seconds for a 5-second, 512×512 MiniMax-H3 video and have optimized it down to 69 seconds using two AMD Radeon AI PRO R9700 32GB GPUs with Vulkan on Linux.

The improvement came from software optimization, including dual-GPU workload distribution, synchronization, cross-GPU transfers, and Vulkan execution improvements. Both GPUs are actively contributing to generation.

I'm continuing to optimize the pipeline and would be interested in comparing approaches with other Vulkan developers. Yes I did undervolt the cards a bit and reduced watts also increased memory speed. Why not it saved 2 seconds for testing llol.had to edit this a few a times. I did get up to 19 seconds using one card. 10 second videos are now down to 174 seconds using both cards with audio...