[stderr]
/home/xiaohong/LTX-2/.venv/lib/python3.12/site-packages/setuptools/dist.py:332:
InformationOnly: Normalizing '3.0.0.b1' to '3.0.0b1'
self.metadata.version = self._normalize_version(self.metadata.version)
/home/xiaohong/LTX-2/.venv/lib/python3.12/site-packages/setuptools/dist.py:759:
SetuptoolsDeprecationWarning: License classifiers are deprecated.
!!
********************************************************************************
Please consider removing the following classifiers in favor of
a SPDX license expression:
License :: OSI Approved :: Apache Software License
See
https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license
for details.
********************************************************************************
!!
self._finalize_license_expression()
W0114 07:08:01.022000 1591534 torch/utils/cpp_extension.py:531] There
are no /usr/bin/g++-11 version bounds defined for CUDA version 13.0
error: could not create 'flash_attn_3/_C.abi3.so': No such file or
directory
hint: This usually indicates a problem with the package or the build
environment.
DEBUG Released lock at /home/xiaohong/LTX-2/.venv/.lock
DEBUG Released lock at /home/xiaohong/.cache/uv/.lock
I also was able to reproduce your error. Before running your commands, I created the directory first.
For me, I was working out of a NGC PyTorch container where my working directory was /workspace/flash-attention/hopper (via the flash-attention repo). I did mkdir -p flash_attn_3and it worked for me!
Please try that fix and let me know if you have any other questions or concerns!
Adding a data point in case it saves someone else the 50-minute build cycle.
Following the workaround described upstream (the mkdir -p flash_attn_3 fix combined with setting TORCH_CUDA_ARCH_LIST) the FA3 build completes successfully inside nvcr.io/nvidia/pytorch:26.03-py3 on a DGX Spark (GB10, compute capability 12.1, aarch64, CUDA 13.2 forward-compat driver). For the record I used TORCH_CUDA_ARCH_LIST="12.0" per the sm_120 binary-compatibility approach documented in a recent Medium writeup on FA2 builds for this hardware. pip install -e . --verbose --no-build-isolation finishes clean after about 50 minutes, the editable wheel registers, and import flash_attn_interface succeeds.
At runtime, however, a minimal flash_attn_func(q, k, v, causal=True) on bf16 tensors fails with:
CUDA error (flash-attention-src/hopper/flash_fwd_launch_template.h:193):
no kernel image is available for execution on the device
Looking at the build log, every kernel instantiation object file names its target as sm80 or sm90 (for example flash_fwd_hdim128_bf16_sm90.o, flash_bwd_hdim128_bf16_sm80.o). I do not see any sm_120 or sm_121 compilations, which is consistent with FA3’s upstream Hopper kernel set not currently including Blackwell instantiations, and appears to be the tracking issue in Dao-AILab/flash-attention#1969. It also lines up with the choice made in AI2’s open-instruct DGX Spark branch to mark flash-attn as unavailable on aarch64 and fall back to SDPA.
A few questions I would genuinely appreciate correction on:
Is my read of the build log correct, i.e., the current FA3 code path produces only SM80 and SM90 kernels regardless of TORCH_CUDA_ARCH_LIST, so the “successful build” on GB10 is effectively producing Hopper and Ampere binaries with no Blackwell match? Or is there a build flag or source path I missed?
Has anyone produced SM120 or SM121 compatible FA3 kernels using TORCH_CUDA_ARCH_LIST="12.1" or the accelerated "12.1a" variant? Medium reports that FA2.8.3 builds usefully at "12.0", but that is a different codebase.
For DGX Spark users, is the recommended path for now essentially “use FA2 or SDPA,” since flash_attn 2.7.4 is pre-installed in the NGC container and in my tests produces outputs bit-exact with torch.nn.functional.scaled_dot_product_attention? If so, that would be worth adding to this thread for the next person who reaches a successful FA3 build and is then surprised by a runtime kernel-image failure.
Happy to share the exact reproduction (container tag, build script, verification harness) if useful. I may still be missing something obvious here, and am genuinely interested in being corrected.
Thank you for the investigation. It looks like we’ll have to wait for V4 to get this functionality and in the mean time, we can rely on Sage Attention.