GIMM-VFI Interpolate

This is the node that actually does the work: feed it your low-fps clip and it hands back a batch with new frames woven in between the ones you already have. Same job as RIFE VFI or FILM VFI - the standard back-half of a video workflow, where you generate cheap at a low frame rate (Wan, Hunyuan, AnimateDiff, whatever) and then interpolate up to something that plays smoothly. The reason to reach for GIMM-VFI specifically instead of the usual suspects: it's the one people report holding together on motion that makes RIFE ghost and smear - fast pans, things crossing behind other things, chaotic action. The catch is speed, and it's not subtle: community timing on a matched clip put RIFE around 9 seconds and GIMM's variants at 25-53 seconds. You're trading a lot of runtime for a specific quality win, so use it where that trade actually pays off.

How it's different from RIFE

RIFE estimates flow between a pair of frames and works down toward a target multiplier. GIMM-VFI ("Generalizable Implicit Motion Modeling") models motion as a continuous function of time instead, which is why its own model files carry "arb" in the name - arbitrary-time interpolation, not just fixed doubling. Practically, that shows up in this node's interpolation_factor going all the way to 100 rather than topping out at a couple of power-of-2 steps. You don't have to double, then double again - you tell it directly how far to stretch.

The inputs that matter

• gimmvfi_model - plug in the output of (Down)Load GIMMVFI Model here. Non-negotiable, this is what actually does the interpolating.
• images - your frame batch, wired from a VAE Decode or wherever your source frames come from.
• interpolation_factor (default 8, 1-100) - how far you're stretching the clip. This is the knob that actually changes your output. Start conservative; a factor of 8 on a 16fps clip gets you to 128fps worth of frames, which is a lot more than most workflows need, so don't just leave the default without thinking about your target fps.
• ds_factor (default 1, 0.01-1) - a downsample factor applied before flow estimation. Lower it if you're fighting memory or speed on a high-resolution clip; you're trading a bit of motion-estimation precision for headroom. Leave it at 1 unless you have a reason not to.
• seed - there for reproducibility. Leave at 0 unless you're deliberately trying to get a different result on a re-run.

output_flows is optional and off by default - flip it on and the second output, flow_tensors, actually populates with a visualization of the motion field the model computed. That's a debugging aid for when interpolation looks wrong and you want to see what motion it thought it saw; it's not something you feed into a video pipeline. Leave it off for normal use.

The outputs

images is your expanded frame batch - wire it into a Video Combine node (VideoHelperSuite) or a Save Image sequence to turn it back into a file. flow_tensors only has anything in it if output_flows was on; otherwise ignore it.

Installing it

Same pack as the loader node: ComfyUI Manager, search "ComfyUI-GIMM-VFI," install, restart - or cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-GIMM-VFI and restart manually. The pack needs cupy (the README pins cupy-cuda12==13.3.0 as tested), and unlike the RIFE/FILM pack there's no documented non-CUDA fallback - this is an NVIDIA-only affair as of now.

Where people get burned

The slow-motion trap. Same failure mode as every interpolator: interpolation_factor adds frames, it doesn't change your playback fps. If you stretch a 16fps clip by a factor of 8 and leave your Video Combine node at 16fps, you get a clip that plays back at 1/8th speed for eight times as long, not a smoother clip. Bump the output fps to match what you actually generated.

Reaching for this by default and wondering why everything is slow. GIMM-VFI's whole reason to exist is quality on hard motion, and that comes at a real time cost - several times slower than RIFE on the same clip, by community measurement. If your source footage is calm - steady camera, slow subject motion - RIFE or FILM will get you there faster with results that are hard to tell apart. Save GIMM-VFI for the shot that actually needs it.

No cache-clearing knob for OOM. RIFE VFI has a clear_cache_after_n_frames safety valve for long clips; this node doesn't expose an equivalent. If you're running out of memory on a long or high-res batch, your levers are ds_factor (lower it), the R model instead of F on the loader, or just splitting your clip into smaller chunks before you interpolate.