SadTalker 256 vs 512: quality, time and VRAM

Same input, two base render sizes

Only size changes in the main pair. Both use crop, still OFF, enhancer none, batch size 2, expression scale 1.0 and pose style 0. The synchronized player shows 256 on the left, 512 on the right and uses one audio track.

Inspect eyes, skin, mouth and face edges

In the sampled close-ups, the 256 render looks softer around the eyes, beard and skin texture. The 512 render shows finer-looking facial texture at this enlarged display size. Mouth shape, blinking and head position also differ between the independent runs, so those differences cannot be attributed to resolution alone. Neither sample establishes objectively better lip sync or identity accuracy.

Look across the whole clip, especially around teeth, eye shape, facial hair and the jaw boundary. These are visual observations from one input, not scored identity, lip-sync or temporal-consistency measurements.

Measured render time and sampled VRAM

We rendered four combinations once each to cover both questions with minimal GPU time. There were no extra warm-ups or repeated trials. The node starts a new worker for every render; model-loading time is included. Values are individual measurements, not medians or a universal speed ranking.

Swipe the table sideways to view time, resolution and VRAM.

With GFPGAN OFF, 256 took 27.88 s and 512 took 55.41 s: 512 was 1.99× the elapsed time in these runs. The sampled whole-GPU peak rose from 4,799 MiB to 10,047 MiB. The final unenhanced videos are 256 × 256 and 512 × 512.

Server execution_start → execution_success timing includes input loading, worker/model startup, rendering and export; queue wait and provisioning are excluded. Fresh filenames invalidate input caching, and successful outputs were checked for video/audio streams and hash integrity.

Reproduce the comparison in ComfyUI

Start with our ComfyUI setup guide. This workflow extends its LoadImage / LoadAudio template with two SadTalker nodes sharing the same inputs.

1. Get the comparison workflow and drag it into ComfyUI.
2. Upload the portrait and the narration. Both nodes share them.
3. Set the left node to size = 256 and the right to size = 512. Keep enhancer = none on both. Keep crop, still OFF (displayed as animated), batch 2, expression 1.0 and pose 0.
4. Click Run. Generated MP4s and logs are saved under ComfyUI/output/sadtalker/<run-id>/. Repeating an unchanged workflow can return cached results.

for file in 256-off-api.json 512-off-api.json; do
  python -c 'import json,sys; print(json.dumps({"prompt":json.load(open(sys.argv[1]))}))' "$file" > prompt.json
  curl -X POST http://127.0.0.1:8188/prompt -H 'Content-Type: application/json' --data-binary @prompt.json
done

Which render size should you use?

Limits and failed runs

4 of 4 configurations completed successfully. No render errors occurred in these four runs. This is one portrait, one narration and one rented GPU. There are no repeat-trial error bars, scored lip-sync or identity metrics, or out-of-memory boundary tests.

GFPGAN OFF and ON are separate SadTalker runs. The template has no seed control, so part of a frame-level difference may come from expression, blinking or head motion. This is an end-to-end ComfyUI toggle comparison; it does not isolate restoration by processing the exact same generated frame twice.

If a render fails or memory runs out, inspect its worker log and reduce batch size to 1. That setting was not tested here. Changing batch size, preprocessing, still mode, hardware or worker CPU threads makes the timings less directly comparable.

Implementation references: the tested enhancement/upscaling code, GFPGAN’s official restoration project, and the tested ComfyUI node.