Fix SadTalker CUDA
out of memory.

Try these changes in this order:

1. Close other applications using your NVIDIA GPU.
2. Restart SadTalker or its Python process.
3. Set SadTalker batch size to 1.
4. Use the 256 face model instead of 512.
5. Turn off GFPGAN Face Enhancer.
6. Turn off the background enhancer if enabled.
7. Run SadTalker again while monitoring VRAM with nvidia-smi.

Run this from your SadTalker folder with its Python environment active. Replace input.wav and input.png with your own file paths. The multiline examples use Bash; in Windows PowerShell or Command Prompt, put the command on one line:

python inference.py \
  --driven_audio input.wav \
  --source_image input.png \
  --size 256 \
  --batch_size 1

SadTalker uses PyTorch to run neural-network operations on an NVIDIA GPU.

The GPU has its own memory called VRAM. When PyTorch requests another block of GPU memory and enough usable VRAM is not available, generation can stop with a CUDA out-of-memory error.

A typical error begins with:

torch.cuda.OutOfMemoryError: CUDA out of memory

The rest of the message may tell you how much memory PyTorch attempted to allocate, how much VRAM the GPU contains, and how much memory remained free.

The exact numbers will be different on every system.

Open another terminal while SadTalker is running:

nvidia-smi

Look for:

Memory-Usage

For example:

8000 MiB / 12288 MiB

This illustrative reading means about 7.8 GiB of a 12 GiB GPU is occupied; it is not a measurement from our test.

Also inspect the Processes section at the bottom of nvidia-smi.

You may find another Python process, AI application, Stable Diffusion instance, browser workload, or another GPU program already consuming VRAM.

Monitor VRAM Continuously on Linux

Use:

watch -n 1 nvidia-smi

This refreshes GPU usage every second.

Press:

Ctrl+C

to stop monitoring.

This is the first fix I recommend.

Run:

nvidia-smi

Check which processes are using GPU memory.

If another program that belongs to you is consuming several gigabytes of VRAM, close it before starting SadTalker.

On Linux you can also inspect Python processes:

ps -ef | grep python

Do not terminate random processes on a shared GPU server. Only stop a process when you know it belongs to your own workload.

After closing the unwanted process, run:

nvidia-smi

again.

Make sure the GPU now has substantially more free memory.

Then retry SadTalker.

SadTalker's command-line interface uses:

--batch_size

for face rendering.

The default is 2.

Try:

--batch_size 1

Example:

python inference.py \
  --driven_audio input.wav \
  --source_image input.png \
  --batch_size 1

If you use the SadTalker WebUI, reduce the batch size in generation setting to:

1

A smaller batch generally requires less GPU memory.

SadTalker supports 256 and 512 face-render resolutions.

If you are running:

--size 512

change it to:

--size 256

Example:

python inference.py \
  --driven_audio input.wav \
  --source_image input.png \
  --size 256 \
  --batch_size 1

SadTalker's default CLI resolution is already 256, making this a sensible setting for GPUs with limited VRAM.

In the WebUI, select:

256

for the face model resolution.

SadTalker can optionally run a face-restoration model after generating the animation.

You may see:

--enhancer gfpgan

in your command.

Try removing it.

Instead of:

python inference.py \
  --driven_audio input.wav \
  --source_image input.png \
  --enhancer gfpgan

run:

python inference.py \
  --driven_audio input.wav \
  --source_image input.png

If you're using WebUI, turn off:

GFPGAN as Face enhancer

This isolates the additional restoration stage so you can check whether basic generation completes first.

SadTalker also supports:

--background_enhancer realesrgan

If you enabled it, remove the option while troubleshooting.

Start with basic generation first.

Once basic SadTalker generation works reliably, you can test optional enhancement separately.

If your GPU is struggling, use this as your starting point:

python inference.py \
  --driven_audio input.wav \
  --source_image input.png \
  --result_dir results \
  --size 256 \
  --batch_size 1

Notice what is intentionally missing:

--enhancer gfpgan
--background_enhancer realesrgan

Start with the simpler configuration before enabling additional processing.

PyTorch uses a CUDA caching allocator.

This means GPU memory shown by nvidia-smi can sometimes remain reserved while a Python process is still alive.

Stop SadTalker completely and start it again.

Then check:

nvidia-smi

before generating another video.

If an old Python process remains active, identify it with:

ps -ef | grep python

and stop only the process you own and recognize.

You may see this command recommended online:

torch.cuda.empty_cache()

It can release unused cached memory so that memory becomes available to other GPU applications.

