Optimisation Mémoire LLM : KV Cache, Quantification & RAG

Introduction : enjeux stratégiques de la mémoire des LLM

Les Large Language Models (LLM) s’appuient sur trois types de mémoire pour générer des réponses cohérentes et contextualisées :

• Mémoire paramétrique : stockage des paramètres (7 B à 70 B+), déterminant la capacité de raisonnement.
• Mémoire de travail : KV cache construit à chaque inférence pour conserver l’historique actif.
• Mémoire externe : retrieval-augmented generation (RAG) via bases vectorielles pour enrichir le contexte sans alourdir le modèle.

Pour les DSI et CTO, maîtriser ces ressources permet de :

• Réduire le Total Cost of Ownership (TCO) GPU et CPU.
• Garantir les Service Level Objectives (p95/p99 latences, p95 < 800 ms).
• Assurer la souveraineté et la sécurité des données (RGPD, SOX).

Ce guide technique approfondit les choix de quantification, les optimisations du KV cache, les architectures RAG, et fournit des benchmarks reproductibles pour une plateforme LLM rentable et scalable.

1) Mémoire paramétrique : quantification et trade-offs qualité/coût

La mémoire paramétrique regroupe l’ensemble des poids appris. Elle peut résider en VRAM (GPU) ou en RAM CPU selon la quantification :

• fp16 : qualité maximale, empreinte ≈ 2× fp32, mobilisation GPU privilégiée.
• int8 (LLM.int8) : – 50 % de VRAM, perte < 1 % sur GLUE/SQuAD, idéale pour conformité.
• 4-bit (GPTQ, QLoRA) : – 75 % de VRAM, latence +5–10 %, attention aux tâches de Q/R complexes.

1.1 Benchmark quantification : méthode reproductible

Environnement :

• GPU : NVIDIA A100 40 Go.
• OS : Ubuntu 22.04, CUDA 11.8, cuDNN 8.6.
• Frameworks : PyTorch 2.0, transformers 4.32, bitsandbytes 0.39.

Commandes du benchmark (batch=1, contexte=512 tokens, seed=42) :

export CUDA_VISIBLE_DEVICES=0
python benchmark_quant.py \
  --model facebook/opt-13b \
  --quantization {none,int8,4bit} \
  --batch_size 1 \
  --context_length 512 \
  --seed 42 \
  --framework transformers \
  --output metrics.json

Extrait de metrics.json (GLUE score, SQuAD F1, VRAM utilisée, latence moyen) :

Interprétation : int8 offre un compromis idéal qualité/empreinte. Le 4-bit réduit drastiquement les besoins VRAM, au prix d’un léger glissement sémantique sur des tâches complexes. Testez systématiquement (BoolQ, LogiQA) avant production.

2) Mémoire de travail : mathématiques du KV cache et optimisations

Le KV cache stocke les clés (K) et valeurs (V) à chaque couche d’attention pour générer la prochaine token. Sa consommation suit la formule :

Mem_KV = L × N × 2 × H × D × sizeof(dtype)

• L = nombre de tokens (context length).
• N = nombre de couches (ex. 40 pour 13 B).
• H = nombre de têtes (ex. 40).
• D = dimension par tête (ex. 64).
• sizeof(dtype) = 2 bytes pour fp16, 1 pour 8-bit quantifié, 0,5 pour 4-bit.

Exemple pour un 13 B, L=32 000, N=40, H×D=2560 :

• fp16 : 32 000×40×2×2560×2 B ≈ 12,8 Go.
• 8-bit : 32 000×40×2×2560×1 B ≈ 6,4 Go.
• 4-bit : 32 000×40×2×2560×0,5 B ≈ 3,2 Go.

2.1 Benchmarks KV cache : configuration et résultats

Configuration GPU : A100 80 Go, batch=1, contexte=32 000 tokens, seed=123, mesure via nvidia-smi et time.perf_counter().

python benchmark_kv.py \
  --model meta-llama/Llama-2-13b \
  --dtype {bf16,8bit,4bit} \
  --context_length 32000 \
  --batch_size 1 \
  --profile_gpu \
  --seed 123

Recommandation : limitez la fenêtre de contexte à 32 k tokens. Au-delà, latence p95 > 2000 ms. Privilégiez RAG ou résumés hiérarchiques.

3) Mémoire externe : Retrieval-Augmented Generation (RAG)

Le RAG permet de rechercher des documents pertinents en amont de l’inférence pour enrichir le contexte sans gonfler le KV cache. Les deux principaux index sont :

• HNSW (graph-based) : < 20 ms @ 1 M vecteurs, Recall@10 ≈ 99 %.
• IVF+PQ (inverted file + product quantization) : 5–10 ms @ 10–100 M vecteurs, Recall@10 ≈ 90 %.

