Open-source project
Dao-AILab/flash-attention avatar
Dao-AILab/flash-attention

FlashAttention: The Kernel That Reshaped Attention, Now Spanning Four Generations

Fast and memory-efficient exact attention. FlashAttention This repository provides the official implementation of FlashAttention and FlashAttention-2 from the following papers.

24,920 stars3,070 forksPythonBSD-3-Clause

At a glance

What is it?
Dao-AILab's FlashAttention repository is the reference implementation of IO-aware exact attention, covering CUDA and ROCm backends across four major versions. This review focuses on what each generation offers, how to install them, and where the project's complexity becomes a real cost.
Who is it for?
Adopt FlashAttention if you train or fine-tune transformer models on NVIDIA Ampere or newer GPUs, or on AMD MI200 and later, and you need exact attention with lower memory use. Skip it if you target Turing GPUs, need Windows as a first-class platform, or want a stable API across all hardware.
Can I use it commercially?
Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Why FlashAttention Exists and Who Needs It

The core problem is memory. Standard attention materializes an N x N matrix, which costs quadratic memory in sequence length. For a 64K-token context, that matrix alone can exceed GPU memory before any compute happens. FlashAttention avoids materializing the full matrix by tiling the computation and keeping only the final output and softmax statistics in registers and shared memory. This is exact attention, not an approximation. The intended users are researchers and engineers training or serving transformer models on GPUs, particularly those pushing sequence lengths beyond what a naive implementation can fit. The README points to a usage page listing many projects that adopted it, but the repository itself is the reference implementation, not a library with a stable high-level API.

The Core Mechanism: IO-Awareness and Online Softmax

FlashAttention works by being IO-aware, meaning it explicitly manages data movement between the GPU's slow HBM and its fast on-chip SRAM. The algorithm computes attention in blocks, loading Q, K, and V tiles into SRAM, computing partial attention scores, and updating an online softmax that rescales previous outputs as new blocks arrive. This avoids writing the full attention matrix to HBM. FlashAttention-2 improves on the first version by better parallelization and work partitioning across threads and warps, as described in the paper. The mechanism is exact: the output is mathematically identical to standard attention, just computed in a different order. For practitioners, this means you get the same results but with memory savings that scale linearly with sequence length instead of quadratically.

Three Installation Paths, Three Different Packages

The repository now contains three distinct packages. The classic FlashAttention-2 installs via `pip install flash-attn --no-build-isolation`. FlashAttention-3 lives in the `hopper` subdirectory and installs with `python setup.py install` from that folder, or via the `flash-attn-3` package from git. FlashAttention-4 is a separate PyPI package: `pip install flash-attn-4`, with an optional `cu13` extra for CUDA 13. Each package has a different import path. FlashAttention-2 uses `from flash_attn import flash_attn_func`. FlashAttention-3 uses `from flash_attn_3 import flash_attn_interface`. FlashAttention-4 uses `from flash_attn.cute import flash_attn_func`. This split is a source of confusion. If you install the wrong package for your GPU, the import may succeed but the kernel may not run. The README also warns about `ninja`: without it, compilation can take two hours; with it, three to five minutes on a 64-core machine. You can cap parallel jobs with `MAX_JOBS=4` if RAM is tight.

Hardware Support: CUDA, ROCm, and the Turing Gap

CUDA support covers Ampere, Ada, and Hopper GPUs (A100, RTX 3090, RTX 4090, H100). Turing GPUs like T4 and RTX 2080 are not supported in this repository; the README points to a separate fork for a core subset. FP16 and BF16 are supported, with BF16 requiring Ampere or newer. Head dimensions up to 256 are supported for forward and backward, with a note that head dim 256 backward works on consumer GPUs since version 2.5.5 (without dropout). On the AMD side, there are two backends. The Composable Kernel backend is default and supports MI200, MI250, MI300, MI355, and RDNA 3/4, with FP16 and BF16. The Triton backend supports CDNA and RDNA with FP32 as well, plus features like MQA/GQA, dropout, rotary embeddings, ALiBi, and paged attention. Sliding window attention is listed as work in progress. This breadth is useful, but it means you must know exactly which backend your PyTorch build uses, and the Triton backend requires setting `FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE` at install time.

FlashAttention-3 and FlashAttention-4: Beta Status and New Constraints

