KVortex : Offloader VRAM→RAM pour LLMs vLLM et Inférence

Vos pipelines de données d'entraînement sont-ils protégés contre l'empoisonnement ?

Problématique : Pourquoi le KV cache explose la VRAM

Mécanisme du KV cache dans les transformers

Dans une architecture transformer, chaque layer calcule des matrices K (keys) et V (values) pour tous les tokens du contexte. Lors de l'inférence auto-régressive (génération token par token), on réutilise les K/V des tokens précédents au lieu de les recalculer, ce qui accélère considérablement la génération.

Pour un modèle comme Llama 3.3 70B (80 layers, 8192 hidden_dim, 64 attention heads) avec un contexte de 128K tokens :

Taille KV cache = 2 (K+V) × 80 layers × 128K tokens × 8192 dim × 2 bytes (FP16)
                = 2 × 80 × 131072 × 8192 × 2 = ~210 GB

Avec une GPU A100 80GB, impossible de stocker entièrement ce cache en VRAM. Les solutions classiques (troncature de contexte, batch size = 1) dégradent soit la qualité, soit le throughput. Pour approfondir, consultez IA pour le DFIR : Accélérer les Investigations Forensiques.

Limites des approches existantes

• Paged Attention (vLLM) : Gère efficacement l'allocation mémoire GPU mais ne peut pas offloader vers la RAM nativement.
• FlashAttention : Optimise le calcul d'attention mais ne résout pas le problème de taille totale du cache.
• Quantization (INT8/INT4) : Réduit la précision mais n'adresse pas les contextes extrêmement longs (>100K tokens).

Architecture Technique de KVortex

1. Cache Content-Addressable avec SHA256

KVortex utilise un cache content-addressable : chaque bloc KV est identifié par le hash SHA256 de son contenu (prompt_ids + position). Cela permet la déduplication automatique lorsque plusieurs requêtes partagent un préfixe commun (system prompts, few-shot examples).

std::string block_id = sha256(
    prompt_tokens.data(), 
    prompt_tokens.size() * sizeof(int32_t)
);
if (cache.contains(block_id)) {
    return cache.get(block_id); // Hit: pas de calcul
}
// Miss: calculer et stocker
cache.insert(block_id, compute_kv_block(prompt_tokens));

Gain observé : Jusqu'à 60% de réduction du cache effectif sur des workloads avec prompts répétitifs (chatbots, API structurées).

2. Politique d'éviction LRU avec priorité temporelle

L'éviction des blocs de la VRAM utilise un LRU (Least Recently Used) augmenté d'un score de priorité basé sur :

• Fréquence d'accès : Blocs réutilisés souvent restent en VRAM
• Taille : Préférence pour évincer les gros blocs (meilleur ratio libération/transfert)
• Timestamp : Blocs non accédés depuis >30s candidats prioritaires

Le seuil de déclenchement est configurable : par défaut à 85% VRAM occupée, KVortex offload par batch de 256MB jusqu'à redescendre sous 75%.

3. Multi-Stream GPU et Transferts Asynchrones

Pour minimiser l'impact latence, KVortex utilise 4 CUDA streams en parallèle : Pour approfondir, consultez Data Platform IA-Ready : Architecture de Référence 2026.

cudaStream_t streams[4];
for (int i = 0; i < 4; i++) {
    cudaStreamCreateWithFlags(&streams[i], cudaStreamNonBlocking);
}

// Offload batch asynchrone
for (size_t i = 0; i < blocks_to_evict.size(); i++) {
    int stream_id = i % 4;
    cudaMemcpyAsync(
        ram_buffer + offsets[i], 
        vram_blocks[i], 
        block_sizes[i],
        cudaMemcpyDeviceToHost, 
        streams[stream_id]
    );
}
cudaDeviceSynchronize(); // Attente completion

En pratique, sur PCIe 4.0 x16 (64 GB/s bidirectionnel), un batch de 1GB s'offload en ~18ms grâce au parallélisme.

4. Prefetching Prédictif

