FramePack

FramePack is a next-frame (next-frame-section) prediction model: instead of diffusing a whole clip at once, it predicts the following frame sections progressively. Its input context is compressed to a constant length, so the generation workload is invariant to video length. A 13B parameter model runs in 6 GB of GPU memory, and a 60 second, 1800 frame clip at 30 fps is in reach. It is open source under Apache-2.0 and ships as desktop software with a Gradio interface. Sections appear one after another.

Why the context stays constant

• Each input frame is tokenized with a variable patchifying kernel: important frames get a longer context, distant ones a much shorter one, so the total token count stays bounded.
• Importance can be measured by time proximity, feature similarity or a hybrid; the resulting compression pattern (FramePack scheduling) keeps a constant cost regardless of clip length, which makes computation per frame O(1).
• Drift, the quality decay of long videos, is handled with anti-drifting sampling: in image-to-video the endpoint is established early and intermediate sections are generated in inverted temporal order towards that anchor. F1 uses vanilla sampling, while the planned P1 adds planned anti-drifting.

What it needs

• An NVIDIA GPU from the RTX 30XX, 40XX or 50XX series with fp16 and bf16 support, at least 6 GB of VRAM, and Windows or Linux; the GTX 10XX and 20XX series are untested.
• On Windows an all-in-one package (CUDA 12.6, PyTorch 2.6) is uncompressed, updated with update.bat and started with run.bat; the weights download automatically and are over 30 GB.
• On Linux a separate Python 3.10 environment is recommended: a PyTorch CUDA 12.6 build, requirements.txt, then python demo_gradio.py. Published examples are around 480p at 30 fps.
• At CyberElectro it runs in a Docker container on a Windows workstation with an NVIDIA GPU, started by a local wrapper script.

Time and quality expectations

• Documented speed on an RTX 4090 is 2.5 seconds per frame, or 1.5 with TeaCache; laptop GPUs are 4 to 8 times slower, so a 60 second clip takes hours.
• TeaCache is not lossless, and sage-attention, quantization or GGUF weights also influence results; the repository recommends them for testing ideas, with the final render through the full diffusion process.
• A 1 second clip in the UI early on is expected, since the model works section by section.
• Next-frame models are sensitive to subtle differences in noise and hardware, so the official sanity check is worth running before a first custom input.
• Short clips with little motion work best: prompts should forbid camera movement and allow only slow micro-motion.
• The repository warns that it is the only official source; similarly named websites are not.

Batch runs

• One job is sent to a running instance at a time; a single job already brings the GPU close to saturation, so parallel submission only risks mixed up outputs.
• The batch loops sequentially over one reused client, waits for the previous job to finish, and writes output next to the source image; an existing readable video is skipped unless an overwrite is requested.
• The wrapper script logs source, job state and target path, and success is reported only when the target file exists, is non-empty and opens.

Further reading

• FramePack repository
• FramePack project page
• Frame Context Packing and Drift Prevention in Next-Frame-Prediction Video Diffusion Models

At CyberElectro FramePack is the tool for short image-to-video clips: it runs in a container behind a wrapper script, one job at a time, and only verified local output is accepted. Input images come from models such as FLUX and our own LoRA weights.