FlashAttention-3 is a beta release optimized for Hopper GPUs (H100, H800). It requires CUDA 12.3 or later, with 12.8 recommended. It currently supports FP16/BF16 forward and backward, and FP8 forward. FlashAttention-4 is written in CuTeDSL and targets Hopper and Blackwell (H100, B200). The README does not state a beta label for FlashAttention-4, but the release tags use `fa4-v4.0.0.beta28`, which strongly implies beta. This matters for production use. The API for FlashAttention-4 is simple: `flash_attn_func(q, k, v, causal=True)`, but the kernel is tied to very recent GPU architectures. If you are on an A100, you cannot use FlashAttention-3 or 4; you must stick with FlashAttention-2. If you are on H100, you have a choice, but the README gives no guidance on when to pick 3 over 4. The lack of a clear migration path between versions is a genuine limitation.

A Real Alternative: PyTorch's Native SDPA and the Trade-Off

The most direct alternative is PyTorch's built-in scaled dot product attention (SDPA), which since PyTorch 2.0 includes an efficient attention implementation that may use FlashAttention kernels internally on compatible hardware. The difference is approach: PyTorch's SDPA is a fused operation that selects a backend (including a math fallback) automatically, while this repository gives you explicit control over the kernel and its parameters. SDPA is easier to adopt because it requires no separate install and no manual kernel selection. However, SDPA may not expose all the tuning options or the exact kernel versions that FlashAttention provides, and it may fall back to a slower path on some hardware. If you need the latest kernels (FlashAttention-3 FP8, FlashAttention-4 on Blackwell) or you want to benchmark specific kernel variants, this repository is necessary. If you just need fast attention on a supported GPU and want minimal dependency management, PyTorch's SDPA might be sufficient. The README does not compare against SDPA, but the existence of a fallback path is well known from PyTorch documentation.

Maintenance and Upgrade Cost: What the Repository Reveals

The repository is actively maintained, with recent beta releases for FlashAttention-4 in August 2026. The license is BSD-3-Clause, which permits commercial use and modification with attribution. The README explicitly states that FlashAttention and FlashAttention-2 are free to use and modify, and asks for citation. Upgrade cost is non-trivial. Each major version has a different package name and import path, so moving from FlashAttention-2 to 3 or 4 is not a drop-in replacement. You must change imports and likely rebuild the kernel for your specific GPU. The README also notes that the full test suite takes hours to run, which means verifying a new version is a time investment. The `ninja` dependency and the `MAX_JOBS` environment variable highlight that compilation is resource-intensive. If you rely on prebuilt wheels, note that the README only discusses source compilation for most paths; prebuilt wheels are not promised for all platforms. Windows support is described as 'might work' starting v2.3.2, with a call for help on prebuilt CUDA wheels. This is a clear warning for Windows users.

The Bottom Line: Where FlashAttention Sits in the Ecosystem

FlashAttention is not a single library but a family of kernels with a fragmented packaging strategy. The core algorithm is proven and widely used, but the repository's value depends entirely on your hardware. If you run on A100 or RTX 4090, FlashAttention-2 is stable and well documented. If you run on H100, you have beta options that may or may not be faster. If you run on Turing or Windows, this repository is the wrong tool. The memory savings are real and exact, but they come at the cost of installation complexity and version-specific APIs. The README is clear about what works, but it does not offer a unified interface across generations. That is a deliberate trade-off: each version is optimized for a specific architecture, and the authors prioritize performance over consistency. For a production team, the first step is not to install the latest version but to check which package matches your GPU and CUDA version. The repository gives you the commands, but it does not make the choice for you.

Editorial conclusion

Adopt FlashAttention if you train or fine-tune transformer models on NVIDIA Ampere or newer GPUs, or on AMD MI200 and later, and you need exact attention with lower memory use. Skip it if you target Turing GPUs, need Windows as a first-class platform, or want a stable API across all hardware. Before adopting, verify your CUDA or ROCm version, confirm your head dimension is within the supported range (up to 256 for most backends), and check whether the beta status of FlashAttention-3 and FlashAttention-4 is acceptable for your production timeline. The repository is the canonical source, but the split between flash-attn, flash-attn-3, and flash-attn-4 packages means you must pick the right one for your GPU generation.

Official sources

  1. Official README
  2. Project repository
  3. Release notes
Community notes

Community notes