Flash Attention 是什麼|為何更快又省 VRAM

打開 LM Studio 的模型載入設定、翻 llama.cpp 的參數表、或是查 Ollama 的環境變數清單,你遲早會撞見同一個名詞:Flash Attention。中文圈的說明大多停在「開了比較快、比較省記憶體」這一句,然後就沒有然後了。於是實際使用時就會冒出一串沒人回答的問題:開了會不會讓模型變笨?我這張卡到底吃不吃得到?為什麼有人說開了根本沒差?

站長我把論文與各家原始碼翻過一輪後,發現中文資料最常弄反的其實是三件事,而且三件都會直接影響你的判斷:第一,Flash Attention 是「演算法」不是「某個 pip 套件」,flash-attn 那個套件的硬體門檻,跟 llama.cpp 裡那個 -fa 完全是兩回事;第二,它省的是注意力計算過程中的中間矩陣,不是模型權重、也不是 KV cache,所以「開了就塞得下更大的模型」是誤會;第三,論文把它定位為 exact attention(精確注意力),不是近似法——它跟「量化」那種拿品質換空間的手段,根本不同類。

這篇就把這三件事一次講清楚,順便附上各工具的實際開關名稱與硬體需求。

🧪 原理拆解

瓶頸不在「算得慢」,在「搬得慢」

先講結論:注意力真正的成本大戶不是浮點運算,而是資料在顯示卡不同層記憶體之間來回搬運。

FlashAttention 原始論文(arXiv:2205.14135,2022 年 5 月 27 日投稿)開宗明義指出:Transformer 在長序列上又慢又吃記憶體,因為自注意力的時間與記憶體複雜度對序列長度呈二次方成長。過去學界的解法是「近似注意力」——犧牲一點模型品質換取較低的計算複雜度,但論文直言,這類方法往往換不到實際的 wall-clock 加速。作者群(Tri Dao、Daniel Y. Fu、Stefano Ermon、Atri Rudra、Christopher Ré)認為缺的那塊拼圖是讓演算法 IO-aware:把 GPU 各層記憶體之間的讀寫成本也一起算進來。

這個觀點到 2026 年仍然成立。NVIDIA 官方技術部落格談長 context 推論最佳化時,同樣把注意力的 O(N²) 複雜度稱為主要瓶頸,並且描述解碼階段「GPU 花在搬 KV cache 資料的時間,比花在計算上的還多」。

顯示卡的記憶體是分層的:容量大但相對慢的 HBM(就是你看規格表上寫的那個 VRAM),以及容量極小但極快的晶片內 SRAM。傳統注意力實作會把中間結果寫回 HBM 再讀出來,一來一回,頻寬就這樣被吃掉了。

分塊計算:那張 N×N 的大表,乾脆不要寫下來

Flash Attention 的核心動作叫 tiling(分塊)。

傳統做法會在 HBM 裡實際生成一張 N×N 的注意力矩陣(N 是序列長度)——4K token 就是一張 4096×4096 的表,32K token 就是 32768×32768。這張表寫進去、讀出來,就是整個瓶頸所在。

Flash Attention 的做法是:把 K、V 矩陣切成小塊載進速度極快的 SRAM,再對 Q 矩陣的區塊做迴圈,一塊一塊算,算完把輸出寫回 HBM——全程不在 HBM 裡把那張完整的 N×N 矩陣生出來。論文分析了它的 IO 複雜度,證明它需要的 HBM 存取次數比標準注意力少,而且在一定範圍的 SRAM 容量下是最佳的。

結果就是 FlashAttention-2 論文摘要寫的那句話:記憶體用量從二次方變成線性(linear instead of quadratic),而且是在沒有任何近似的前提下達成。

這也解釋了一個很多人不解的現象:為什麼短 prompt 感覺不出差別?因為當 N 很小的時候,那張 N×N 的表本來就沒多大,省下來的東西自然也就那麼一點。Flash Attention 的效益是隨序列長度放大的,長文件、長對話、RAG 這種塞一大坨 context 的場景,才是它真正的主場。

為什麼結果不會變:exact,不是近似

這是最該說清楚的一點:Flash Attention 不會讓模型變笨。

FlashAttention 第一篇論文的標題就寫著 exact attention(精確注意力),第二代論文摘要更直接寫明「with no approximation」(沒有近似)。它跟 Q4/Q8 量化、跟稀疏注意力那類「拿精度換資源」的手段完全不同類——量化是真的把權重的位元數砍掉,Flash Attention 則是把同一道題目換個順序算完。

要補一句誠實的但書:「數學上等價」不等於「每個位元都一模一樣」。浮點數加總順序改變本來就會產生極小的數值差異,分塊計算自然會改變加總順序。但這跟「降低品質換速度」是兩回事,不該混為一談。

如果你想知道真正會影響模型輸出品質的是哪些設定,可以參考站內這篇本地 LLM 模型怎麼選?7B/70B、Q4/Q8 量化與 VRAM 一次搞懂,量化才是那個需要斟酌取捨的地方。

從 FA-1 到 FA-4:後面幾代在解什麼問題

