Ollama vs vLLM 2026 : Comparatif Déploiement LLM Local
Installation, Benchmarks, Quantification & Monitoring

1. Vue d'Ensemble : Ollama et vLLM, Deux Philosophies

Ollama et vLLM répondent au même besoin — faire tourner un LLM en local et l'exposer via une API — mais avec des priorités radicalement différentes. Comprendre ces priorités est essentiel pour choisir le bon outil selon votre contexte.

Ollama est construit autour de l'expérience développeur. Son objectif est de rendre le déploiement LLM aussi simple que possible : une commande pour installer, une commande pour télécharger un modèle, une commande pour le lancer. Ollama gère automatiquement la quantification (il télécharge des versions GGUF pré-quantifiées), le swap entre GPU et RAM si le modèle ne tient pas en VRAM, et propose une interface CLI et web. C'est l'outil de référence pour explorer, développer et déployer dans des environnements modestes.

vLLM est construit autour de la performance en production. Son innovation principale — le paged attention — résout un problème fondamental de gestion mémoire GPU qui limitait le débit des serveurs LLM précédents. Combiné au continuous batching, vLLM peut traiter 10 fois plus de requêtes par seconde qu'Ollama sur le même matériel dès que le volume de requêtes simultanées dépasse 5-10. C'est l'outil de référence pour la production haute disponibilité.

2. Benchmarks : Tokens/s, Latence, Débit Concurrentiel

Débit single-request (1 requête à la fois)

Contre-intuitivement, Ollama est légèrement plus rapide en single-request car il utilise llama.cpp (très optimisé pour l'inférence séquentielle sur GPU). vLLM est conçu pour le batch et a plus d'overhead en single-thread.

Débit multi-requêtes simultanées (le cas réel en production)

Le continuous batching de vLLM lui permet d'agréger les requêtes en cours de traitement — une nouvelle requête qui arrive pendant qu'une autre est générée est immédiatement ajoutée au batch courant, sans attendre la fin. Ollama traite les requêtes séquentiellement (ou en parallèle limité avec OLLAMA_NUM_PARALLEL=4), ce qui plafonne le débit total rapidement.

Latence Time-To-First-Token (TTFT)

3. Setup Ollama : Installation Complète et Configuration

Installation (Linux/Mac/Windows)

# Linux (Ubuntu 22.04+)
curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl enable ollama
sudo systemctl start ollama

# Mac (Homebrew)
brew install ollama
brew services start ollama

# Windows : télécharger l'installeur sur ollama.com/download

Commandes Essentielles

# Télécharger des modèles
ollama pull mistral:7b-instruct-q4_K_M  # ~4.1 GB
ollama pull qwen2.5:7b-instruct          # ~4.7 GB
ollama pull phi4:latest                  # ~9.1 GB

# Lister les modèles installés
ollama list

# Supprimer un modèle
ollama rm mistral:7b-instruct-q4_K_M

# Lancer le serveur (exposé sur le réseau local)
OLLAMA_HOST=0.0.0.0:11434 ollama serve

Configuration Avancée pour la Performance

# Variables d'environnement clés (à définir avant de lancer ollama serve)
export OLLAMA_NUM_PARALLEL=4        # 4 requêtes en parallèle (recommandé RTX 4090)
export OLLAMA_MAX_LOADED_MODELS=2   # Garde 2 modèles en VRAM simultanément
export OLLAMA_KEEP_ALIVE=5m         # Garde le modèle en VRAM 5min après la dernière req
export OLLAMA_FLASH_ATTENTION=1     # Active Flash Attention 2 (perf +15%)

# Exemple de Modelfile personnalisé (system prompt + paramètres)
FROM mistral:7b-instruct-q4_K_M
SYSTEM "Tu es un assistant commercial expert en B2B pour Geniuspace. Tu réponds toujours en français, de façon concise et professionnelle."
PARAMETER temperature 0.3
PARAMETER num_ctx 8192

ollama create geniuspace-commercial -f ./Modelfile
ollama run geniuspace-commercial

Intégration Python (Compatible OpenAI SDK)

from openai import OpenAI

# Ollama expose une API 100% compatible OpenAI
client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # Requis syntaxiquement, valeur ignorée
)

response = client.chat.completions.create(
    model="geniuspace-commercial",
    messages=[
        {"role": "system", "content": "Tu es un assistant commercial B2B."},
        {"role": "user", "content": "Rédige un email de relance pour un prospect qui n'a pas répondu depuis 2 semaines."}
    ],
    temperature=0.3,
    max_tokens=500
)

print(response.choices[0].message.content)

4. Setup vLLM : Déploiement Production Avancé

Installation et Premier Lancement

# Prérequis : Python 3.9+, CUDA 12.1+, GPU Nvidia
pip install vllm

# Lancer le serveur vLLM (API OpenAI-compatible sur port 8000)
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.3 \
    --dtype float16 \
    --max-model-len 8192 \
    --max-num-seqs 64 \
    --port 8000 \
    --host 0.0.0.0