However, it does not free GPU memory that is still being used by active PyTorch tensors.

For a normal SadTalker user, completely restarting the failed Python/SadTalker process is usually easier than modifying SadTalker's code to call empty_cache().

Some CUDA OOM messages mention:

PYTORCH_CUDA_ALLOC_CONF

Use the documentation for your installed PyTorch version. Current PyTorch documents PYTORCH_ALLOC_CONF, with PYTORCH_CUDA_ALLOC_CONF retained as a compatibility alias; older SadTalker environments commonly use the latter.

Allocator tuning can sometimes help when memory fragmentation is the actual problem.

However, PyTorch describes options such as max_split_size_mb as a last-resort setting for workloads that fail because of allocator fragmentation.

I would not use allocator settings as the first SadTalker fix.

First try:

• freeing VRAM,
• batch size 1,
• resolution 256,
• disabling GFPGAN,
• disabling background enhancement,
• restarting SadTalker.

Only investigate allocator configuration if the error specifically suggests that reserved but unused memory is unusually large.

You can verify your CUDA GPU from the SadTalker environment with:

python -c "import torch; ok=torch.cuda.is_available(); print(ok); print(torch.cuda.get_device_name(0) if ok else 'CUDA unavailable')"

A healthy NVIDIA setup should return something similar to:

True
NVIDIA GeForce RTX 3060

If CUDA is available, inspect free and total GPU memory. This checks device-wide availability in a separate process; it does not measure SadTalker’s peak allocation:

python -c "import torch; free,total=torch.cuda.mem_get_info(); print('Free:',round(free/1024**3,2),'GiB'); print('Total:',round(total/1024**3,2),'GiB')"

Do not confuse a CUDA OOM with a CUDA initialization problem.

A genuine memory error usually contains:

CUDA out of memory

Errors such as:

Failed to initialize NVML

or:

Driver/library version mismatch

are different problems.

Likewise, CUDA initialization errors should be fixed at the NVIDIA driver/CUDA level rather than by lowering SadTalker's batch size.

After applying a change, first run:

nvidia-smi

Record the free VRAM.

Then run SadTalker:

python inference.py \
  --driven_audio input.wav \
  --source_image input.png \
  --result_dir results \
  --size 256 \
  --batch_size 1

While generation is running, monitor:

watch -n 1 nvidia-smi

The fix is verified when:

• SadTalker completes without a CUDA OOM,
• an MP4 is created in the results directory,
• the MP4 opens and plays with the expected audio,
• and the process releases its GPU allocations when it exits (other programs may still occupy VRAM).

If you want the shortest path, use this order:

There is no single VRAM requirement that guarantees every SadTalker configuration will work.

A user in SadTalker discussion #457 reported an OOM on a 4 GB NVIDIA laptop GPU. That report is evidence of a failure, not a verified recovery or a universal minimum-VRAM requirement.

Available VRAM also depends on other GPU processes and the options enabled during inference.

If you're working with limited VRAM, start with:

256 resolution
batch size 1
no GFPGAN
no background enhancer

SadTalker's CLI includes a CPU option.

You can try:

python inference.py \
  --driven_audio input.wav \
  --source_image input.png \
  --cpu

CPU inference will normally be significantly slower than NVIDIA GPU inference, so I would treat this as a fallback rather than the first solution.

If your problem is not actually a CUDA memory error, check these guides:

• SadTalker Installation Guide
• SadTalker GitHub Guide
• SadTalker Hugging Face Guide
• SadTalker Docker Setup
• SadTalker Model and Checkpoint Guide
• SadTalker FAQs

Why does SadTalker say CUDA out of memory?

The GPU does not have enough usable VRAM for the current operation. Another GPU process, higher rendering settings, batch size, or optional enhancement can contribute to the problem.

What batch size should I use?

For troubleshooting low VRAM, start with:

batch size = 1

Should I use SadTalker 256 or 512?

Try 256 first when GPU memory is limited.

Does GFPGAN require additional resources?

GFPGAN runs an additional face-restoration stage. If SadTalker fails during or around enhancement, disable GFPGAN and test basic generation first.

Will torch.cuda.empty_cache() solve every OOM?

No. It releases unused cached allocations, not memory occupied by active tensors.

How do I know another program is using my GPU?

Run:

nvidia-smi

and inspect the process list and GPU memory usage.

What if nvidia-smi itself fails?

Then you probably have a GPU driver or NVIDIA runtime problem rather than a normal SadTalker CUDA OOM. Fix the NVIDIA environment before troubleshooting SadTalker's memory settings.