KVortex anticipe les accès futurs en analysant les patterns de requêtes. Lorsqu'une conversation multi-tours est détectée (même session_id), les blocs KV de l'historique sont rechargés en avance pendant que le modèle génère la réponse précédente.

Installation et Configuration

Prérequis

• GPU : NVIDIA avec Compute Capability ≥ 7.0 (Volta, Turing, Ampere, Ada, Hopper)
• Compilateur : GCC 11+ ou Clang 14+ (support C++23)
• CUDA : CUDA Toolkit 12.0+
• RAM : Minimum 64GB recommandé (pour offloader efficacement)

Compilation depuis les sources

# Cloner le repository
git clone https://github.com/ayinedjimi.git
cd KVortex

# Créer le build directory
mkdir build && cd build

# Configurer avec CMake
cmake -DCMAKE_BUILD_TYPE=Release \
      -DCMAKE_CUDA_ARCHITECTURES=80 \
      -DKVORTEX_ENABLE_BENCHMARKS=ON \
      ..

# Compiler (utilise tous les cores disponibles)
make -j$(nproc)

# Installer (nécessite sudo)
sudo make install

Intégration avec vLLM

KVortex s'intègre à vLLM via une extension C++ Python binding (pybind11). Installer la wheel :

pip install kvortex-vllm  # depuis PyPI

# Ou depuis les sources
cd KVortex/python
pip install -e .

Configuration dans vLLM (fichier config.yaml) :

model: "meta-llama/Llama-3.3-70B-Instruct"
tensor_parallel_size: 2
gpu_memory_utilization: 0.85

kv_cache:
  backend: "kvortex"
  offload_threshold: 0.85     # Offload à 85% VRAM
  ram_cache_size: "128GB"     # Limite cache RAM
  prefetch_enabled: true
  num_streams: 4
  block_size: 128             # Granularité 128 tokens

Benchmarks de Performance

Setup de test

• Hardware : 2× NVIDIA A100 80GB, 512GB RAM DDR5, AMD EPYC 7763 (64 cores)
• Modèle : Llama 3.3 70B Instruct (FP16)
• Workload : 500 conversations simultanées, contexte moyen 32K tokens

Résultats comparatifs

Analyse des gains

• Throughput 3.6× supérieur : Grâce à la capacité de servir 500 requêtes concurrentes vs. 120 max en mode vanilla (limite VRAM).
• Latence P99 réduite de 52% : Les blocs KV préchargés évitent les stalls de génération lors du context switch.
• Utilisation VRAM optimisée : 68GB vs. 76GB, car les blocs froids sont offloadés proactivement avant OOM.

Cas d'Usage Principaux

Comparaison avec d'Autres Solutions

KVortex se distingue par sa combinaison unique d'offloading intelligent, déduplication content-addressable et optimisations GPU avancées (multi-stream, prefetching). DeepSpeed ZeRO-Infinity et FlexGen se concentrent sur l'entraînement/fine-tuning, tandis que KVortex cible spécifiquement l'inférence production haute performance.

Limitations et Roadmap

Limitations actuelles

• Latence PCIe : Sur des requêtes très courtes (<10 tokens générés), l'overhead de transfert VRAM↔RAM peut dépasser le gain. KVortex est optimal pour contextes >16K tokens.
• Support modèles : Actuellement testé avec Llama, Mistral, Qwen. Support GPT-NeoX et Falcon prévu pour v1.1.
• Multi-GPU : L'offloading cross-GPU (NVLink) n'est pas encore implémenté. Pour l'instant, chaque GPU offload vers sa zone RAM dédiée.

Roadmap v1.1-v2.0

• NVSwitch offloading : Utiliser NVLink/NVSwitch pour offloader entre GPUs avant la RAM (latence 10× inférieure).
• Compression adaptative : Compresser les blocs KV en RAM avec zstd/lz4 (trade-off CPU vs. RAM).
• Integration TensorRT-LLM : Extension pour NVIDIA TensorRT-LLM en plus de vLLM.
• Dashboard Prometheus : Métriques temps réel (hit rate, transfer bandwidth, évictions) via exporter Prometheus.