Avancé 12 minOptimisation

Flash Attention 2 sur LLM local : activer et benchmarker le gain

Flash Attention 2 (FA2) est l'optimisation qui transforme un LLM local à long contexte d'inutilisable à confortable. Activé d'une variable d'environnement dans Ollama, d'un flag dans llama.cpp, par défaut dans vLLM — encore faut-il que votre GPU le supporte vraiment. Ce guide montre comment l'activer dans les trois principaux runtimes, mesurer le gain réel (mémoire KV cache et tokens/sec) selon la taille de contexte, et identifier les cas où ça ne sert à rien.

Par Mohamed Meguedmi·Màj 2026-06-11·Testé sur Windows, macOS, Linux

#Pourquoi Flash Attention 2

L'attention classique d'un transformer a une complexité mémoire quadratique en fonction de la longueur du contexte. Doubler le contexte quadruple la VRAM consommée par l'attention. À 32k tokens, sur un modèle 8B en FP16, la matrice d'attention seule peut peser plus que les poids du modèle.

Flash Attention, introduit par Tri Dao en 2022 puis raffiné en FA2 en 2023, ne change pas le résultat mathématique : il change la façon de le calculer. L'idée est de traiter l'attention par blocs (tiling) directement dans la SRAM du GPU plutôt que de matérialiser la matrice complète en HBM. Le résultat est strictement identique à l'attention naïve, à la précision près.

Concrètement, sur un LLM local en inférence, FA2 apporte deux gains qui se cumulent : la mémoire dédiée à l'attention devient quasi-linéaire en taille de contexte au lieu de quadratique (KV cache largement allégé), et le débit augmente de 2 à 4× sur les longs contextes parce que les accès mémoire coûteux sont éliminés.

i
Ce que FA2 n'est pas
Ce n'est pas une compression. La qualité de génération est identique au bit près (modulo l'ordre des additions flottantes). Ce n'est pas non plus une quantization : FA2 et la quantization du KV cache (Q8_0 par exemple) sont deux optimisations distinctes que vous pouvez cumuler.

#Prérequis GPU et logiciels

Flash Attention 2 exploite des instructions matricielles spécifiques (tensor cores) qui n'existent que sur certaines générations de GPU. C'est le premier critère à vérifier avant toute chose.

NVIDIA Ampere (RTX 3000, A100) et plus récent
Support FA2 complet et performant. C'est le sweet spot : compute capability 8.0+.
NVIDIA Ada Lovelace (RTX 4000) et Blackwell (RTX 5000)
Support natif optimal. Gains maximaux sur RTX 4090 / 5090 grâce aux tensor cores Hopper-class.
NVIDIA Turing (RTX 2000, T4)
Support partiel et plus lent. FA2 fonctionne mais sans bénéficier des instructions BF16. Activez-le, mesurez : parfois neutre, parfois positif.
NVIDIA Pascal (GTX 1080 Ti, P40) et antérieur
Non supporté. Les tensor cores n'existent pas. Le flag est silencieusement ignoré ou produit une erreur à l'exécution.
AMD RDNA 3/4 (RX 7000/9000)
Support via ROCm avec le port officiel de Flash Attention (composable_kernel). Performance proche du natif sur RX 7900 XTX et au-dessus.
Apple Silicon (M1 à M4)
Pas de Flash Attention 2 à proprement parler. Metal a ses propres kernels d'attention fusionnée. Les runtimes (llama.cpp Metal, MLX) utilisent l'équivalent automatiquement, vous n'avez rien à activer.
!
Précision requise : FP16 ou BF16
FA2 ne fonctionne pas en FP32. Les modèles GGUF (Q4_K_M, Q5_K_M, etc.) sont dé-quantizés à la volée vers FP16 pour l'attention, donc ça marche. Mais si vous chargez un modèle en FP32 (cas rare en inférence), désactivez FA2 ou le runtime refusera.

#Activer Flash Attention 2 dans Ollama

Depuis la version 0.3, Ollama supporte Flash Attention via une variable d'environnement. Ce n'est pas activé par défaut historiquement, car les anciennes cartes peuvent ne pas le supporter. À vous de l'allumer.

Activation ponctuelle (Linux/macOS)
OLLAMA_FLASH_ATTENTION=1 ollama serve

Pour le rendre persistant via systemd (cas Linux courant) :

systemd drop-in
sudo systemctl edit ollama.service

