Your workflow probably isn’t broken. It’s likely just the software in your execution environment that’s broken.

Setting up an open-source generative AI environment—not just ComfyUI—is quite fragile. In short, it can break at the slightest provocation. It’s absolutely true that the first major hurdle is the installation itself …

The general rule is: “Once it’s working properly, stick with that setup and avoid making changes as much as possible,” and “When working on something else, set up a separate, isolated environment.” I think this is relatively easier to do with the Portable version… People who take this seriously use virtual containers or similar solutions.

So, in your case, the error message indicates that it’s the ONNX Runtime that’s broken. This is a relatively mild case, and reinstalling it isn’t that difficult. (I’m not saying it’s easy, though…)

---

This does not look like a workflow mistake anymore

Your workflow may still be basically fine.

The strongest clue is the log error:

Error loading "...\onnxruntime_providers_cuda.dll" which depends on "cublasLt64_12.dll" which is missing.

That means the GPU runtime layer for ReActor/ONNX Runtime is failing to load. In plain English:

• your face-swap graph can still be logically correct
• but the GPU engine underneath it is now broken
• so the node no longer processes frames the way it did before

That is why rebuilding the workflow from scratch did not fix it.

---

The key diagnosis

This looks much more like:

• ONNX Runtime GPU / CUDA dependency break
• possibly made more fragile by Portable + Python 3.13
• not primarily a “wrong ReActor settings” issue

The most important current sources point the same way:

• ComfyUI Portable now ships as Python 3.13 + CUDA 13.0 by default, and also offers an alternative Python 3.12 + CUDA 12.6 build for older GPUs: ComfyUI Portable (official docs)

• ONNX Runtime CUDA says its GPU packages must match the runtime environment by CUDA major version and cuDNN major version , and that CUDA 12 builds are for CUDA 12.x ; cuDNN 8 and 9 are not interchangeable : ONNX Runtime CUDA provider docs

• ONNX Runtime also documents a Windows-specific fix/workaround: it can preload CUDA, cuDNN, and MSVC runtime DLLs , and on Windows its default search order checks the PyTorchlib directory first: ONNX Runtime CUDA provider docs

• There is a current ReActor issue with your same family of error (cublasLt64_12.dll missing) in a Portable-style setup: ReActor issue #201

• There is also a current ReActor issue for latest ComfyUI + Python 3.13 where GPU use is broken and package conflicts show up: ReActor issue #214

• Current onnxruntime-gpu supports Python >= 3.11, including modern Python, so Python 3.13 is not automatically unsupported by ONNX Runtime itself: onnxruntime-gpu on PyPI

---

What I think happened

The most likely story is:

1. your workflow genuinely worked
2. an update changed the ONNX Runtime / CUDA dependency situation
3. the GPU provider stopped loading
4. ReActor stopped processing the frame sequence properly
5. you now only get a tiny fragment of output

That matches your symptoms better than “the graph suddenly forgot how to work.”

The fact that it now outputs only the last few frames is very likely a secondary symptom of the runtime break, not the root cause.

---

Is Python 3.13 the cause?

Short answer

Possibly a contributing factor, but probably not the main cause of this exact error.

Why

Your exact error is about a missing CUDA 12 DLL.

That points more strongly to:

• missing CUDA 12.x runtime visibility
• mismatched cuDNN
• missing MSVC runtime
• or ONNX Runtime no longer finding the right DLLs after an update

Python 3.13 can still matter because the broader ReActor ecosystem is clearly more fragile there right now, but the immediate smoking gun is still the missing CUDA DLL.

So I would rank causes like this:

1. Most likely : CUDA / ONNX Runtime dependency mismatch
2. Also likely : update changed how ORT finds DLLs
3. Possible contributor : Python 3.13 makes the stack more brittle
4. Less likely : Python 3.13 alone is the whole root cause

---

The most realistic fixes and workarounds now

Option A — quickest diagnostic: test CPU fallback once

This is the fastest way to answer:

“Is my graph still okay?”

Temporarily switch the ONNX side to CPU and run the exact same workflow.

If it works again — slower, but logically correctly — then your graph is probably fine and the GPU runtime path is definitely the part that broke.

I would use this as:

• a diagnostic
• and a temporary emergency workaround

not as the final solution.

---

Option B — most likely real fix: restore the CUDA 12 / cuDNN 9 / MSVC chain

This is the highest-probability proper fix.

ONNX Runtime’s current CUDA guidance says the GPU provider depends on:

• matching CUDA major version
• matching cuDNN major version
• and accessible runtime DLLs

A current ONNX Runtime issue also shows a dependency trace including:

• cublasLt64_12.dll
• cublas64_12.dll
• cudnn64_9.dll
• MSVCP140.dll
• VCRUNTIME140.dll
• VCRUNTIME140_1.dll

See:

• ONNX Runtime issue #21825

So the practical fix path is:

1. update GPU driver
2. repair/install latest MSVC redistributable
3. make sure CUDA 12.x runtime DLLs are present and visible
4. make sure cuDNN 9.x is present and visible
5. reinstall onnxruntime-gpu inside Portable Python

