ComfyUI SageAttention Crashes and Flash Attention Errors

Removing the flag from your launch line is the whole fix — there is no runtime toggle, because ComfyUI selects the attention backend once at import time from a mutually exclusive argparse group. Before you do that, read the console: a Python-level failure inside SageAttention or FlashAttention is caught and silently downgraded to PyTorch attention with a one-line log message, which means a "working" run may not have been using your speed flag at all. A hard Fatal Python error: Aborted with no traceback is the opposite case — that is a native crash the fallback cannot catch, and every reported instance so far is a specific combination of backend, checkpoint precision and dynamic VRAM at long sequence length, not "SageAttention is broken".

Attention backends are the single most-recommended ComfyUI speed tweak on the internet, which means an enormous number of people install one, and a visible fraction end up here. This page is only about the install-and-crash path: what each flag needs, what it prints when it does not have it, what the known crash signatures look like, and how to get back to a working install. It is not an explainer on how flash attention works — that is our flash attention guide, which comes at it from the LLM side.

Flag names, help text and error strings below were read from comfy/cli_args.py and comfy/ldm/modules/attention.py on master (current release v0.33.1, published 13 August 2026). Crash reports are credited to the issue they come from.

Which attention flags does ComfyUI actually accept?

Six, and you can only pass one. They sit in a single add_mutually_exclusive_group() in cli_args.py, so argparse will reject two of them together before ComfyUI starts:

Two of those are frequently misread. --use-pytorch-cross-attention is not a third-party backend — it forces torch's own scaled dot-product attention, which is what most people should be on. And --use-ck-attention is the newest of the six: it was added along with the Comfy Kitchen INT8 attention kernels, so a slightly older install will not have it at all.

The selection order lives at the bottom of attention.py and is worth knowing, because it explains why a flag can appear to do nothing:

if model_management.sage_attention_enabled():
    logging.info("Using sage attention")
elif model_management.flash_attention_enabled():
    logging.info("Using Flash Attention")
elif model_management.xformers_enabled():
    logging.info("Using xformers attention")
elif model_management.pytorch_attention_enabled():
    logging.info("Using pytorch attention")

…and then, separately and last, --use-ck-attention overrides whatever that chain picked. Your startup log tells you which one won. If you passed a flag and the log says Using pytorch attention, something overrode you — start there, not with a crash you have not had yet.

What does each backend print when it is missing?

All three third-party backends fail loudly at startup rather than at generation time, which is genuinely helpful and means a lot of "SageAttention doesn't work" reports are really "SageAttention is not installed". These strings are verbatim from attention.py:

SageAttention, missing package:

To use the `--use-sage-attention` feature, the `sageattention` package must be installed first.
command:
	<your python> -m pip install sageattention

FlashAttention, missing package:

To use the `--use-flash-attention` feature, the `flash-attn` package must be installed first.
command:
	<your python> -m pip install flash-attn

Comfy Kitchen attention, build without the kernels:

Comfy Kitchen attention is unavailable. Install a Comfy Kitchen build with attention support to use --use-ck-attention.

All three are followed by exit(-1) in the source — ComfyUI does not start. If the process is up and generating, the backend imported successfully, whatever else is going wrong.

A fourth case looks different again: if argparse rejects --use-ck-attention as an unrecognised argument, you are simply on a build that predates it. That is what happened in #15603, and the resolution is a good trap to know about — the reporter had installed the nightly channel through comfy-cli and found it shipped comfy-kitchen 0.2.26, while the repo's own requirements.txt pinned 0.2.31. In their words: "apparently --version latest is newer than --version nightly". If you are chasing a flag that the docs say exists, check your comfy-kitchen version before you conclude anything.

What do the known crashes look like?

This is the table to match against. Each row is a real, dated report or a real string from the source — not a category.

The pattern across the top three rows is the important part. None of them is "SageAttention crashes". Every one is a conjunction: this backend, with this quantised checkpoint, with dynamic VRAM, above this sequence length. #15566 is the cleanest demonstration — the reporter ran eleven variations of the same graph and seed, and removing any single factor produced a clean run, including simply making the video smaller.

Why does it abort with no traceback?

Because a native abort is not a Python exception, and ComfyUI's fallback only catches exceptions.

Look at what the source actually does. Inside attention_sage:

try:
    out = sageattn(q, k, v, **sage_kwargs)
except Exception as e:
    logging.error("Error running sage attention: {}, using pytorch attention instead.".format(e))
    exception_fallback = True

That is a real safety net — a shape mismatch, an unsupported dtype, a kernel that raises, all land there and the graph continues on PyTorch attention. attention_flash has the same structure with Flash Attention failed, using default SDPA:, and SageAttention 3 has Error running SageAttention3: %s, falling back to pytorch attention.

What it cannot catch is the process dying underneath the interpreter. When a CUDA or HIP kernel faults, the abort happens at the driver level; Python's faulthandler prints the stack of the thread that happened to be running, then the process is gone. That is why #15566's stack points at F.silu — the reporter is explicit that "this is where the Python thread was when the process aborted, not necessarily where the fault originated". Do not go debugging SiLU.