# Dans l'éditeur, ajoutez :
[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

# Puis :
sudo systemctl daemon-reload
sudo systemctl restart ollama

Sur Windows, ajoutez la variable d'environnement utilisateur via Panneau de configuration > Système > Variables d'environnement, puis redémarrez Ollama. Sur macOS, utilisez launchctl setenv ou ajoutez la variable dans votre shell rc.

Cumulez avec la quantization KV cache
OLLAMA_KV_CACHE_TYPE=q8_0 quantize le KV cache à 8 bits, divisant à nouveau sa taille par deux pour une perte de qualité quasi-nulle. Combiné à FA2, vous pouvez tripler la taille de contexte que votre VRAM tient. q4_0 est encore plus agressif mais commence à se voir sur les modèles de raisonnement.

Pour vérifier que FA2 est bien actif, lancez ollama avec OLLAMA_DEBUG=1 et cherchez la ligne flash_attention=true dans les logs au chargement du modèle.

#Activer Flash Attention 2 dans llama.cpp

llama.cpp expose un flag explicite, plus contrôlable qu'Ollama : -fa (ou --flash-attn dans sa forme longue). Il s'utilise aussi bien avec llama-cli qu'avec llama-server.

llama-cli avec FA2
./llama-cli -m models/qwen2.5-14b-instruct-q5_k_m.gguf \
  --flash-attn \
  --ctx-size 32768 \
  -p "Résume ce document..."
llama-server avec FA2
./llama-server -m models/qwen2.5-14b-instruct-q5_k_m.gguf \
  -fa \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --host 0.0.0.0 --port 8080

Les flags --cache-type-k et --cache-type-v quantizent respectivement les clés et valeurs du KV cache. q8_0 est la valeur sûre (perte quasi nulle), q4_0 est l'option agressive. Notez que la quantization du KV cache exige FA2 activé : sans -fa, ces flags sont rejetés.

i
Compilation requise
Si vous avez compilé llama.cpp avec -DGGML_CUDA=ON, FA2 est inclus automatiquement. Sur builds Vulkan, le support FA2 est plus récent et moins mature — testez avant de pousser en prod. Côté Metal (macOS), FA2 est intégré nativement, le flag -fa est accepté mais l'implémentation passe par les kernels Apple.

#Activer Flash Attention 2 dans vLLM

vLLM utilise Flash Attention 2 par défaut depuis la version 0.2, et bascule sur FlashAttention-3 sur Hopper (H100) et Blackwell quand c'est possible. Vous n'avez en général rien à activer. Le seul cas où vous devez intervenir est pour forcer un backend, par exemple pour comparer ou pour contourner un bug sur un GPU exotique.

Forcer le backend Flash Attention
VLLM_ATTENTION_BACKEND=FLASH_ATTN \
  vllm serve Qwen/Qwen2.5-14B-Instruct \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

Les backends disponibles sont FLASH_ATTN (FA2), FLASHINFER (encore plus rapide sur certaines tailles, requiert l'installation de flashinfer), XFORMERS (fallback Ampere et antérieur), et TORCH_SDPA (fallback générique). Sur GPU récent, FLASH_ATTN ou FLASHINFER sont les bons choix.

FlashInfer sur Hopper / Blackwell
Si vous servez du Qwen 32B ou plus sur H100/B200 avec beaucoup de requêtes concurrentes, installez flashinfer et basculez VLLM_ATTENTION_BACKEND=FLASHINFER. Le gain en débit batché est mesurable (10–20% selon la charge) parce que FlashInfer optimise mieux les KV cache paginés de vLLM.

#Gain mesuré par taille de contexte

Le gain de Flash Attention 2 dépend massivement de la taille du contexte. À contexte court, il est marginal voire négatif (overhead du tiling). À contexte long, c'est la différence entre tourner et ne pas tourner. Voici des mesures représentatives sur RTX 4090 24 Go avec Qwen2.5 14B Q5_K_M.

Contexte 2k tokens
Sans FA2 : 52 tok/s, 11.2 Go VRAM. Avec FA2 : 53 tok/s, 11.0 Go. Gain : ~2%. Inutile à cette échelle.
Contexte 8k tokens
Sans FA2 : 47 tok/s, 12.8 Go. Avec FA2 : 51 tok/s, 11.6 Go. Gain : +9% vitesse, –1.2 Go.
Contexte 16k tokens
Sans FA2 : 38 tok/s, 15.4 Go. Avec FA2 : 48 tok/s, 12.6 Go. Gain : +26% vitesse, –2.8 Go.
Contexte 32k tokens
Sans FA2 : OOM (>24 Go). Avec FA2 : 42 tok/s, 15.1 Go. FA2 rend simplement le contexte 32k accessible.
Contexte 64k tokens (FA2 + KV q8_0)
39 tok/s, 18.7 Go. Sans FA2 + sans quant KV : impossible sur 24 Go.

Sur Llama 3.1 8B (modèle plus petit, attention head dimension différente), le gain à 32k est plus modeste (+15% vitesse) parce que l'attention pèse moins dans le coût total. Sur DeepSeek-R1-Distill 32B, le gain à 16k est massif (+45%) car le modèle est lourd et le ratio attention/feedforward joue en faveur de FA2.

i
Mesurez chez vous
Ces chiffres servent d'ordre de grandeur. La taille des têtes d'attention, la quantization du modèle, la fréquence GPU et la version du runtime font varier le gain de ±20%. Lancez votre prompt typique avec et sans -fa pour décider.

#Cas où ça n'aide pas (ou nuit)

GPU Pascal / Maxwell
GTX 1080 Ti, P40, Tesla M40, Titan X Maxwell. Pas de tensor cores compatibles. Le flag est ignoré sur Ollama, rejeté sur llama.cpp récent. Pas de gain possible — utilisez xformers ou rien.
Inférence très courte (chat 500 tokens)
Si vous générez systématiquement des réponses courtes sur des prompts courts, FA2 ajoute un overhead de quelques pourcents sans rien apporter. Notable surtout sur les petits modèles 1B-3B.
CPU pur
FA2 est une optimisation GPU. Sur llama.cpp CPU, le flag est ignoré. Les optimisations CPU passent par d'autres voies (ARM SVE, AVX-512, etc.).
Modèles avec attention sliding window non standard
Mistral 7B v0.1 (sliding window 4096), Gemma 2 (alternance global/local) : selon les versions de runtime, FA2 peut tomber en fallback. Vérifiez les logs, parfois c'est le backend qui ne le supporte pas encore.
Apple Silicon
Sur M1-M4, le flag -fa de llama.cpp est accepté mais l'implémentation passe par Metal qui fait déjà ses propres optimisations. Le gain mesuré est marginal car l'attention Metal est déjà fusionnée nativement.

#FA2 vs xformers vs PyTorch SDPA

Vous croiserez ces trois noms en lisant la doc des runtimes. Ils ne font pas exactement la même chose et n'ont pas le même âge.

xformers (Meta, 2021)
Bibliothèque de kernels efficaces incluant memory_efficient_attention. Précurseur de Flash Attention. Encore utilisé en fine-tuning (Unsloth, Axolotl) parce qu'il supporte plus de variantes d'attention. Plus lent que FA2 en inférence sur Ampere+.
Flash Attention 2 (Tri Dao, 2023)
Successeur de Flash Attention 1. Spécialisé inférence et entraînement, kernels CUDA écrits à la main, le plus rapide sur Ampere et Hopper. Standard de fait en 2026.
PyTorch SDPA
torch.nn.functional.scaled_dot_product_attention. Depuis PyTorch 2.0, dispatche automatiquement vers Flash Attention 2 quand c'est possible, sinon vers xformers, sinon vers l'implémentation naïve. C'est ce que vLLM et beaucoup de runtimes utilisent en interne.
FlashAttention-3 (Tri Dao + NVIDIA, 2024)
Spécifique aux GPU Hopper (H100) et Blackwell. Exploite les FP8 et asymétrie warp-spécialisée. Si vous tournez sur H100, FA3 bat FA2. Sur RTX consumer, FA2 reste la cible.
En pratique, vous n'avez pas à choisir
Le runtime décide pour vous : vLLM choisit le meilleur backend selon le GPU détecté, llama.cpp utilise sa propre implémentation FA2 derrière le flag -fa, Ollama de même. Les distinctions ci-dessus comptent quand vous écrivez du code PyTorch ou que vous fine-tunez.

#Dépannage

Le flag semble ignoré (pas de gain)
Vérifiez la version du runtime (Ollama ≥ 0.3, llama.cpp commit récent). Activez les logs verbeux : OLLAMA_DEBUG=1 ou llama-cli --verbose. Cherchez flash_attention=true ou flash_attn=enabled.
Erreur unsupported head dimension
Certaines dimensions de têtes (96, 192) ne sont pas supportées par toutes les versions de FA2. Mettez à jour le runtime ou retombez sur le backend par défaut. Concerne surtout les modèles exotiques.
Régression de qualité visible
Très rare avec FA2 seul (résultat mathématiquement équivalent). Si vous voyez une dégradation, c'est probablement la quantization du KV cache, pas FA2. Désactivez --cache-type-k/v et regardez si le problème persiste.
OOM malgré FA2 activé
FA2 réduit la mémoire de l'attention, pas celle des poids. Si votre modèle 30B Q5 ne tient pas en 16 Go de VRAM, FA2 ne sauve rien. Descendez d'un cran de quantization (Q4_K_M) ou utilisez un modèle plus petit.
vLLM tombe sur xformers au lieu de FA2
Vérifiez l'install : pip install flash-attn --no-build-isolation. Sur Turing, vLLM préfère xformers parce que FA2 y est moins optimisé. C'est attendu.

#Pour aller plus loin

Flash Attention 2 est le premier réflexe pour étendre le contexte utilisable sur une VRAM donnée. Si vous voulez aller plus loin dans l'optimisation, ces guides connexes complètent bien :

Quantization GGUF en 2026 : Q4_K_M vs Q5_K_M vs Q6_K
Le compagnon évident : réduire la taille du modèle pour libérer de la VRAM, à combiner avec FA2 pour aller plus loin en contexte.
Compiler llama.cpp avec CUDA
Indispensable si vous voulez la version la plus récente de FA2 dans llama.cpp et benchmarker proprement.
Déployer vLLM en production
FA2 prend tout son sens en serveur multi-requêtes batché : c'est là que le gain explose.
Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.