Flash Attention 不是一個定案的東西,四年來已經迭代四代,每一代解的問題都不一樣:

版本	發表時間	解決什麼	官方公布的效果
FlashAttention	2022-05	IO-aware + 分塊,避免生成 N×N 矩陣	GPT-2(序列 1K)提速 3×;BERT-large 端到端快 15%
FlashAttention-2	2023-07	改善執行緒區塊與 warp 之間的工作切分	較前代約 2×,A100 上達理論峰值 FLOPs/s 的 50–73%
FlashAttention-3	2024-07	Hopper 專用:非同步、warp specialization、FP8	H100 上較 FA-2 快 1.5–2.0×,FP16 達 740 TFLOPs/s
FlashAttention-4	官方 repo 現行	以 CuTeDSL 改寫,針對 Hopper 與 Blackwell	官方標示最佳化目標為 H100、B200

幾個值得注意的細節:FlashAttention-2 論文指出前一代雖然已經很快,但只達到理論最大 FLOPs/s 的 25–40%,離最佳化過的矩陣乘法還有距離;而 FlashAttention-3 論文則點名 FlashAttention-2 在 H100 上只有 35% 的使用率,因為它還沒用上新硬體的非同步能力。這種「上一代在新硬體上突然變得不夠好」的循環,是 GPU 世代交替時的常態。

FlashAttention-3 另外做了一件事值得記一筆:它的 FP8 版本經驗證,數值誤差比基準 FP8 注意力低 2.6 倍。也就是說,低精度不必然等於粗糙,關鍵在實作。

🔧 各推論工具怎麼開

直接講操作:多數本地推論工具已經幫你處理好了,你需要做的通常是「確認它有開」,而不是「想辦法把它裝起來」。

llama.cpp:參數是 -fa 或 --flash-attn,可接受的值為 on、off、auto 三種。查 common/common.h 的原始碼可以看到,預設值是 LLAMA_FLASH_ATTN_TYPE_AUTO,也就是 auto——執行期自己判斷,支援就開、不支援就退回。要強制打開就寫成這樣:

llama-server -m model.gguf -fa on

Ollama:靠環境變數 OLLAMA_FLASH_ATTENTION 控制。原始碼 envconfig/config.go 裡對這個變數的註解寫的是「enables the experimental flash attention feature」,而且用的是 BoolWithDefault(三態,沒設定就走預設)。Windows 上要設定環境變數,先設好再重啟 Ollama 服務,設定才會生效:

setx OLLAMA_FLASH_ATTENTION 1

設完記得完整結束 Ollama 再重開,不是關掉視窗而已。

GUI 前端:像 LM Studio 這類圖形介面工具,通常會把底層引擎的這個開關包成設定頁裡的一個選項。選項名稱各家不同,不確定時以該工具自己的官方文件為準。

PyTorch / Hugging Face 這一側:這裡有個很多人不知道的事實——你可能早就在用了。PyTorch 官方文件明確寫著,torch.nn.functional.scaled_dot_product_attention(SDPA)目前有三種支援的實作,而第一個就是 FlashAttention-2。只要你的程式走 SDPA,底層就有機會直接派給 Flash Attention,你完全不用做任何事。

🧩 硬體與版本需求:哪些卡吃得到

這一節是本文最重要的更正:「Flash Attention」是演算法名稱,不是單一實作。同一個名詞底下至少有兩套完全不同的東西,硬體門檻天差地遠。

第一套:Dao-AILab 的 flash-attn 套件(CUDA 官方實作)

依官方 repo README 現行說明,FlashAttention-2 的 CUDA 版本要求:

GPU 架構:Ampere、Ada 或 Hopper(例如 A100、RTX 3090、RTX 4090、H100)。Turing 世代(T4、RTX 2080)要另外找 flash-attention-turing 這個獨立 repo,而且只支援核心功能的子集。
CUDA:12.0 以上。
PyTorch:2.2 以上。
作業系統:Linux。README 寫的是「自 v2.3.2 起 Windows 可能可以」(might work),並註明 Windows 編譯仍有額外條件——這個措辭本身就說明它不是官方保證的路徑。
資料型別:fp16 與 bf16(bf16 需要 Ampere 以上)。head dimension 最高到 256。

至於更新的兩代:FlashAttention-3 在 repo 中屬於 beta,要求 H100 / H800 與 CUDA 12.3 以上(官方建議 12.8);FlashAttention-4 以 CuTeDSL 撰寫,官方說明針對 Hopper 與 Blackwell(H100、B200)最佳化。看得出來,新版本正在往資料中心等級的硬體走。

第二套:llama.cpp / ggml 自己的實作

如果你是在本地跑 GGUF 模型,上面那張硬體清單跟你沒有直接關係。llama.cpp 底層的 ggml 有自己的 FLASH_ATTN_EXT 運算,而且在 CUDA、Vulkan、Metal 與 CPU 四個 backend 的原始碼裡都能查到對應處理。換句話說,不是 NVIDIA 卡、不是 Ampere 以上,一樣可能吃得到 Flash Attention,能不能用取決於你的 backend 實作與模型架構,不是取決於那個 pip 套件的支援清單。