Two consequences worth acting on:

1. A stack in a faulthandler dump is a location, not a cause. Treat it the way you would treat an asynchronous CUDA error.
2. CUDA_LAUNCH_BLOCKING=1 is the diagnostic, not the fix. In #15566 it made the crash go away entirely, which is itself the finding: a failure that disappears under serialised kernel launches is a synchronisation or tensor-lifetime problem, not a bad kernel. It also costs you the asynchrony you installed the backend for.

How do you turn an attention backend off cleanly?

Remove the flag. Then check the graph, because a node can turn it back on.

There is no in-app switch for the launch flag: optimized_attention is bound once, at module import, from the chain shown earlier. Editing your launch line and restarting is the entire procedure. Where people get stuck is that this is not the only way a backend gets selected.

• ModelAttentionBackend is a core node that sets the backend for one model in one graph. #15529 reproduces the Comfy Kitchen alignment RuntimeError by adding exactly that node between UNETLoader and the sampler chain, with no flag involved.
• Custom-node patchers. KJNodes ships sage attention nodes that patch the model directly; both #15482 and #15263 involve them. If your launch line is clean and the console still shows a sage stack frame, search your workflow JSON for the node.
• Your desktop-app settings. If you use the ComfyUI desktop build, launch arguments live in a settings file rather than a shell command, so "I removed the flag" and "the flag is no longer being passed" are not automatically the same statement.

If you are unsure whether you have cleanly reverted, the startup log is authoritative. Using pytorch attention with no Using sage attention above it, and no attention-backend node in the graph, means you are on SDPA — which is the launch configuration our complete ComfyUI guide assumes throughout.

For a clean reversion of the package as well as the flag, uninstall it — a stale sageattention or flash-attn wheel compiled against a different torch build is its own well-populated failure mode, and it surfaces as an import error rather than a crash. Our guide to ComfyUI custom node install failures covers the neighbouring case where a node pack pulls in its own kernels.

Is it worth keeping the backend at all?

That depends on evidence you can gather in about two minutes, and we are deliberately not going to hand you a speedup number.

Step one: confirm it is actually running. Grep your console for Error running sage attention and Flash Attention failed, using default SDPA. Both are logged per failing call, so a graph that hits them repeatedly will fill the log. If either is there, you have been paying the install cost and running SDPA anyway.

Step two: time the same seed and graph with and without the flag, on your machine. This is the only number that means anything, because the answer varies by GPU architecture, checkpoint precision, resolution and sequence length — the four axes every crash report on this page turns on. Published benchmarks from someone else's configuration will not predict yours.

Step three: weigh the memory side, which is the part tutorials skip. There is one figure worth quoting here, and it is a bug magnitude rather than a benchmark. In #15585, the reporter documents that BaseModel.memory_required() chooses between an efficient and a conservative estimate formula by checking xformers_enabled() and pytorch_attention_flash_attention() — and never flash_attention_enabled(). Their description of the gap, in the issue title, is a "7.5x overestimate" at bf16, and the follow-up PR #15586 adds unit tests "pinning the 7.5x bf16 ratio between the two formulas". That is an internal ratio between two estimator branches, not a measurement of anything's speed or real memory use — the practical consequence is that a model which fits gets loaded partially and streams weights over PCIe every step. Both were open when this was written.

On AMD specifically, the backend question is entangled with whether your torch wheel ships AOTriton kernel images at all, which changes what ComfyUI enables without you asking. That whole thread is ComfyUI on AMD: ROCm noise, black image and crash fixes. AMD's own ROCm blog post on ComfyUI attention backends (20 July 2026) is the best vendor-side write-up of the tradeoffs, and it is where the FLASH_ATTENTION_TRITON_AMD_ENABLE and TORCH_ROCM_FA_PREFER_CK variables come from.

The honest default: if you are on NVIDIA with a supported architecture and your workflows are stable, --use-pytorch-cross-attention is the boring answer and costs you nothing to install. Reach for a third-party backend when you have a specific, measured problem it solves, not because a tutorial listed it under "optimisations".

What are the install prerequisites, per backend?

Attribution matters here, so this is what the projects themselves state — not what we tested.

SageAttention. The thu-ml/SageAttention README lists support for "Ampere, Ada and Hopper GPUs", with SageAttention3 covering Blackwell, and a base environment of "python>=3.9, torch>=2.3.0, triton>=3.0.0". CUDA requirements are stated per generation: ">=12.8 for Blackwell or SageAttention2++", ">=12.4 for fp8 support on Ada", ">=12.3 for fp8 support on Hopper", ">=12.0 for Ampere". Note that ComfyUI checks for two separate packages — sageattention for sageattn, and sageattn3 for sageattn3_blackwell — and registers them as distinct backends, so having one does not give you the other.