3.1 Méthodologie de benchmark RAG

Environnement :

• Indexation FAISS v1.7, Milvus v2.2.
• Hardware CPU : 16 cœurs, 64 Go RAM.
• Mesure via time.time(), psutil, rappel via recall@k.

# Création de l'index HNSW
python create_index.py \
  --index_type HNSW \
  --dim 1024 \
  --M 32 \
  --ef_construction 200 \
  --data embeddings.npy

# Query benchmark
python query_index.py \
  --index_path hnsw.index \
  --batch_queries queries.npy \
  --k 20 \
  --profile_time \
  --seed 2024

3.2 Re-ranking et latence additionnelle

Après top-k retrieval, un cross-encodeur (e.g. sentence-transformers/all-mpnet-base-v2) permet de réduire les hallucinations (~ –25 % erreurs) mais ajoute ~ 30 ms par document :

• Initial retrieval : 18 ms.
• Re-ranking 20 docs : 20 × 30 ms = 600 ms (optimisable en batch).
• Total RAG step : ~ 618 ms.

Astuce : limiter re-ranking à top-5 et utiliser caching LRU pour les requêtes fréquentes.

Résumés hiérarchiques : chunker en 300–800 tokens avec 50–100 tokens de chevauchement, puis synthèse récursive diminue le contexte de 50–70 % et maintient la latence p95 < 350 ms.

4) Matériel & moteurs d’inférence

4.1 Choix GPU

• A100 80 Go ou H100 80 Go pour multi-tenant interactif (latence < 800 ms).
• Prix GPU on-prem : 20–40 k€. Cloud : A100 ~ 3 €/h, H100 ~ 6 €/h.
• Coût cible : < 0,05 €/1 000 tokens (batch optimisé, quantification).

4.2 Moteurs d’inférence

• vLLM : PagedAttention, dynamic batching, KV reuse. – 35 % p95 vs baseline.
• TensorRT-LLM : kernels CUDA optimisés, IA Precision (fp16/int8) pour + 20 % de débit.
• Text Generation Inference (OCI) : intégration Kubernetes, autoscaling GPU.
• Offload KV sur CPU/NVMe/DPU pour tâches offline (+20–50 ms).

5) Mise en production & exploitation

• Dimensionnement : 7B–13B quantifié + RAG pour p95 < 800 ms. Monter à 34B/70B si KPI métier (CSAT, MRR) chutent > 5 %.
• Politique de contexte : 8k–32k tokens + résumés hiérarchiques. Éviter ≥ 64k tokens (cas < 10 %).
• Observabilité : métriques p95/p99 latence LLM & RAG, coût/1 000 tokens, hit-rate RAG, qualité (BLEU, F1, hallucination).
• Scalabilité : autoscaling GPU basé backlog/SLO, continuous batching, caching réponses fréquentes.
• Sécurité & conformité : cloisonnement locataire, chiffrement AES-256 at-rest/in-transit, scrub PII, audit trails RGPD/SOX.
• Résilience : timeouts/circuit breakers (embedding < 200 ms, RAG < 50 ms, LLM < 1 000 ms), fallbacks minimaux.
• Qualité : filtrage injection, sortie structurée (JSON Schema), évaluation continue H2H.

6) Retours d’expérience

Support B2B (3 M passages) : adoption RAG + résumés hiérarchiques a compressé le contexte de 65 %, réduit p95 de 1200→780 ms, – 40 % coût GPU.

Knowledge base interne : re-ranking cross-encoder a réduit hallucinations de 25 % vs top-k seul, p95 resté < 800 ms.

Chatbot interne : KV cache 4-bit sur A100 80 Go a doublé les sessions concurrentes sans impacter CSAT.

Annexe : checklist IT pour déploiement LLM

• Modèle : 7B–13B quantifié + RAG robuste. 34B/70B si qualité métier nécessite.
• Contexte : 8k–32k tokens + résumés hiérarchiques, éviter ≥ 64k.
• Moteur : continuous batching, PagedAttention (vLLM), TensorRT-LLM profiling KV.
• Index : HNSW (< 1 M vecteurs) ou IVF+PQ (> 10 M vecteurs).
• Déploiement : cloud managé pour time-to-value, on-prem pour souveraineté.
• Sécurité : AES-256, locataire cloisonné, PII scrub, rétention explicite.
• Budget : 20–40 k€/GPU on-prem ou 3–6 €/h cloud. cible < 0,05 €/1 000 tokens.

Sources & références : Benchmarks internes Codolie (2024), GLUE/SQuAD, documentation vLLM/TensorRT-LLM, FAISS/Milvus whitepapers, NVIDIA Developer Blog.