Hunyuan Video Sampler Save

First, the naming trap: despite "Save" sitting right there in the name, this node doesn't save anything. Look at its outputs and there's exactly one - a LATENT - and it's not flagged as an output node. It's a sampler, full stop. You still need a VAE decode and a save/video-combine node after it, same as with a plain KSampler. Whatever "Save" was supposed to mean here, the schema doesn't back it up, so don't go looking for a file-writing option on this node - there isn't one.

What it actually is: this pack's own KSampler, built to take Hunyuan's video-shaped latents specifically. The author's pitch is memory-efficient sequential frame processing, progress tracking for long generations, and interrupt-safe handling - all plausible things to want when you're sampling a whole clip instead of one frame, since a naive whole-batch approach can spike VRAM hard. There's no benchmark in the README and no community threads discussing this pack at all, so take the "optimized" framing as an unverified claim rather than a proven win over the stock KSampler - it might be exactly that under the hood with a friendlier signature.

How it works

Mechanically it's the KSampler you already know: model, positive/negative conditioning, a latent in, sampler + scheduler + steps + cfg + denoise, a latent out. The one meaningful difference is the latent input is explicitly named video_latents, signaling it expects the multi-frame latent this pack's EmptyVideoLatentForHunyuan produces rather than a single-image latent.

The inputs and outputs that matter

• model, positive, negative - your loaded Hunyuan checkpoint and text conditioning, same as any sampler.
• video_latents - the LATENT from EmptyVideoLatentForHunyuan (or another Hunyuan-shaped latent source).
• steps (default 20) and cfg (default 8, range 0–100) - standard sampling controls. Hunyuan's checkpoints aren't guidance-distilled the way a lot of 2026's speed-tuned models are, so a real CFG value in the 6–10 range is expected here, not the CFG-1 trend you'd apply to a distilled turbo model.
• sampler_name / scheduler - the full stock ComfyUI lists (34 samplers, 9 schedulers including linear_quadratic, which is the kind of scheduler built for flow-matching DiT models like Hunyuan). Start with something plain like simple or normal - aggressive schedules built for older DDPM-style trajectories can distort a flow-matching one rather than help it.
• denoise (default 0.6, range 0–1) - worth flagging on its own below.

Output is a single LATENT - decode it with a VAE Decode node and hand the result to a video-combine or save node; this node itself never writes a file.

How to install it

Via ComfyUI Manager: search ComfyUI-HunyuanVideoSamplerSave, install, restart. Manually:

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

then restart. You also need a Hunyuan diffusion model in models/unet - the README points at a single anonymous Google Drive link with no filename or version noted. If you have a choice, source your Hunyuan checkpoint from Tencent's official Hugging Face repo instead and only fall back to the README's link if you specifically need whatever they packaged there.

Common issues & troubleshooting

Your output looks half-formed or mushy. Check denoise first. The default is 0.6, which is an img2img-style partial-denoise value - fine if you're refining an existing latent, wrong if you're generating from scratch off an empty latent from EmptyVideoLatentForHunyuan. For a clean text-to-video run, push denoise to 1.0.

Nothing downstream, or ComfyUI complains the queue produced no output. This node is not an output node despite its name - you need a VAEDecode plus a save/combine node chained after it.

Type mismatch at the model or positive/negative wires. This node expects a Hunyuan-format model and its matching text encoder output - wiring in an SDXL or Flux checkpoint will fail at the connection, not silently misbehave.

It's slow and you don't know if that's normal. There's no published benchmark for this node's "memory-efficient" claim, so run one short test clip before committing GPU time to a long batch - you're the first data point here, not the last.