Reference only

Optional backend warnings: decide what blocks your workflow

Use process state and workflow requirements, not log color alone, to judge whether a warning blocks the task.

Decide by impact, not log color

A warning can name an optional feature, a required backend, or a custom node that failed to register. The text alone does not establish which applies to your workflow. Kornia documents separately installed extras for particular features, while Nunchaku documents Python, PyTorch and wheel compatibility requirements for its own backend. ComfyUI also documents failed custom-node imports and frontend-extension conflicts. Kornia Nunchaku ComfyUI

Three questions before changing the environment

1. Did the process exit? Record the first relevant exception and whether the same ComfyUI instance still serves its UI or /system_stats. A responsive server does not prove every node or workflow works; it only narrows the failure scope. Server routes

2. Does the current workflow use the affected feature? Identify the actual node or import chain. Check whether its class appears in that instance's /object_info, which lists registered node types. A package folder on disk is not proof that its import succeeded. Server routes Custom-node troubleshooting

3. Is the feature required on this path? Compare the warning with the package's documented requirements. If the workflow requires it, fix the first applicable error in the ComfyUI interpreter and version combination. If the workflow does not use it, record that limited finding; do not label the warning universally safe to ignore.

Test the smallest relevant path

Keep the original environment details and workflow. Run a minimal task that actually exercises the affected node or feature, then check the execution result and output. Do not install a similarly named package merely because a log mentions Triton, SageAttention or another accelerator; identify the calling project and its compatible instructions first.

If the project's documented fallback runs after disabling an acceleration path, record the fallback device, output and any observed timing separately. This proves only that fallback path worked for that task; it does not show that the missing acceleration was repaired or that performance and output are unchanged.

Recheck when conditions change

Record the ComfyUI and node versions, Python interpreter, exact warning, affected workflow, test result and any deferred limitation. Reassess after changing a node, model, backend or workflow. This is an editorial triage sequence based on the linked documentation, not a diagnosis of a reader's machine.

Sources and limits

No local installation, GPU workflow, fallback benchmark or output comparison was performed by this site.

Was this page helpful?

Anonymous. Only a yes/no counter is stored; no account, IP address or device details.

Sources & references

Official Kornia, Nunchaku and ComfyUI references rechecked 2026-09-25. Triage sequence is editorial guidance; no installation, GPU workflow, fallback benchmark or output comparison was performed.

01Kornia installation and optional extrasSource checked: 2026-09-2502Nunchaku installation requirementsSource checked: 2026-09-2503ComfyUI server routesSource checked: 2026-09-2504ComfyUI custom-node troubleshootingSource checked: 2026-09-25

Report an issue · 981fa433-a196-55f2-955f-e92c9eb04d11