Found during review of #84 (size VAE decode memory from measured peaks). Documentation-only; the formula itself is correct and does what the PR set out to do.
What
estimate_vae_working_memory_minimax_h3() in invokeai/backend/util/vae_working_memory.py closes its docstring with:
Calibrated 2026-08-09 on a W7900 (gfx1100, fp32, real released config), peak reserved: [...] a full 768x1344 decode 4.37 GiB at 90 frames and 7.92 GiB at 243 frames. This formula returns ~1.3-1.4x those.
Evaluating the shipped formula against those two points (released geometry: tokens_chunk_size=5, token_overlap=2, temporal_compression_ratio=4, fp32):
| Case |
Measured |
Formula |
Ratio |
| 768x1344 decode, 90 frames |
4.37 GiB |
5.73 GiB |
1.31x |
| 768x1344 decode, 243 frames |
7.92 GiB |
11.38 GiB |
1.44x |
So the lower bound is right and the upper bound is slightly understated.
Why it matters
Small, but the number is load-bearing documentation. The margin here is the whole point of the change — under-reserving is not a near miss, it is an unrecoverable failure that surfaces from hipBLAS as HIPBLAS_STATUS_INTERNAL_ERROR and is not even recognised as an OOM by the model cache. Anyone later tuning MINIMAX_H3_ALLOCATOR_HEADROOM or MINIMAX_H3_CHUNK_BYTES_PER_PIXEL will reason from this sentence, and it understates how much headroom is actually being taken from the weight budget at long clip lengths.
Note the ratio is not constant — it grows with clip length, because the clip term scales with frames while the chunk term does not. "~1.3-1.4x" reads as a flat factor when it is really a range that widens.
Suggested fix
Restate as measured, e.g. "returns 1.3x at 90 frames rising to ~1.45x at 243 — the ratio grows with clip length, since the clip term scales with frame count and the chunk term does not."
Scope
Docstring only, invokeai/backend/util/vae_working_memory.py. No behaviour change. Low priority.
Found during review of #84 (size VAE decode memory from measured peaks). Documentation-only; the formula itself is correct and does what the PR set out to do.
What
estimate_vae_working_memory_minimax_h3()ininvokeai/backend/util/vae_working_memory.pycloses its docstring with:Evaluating the shipped formula against those two points (released geometry:
tokens_chunk_size=5,token_overlap=2,temporal_compression_ratio=4, fp32):So the lower bound is right and the upper bound is slightly understated.
Why it matters
Small, but the number is load-bearing documentation. The margin here is the whole point of the change — under-reserving is not a near miss, it is an unrecoverable failure that surfaces from hipBLAS as
HIPBLAS_STATUS_INTERNAL_ERRORand is not even recognised as an OOM by the model cache. Anyone later tuningMINIMAX_H3_ALLOCATOR_HEADROOMorMINIMAX_H3_CHUNK_BYTES_PER_PIXELwill reason from this sentence, and it understates how much headroom is actually being taken from the weight budget at long clip lengths.Note the ratio is not constant — it grows with clip length, because the clip term scales with frames while the chunk term does not. "~1.3-1.4x" reads as a flat factor when it is really a range that widens.
Suggested fix
Restate as measured, e.g. "returns 1.3x at 90 frames rising to ~1.45x at 243 — the ratio grows with clip length, since the clip term scales with frame count and the chunk term does not."
Scope
Docstring only,
invokeai/backend/util/vae_working_memory.py. No behaviour change. Low priority.