External Publication
Visit Post

Nvidia driver update - reactor node

Hugging Face Forums [Unofficial] May 26, 2026
Source

Yeah, ONNX Runtime breaks quite easily after environment changes… switching it to CPU temporarily may be a good move. Maybe something like this?

That error is very informative. It means the clean reinstall probably helped, but ONNX Runtime’s CUDA provider is still not loading correctly.

This line is the key:

Error loading:
D:\ComfyUI_windows_portable\python_embeded\Lib\site-packages\onnxruntime\capi\onnxruntime_providers_cuda.dll

which depends on:
cublasLt64_12.dll

which is missing.

So I would read the current state like this:

Clean ComfyUI install: probably OK
Basic PyTorch CUDA test: probably OK, if your earlier torch command passed
Basic ReActor still-image swap: works
ONNX Runtime CUDAExecutionProvider: broken or drifting
ONNX Runtime CPUExecutionProvider: probably being used as fallback

So this is not the same problem as before. You made progress.

Before, the whole environment was probably mixed. Now the problem looks narrower:

ReActor can run, but ONNX Runtime GPU acceleration cannot load the CUDA 12 DLLs it expects.

That missing cublasLt64_12.dll is a CUDA 12 cuBLAS runtime DLL. ONNX Runtime’s CUDA provider is trying to load it, and Windows cannot find it.

Similar ReActor reports:

  • ComfyUI-ReActor issue #201 - cublasLt64_12.dll missing
  • ComfyUI-ReActor issue #188 - CUDA provider / CPU tensor / cublasLt64_12.dll
  • ComfyUI-ReActor issue #195 - Python 3.13 + GPEN-BFR + cublasLt64_12.dll

Relevant ONNX Runtime docs:

  • ONNX Runtime CUDA Execution Provider
  • ONNX Runtime Install docs

Important caveat: this may be real GPU/runtime drift

I would not assume this is only a harmless warning.

It might be harmless if ReActor falls back to CPU and the output looks correct. But it might also mean the GPU execution layer genuinely drifted.

In other words, this could be real drift in the execution substrate:

GPU model / architecture
NVIDIA driver
PyTorch CUDA build
onnxruntime-gpu version
CUDA runtime DLLs
cuDNN runtime DLLs
Windows DLL search path
ComfyUI embedded Python environment

That matters because ONNX Runtime GPU support is sensitive to the exact combination of CUDA, cuDNN, Python, PyTorch, and GPU architecture.

So CPU mode is not “the final answer.” It is a stabilization and isolation step :

First: make ReActor work reliably on CPU.
Then: treat ONNX Runtime GPU as a separate optimization / migration problem.

This keeps you from breaking the clean install again while trying to fix GPU acceleration.

Why the face swap still worked

Because ONNX Runtime can often fall back to CPU.

So this can happen:

ONNX Runtime tries CUDAExecutionProvider
CUDA provider fails because a CUDA DLL is missing
ONNX Runtime continues with CPUExecutionProvider
ReActor still produces an image
console prints scary CUDA errors

That would explain:

simple ReActor image test works
but console shows cublasLt64_12.dll errors

The main downside may be speed.

But if later video or face-restore paths become unstable, then the broken CUDA provider may matter more.

First: capture the exact GPU/runtime state

Before changing packages again, I would record this:

cd D:\ComfyUI_windows_portable

nvidia-smi

.\python_embeded\python.exe -c "import sys; print('python=', sys.version)"

.\python_embeded\python.exe -c "import torch; print('torch=', torch.__version__); print('torch cuda=', torch.version.cuda); print('cuda available=', torch.cuda.is_available()); print('gpu=', torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'no gpu'); print('capability=', torch.cuda.get_device_capability(0) if torch.cuda.is_available() else 'no gpu')"

.\python_embeded\python.exe -c "import onnxruntime as ort; print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers())"

.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime torch nvidia cuda cudnn"

The GPU name and compute capability matter. For example, if someone is on a very new GPU architecture, old CUDA wheels or runtime packages can genuinely be wrong even if the code did not change.

So I would save this output somewhere before fixing anything.

Interpret the provider result

Run:

cd D:\ComfyUI_windows_portable

.\python_embeded\python.exe -c "import onnxruntime as ort; print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers())"

Case A

providers= ['CUDAExecutionProvider', 'CPUExecutionProvider']

This means ONNX Runtime package-level CUDA support is present, but loading the actual CUDA DLLs may still fail at runtime.

Case B

providers= ['CPUExecutionProvider']

or:

providers= ['AzureExecutionProvider', 'CPUExecutionProvider']

This means ONNX Runtime is effectively CPU-only.

Case C

Error loading onnxruntime_providers_cuda.dll
missing cublasLt64_12.dll

This means onnxruntime-gpu is installed, but the CUDA 12 runtime DLL it expects is not findable.

Check for mixed ONNX Runtime packages

This is worth checking:

.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime"

A confusing state would be:

onnxruntime
onnxruntime-gpu

Ideally, for a clean CPU-only temporary state, you want only:

onnxruntime

For a clean GPU state, you want only:

onnxruntime-gpu

Mixed CPU/GPU ONNX packages can make debugging harder.

Safest short-term workaround: make ONNX Runtime CPU-only

Because the simple ReActor swap already works, I would probably stabilize first.

The idea is:

Remove broken ONNX Runtime GPU provider
Use CPU ONNX Runtime
Verify ReActor still works
Verify the cublasLt64_12.dll warning disappears
Then decide whether GPU acceleration is worth fixing

Commands:

cd D:\ComfyUI_windows_portable

.\python_embeded\python.exe -m pip uninstall -y onnxruntime-gpu

.\python_embeded\python.exe -m pip install --upgrade --force-reinstall onnxruntime

Then verify:

.\python_embeded\python.exe -c "import onnxruntime as ort; print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers())"

A good temporary result is:

providers= ['CPUExecutionProvider']

or sometimes:

providers= ['AzureExecutionProvider', 'CPUExecutionProvider']

Then restart ComfyUI and test the same simple ReActor face swap again.

If the warning disappears and the image still works, then you have a stable baseline:

ComfyUI works
ReActor works
ONNX Runtime uses CPU
no missing cublasLt64_12.dll warning

That is a good recovery state.

Not necessarily the final fastest state, but a good stable state.

Why CPU-only may be the right next move

Because you have already proven something important:

fresh install worked
basic commands worked
basic ReActor image swap worked

So the remaining issue is narrower:

ONNX Runtime GPU acceleration is not loading

That should be treated separately.

If you try to fix ONNX GPU immediately, you may end up changing:

onnxruntime-gpu
CUDA runtime packages
cuDNN packages
PyTorch
Windows PATH
NVIDIA driver
ReActor dependencies

all at once again.

That is exactly how the original mixed environment probably happened.

So I would first get a clean CPU baseline, then handle GPU acceleration as a second phase.

If you later want to fix ONNX Runtime GPU

Only do this after CPU ReActor is stable.

The goal would be:

Make onnxruntime-gpu able to find the CUDA 12 / cuDNN DLLs it expects.

There are several possible paths.

Option A: Try ONNX Runtime GPU with CUDA/cuDNN extras

ONNX Runtime documents installation forms that can bring CUDA/cuDNN runtime dependencies into the Python environment.

In ComfyUI portable, use embedded Python:

cd D:\ComfyUI_windows_portable

.\python_embeded\python.exe -m pip uninstall -y onnxruntime onnxruntime-gpu

.\python_embeded\python.exe -m pip install --upgrade "onnxruntime-gpu[cuda,cudnn]"

Then test:

.\python_embeded\python.exe -c "import onnxruntime as ort; ort.preload_dlls(); print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers()); ort.print_debug_info()"

Relevant docs:

  • ONNX Runtime CUDA Execution Provider - preload DLLs
  • ONNX Runtime Install

But I would treat this as a second-phase experiment, not the immediate recovery step.

Option B: Preload PyTorch / NVIDIA DLLs before ONNX Runtime

ONNX Runtime documents that preloading DLLs can help it use CUDA/cuDNN DLLs from PyTorch or NVIDIA Python packages.

The basic idea is:

import torch
import onnxruntime

or:

import onnxruntime
onnxruntime.preload_dlls()

But whether this helps inside ComfyUI depends on when ReActor creates its ONNX Runtime sessions. If the custom node creates sessions before the preload happens, the preload test may work in a standalone command but not fix the node.

So this is useful for diagnosis, but not always a clean user-level fix.

Option C: Install CUDA runtime globally

You could install CUDA 12 runtime/toolkit so Windows can find cublasLt64_12.dll.

But I would not start there.

Global CUDA and PATH edits can make things harder to reason about. For ComfyUI portable, I would prefer keeping dependencies inside the portable Python environment where possible.

Do not confuse these two questions

There are now two separate questions:

Question 1:
Can ReActor work reliably at all?

Question 2:
Can ReActor use ONNX Runtime GPU acceleration?

You have probably answered Question 1: yes, at least for a simple still image.

Question 2 is still unresolved.

That means the practical recovery route is:

First stabilize ReActor CPU.
Then decide whether ONNX GPU is worth fixing.

What I would do next

My exact next steps would be:

1. Save the current command outputs
2. Confirm the simple ReActor still-image test works
3. Check ONNX Runtime providers
4. Remove onnxruntime-gpu
5. Install CPU onnxruntime
6. Restart ComfyUI
7. Confirm the cublasLt64_12.dll warning is gone
8. Test simple ReActor still image again
9. Test your real still-image workflow
10. Test short video
11. Only later try ONNX Runtime GPU again

Commands:

cd D:\ComfyUI_windows_portable

.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime"

.\python_embeded\python.exe -m pip uninstall -y onnxruntime-gpu

.\python_embeded\python.exe -m pip install --upgrade --force-reinstall onnxruntime

.\python_embeded\python.exe -c "import onnxruntime as ort; print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers())"

Then restart ComfyUI.

How to interpret the result

Good temporary result

providers= ['CPUExecutionProvider']
ReActor still works
no cublasLt64_12.dll warning

Meaning:

You now have a stable CPU ReActor setup.
It may be slower, but it is clean.

Still noisy

cublasLt64_12.dll warning still appears

Then onnxruntime-gpu is probably still installed somewhere in the ComfyUI embedded Python environment, or another package is still importing the GPU provider.

Check again:

.\python_embeded\python.exe -m pip list | findstr /i "onnxruntime"

ReActor stops working after CPU-only install

Then reinstall official ReActor using its installer:

cd D:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-ReActor

install.bat

But make sure it uses:

D:\ComfyUI_windows_portable\python_embeded\python.exe

not system Python.

Short version

Your new install probably worked.

The remaining error is probably:

ONNX Runtime GPU provider is broken or drifting
but ReActor can still run through CPU provider

So I would not reinstall everything again.

I would first stabilize ONNX Runtime as CPU-only:

cd D:\ComfyUI_windows_portable

.\python_embeded\python.exe -m pip uninstall -y onnxruntime-gpu

.\python_embeded\python.exe -m pip install --upgrade --force-reinstall onnxruntime

Then test ReActor again.

If that works and the warning disappears, you have a usable recovery state.

After that, GPU acceleration can be treated as a separate ONNX Runtime / CUDA / cuDNN / GPU-architecture migration problem, not as the main ReActor recovery problem.

Discussion in the ATmosphere

Loading comments...