Au-delà d'Ollama : optimisez l'inférence avec vLLM et TGI

Ollama a révolutionné l’accès aux LLM locaux par sa simplicité déconcertante. Cependant, pour ceux qui gèrent des charges de travail intensives, qui servent plusieurs utilisateurs ou qui recherchent un débit de tokens maximal, Ollama peut devenir un goulot d’étranglement.

S’il est parfait pour le “chat” interactif, Ollama n’est pas conçu pour le throughput (débit global). C’est ici qu’entrent en jeu vLLM et TGI (Text Generation Inference).

Pourquoi quitter le confort d’Ollama ?

Le secret de la performance en inférence réside dans la gestion de la mémoire, et plus précisément du KV Cache (Key-Value Cache).

Ollama utilise principalement llama.cpp, qui est exceptionnel pour la polyvalence et le CPU, mais moins optimisé pour le traitement massif de requêtes simultanées. vLLM et TGI introduisent des concepts comme le PagedAttention, qui permet de fragmenter la mémoire du cache pour éviter le gaspillage et augmenter drastiquement le nombre de requêtes traitées par seconde.

Comparatif rapide

CaractéristiqueOllamavLLMTGI (Hugging Face)
CibleUtilisateur final / DevProduction / APIProduction / Enterprise
Points fortsSimplicité, Multi-plateformeDébit massif, PagedAttentionStabilité, Intégration HF
InstallationUn seul binaireDocker / PythonDocker
Consommation VRAMOptimisée (Quantifiée)Élevée (Pré-allocation)Élevée
FrontendIntégré / API OpenAIAPI OpenAI / HTTPAPI Propriétaire / OpenAI

1. Prérequis Matériels

Pour faire tourner vLLM ou TGI, vous ne pouvez plus vous contenter de “quelques Go de RAM”. Ces outils sont conçus pour le GPU et exigent une infrastructure robuste.

  • GPU NVIDIA : Architecture Ampere (RTX 3000) ou plus récent. Drivers NVIDIA et CUDA Toolkit installés.
  • GPU AMD (Radeon) : Architecture RDNA 2 ou 3. Stack ROCm installée.
  • VRAM : Minimum 16 Go pour des modèles 7B-13B. Pour des modèles 26B ou 70B, visez 24 Go à 48 Go (ou plus pour le Bare Metal).
  • CPU : Processeur multi-cœurs récent (Xeon ou EPYC) avec 32 threads ou plus recommandé pour le débit massif.
  • RAM : Minimum 32 Go de RAM système.
  • Stockage : SSD rapide avec au moins 500 Go d’espace libre pour les poids des modèles.
  • OS : Linux (Ubuntu 22.04 LTS fortement recommandé).

2. Mise en place de vLLM avec Docker

vLLM est actuellement le choix privilégié pour sa simplicité de déploiement et ses performances brutales. C’est la méthode la plus rapide pour démarrer.

Déploiement via Docker Compose (NVIDIA)

Voici une configuration optimisée pour le modèle Gemma 4 26B.

services:
  vllm:
    image: vllm/vllm-openai:latest
    container_name: vllm-server
    runtime: nvidia
    ports:
      - "8000:8000"
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
    environment:
      - HUGGING_FACE_HUB_TOKEN=votre_token_hf # Optionnel, pour les modèles privés
    command: >-
      --model google/gemma-4-26b
      --gpu-memory-utilization 0.90
      --max-model-len 32768
      --tensor-parallel-size 1
    restart: unless-stopped

Explication des paramètres clés :

  • --gpu-memory-utilization 0.90 : vLLM pré-alloue 90% de votre VRAM pour le KV Cache. C’est ce qui permet la vitesse, mais cela empêche d’autres applications d’utiliser le GPU.
  • --max-model-len : Définit la fenêtre de contexte maximale. Attention, plus ce chiffre est haut, plus la consommation de VRAM augmente.
  • --tensor-parallel-size : Si vous avez plusieurs GPU, augmentez ce chiffre pour répartir le modèle.

Cas particulier : GPU AMD (Radeon)

Pour les cartes Radeon, vLLM propose une image spécifique basée sur ROCm. Le déploiement est similaire, mais nécessite quelques ajustements :

services:
  vllm-rocm:
    image: vllm/vllm-rocm:latest
    container_name: vllm-rocm-server
    devices:
      - /dev/kfd:/dev/kfd
      - /dev/dri:/dev/dri
    ports:
      - "8000:8000"
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
    environment:
      - HSA_OVERRIDE_GFX_VERSION=10.3.0 # Optionnel, pour forcer la compatibilité RDNA 2
    command: >-
      --model google/gemma-4-26b
      --gpu-memory-utilization 0.90
      --max-model-len 32768
    restart: unless-stopped

3. Installation “Bare Metal” (Performance Maximale)

Pour ceux qui ne souhaitent pas utiliser Docker ou qui visent des performances critiques (comme sur des H100), l’installation directe sur l’OS est préférable.