FlashAttention. ComfyUI imports flash_attn_func from Dao-AILab/flash-attention and wraps it as a torch custom op. On ROCm this is where the CK-versus-Triton split lives; #15585 documents torch 2.12.0+rocm7.14.0 shipping libaotriton_v2.so without the aotriton.images kernel directory while 2.13.0+rocm7.2 ships both, which is enough to change what ComfyUI enables.

Comfy Kitchen attention. Comes from the comfy-kitchen package rather than a separate install, and availability is gated on comfy_kitchen.int8_attention_is_available(). Per #15603, the version matters and the release channels are counterintuitive.

One prerequisite applies to all three and is the most common cause of a broken install after an update: a backend wheel is compiled against a specific torch build. Upgrade torch without rebuilding, and the extension fails to import. That failure looks nothing like the crashes on this page — it is an import-time error naming a mangled C++ symbol — and it is a different diagnosis.

What we could not verify

• We did not reproduce these crashes. Every signature above is either quoted from a linked GitHub issue or read out of ComfyUI's source. We are not going to invent a reproduction on hardware we do not have, and a page that pretended otherwise would be worth less than this one.
• No speedup figures appear here. The only quantity we quote — the 7.5x estimator ratio — is a maintainer-and-reporter description of a bug magnitude in #15585, attributed as such, and it is explicitly not a benchmark.
• These issues are live. #15566, #15802, #15263, #15529 and #15585 were open at the time of writing; #15482 and #15603 were closed; PR #15586 was unmerged. Attention backends are also under active development in-tree — the Comfy Kitchen path is weeks old. Check before you plan around anything here.
• Flag names drift. --use-ck-attention did not exist in slightly older builds. Run python main.py --help and trust your own install over any article, this one included.
• We have not enumerated custom-node patchers. KJNodes is the one that shows up repeatedly in these reports, but any node pack can patch attention. If your console shows a backend you did not ask for, the graph is the place to look.

FAQ

How do I disable SageAttention in ComfyUI?

Remove --use-sage-attention from your launch command and restart — the backend is chosen once at import time, so there is no runtime toggle. Then confirm it took: your startup log should read Using pytorch attention rather than Using sage attention. If it still says sage, something other than the flag is enabling it, most likely a ModelAttentionBackend node or a KJNodes patcher inside the workflow itself.

Why did ComfyUI exit immediately after I added an attention flag?

Because the package behind the flag is not importable. ComfyUI checks at startup and calls exit(-1) with a specific message: for SageAttention it prints "To use the --use-sage-attention feature, the sageattention package must be installed first." along with the exact pip command using your interpreter's path. FlashAttention prints the equivalent for flash-attn. If the message instead reads "Comfy Kitchen attention is unavailable", your comfy-kitchen build has no attention kernels.

What does Fatal Python error: Aborted with a stack at F.silu mean?

It means the process died at the native level, and the faulthandler printed wherever the Python thread happened to be — not where the fault occurred. #15566 documents this exact signature and says so explicitly. In that report it only happened with SageAttention, dynamic VRAM and a large sequence length all active at once; disabling dynamic VRAM, dropping the sage flag, or simply generating a smaller video each made it go away.

Does --use-flash-attention make ComfyUI use more VRAM?

Not directly, but per #15585 it can make ComfyUI think it needs far more. The memory estimator picks its formula without consulting flash_attention_enabled(), so with that flag it can fall to the conservative branch — described in the issue as a 7.5x overestimate at bf16 — and the loader then partially loads the model and streams weights over PCIe every step. The visible symptom is a loaded partially log line on a card that should have fit the model.

Is --use-ck-attention a valid ComfyUI flag?

On current master, yes: it is in cli_args.py with the help text "Use Comfy Kitchen attention." If your build rejects it as an unrecognised argument, you are on an older comfy-kitchen. #15603 is the cautionary tale — comfy-cli's nightly channel shipped comfy-kitchen 0.2.26 while the repo pinned 0.2.31, so --version latest was newer than --version nightly and only the former accepted the flag.

Can I use two attention backends at once?

No. All six live in one add_mutually_exclusive_group() in cli_args.py, so argparse rejects any two together at startup. There is one wrinkle: --use-ck-attention is applied after the main selection chain in attention.py, so when it is active it overrides whatever else would have been chosen. Per-model overrides through the ModelAttentionBackend node are a separate mechanism and do stack on top of the flag.

Sources

• ComfyUI — comfy/ldm/modules/attention.py (backend selection chain, fallback and error strings) and comfy/cli_args.py (the mutually exclusive flag group and its help text), master, release v0.33.1 published 13 Aug 2026
• thu-ml/SageAttention (supported architectures, torch/triton/CUDA requirements) and Dao-AILab/flash-attention
• AMD ROCm Blogs — "Understanding Attention Algorithms and Their Backends for Image and Video Generation" (20 July 2026)
• Comfy-Org/ComfyUI issues #15263, #15482, #15529, #15566, #15585, #15603, #15802, and PR #15586