{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigdd6ajsyblt35htjxt4gddxrqvpkzemwe4ueln456rqub3dpz24e",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mmrkvjm4afz2"
  },
  "path": "/t/nvidia-driver-update-reactor-node/176221#post_4",
  "publishedAt": "2026-05-26T17:11:27.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "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",
    "ONNX Runtime CUDA Execution Provider",
    "ONNX Runtime Install docs",
    "ONNX Runtime CUDA Execution Provider - preload DLLs",
    "ONNX Runtime Install"
  ],
  "textContent": "Yeah, ONNX Runtime breaks quite easily after environment changes… switching it to CPU temporarily may be a good move. Maybe something like this?\n\n* * *\n\nThat error is very informative. It means the clean reinstall probably helped, but **ONNX Runtime’s CUDA provider is still not loading correctly**.\n\nThis line is the key:\n\n\n    Error loading:\n    D:\\ComfyUI_windows_portable\\python_embeded\\Lib\\site-packages\\onnxruntime\\capi\\onnxruntime_providers_cuda.dll\n\n    which depends on:\n    cublasLt64_12.dll\n\n    which is missing.\n\n\nSo I would read the current state like this:\n\n\n    Clean ComfyUI install: probably OK\n    Basic PyTorch CUDA test: probably OK, if your earlier torch command passed\n    Basic ReActor still-image swap: works\n    ONNX Runtime CUDAExecutionProvider: broken or drifting\n    ONNX Runtime CPUExecutionProvider: probably being used as fallback\n\n\nSo this is **not the same problem as before**. You made progress.\n\nBefore, the whole environment was probably mixed. Now the problem looks narrower:\n\n> ReActor can run, but ONNX Runtime GPU acceleration cannot load the CUDA 12 DLLs it expects.\n\nThat 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.\n\nSimilar ReActor reports:\n\n  * ComfyUI-ReActor issue #201 - cublasLt64_12.dll missing\n  * ComfyUI-ReActor issue #188 - CUDA provider / CPU tensor / cublasLt64_12.dll\n  * ComfyUI-ReActor issue #195 - Python 3.13 + GPEN-BFR + cublasLt64_12.dll\n\n\n\nRelevant ONNX Runtime docs:\n\n  * ONNX Runtime CUDA Execution Provider\n  * ONNX Runtime Install docs\n\n\n\n## Important caveat: this may be real GPU/runtime drift\n\nI would **not** assume this is only a harmless warning.\n\nIt 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.\n\nIn other words, this could be real drift in the execution substrate:\n\n\n    GPU model / architecture\n    NVIDIA driver\n    PyTorch CUDA build\n    onnxruntime-gpu version\n    CUDA runtime DLLs\n    cuDNN runtime DLLs\n    Windows DLL search path\n    ComfyUI embedded Python environment\n\n\nThat matters because ONNX Runtime GPU support is sensitive to the exact combination of CUDA, cuDNN, Python, PyTorch, and GPU architecture.\n\nSo CPU mode is not “the final answer.” It is a **stabilization and isolation step** :\n\n\n    First: make ReActor work reliably on CPU.\n    Then: treat ONNX Runtime GPU as a separate optimization / migration problem.\n\n\nThis keeps you from breaking the clean install again while trying to fix GPU acceleration.\n\n## Why the face swap still worked\n\nBecause ONNX Runtime can often fall back to CPU.\n\nSo this can happen:\n\n\n    ONNX Runtime tries CUDAExecutionProvider\n    CUDA provider fails because a CUDA DLL is missing\n    ONNX Runtime continues with CPUExecutionProvider\n    ReActor still produces an image\n    console prints scary CUDA errors\n\n\nThat would explain:\n\n\n    simple ReActor image test works\n    but console shows cublasLt64_12.dll errors\n\n\nThe main downside may be speed.\n\nBut if later video or face-restore paths become unstable, then the broken CUDA provider may matter more.\n\n## First: capture the exact GPU/runtime state\n\nBefore changing packages again, I would record this:\n\n\n    cd D:\\ComfyUI_windows_portable\n\n    nvidia-smi\n\n    .\\python_embeded\\python.exe -c \"import sys; print('python=', sys.version)\"\n\n    .\\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')\"\n\n    .\\python_embeded\\python.exe -c \"import onnxruntime as ort; print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers())\"\n\n    .\\python_embeded\\python.exe -m pip list | findstr /i \"onnxruntime torch nvidia cuda cudnn\"\n\n\nThe 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.\n\nSo I would save this output somewhere before fixing anything.\n\n## Interpret the provider result\n\nRun:\n\n\n    cd D:\\ComfyUI_windows_portable\n\n    .\\python_embeded\\python.exe -c \"import onnxruntime as ort; print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers())\"\n\n\n### Case A\n\n\n    providers= ['CUDAExecutionProvider', 'CPUExecutionProvider']\n\n\nThis means ONNX Runtime package-level CUDA support is present, but loading the actual CUDA DLLs may still fail at runtime.\n\n### Case B\n\n\n    providers= ['CPUExecutionProvider']\n\n\nor:\n\n\n    providers= ['AzureExecutionProvider', 'CPUExecutionProvider']\n\n\nThis means ONNX Runtime is effectively CPU-only.\n\n### Case C\n\n\n    Error loading onnxruntime_providers_cuda.dll\n    missing cublasLt64_12.dll\n\n\nThis means `onnxruntime-gpu` is installed, but the CUDA 12 runtime DLL it expects is not findable.\n\n## Check for mixed ONNX Runtime packages\n\nThis is worth checking:\n\n\n    .\\python_embeded\\python.exe -m pip list | findstr /i \"onnxruntime\"\n\n\nA confusing state would be:\n\n\n    onnxruntime\n    onnxruntime-gpu\n\n\nIdeally, for a clean CPU-only temporary state, you want only:\n\n\n    onnxruntime\n\n\nFor a clean GPU state, you want only:\n\n\n    onnxruntime-gpu\n\n\nMixed CPU/GPU ONNX packages can make debugging harder.\n\n## Safest short-term workaround: make ONNX Runtime CPU-only\n\nBecause the simple ReActor swap already works, I would probably stabilize first.\n\nThe idea is:\n\n\n    Remove broken ONNX Runtime GPU provider\n    Use CPU ONNX Runtime\n    Verify ReActor still works\n    Verify the cublasLt64_12.dll warning disappears\n    Then decide whether GPU acceleration is worth fixing\n\n\nCommands:\n\n\n    cd D:\\ComfyUI_windows_portable\n\n    .\\python_embeded\\python.exe -m pip uninstall -y onnxruntime-gpu\n\n    .\\python_embeded\\python.exe -m pip install --upgrade --force-reinstall onnxruntime\n\n\nThen verify:\n\n\n    .\\python_embeded\\python.exe -c \"import onnxruntime as ort; print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers())\"\n\n\nA good temporary result is:\n\n\n    providers= ['CPUExecutionProvider']\n\n\nor sometimes:\n\n\n    providers= ['AzureExecutionProvider', 'CPUExecutionProvider']\n\n\nThen restart ComfyUI and test the same simple ReActor face swap again.\n\nIf the warning disappears and the image still works, then you have a stable baseline:\n\n\n    ComfyUI works\n    ReActor works\n    ONNX Runtime uses CPU\n    no missing cublasLt64_12.dll warning\n\n\nThat is a good recovery state.\n\nNot necessarily the final fastest state, but a good stable state.\n\n## Why CPU-only may be the right next move\n\nBecause you have already proven something important:\n\n\n    fresh install worked\n    basic commands worked\n    basic ReActor image swap worked\n\n\nSo the remaining issue is narrower:\n\n\n    ONNX Runtime GPU acceleration is not loading\n\n\nThat should be treated separately.\n\nIf you try to fix ONNX GPU immediately, you may end up changing:\n\n\n    onnxruntime-gpu\n    CUDA runtime packages\n    cuDNN packages\n    PyTorch\n    Windows PATH\n    NVIDIA driver\n    ReActor dependencies\n\n\nall at once again.\n\nThat is exactly how the original mixed environment probably happened.\n\nSo I would first get a clean CPU baseline, then handle GPU acceleration as a second phase.\n\n## If you later want to fix ONNX Runtime GPU\n\nOnly do this after CPU ReActor is stable.\n\nThe goal would be:\n\n\n    Make onnxruntime-gpu able to find the CUDA 12 / cuDNN DLLs it expects.\n\n\nThere are several possible paths.\n\n### Option A: Try ONNX Runtime GPU with CUDA/cuDNN extras\n\nONNX Runtime documents installation forms that can bring CUDA/cuDNN runtime dependencies into the Python environment.\n\nIn ComfyUI portable, use embedded Python:\n\n\n    cd D:\\ComfyUI_windows_portable\n\n    .\\python_embeded\\python.exe -m pip uninstall -y onnxruntime onnxruntime-gpu\n\n    .\\python_embeded\\python.exe -m pip install --upgrade \"onnxruntime-gpu[cuda,cudnn]\"\n\n\nThen test:\n\n\n    .\\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()\"\n\n\nRelevant docs:\n\n  * ONNX Runtime CUDA Execution Provider - preload DLLs\n  * ONNX Runtime Install\n\n\n\nBut I would treat this as a second-phase experiment, not the immediate recovery step.\n\n### Option B: Preload PyTorch / NVIDIA DLLs before ONNX Runtime\n\nONNX Runtime documents that preloading DLLs can help it use CUDA/cuDNN DLLs from PyTorch or NVIDIA Python packages.\n\nThe basic idea is:\n\n\n    import torch\n    import onnxruntime\n\n\nor:\n\n\n    import onnxruntime\n    onnxruntime.preload_dlls()\n\n\nBut 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.\n\nSo this is useful for diagnosis, but not always a clean user-level fix.\n\n### Option C: Install CUDA runtime globally\n\nYou could install CUDA 12 runtime/toolkit so Windows can find `cublasLt64_12.dll`.\n\nBut I would not start there.\n\nGlobal 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.\n\n## Do not confuse these two questions\n\nThere are now two separate questions:\n\n\n    Question 1:\n    Can ReActor work reliably at all?\n\n    Question 2:\n    Can ReActor use ONNX Runtime GPU acceleration?\n\n\nYou have probably answered Question 1: yes, at least for a simple still image.\n\nQuestion 2 is still unresolved.\n\nThat means the practical recovery route is:\n\n\n    First stabilize ReActor CPU.\n    Then decide whether ONNX GPU is worth fixing.\n\n\n## What I would do next\n\nMy exact next steps would be:\n\n\n    1. Save the current command outputs\n    2. Confirm the simple ReActor still-image test works\n    3. Check ONNX Runtime providers\n    4. Remove onnxruntime-gpu\n    5. Install CPU onnxruntime\n    6. Restart ComfyUI\n    7. Confirm the cublasLt64_12.dll warning is gone\n    8. Test simple ReActor still image again\n    9. Test your real still-image workflow\n    10. Test short video\n    11. Only later try ONNX Runtime GPU again\n\n\nCommands:\n\n\n    cd D:\\ComfyUI_windows_portable\n\n    .\\python_embeded\\python.exe -m pip list | findstr /i \"onnxruntime\"\n\n    .\\python_embeded\\python.exe -m pip uninstall -y onnxruntime-gpu\n\n    .\\python_embeded\\python.exe -m pip install --upgrade --force-reinstall onnxruntime\n\n    .\\python_embeded\\python.exe -c \"import onnxruntime as ort; print('onnxruntime=', ort.__version__); print('providers=', ort.get_available_providers())\"\n\n\nThen restart ComfyUI.\n\n## How to interpret the result\n\n### Good temporary result\n\n\n    providers= ['CPUExecutionProvider']\n    ReActor still works\n    no cublasLt64_12.dll warning\n\n\nMeaning:\n\n\n    You now have a stable CPU ReActor setup.\n    It may be slower, but it is clean.\n\n\n### Still noisy\n\n\n    cublasLt64_12.dll warning still appears\n\n\nThen `onnxruntime-gpu` is probably still installed somewhere in the ComfyUI embedded Python environment, or another package is still importing the GPU provider.\n\nCheck again:\n\n\n    .\\python_embeded\\python.exe -m pip list | findstr /i \"onnxruntime\"\n\n\n### ReActor stops working after CPU-only install\n\nThen reinstall official ReActor using its installer:\n\n\n    cd D:\\ComfyUI_windows_portable\\ComfyUI\\custom_nodes\\ComfyUI-ReActor\n\n    install.bat\n\n\nBut make sure it uses:\n\n\n    D:\\ComfyUI_windows_portable\\python_embeded\\python.exe\n\n\nnot system Python.\n\n## Short version\n\nYour new install probably worked.\n\nThe remaining error is probably:\n\n\n    ONNX Runtime GPU provider is broken or drifting\n    but ReActor can still run through CPU provider\n\n\nSo I would not reinstall everything again.\n\nI would first stabilize ONNX Runtime as CPU-only:\n\n\n    cd D:\\ComfyUI_windows_portable\n\n    .\\python_embeded\\python.exe -m pip uninstall -y onnxruntime-gpu\n\n    .\\python_embeded\\python.exe -m pip install --upgrade --force-reinstall onnxruntime\n\n\nThen test ReActor again.\n\nIf that works and the warning disappears, you have a usable recovery state.\n\nAfter that, GPU acceleration can be treated as a separate ONNX Runtime / CUDA / cuDNN / GPU-architecture migration problem, not as the main ReActor recovery problem.",
  "title": "Nvidia driver update - reactor node"
}