CORRECTION to an earlier commit, which recorded "decoder_tile_size 256 is broken BY ITSELF -- 82% of the tile is exactly zero". That was true of what I ran and false about the parameter. decoder_tile_size = 512 (default) decoder_tile_stride = 384 (default, an INDEPENDENT parameter) Overlap is 512-384 = 128. Setting size to 256 and leaving stride at 384 makes the STRIDE LARGER THAN THE TILE, so tiles stop overlapping and leave 128 px gaps with zero coverage. Dividing by a zero weight window is exactly the 82% zeros and 53984 NaNs. Change both and it is fine. With the stride moved to match (both divisible by latent_compression = 8): 512/384 (default) 2890 MiB IDENTICAL rmse 0.89 m 384/288 2216 MiB NEAR rmse 12.67 m 256/192 1656 MiB NEAR rmse 12.76 m VRAM drops 43% at 256/192 -- the constraint I had called untouchable earlier in the session, twice, both times wrongly. The cost is rmse 12.7 m against a field whose sd is 364 m, about 3.5%, from the reduced overlap changing the blend. TIMING IS NOT MEASURABLE HERE. The run deliberately repeated the default config last as a drift check: 5.68 s at the start, 9.64 s at the end. 1.7x drift across four configs, because the GPU heats to 86 C and throttles from 2100 to 1410 MHz. Clock pinning needs root and was declined, so every speed claim from now on has to come from an ALTERNATING A/B (as the autocast result did) rather than a table, at double the cost per experiment. VRAM and correctness are unaffected by drift and remain trustworthy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>