小珠光VFI防丢帧

If you generate video with Wan and you've read any production workflow, you've seen the pipeline: generate at 480p, interpolate frames with GIMM-VFI to smooth the motion, then upscale with SeedVR2 (the wan-video ecosystem doc calls it out explicitly). GIMM-VFI is a generalizable video frame interpolator that reads optical flow to invent the in-between frames. 小珠光VFI防丢帧 ("Xiaozhuguang VFI anti-frame-loss") takes the two nodes you'd normally use - the GIMM-VFI model loader and the interpolate node - and merges them into one, then adds a trick that keeps the frame count exact.

That display name isn't marketing. The classic GIMM-VFI footgun is that interpolation only cleanly splits a pair of frames into factor slots when the total frame count cooperates, and you can end up short by a frame or two at the tail - which is precisely the flicker you're trying to smooth. This node pads the sequence with copies of the last frame to a tidy 4N+1 length, interpolates, then trims back to exactly original_count × factor frames. Nothing lost, nothing extra, no dead frames at the end.

What you actually set

• images - your frame sequence, straight from a video loader or frame extractor.
• model - two choices, gimmvfi_r_arb_lpips_fp32.safetensors (uses a RAFT flow estimator) or gimmvfi_f_arb_lpips_fp32.safetensors (FlowFormer). The F variant is the one the community favours for the heavy lifting.
• interpolation_factor (1–100, default 2) - how many frames out per frame in. 2 doubles the framerate.
• ds_factor (0.01–1.0, default 1) - internal downsampling for memory. Drop it below 1 when the sequence is long or your card is small; quality takes a mild hit but it's the main VRAM lever.
• precision (fp32/bf16/fp16, default fp32) - this node defaults to the heaviest precision. On anything but a big card, bf16 is the sane first move.
• torch_compile (bool, default off) - compiles parts of the model; needs Triton installed.
• input_fps (optional float port, default 25) - wire this from your video loader. The node multiplies it by the factor and hands you the result back.

What comes out

Two outputs: images (the interpolated sequence) and output_fps - computed as input_fps × interpolation_factor, which is the one you wire into your video combine node's fps so the export stays at the right speed instead of playing back slow-mo.

Installing and first-run setup

Same as every node in the pack - ComfyUI Manager (search "ComfyUI-xiaozhuguang") or:

cd ComfyUI/custom_nodes/
git clone https://github.com/xiaozhuguang/ComfyUI-xiaozhuguang.git

The VFI-specific machinery is bundled (the xzg_gimmvfi/ subpackage), so you don't need the separate ComfyUI-GIMM-VFI plugin. What you do need are its runtime deps, which the pack's requirements.txt lists separately: omegaconf, yacs, easydict, timm, huggingface_hub, and notably cupy-cuda12x>=13.3.0 - a CUDA-12 build, so if your torch is built for a different CUDA version that's the install bump you'll hit. The weights auto-download from HuggingFace (Kijai/GIMM-VFI_safetensors) on first run into ComfyUI/models/interpolation/gimm-vfi/, along with the matching flow-estimator file. No network or blocked HF means manual placement in that folder.

Where people get burned

• It's slow - that's normal. GIMM-VFI is quality-first; community testing puts it around four times slower than RIFE on the same footage (one 81-frame 2x job: ~50s RIFE vs ~4min GIMM). It earns that with better handling of fast motion and complex scenes, but don't reach for it when you need speed - RIFE or ComfyUI's built-in Film VFI are the fast lane.
• fp32 default. It'll run, then it'll OOM on a modest card. Set bf16 (or fp16) and keep ds_factor in mind before blaming the GPU.
• torch_compile silently needs Triton. Leave it off unless you've confirmed Triton is importable; the gain isn't worth a mystery import error.
• First run looks hung. The model download happens inside the node's first execution with nothing pretty on screen; give it a beat before assuming it's frozen.