Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

MiniMax H3 VAE working-memory docstring states ~1.3-1.4x its measured peaks; the 243-frame case is 1.44x

Open Beginner friendly
  • Is something wrong?
#9,629 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
88/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Quiet
Tech stack
python
Domain
machine-learning

Research direction

Open invokeai/backend/util/vae_working_memory.py and find estimate_vae_working_memory_minimax_h3(). Update only its closing docstring statement to describe the measured ratio at 90 frames and 243 frames, noting that the ratio grows with clip length. Done means the wording matches the supplied measurements and the formula and behavior remain unchanged.

Written by the indexing model from the issue text.

Description

Found during review of invoke-ai/InvokeAI-7#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.

Dominant language
TypeScript
Stars
28.9k
Forks
3.1k
Avg merge
3d 17h
Merged PRs (30d)
188

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from invoke-ai/InvokeAI

All issues in invoke-ai/InvokeAI

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.