{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiccoehymfn54mena6ducolaimpuycekdhv4ysp5ypww45ktnni3tm",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mldkh4vhvfu2"
  },
  "path": "/t/1st-movie-clip/175306#post_16",
  "publishedAt": "2026-05-08T10:17:46.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "ComfyUI Portable (official docs)",
    "ONNX Runtime CUDA provider docs",
    "ReActor issue #201",
    "ReActor issue #214",
    "onnxruntime-gpu on PyPI",
    "ONNX Runtime issue #21825",
    "ComfyUI Portable",
    "Wan2GP issue #1513"
  ],
  "textContent": "Your **workflow probably isn’t broken**. It’s likely just the software in your execution environment that’s broken.\n\nSetting 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** …\n\nThe 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.\n\nSo, 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…)\n\n* * *\n\n# This does **not** look like a workflow mistake anymore\n\nYour workflow may still be basically fine.\n\nThe strongest clue is the log error:\n\n\n    Error loading \"...\\onnxruntime_providers_cuda.dll\" which depends on \"cublasLt64_12.dll\" which is missing.\n\n\nThat means the **GPU runtime layer** for ReActor/ONNX Runtime is failing to load. In plain English:\n\n  * your face-swap graph can still be logically correct\n  * but the GPU engine underneath it is now broken\n  * so the node no longer processes frames the way it did before\n\n\n\nThat is why rebuilding the workflow from scratch did **not** fix it.\n\n* * *\n\n## The key diagnosis\n\nThis looks much more like:\n\n  * **ONNX Runtime GPU / CUDA dependency break**\n  * possibly made more fragile by **Portable + Python 3.13**\n  * **not** primarily a “wrong ReActor settings” issue\n\n\n\nThe most important current sources point the same way:\n\n  * **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:\nComfyUI Portable (official docs)\n\n  * **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** :\nONNX Runtime CUDA provider docs\n\n  * 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 **PyTorch`lib` directory first**:\nONNX Runtime CUDA provider docs\n\n  * There is a current **ReActor** issue with your same family of error (`cublasLt64_12.dll` missing) in a Portable-style setup:\nReActor issue #201\n\n  * There is also a current **ReActor** issue for **latest ComfyUI + Python 3.13** where GPU use is broken and package conflicts show up:\nReActor issue #214\n\n  * Current `onnxruntime-gpu` supports **Python >= 3.11**, including modern Python, so Python 3.13 is **not automatically unsupported** by ONNX Runtime itself:\nonnxruntime-gpu on PyPI\n\n\n\n\n* * *\n\n## What I think happened\n\nThe most likely story is:\n\n  1. your workflow genuinely worked\n  2. an update changed the **ONNX Runtime / CUDA dependency situation**\n  3. the GPU provider stopped loading\n  4. ReActor stopped processing the frame sequence properly\n  5. you now only get a tiny fragment of output\n\n\n\nThat matches your symptoms better than “the graph suddenly forgot how to work.”\n\nThe fact that it now outputs only the last few frames is very likely a **secondary symptom** of the runtime break, not the root cause.\n\n* * *\n\n## Is Python 3.13 the cause?\n\n### Short answer\n\n**Possibly a contributing factor, but probably not the main cause of this exact error.**\n\n### Why\n\nYour exact error is about a **missing CUDA 12 DLL**.\n\nThat points more strongly to:\n\n  * missing **CUDA 12.x** runtime visibility\n  * mismatched **cuDNN**\n  * missing **MSVC runtime**\n  * or ONNX Runtime no longer finding the right DLLs after an update\n\n\n\nPython 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.\n\nSo I would rank causes like this:\n\n  1. **Most likely** : CUDA / ONNX Runtime dependency mismatch\n  2. **Also likely** : update changed how ORT finds DLLs\n  3. **Possible contributor** : Python 3.13 makes the stack more brittle\n  4. **Less likely** : Python 3.13 alone is the whole root cause\n\n\n\n* * *\n\n## The most realistic fixes and workarounds now\n\n## Option A — quickest diagnostic: test CPU fallback once\n\nThis is the fastest way to answer:\n\n> “Is my graph still okay?”\n\nTemporarily switch the ONNX side to CPU and run the exact same workflow.\n\nIf it works again — slower, but logically correctly — then your graph is probably fine and the GPU runtime path is definitely the part that broke.\n\nI would use this as:\n\n  * a **diagnostic**\n  * and a **temporary emergency workaround**\n\n\n\nnot as the final solution.\n\n* * *\n\n## Option B — most likely real fix: restore the CUDA 12 / cuDNN 9 / MSVC chain\n\nThis is the highest-probability proper fix.\n\nONNX Runtime’s current CUDA guidance says the GPU provider depends on:\n\n  * matching **CUDA major version**\n  * matching **cuDNN major version**\n  * and accessible runtime DLLs\n\n\n\nA current ONNX Runtime issue also shows a dependency trace including:\n\n  * `cublasLt64_12.dll`\n  * `cublas64_12.dll`\n  * `cudnn64_9.dll`\n  * `MSVCP140.dll`\n  * `VCRUNTIME140.dll`\n  * `VCRUNTIME140_1.dll`\n\n\n\nSee:\n\n  * ONNX Runtime issue #21825\n\n\n\nSo the practical fix path is:\n\n  1. update GPU driver\n  2. repair/install latest MSVC redistributable\n  3. make sure **CUDA 12.x runtime DLLs** are present and visible\n  4. make sure **cuDNN 9.x** is present and visible\n  5. reinstall `onnxruntime-gpu` inside Portable Python\n\n\n\n* * *\n\n## Option C — very good Windows workaround: use ORT DLL preloading\n\nThis is one of the strongest current workarounds because it is **official ONNX Runtime behavior** , not a random hack.\n\nORT says you can:\n\n  * import `torch` before creating the ONNX Runtime session, or\n  * call `onnxruntime.preload_dlls()`\n\n\n\nto preload:\n\n  * CUDA DLLs\n  * cuDNN DLLs\n  * MSVC runtime DLLs\n\n\n\nAnd on Windows it searches:\n\n  1. the **PyTorch`lib` directory**\n  2. NVIDIA CUDA/cuDNN Python runtime packages\n  3. then the default DLL search path\n\n\n\nSee:\n\n  * ONNX Runtime CUDA provider docs\n\n\n\nWhy this matters for you:\n\n  * ComfyUI Portable already includes **PyTorch**\n  * so the right DLLs may already exist\n  * but ORT may not be finding them correctly after the update\n\n\n\nThis is one of the most attractive “minimal change” fixes.\n\n* * *\n\n## Option D — clean reinstall of ONNX Runtime in the **Portable Python only**\n\nThis is very feasible and very relevant.\n\nPortable uses its own embedded Python:\n\n  * `python_embeded\\python.exe`\n\n\n\nOfficial ComfyUI Portable docs:\n\n  * ComfyUI Portable\n\n\n\nSo all package work should use that Python, not your system Python.\n\n### Check what is installed\n\nRun:\n\n\n    python_embeded\\python.exe -V\n    python_embeded\\python.exe -m pip show onnxruntime onnxruntime-gpu\n\n\n### If the ONNX stack looks messy\n\nA clean reinstall is reasonable:\n\n\n    python_embeded\\python.exe -m pip uninstall -y onnxruntime onnxruntime-gpu\n    python_embeded\\python.exe -m pip install --only-binary=:all: onnxruntime-gpu\n\n\nThat is a very realistic thing to try **before** wiping everything else.\n\n* * *\n\n## Option E — fallback compatibility route: use a known-good older combo\n\nThis is not my first choice, but it is a real-world fallback.\n\nThere are community reports of:\n\n  * older Portable/Python combinations\n  * older ONNX Runtime versions\n  * and older CUDA/cuDNN combos\n\n\n\nworking when newer combinations did not.\n\nAlso, the official ComfyUI Portable docs themselves expose a meaningful split:\n\n  * standard Nvidia portable = **Python 3.13 + CUDA 13.0**\n  * alternative Nvidia portable = **Python 3.12 + CUDA 12.6**\n\n\n\nSee:\n\n  * ComfyUI Portable\n\n\n\nThat is relevant because your current error is specifically asking for a **CUDA 12-era DLL**.\n\nSo if the modern stack keeps fighting you, a very reasonable fallback is:\n\n  * a second Portable install\n  * using the **Python 3.12 + CUDA 12.6** variant\n  * with a fresh ReActor/ORT setup\n\n\n\nI would not start there, but I would absolutely keep it in reserve.\n\n* * *\n\n## One especially relevant exact case online\n\nThe single most concrete “same symptom → fix” example I found is this:\n\n  * a current issue where the user had the same **missing`cublasLt64_12.dll`** pattern\n  * and the fix was to install **CUDA 12.8**\n\n\n\nSee:\n\n  * Wan2GP issue #1513\n\n\n\nThat does **not** prove CUDA 12.8 is the exact answer for your machine.\n\nBut it strongly supports this interpretation:\n\n> 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.\n\n* * *\n\n## My actual recommendation order\n\nIf this were my machine, I would do this:\n\n### 1. Confirm the actual Portable environment\n\nRun:\n\n\n    python_embeded\\python.exe -V\n    python_embeded\\python.exe -m pip show onnxruntime onnxruntime-gpu\n\n\nThis tells you:\n\n  * exact Python version\n  * exact ONNX package/version\n  * whether you are really using the embedded environment\n\n\n\n* * *\n\n### 2. Do one CPU-only diagnostic run\n\nNot because CPU is your final answer.\n\nDo it because it answers the most important question:\n\n> “Is the graph still okay?”\n\nIf CPU works, your graph is basically vindicated.\n\n* * *\n\n### 3. Repair the GPU runtime chain\n\nIn this order:\n\n  * update NVIDIA driver\n  * repair/install latest MSVC redistributable\n  * ensure **CUDA 12.x runtime** is available\n  * ensure **cuDNN 9.x** is available if your ORT build expects it\n  * reinstall `onnxruntime-gpu` inside Portable Python\n\n\n\n* * *\n\n### 4. Try ORT DLL preloading\n\nThis is one of the smartest next steps because it is:\n\n  * official\n  * current\n  * Windows-specific\n  * PyTorch-friendly\n\n\n\nSee:\n\n  * ONNX Runtime CUDA provider docs\n\n\n\n* * *\n\n### 5. Only then consider stepping back from Python 3.13\n\nI would only do this if:\n\n  * the CUDA/ORT fixes still leave the stack unstable\n  * or ReActor remains fragile after the runtime issue is fixed\n\n\n\nAt that point, a clean **Python 3.12 + CUDA 12.6 Portable** side install becomes a very reasonable compatibility-first fallback.\n\n* * *\n\n## What I would **not** do now\n\nI would **not** keep changing:\n\n  * ReActor settings\n  * RIFE settings\n  * frame counts inside the graph\n  * video combine settings\n  * face-swap thresholds\n\n\n\nThose are downstream knobs.\n\nRight now, your main blocker is a **runtime failure** , not a workflow-tuning problem.\n\n* * *\n\n## My bottom-line view\n\nThis still looks **fixable**.\n\nThe encouraging part is:\n\n  * your workflow really did work\n  * your core idea was sound\n  * the current failure looks environmental, not conceptual\n\n\n\nSo I would think of this as:\n\n> **restore a working ONNX Runtime GPU path first, then your face-swap workflow has a good chance of working again**\n\nrather than:\n\n> “I need to redesign the whole graph from zero.”\n\nThat is a much better kind of problem to have.\n\n* * *\n\n## The exact links I would keep open\n\n  * ComfyUI Portable (official docs)\n  * ONNX Runtime CUDA provider docs\n  * ReActor issue #201\n  * ReActor issue #214\n  * ONNX Runtime issue #21825\n  * Wan2GP issue #1513\n  * onnxruntime-gpu on PyPI\n\n",
  "title": "1st movie clip!"
}