Workflow

Sixty Seconds on Six Gigabytes: FramePack and Tiled Decoding for Long Low-VRAM Animation

18 September 2026 · RenderBob team

Most low-VRAM tricks shrink the model. A FramePack architecture-animation workflow shrinks the duration problem, generating up to 60-second camera moves from a still on 6GB VRAM.

Most low-VRAM techniques this blog has covered attack model size, fitting a big model onto a small card. A community architecture-animation workflow tackles a related, different problem: fitting a long duration onto a small card. It generates up to 60-second camera-motion animations, push-ins, orbits, and similar moves, from a single static image, on hardware advertised as low as 6GB of VRAM. Those 6GB figures are hardware- and version-dependent. Treat them as a starting claim, then measure on your card.

FramePack

FramePack is the mechanism for the duration problem. Rather than holding an entire long sequence's latent state in memory at once, the naive approach, and the reason long generations blow VRAM budgets, it compresses and packs frame context so the memory requirement does not scale linearly with duration. Combined with BF16 quantisation on the model itself, that is what makes a full minute of animated camera motion feasible on a card where a naive approach would OOM at a fraction of that length.

Tiled decoding

Tiled decoding solves an adjacent bottleneck. The VAE decode step, where a full-resolution frame is reconstructed from its compressed latent, can spike VRAM sharply at higher resolutions, a distinct spike from the sampling stage that block swap covers. Tiled decoding processes the frame in smaller spatial tiles rather than all at once, trading a bit of decode time for a lower peak during that stage. The architecture-animation guide uses 128-pixel tiles on 6GB cards. It is the same split-the-upscale-from-the-sampling advice this blog has given for avoiding the classic OOM that happens when two memory-hungry stages collide.

Animating a static building or product image with camera motion is a common production need: architectural visualisation, product hero shots, any brief that wants a still to feel alive with subtle camera movement rather than full character animation. If that job really does run on modest hardware at up to 60 seconds, it does not need to compete for the studio's scarcest, most VRAM-hungry render nodes.

Low VRAM is not one problem with one fix. Model size, sequence duration, and decode resolution are three distinct memory pressures, each with a dedicated technique: GGUF and other quantisation for the first, FramePack-style compression for the second, tiled decoding for the third. Keep a tested, pinned answer for each, rather than hoping one favourite trick covers every kind of pressure a workflow can throw.