# Avec quantification AWQ (économise VRAM, -5% qualité vs FP16)
python -m vllm.entrypoints.openai.api_server \
    --model TheBloke/Mistral-7B-Instruct-v0.3-AWQ \
    --quantization awq \
    --dtype auto \
    --port 8000

Configuration Docker pour la Production

# docker-compose.yml pour vLLM en production
version: "3.8"
services:
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - NVIDIA_VISIBLE_DEVICES=0
      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
    command:
      - --model=mistralai/Mistral-7B-Instruct-v0.3
      - --dtype=float16
      - --max-model-len=8192
      - --max-num-seqs=64
      - --port=8000
    ports:
      - "8000:8000"
    volumes:
      - ./models:/root/.cache/huggingface
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

5. Quantification : GGUF vs AWQ vs GPTQ

La quantification réduit la taille des poids du modèle en diminuant la précision numérique. En 2026, trois formats dominent selon l'outil de serving :

Règle de choix : utilisez GGUF Q4_K_M avec Ollama (qualité-vitesse optimale, le plus simple à déployer). Utilisez AWQ avec vLLM en production (même ratio qualité/VRAM que GGUF, mais compatible avec les optimisations CUDA de vLLM). N'utilisez FP16 que pour le fine-tuning ou si vous avez assez de VRAM et exigez la qualité maximale.

6. Quand Choisir Ollama, Quand Choisir vLLM

7. Sécurité et Confidentialité : L'Argument Décisif

Le déploiement LLM local supprime structurellement les risques liés à la transmission de données à des tiers. Mais il crée de nouveaux risques : un serveur Ollama ou vLLM exposé sans authentification sur votre réseau interne est accessible à tout utilisateur du réseau — et potentiellement à l'extérieur si le pare-feu est mal configuré.

Sécurisation du Serveur Ollama

# JAMAIS exposer Ollama directement sur 0.0.0.0 sans protection
# Configuration recommandée : Nginx reverse proxy avec authentification basique

# /etc/nginx/sites-available/ollama-api
server {
    listen 443 ssl;
    server_name llm-api.votre-entreprise.fr;

    ssl_certificate /etc/letsencrypt/live/llm-api.votre-entreprise.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/llm-api.votre-entreprise.fr/privkey.pem;

    # Authentification basique (ou remplacer par OAuth2)
    auth_basic "Geniuspace LLM API";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        # Limiter la taille des requêtes (anti-DoS)
        client_max_body_size 10m;
        limit_req zone=api_limit burst=20 nodelay;
    }
}

# Rate limiting dans le bloc http
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=30r/m;

8. 10 Erreurs Classiques à Éviter

1. Exposer Ollama sur 0.0.0.0 sans authentification — Votre serveur LLM devient accessible à tous sur votre réseau. Utilisez toujours un reverse proxy avec auth.
2. Oublier OLLAMA_KEEP_ALIVE — Par défaut, Ollama décharge le modèle de VRAM après 5 minutes d'inactivité. Chaque rechargement prend 10-30 secondes. Augmentez si votre usage est continu.
3. Lancer vLLM sans --max-model-len — vLLM réserve le KV-cache pour la longueur maximale de contexte du modèle (souvent 32 768 ou 128 000 tokens). Sans limite, il peut épuiser votre VRAM dès le démarrage.
4. Confondre tokens Ollama et tokens OpenAI — Les comptages de tokens diffèrent légèrement selon les tokenizers. Ne transposez pas directement les estimations de coût d'une API cloud.
5. Ne pas monitorer la température GPU — Un GPU qui throttle (80°C+) génère 20-40% moins de tokens/s. Installez nvitop ou nvidia-smi dmon pour surveiller en continu.
6. Utiliser GPTQ avec Ollama — Ollama ne supporte que le format GGUF. GPTQ est pour vLLM et AutoGPTQ uniquement.
7. Ne pas configurer num_ctx adapté — Un num_ctx trop petit tronque le contexte (réponses incohérentes sur les longues conversations). Trop grand épuise la VRAM. Calibrez sur votre use case réel.
8. Oublier le swap NVMe — Si votre modèle déborde de VRAM vers la RAM système, la performance chute de 95 %. Mieux vaut descendre d'une taille de modèle ou augmenter la quantification.
9. Mettre à jour vLLM en production sans test — vLLM est en développement actif. Les mises à jour changent parfois les paramètres de configuration. Testez toujours dans un environnement de staging.
10. Négliger les logs d'erreur — Les deux outils génèrent des warnings silencieux importants (VRAM à 90%, requêtes rejetées, batch timeout). Centralisez les logs dans un outil comme Grafana Loki.

9. Monitoring en Production : Métriques et Alertes

Métriques Essentielles à Surveiller

Guillaume Deplanque — Expert IA & Commerce B2B International

15 ans d'expérience en vente B2B, export Chine-Japon-Europe et intégration IA. Fondateur de Geniuspace, basé à Arras (62000). Profil auteur · LinkedIn · contact@geniuspace.io · 06 30 76 62 76