---

Option C — very good Windows workaround: use ORT DLL preloading

This is one of the strongest current workarounds because it is official ONNX Runtime behavior , not a random hack.

ORT says you can:

• import torch before creating the ONNX Runtime session, or
• call onnxruntime.preload_dlls()

to preload:

• CUDA DLLs
• cuDNN DLLs
• MSVC runtime DLLs

And on Windows it searches:

1. the PyTorchlib directory
2. NVIDIA CUDA/cuDNN Python runtime packages
3. then the default DLL search path

See:

• ONNX Runtime CUDA provider docs

Why this matters for you:

• ComfyUI Portable already includes PyTorch
• so the right DLLs may already exist
• but ORT may not be finding them correctly after the update

This is one of the most attractive “minimal change” fixes.

---

Option D — clean reinstall of ONNX Runtime in the Portable Python only

This is very feasible and very relevant.

Portable uses its own embedded Python:

• python_embeded\python.exe

Official ComfyUI Portable docs:

• ComfyUI Portable

So all package work should use that Python, not your system Python.

Check what is installed

Run:

python_embeded\python.exe -V
python_embeded\python.exe -m pip show onnxruntime onnxruntime-gpu

If the ONNX stack looks messy

A clean reinstall is reasonable:

python_embeded\python.exe -m pip uninstall -y onnxruntime onnxruntime-gpu
python_embeded\python.exe -m pip install --only-binary=:all: onnxruntime-gpu

That is a very realistic thing to try before wiping everything else.

---

Option E — fallback compatibility route: use a known-good older combo

This is not my first choice, but it is a real-world fallback.

There are community reports of:

• older Portable/Python combinations
• older ONNX Runtime versions
• and older CUDA/cuDNN combos

working when newer combinations did not.

Also, the official ComfyUI Portable docs themselves expose a meaningful split:

• standard Nvidia portable = Python 3.13 + CUDA 13.0
• alternative Nvidia portable = Python 3.12 + CUDA 12.6

See:

• ComfyUI Portable

That is relevant because your current error is specifically asking for a CUDA 12-era DLL.

So if the modern stack keeps fighting you, a very reasonable fallback is:

• a second Portable install
• using the Python 3.12 + CUDA 12.6 variant
• with a fresh ReActor/ORT setup

I would not start there, but I would absolutely keep it in reserve.

---

One especially relevant exact case online

The single most concrete “same symptom → fix” example I found is this:

• a current issue where the user had the same missingcublasLt64_12.dll pattern
• and the fix was to install CUDA 12.8

See:

• Wan2GP issue #1513

That does not prove CUDA 12.8 is the exact answer for your machine.

But it strongly supports this interpretation:

when the runtime is asking for cublasLt64_12.dll, it wants a CUDA 12.x dependency chain, and a different CUDA major version may not satisfy it.

---

My actual recommendation order

If this were my machine, I would do this:

1. Confirm the actual Portable environment

Run:

python_embeded\python.exe -V
python_embeded\python.exe -m pip show onnxruntime onnxruntime-gpu

This tells you:

• exact Python version
• exact ONNX package/version
• whether you are really using the embedded environment

---

2. Do one CPU-only diagnostic run

Not because CPU is your final answer.

Do it because it answers the most important question:

“Is the graph still okay?”

If CPU works, your graph is basically vindicated.

---

3. Repair the GPU runtime chain

In this order:

• update NVIDIA driver
• repair/install latest MSVC redistributable
• ensure CUDA 12.x runtime is available
• ensure cuDNN 9.x is available if your ORT build expects it
• reinstall onnxruntime-gpu inside Portable Python

---

4. Try ORT DLL preloading

This is one of the smartest next steps because it is:

• official
• current
• Windows-specific
• PyTorch-friendly

See:

• ONNX Runtime CUDA provider docs

---

5. Only then consider stepping back from Python 3.13

I would only do this if:

• the CUDA/ORT fixes still leave the stack unstable
• or ReActor remains fragile after the runtime issue is fixed

At that point, a clean Python 3.12 + CUDA 12.6 Portable side install becomes a very reasonable compatibility-first fallback.

---

What I would not do now

I would not keep changing:

• ReActor settings
• RIFE settings
• frame counts inside the graph
• video combine settings
• face-swap thresholds

Those are downstream knobs.

Right now, your main blocker is a runtime failure , not a workflow-tuning problem.

---

My bottom-line view

This still looks fixable.

The encouraging part is:

• your workflow really did work
• your core idea was sound
• the current failure looks environmental, not conceptual

So I would think of this as:

restore a working ONNX Runtime GPU path first, then your face-swap workflow has a good chance of working again

rather than:

“I need to redesign the whole graph from zero.”

That is a much better kind of problem to have.

---

The exact links I would keep open

• ComfyUI Portable (official docs)
• ONNX Runtime CUDA provider docs
• ReActor issue #201
• ReActor issue #214
• ONNX Runtime issue #21825
• Wan2GP issue #1513
• onnxruntime-gpu on PyPI