Préparation du système et Drivers

L’installation nécessite un noyau récent ($\ge$ 6.2 pour les GPUs récents) et les pilotes CUDA à jour.

# Mise à jour et kernel HWE pour Ubuntu 22.04
sudo apt update && sudo apt upgrade -y
sudo apt install -y linux-generic-hwe-22.04 linux-headers-generic-hwe-22.04
sudo reboot

# Installation des outils de base
sudo apt install -y build-essential dkms wget curl git htop numactl python3-pip python3-venv

Optimisations Système (Crucial pour la production)

Ne négligez pas ces étapes, elles font la différence sur le débit de tokens :

  1. Mode Persistant GPU : Évite la latence de réveil du GPU. sudo systemctl enable --now nvidia-persistenced
  2. CPU Governor : Force le processeur en mode performance. echo 'GOVERNOR="performance"' | sudo tee /etc/default/cpufrequtils && sudo systemctl restart cpufrequtils
  3. Hugepages : Optimise la gestion mémoire pour vLLM. echo 64 | sudo tee /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
  4. Tuned Profile : sudo tuned-adm profile latency-performance

Déploiement de vLLM

Il est recommandé de créer un utilisateur dédié (vllmuser) et un environnement virtuel Python.

# Installation de vLLM
python3 -m venv ~/venv
source ~/venv/bin/activate
pip install --upgrade pip
pip install vllm mistral_common transformers tokenizers uvloop

# Création du cache Triton (essentiel pour les kernels)
mkdir -p ~/.triton && chmod 755 ~/.triton

Exemple de lancement pour un modèle massif (ex: Gemma 4 26B) :

vllm serve google/gemma-4-26b \
  --tensor-parallel-size 2 \
  --dtype auto \
  --gpu-memory-utilization 0.92 \
  --max-model-len 4096 \
  --port 8000

4. Optimisation et Quantification

Si le modèle est trop lourd pour votre GPU, vous devez utiliser des versions quantifiées. vLLM supporte nativement :

  • AWQ (Activation-aware Weight Quantization) : Le meilleur compromis performance/qualité.
  • GPTQ : Très répandu, excellente compatibilité.
  • FP8 : Pour les GPUs récents (H100, RTX 4090), permet de doubler la vitesse d’inférence.

Exemple pour un modèle AWQ : Remplacez le modèle dans le command par une version AWQ (ex: Qwen/Qwen2.5-Coder-7B-Instruct-AWQ).

5. Intégration avec vos outils (Cline, OpenWebUI)

L’avantage majeur de vLLM et TGI est qu’ils exposent une API compatible OpenAI.

Configuration dans Cline (VS Code)

  1. Provider : OpenAI Compatible
  2. Base URL : http://<ip-de-votre-serveur>:8000/v1
  3. Model ID : google/gemma-4-26b

Configuration dans OpenWebUI

Dans les paramètres de connexion, ajoutez une nouvelle connexion OpenAI avec l’URL de votre serveur vLLM. Vous profiterez alors d’une interface fluide avec un débit de tokens impressionnant.

Adaptations pour VRAM limitée (6Go et 12Go)

L’utilisation de vLLM et TGI est gourmande. Si vous ne possédez pas une carte professionnelle ou une RTX 3090/4090, voici comment optimiser vos ressources :

Pour 6 Go de VRAM

À ce niveau, vLLM peut être trop agressif. Il est conseillé de :

  • Privilégier des modèles ultra-légers : Tournez-vous vers les versions compactes de Gemma 4 (ex: Gemma 4 2B).
  • Quantification maximale : Utilisez des versions GGUF ou AWQ en 4-bit.
  • Réduire le contexte : Limitez --max-model-len à 2048 ou 4096 tokens pour éviter le crash Out of Memory.
  • Alternative : Si vLLM échoue, revenez à Ollama qui gère mieux le “swap” entre VRAM et RAM système.

Pour 12 Go de VRAM

C’est le “sweet spot” pour les modèles de taille moyenne :

  • Modèles recommandés : Les versions quantifiées de Gemma 4 (ex: Gemma 4 9B en 4-bit) rentrent parfaitement.
  • Optimisation vLLM : Baissez --gpu-memory-utilization à 0.7 ou 0.8 pour laisser de la place au système et éviter les micro-gelures de l’interface.
  • Gestion du contexte : Vous pouvez monter jusqu’à 8K ou 16K de contexte, mais au-delà, la VRAM saturera rapidement.

Conclusion

Passer d’Ollama à vLLM ou TGI, c’est accepter de perdre un peu en simplicité d’installation pour gagner énormément en efficacité. C’est la différence entre un moteur de voiture et un moteur d’avion : l’un est fait pour la ville, l’autre pour la vitesse pure.

Mon conseil : Gardez Ollama pour vos tests rapides et vos petits modèles, mais déployez vLLM pour vos modèles de production ou vos assistants de code permanents.

Sources

Catégories : DevOps Divers 

Suggestions de lecture :