這也是為什麼 llama.cpp 把預設值設成 auto 而不是 on:效益與可用性並非普遍成立,交給執行期判斷比較安全。

順帶一提,如果你關心的是「怎麼讓本地大模型跑得動」而不只是「跑得快」,那該看的是模型架構與記憶體配置,站內這篇 MoE 混合專家是什麼?為何 235B 模型只算 22B、卻還是很吃 VRAM 講的就是另一半的故事。

💡 總結:冷知識延伸

站長我覺得 Flash Attention 最有意思的地方,在於它證明了一件反直覺的事:在現代 GPU 上,「怎麼搬資料」往往比「算得多快」更決定效能。同一道數學題,換個記憶體存取順序,就能拿到 2 到 3 倍的實際加速,而且答案完全沒變。這在很多人心中「AI 加速 = 買更強的算力」的印象之外,開了另一扇門。

它的影響力也早就超出「一個開關」的層次。2026 年 NVIDIA 在推 Skip Softmax 這類稀疏注意力最佳化時,是直接把邏輯做進 FlashAttention kernel 裡面——Flash Attention 已經從「一個加速選項」變成整個推論堆疊的預設地基,後面的最佳化都疊在它上面長。

給本地跑模型的人三個實務判斷:

llama.cpp 留在 auto 就好,那是官方預設,遇到特定模型出怪問題時再手動關掉測試。
不要期待它讓你塞下更大的模型。它省的是注意力的中間結果,模型權重與 KV cache 該佔多少還是佔多少。
論文裡那些 2×、3× 的數字,是資料中心 GPU 在特定序列長度下量到的,不能直接套用到你家的消費級顯卡。你自己的感受會隨 context 長度、模型架構與 backend 而變——短 prompt 幾乎無感是正常的,不是設定壞了。

❓ 常見問題

Q:Flash Attention 為什麼比較快?不是計算量一樣嗎?

計算量確實幾乎一樣,快在記憶體存取次數少。傳統做法要把 N×N 的注意力矩陣寫進 HBM 再讀回來,Flash Attention 用分塊的方式在晶片內 SRAM 裡完成,避開了這趟往返。論文的用詞是 IO-aware——把讀寫成本當成一級公民來設計演算法,而不是只看浮點運算數。

Q:開了之後模型的回答會變差嗎?

不會。論文把它定位為 exact attention,第二代摘要明寫「no approximation」。它跟量化那種犧牲精度的做法不同類。唯一的但書是浮點加總順序改變會有極小的數值差異,這是所有重排運算順序的最佳化都會有的性質,與品質下降是兩回事。

Q:所有顯卡都支援嗎?

要看你講的是哪一套實作。flash-attn 這個 Python 套件的 CUDA 版本要 Ampere / Ada / Hopper,Turing 要另一個 repo;但 llama.cpp 是自己實作的,CUDA、Vulkan、Metal 與 CPU backend 都有對應的運算。所以「我的卡不在那份清單上」不等於「我用不到 Flash Attention」。

Q:我在本地跑 GGUF,需要另外 pip install flash-attn 嗎?

不需要。llama.cpp 有自己的實作,不依賴 Dao-AILab 那個 Python 套件。那個套件是給 PyTorch 生態(訓練、微調、Transformers 推論)用的。

Q:為什麼有人說開了完全沒差,甚至更慢?

最常見的原因是序列太短——省下來的量隨序列長度放大,短 prompt 本來就沒什麼可省。另一個原因是實作差異:FlashAttention-2 論文自己就指出前一代只達理論峰值的 25–40%,不同版本、不同 backend、不同模型架構的實際效益差很多。llama.cpp 把預設設成 auto 而不是 on,某種程度上就是在承認這件事。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|論文(arXiv 預印本,未標示同儕審查狀態):

FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness(arXiv:2205.14135) — 2026-08-11 查證
FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning(arXiv:2307.08691) — 2026-08-11 查證
FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision(arXiv:2407.08608) — 2026-08-11 查證

📖 第一級|官方原始碼與文件:

Dao-AILab/flash-attention — 官方 repo README(硬體與版本需求、FA-3/FA-4 說明) — 2026-08-11 查證
ggml-org/llama.cpp — common/arg.cpp(-fa 參數定義) — 2026-08-11 查證
ggml-org/llama.cpp — common/common.h(預設值 LLAMA_FLASH_ATTN_TYPE_AUTO) — 2026-08-11 查證
ollama/ollama — envconfig/config.go(OLLAMA_FLASH_ATTENTION) — 2026-08-11 查證
PyTorch 官方文件:torch.nn.functional.scaled_dot_product_attention — 2026-08-11 查證
NVIDIA Technical Blog:Accelerating Long-Context Inference with Skip Softmax in NVIDIA TensorRT LLM — 2026-08-11 查證

📅 本文查證戳記:2026-08-11 撰寫。軟體參數與硬體支援清單隨版本變動,實際操作前請再次確認你所使用版本的官方文件。