De Ollama à vLLM : quand migrer votre serveur LLM local

Ollama est l’une des méthodes les plus simples pour exécuter un modèle de langage local, mais la praticité peut masquer l’instant où une expérience locale se transforme en service d’inférence partagé nécessitant une planification et une observabilité plus rigoureuses.

C’est là que vLLM prend son importance. Migrer d’Ollama vers vLLM n’est pas une mise à niveau automatique. C’est un échange : vous troquez une partie de la simplicité d’Ollama contre un meilleur contrôle sur le lot de requêtes (batching), la gestion de la mémoire, la concurrence, l’inférence distribuée et les opérations en production.

Ce guide aborde les signaux pratiques indiquant que la migration est justifiée, les risques d’une migration trop précoce, et une approche progressive qui permet de maintenir les deux serveurs fonctionnant côte à côte pendant la validation. L’objectif est de vous aider à décider sur la base de mesures plutôt que de listes de fonctionnalités. Pour une vue d’ensemble plus large des options locales, auto-hébergées et cloud, au-delà de ces deux seuls runtime, voir L’hébergement de LLM en 2026 : comparaison des infrastructures locales, auto-hébergées et cloud.

Ollama et vLLM résolvent des problèmes différents

Ollama est principalement optimisé pour une consommation de modèles pratique. Il offre aux développeurs une interface en ligne de commande concise, une API locale, une bibliothèque de modèles, des Modelfiles et un support simple pour les configurations courantes de postes de travail et de bureaux.

vLLM est un moteur d’inférence et une plateforme de service (serving). Ses préoccupations centrales sont la planification des requêtes à haut débit, la gestion efficace de la cache KV (clé-valeur), le lot de requêtes continu (continuous batching), le parallélisme des modèles et la compatibilité avec les applications conçues pour les API de type OpenAI.

La distinction est importante car les deux serveurs peuvent paraître similaires en apparence. Tous deux peuvent exposer une API de chat, diffuser des jetons, exécuter des modèles quantifiés et servir des applications locales. Leurs modèles opérationnels ne deviennent visiblement différents que lorsque le serveur est soumis à une charge soutenue ou concurrente.

Un récapitulatif utile :

La question n’est pas de savoir quel serveur est universellement meilleur. Il s’agit de savoir si votre charge de travail correspond encore au modèle opérationnel qui rend Ollama attractif. Si vous souhaitez une vision plus complète couvrant plus que ces deux runtime, notre comparaison d’Ollama, vLLM, LocalAI, Jan, LM Studio et autres outils LLM locaux couvre le terrain plus large.

Signes que vous avez dépassé les capacités d’Ollama

Une réponse lente ne justifie, à elle seule, pas une migration. La vitesse de génération est souvent limitée par la taille du modèle, la quantification, la bande passante mémoire, la longueur du prompt ou la capacité du GPU plutôt que par le moteur de service, et les signaux de migration plus forts n’apparaissent que lorsque la forme de la charge de travail elle-même commence à compter.

Plusieurs utilisateurs provoquent une latence instable

Un serveur LLM local peut sembler rapide lors d’un test isolé, puis se dégrader fortement lorsque plusieurs clients se connectent. Les requêtes commencent à attendre derrière de longues générations, le temps jusqu’au premier jeton devient inconstant, et un simple prompt volumineux peut affecter tout le monde partageant le modèle.

Ollama peut traiter des requêtes parallèles, et OLLAMA_NUM_PARALLEL contrôle combien de requêtes un modèle chargé peut traiter simultanément — voir comment Ollama gère les requêtes parallèles pour la mécanique de file d’attente et de mémoire derrière ce paramètre. Ce parallélisme n’est pas gratuit : les exigences en mémoire augmentent avec à la fois le nombre de requêtes parallèles configuré et la longueur du contexte.

C’est souvent le premier avertissement pratique. Une configuration qui fonctionne pour une conversation de 8K peut devenir impossible lorsque quatre clients réservent chacun un contexte beaucoup plus grand.

vLLM est conçu pour combiner le travail des requêtes actives par le lot de requêtes continu (continuous batching). Au lieu de traiter chaque requête comme un job d’inférence isolé, il met à jour en continu le lot à mesure que les séquences arrivent, génèrent des jetons et se terminent — un modèle de planification qui devient généralement plus précieux lorsque la concurrence augmente.

Faible utilisation du GPU alors que les requêtes sont en file d’attente

Une file d’attente ne signifie pas nécessairement que le GPU est pleinement utilisé. Dans une configuration de service simple, le travail peut être sérialisé alors que des requêtes supplémentaires auraient pu contribuer à un calcul utile à l’étape de décodage actuelle.

Le planificateur de vLLM est conçu pour maintenir plus de travail utile en cours. PagedAttention gère la mémoire de la cache KV par blocs, tandis que le lot de requêtes continu permet aux séquences actives d’entrer et de sortir dynamiquement du lot d’exécution.

Le résultat n’est pas garanti en termes de latence réduite pour chaque requête individuelle. Sous charge, cependant, il peut produire un débit global nettement meilleur et une utilisation des ressources plus prévisible.

Les prompts longs dominent le temps jusqu’au premier jeton

Les assistants de codage à long contexte, les pipelines RAG et les sessions d’agents peuvent envoyer à plusieurs reprises de longs prompts système ou des préfixes de documents partagés. Le traitement de ces jetons d’entrée est l’étape de préremplissage (prefill), et elle peut dominer le temps jusqu’au premier jeton.

vLLM prend en charge le préremplissage par morceaux (chunked prefill) et le cache préfixe automatique. Le cache préfixe permet aux requêtes ultérieures de réutiliser les blocs de cache KV lorsque leur séquence initiale de jetons correspond à un préfixe déjà traité.

Cela est particulièrement utile lorsque les requèces partagent :

• Un long prompt système
• Les mêmes définitions d’outils
• Un résumé stable du référentiel
• Des exemples few-shot répétés
• Un préfixe de document RAG commun
• Un historique de conversation partagé

Le cache préfixe ne rend pas la génération de sortie plus rapide. Il réduit le calcul des prompts répétés, donc son bénéfice dépend du fait que les requêtes contiennent réellement des préfixes identiques et réutilisables.

Vous avez besoin de plus d’un GPU

Un modèle qui ne tient pas sur un seul GPU est une raison forte de considérer vLLM. Il prend en charge le parallélisme de tenseurs entre les GPU et le parallélisme de pipeline entre plusieurs nœuds ou périphériques.

Cela ne rend pas l’inférence multi-GPU effortless. La bande passante de l’interconnexion GPU, la topologie PCIe, l’architecture du modèle, la mémoire partagée du conteneur et le surcoût de communication affectent toujours les performances.

Néanmoins, vLLM fournit un chemin délibéré pour l’inférence distribuée. Ollama est généralement un meilleur choix pour un seul bureau ou poste de travail où le modèle choisi tient déjà confortablement.

Vous avez besoin d’une observabilité de niveau production

Les réponses API d’Ollama exposent des champs de chronométrage utiles tels que la durée de chargement du modèle, la durée d’évaluation du prompt, le nombre de jetons générés et la durée de génération. Ces valeurs suffisent pour le benchmarking local et la journalisation au niveau de l’application.

vLLM expose des métriques compatibles Prometheus via son point d’accès /metrics. Cela facilite le suivi du volume de requêtes, de la file d’attente, du temps jusqu’au premier jeton, de la latence inter-jetons, de l’utilisation de la cache, des préemptions, du débit et des résultats des requêtes au fil du temps.

Dès que les utilisateurs dépendent du service, l’observabilité n’est plus optionnelle. Sans métriques de file d’attente, de cache et de latence, il est difficile de distinguer un GPU sous-dimensionné d’une limite de contexte surdimensionnée, d’une mauvaise planification, d’un chargement à froid du modèle ou simplement de trop de requêtes simultanées.

Où vLLM gagne réellement

L’avantage le plus important de vLLM n’est pas qu’il puisse produire une réponse plus rapide qu’Ollama sur chaque machine. L’avantage significatif est qu’il donne à l’opérateur davantage de mécanismes pour utiliser efficacement la mémoire et le calcul des accélérateurs coûteux sur de nombreuses requêtes.

Lot de requêtes continu (Continuous Batching)

Le lot de requêtes statique traditionnel fonctionne le mieux lorsque les requêtes ont des longueurs d’entrée et de sortie similaires. Le trafic LLM interactif ne se comporte rarement ainsi : un utilisateur demande une courte classification, un autre soumet un prompt de 20K jetons, et un troisième génère plusieurs milliers de jetons de code.

Le lot de requêtes continu modifie le lot actif à mesure que les requêtes progressent. Les séquences terminées partent, de nouvelles entrées entrent, et le moteur tente d’éviter de gaspiller la capacité du lot sur des requêtes déjà terminées.

Cela améliore le débit lorsque le trafic est concurrent et inégal. Il apporte peu de bénéfice lorsque un seul utilisateur envoie une requête à la fois.

Gestion de la cache KV paginée (Paged KV Cache)

Lors de la génération, le serveur stocke les clés et les valeurs d’attention pour les jetons précédemment traités. Cette cache KV peut consommer une grande quantité de mémoire GPU, en particulier avec de longs contextes et plusieurs séquences actives.

vLLM gère cette cache par blocs au lieu d’exiger que chaque séquence réserve une seule grande allocation continue. Cette approche réduit la fragmentation de la mémoire et permet d’utiliser la capacité de cache disponible de manière plus flexible.

La valeur pratique est une concurrence plus élevée dans le même budget mémoire. Cela ne supprime pas le coût sous-jacent d’un long contexte, mais réduit le gaspillage évitable autour de ce coût. Pour l’arithmétique derrière ce coût sous-jacent — combien de octets une longueur de contexte donnée a réellement besoin, et comment la précision de la cache (FP8, Q8_0, Q4_0) fait le poids par rapport à cela sur une carte de 16 Go — voir La cache KV sur les GPU de 16 Go.

Cache préfixe (Prefix Caching)

De nombreuses requêtes de production partagent un début substantiel. Les agents dotés d’outils peuvent envoyer des schémas de fonctions identiques, les robots d’assistance peuvent utiliser les mêmes documents de politique, et les assistants de codage peuvent inclure à plusieurs reprises les mêmes instructions de référentiel.

Le cache préfixe automatique peut réutiliser la cache calculée pour les préfixes correspondants. Il est particulièrement utile lorsqu’un préfixe stable et volumineux est suivi d’un suffixe spécifique à la requête relativement petit.

Il est moins utile lorsque les modèles, horodatages, ordre des documents ou métadonnées générées dynamiquement changent près du début de chaque prompt. De petites différences dans la tokenisation peuvent empêcher la correspondance du préfixe.

Inférence parallèle et distribuée

vLLM prend en charge plusieurs formes de parallélisme, y compris le parallélisme de tenseurs, de pipeline, de données, d’experts et de contexte. Tous les déploiements n’ont pas besoin de ces modes, mais leur disponibilité compte lorsque le service dépasse un seul GPU.

Pour un poste de travail avec deux GPU appropriés, le parallélisme de tenseurs peut permettre à un modèle plus grand de fonctionner sur les deux périphériques. Pour un service répliqué, le parallélisme de données peut créer plusieurs répliques du moteur pour un débit supplémentaire.

Ces fonctionnalités introduisent une complexité opérationnelle. Elles doivent être adoptées parce que les mesures démontrent un problème de capacité, et non parce que l’inférence distribuée semble plus sophistiquée.

Contrôles de production plus étendus

vLLM expose des contrôles pour l’utilisation de la mémoire GPU, la longueur maximale du modèle, les séquences actives maximales, la quantification, les types de données de cache, décodage spéculatif, l’appel d’outils, la sortie structurée, les alias de modèle, les clés d’authentification et l’exécution distribuée.

Cette flexibilité rend le serveur plus facile à régler pour une charge de travail particulière, mais elle crée également plus d’opportunités pour une configuration invalide ou inefficace. Migrer vers vLLM signifie assumer la responsabilité de ces décisions.

Où Ollama gagne encore

Un guide de migration ne devrait pas traiter Ollama comme un outil préliminaire inférieur. Pour de nombreux déploiements locaux, il reste le meilleur serveur.

Postes de travail personnels

Pour un développeur utilisant une interface de chat, un assistant de code ou une API locale occasionnelle, les avantages opérationnels de vLLM ne compenseront peut-être jamais sa configuration supplémentaire.

Ollama s’installe rapidement, télécharge les modèles via un registre simple et masque de nombreux détails spécifiques au modèle. Il est bien adapté à l’expérimentation et à l’usage privé sur bureau.

Collections de modèles GGUF

Ollama a un workflow naturel autour des modèles GGUF et des Modelfiles. Les utilisateurs existants peuvent avoir des quantifications sélectionnées, des adaptateurs, des modèles, des prompts système et des paramètres qui fonctionnent de manière fiable avec leur matériel.

vLLM prend en charge GGUF, mais son chemin le plus robuste passe généralement par des dépôts de modèles Hugging Face pris en charge et des formats de quantification tels que AWQ, GPTQ, BitsAndBytes, FP8, ou des formats spécifiques aux fournisseurs. Déplacer un déploiement GGUF existant vers vLLM sans évaluer un format de point de contrôle plus natif peut préserver les inconvénients de la migration tout en manquant certains des avantages en termes de performance.

Déchargement mixte CPU et GPU

L’inférence sur bureau repose parfois sur un déchargement partiel sur GPU car le modèle entier ne tient pas dans la VRAM. Cela peut être pratique pour un usage occasionnel, en particulier lorsque la latence n’est pas critique.

vLLM est généralement le plus convaincant lorsque le modèle et la capacité de cache KV requise peuvent être servis efficacement par la configuration de l’accélérateur disponible. Une charge de travail qui dépend fortement de la mémoire système et du déchargement CPU est peut-être mieux adaptée à Ollama ou llama.cpp.

Basculement rapide de modèles

Ollama permet de tirer, exécuter, arrêter et basculer facilement entre de nombreux modèles locaux. C’est utile pour l’évaluation, la rédaction, le codage, les embeddings, la vision et l’expérimentation ponctuelle.

Un déploiement vLLM est plus couramment construit autour d’un modèle délibérément sélectionné qui reste chargé en tant que service. Le déploiement multi-modèles est possible, mais il nécessite une planification des ressources plus explicite.

Administration minimale

Ollama est intentionnellement dogmatique (opinionated). Cela peut être une limitation sous charge, mais c’est un avantage lorsque personne ne veut maintenir une plateforme d’inférence, et si le serveur local a un seul utilisateur, une latence acceptable et pas de file d’attente significative, la migration est susceptible de créer du travail plutôt que d’en supprimer.

Ne migrez pas sur la seule base des jetons par seconde

La vitesse de génération de jetons pour une seule requête est un benchmark incomplet. Deux serveurs peuvent produire un débit de décodage similaire pour une séquence tout en se comportant très différemment avec huit clients concurrents.

Une évaluation utile devrait mesurer au moins :

• Temps jusqu’au premier jeton
• Latence inter-jetons
• Latence de requête de bout en bout
• Débit de traitement du prompt
• Débit de jetons de sortie
• Requêtes terminées par minute
• Temps d’attente dans la file
• Consommation de la mémoire GPU
• Utilisation du GPU
• Taux d’échec et de délai

Exécutez la même famille de modèles, la précision, la longueur de contexte, l’ensemble de prompts, la limite de sortie et le niveau de concurrence sur les deux serveurs. Sinon, le test est plus susceptible de comparer l’emballage du modèle et la configuration que les moteurs de service.

La comparaison la plus utile est un petit test de charge qui représente votre trafic réel. Pour un assistant de codage partagé, cela pourrait inclure des prompts système longs, des préfixes répétés, des réponses en streaming et de deux à huit sessions simultanées.

Planifiez d’abord la migration du modèle

Les noms de modèles Ollama ne correspondent pas automatiquement aux identifiants de modèles vLLM équivalents. Un paquet Ollama peut contenir une quantification GGUF particulière, un modèle de prompt, une configuration de jeton d’arrêt et des paramètres par défaut.

Avant de changer de serveur, identifiez :

1. La famille et la version du modèle d’origine
2. S’il s’agit d’un modèle de base ou d’un modèle ajusté par instruction
3. La quantification actuelle et la précision effective
4. Le modèle de prompt ou de chat
5. La longueur de contexte configurée
6. Les jetons d’arrêt et les paramètres de génération par défaut
7. Les exigences d’appel d’outils ou de sortie structurée
8. Les adaptateurs LoRA ou prompts système personnalisés

Puis choisissez un point de contrôle pris en charge par vLLM qui correspond au comportement prévu. N’assumez pas qu’un point de contrôle AWQ ou FP8 se comportera identiquement au build GGUF utilisé précédemment dans Ollama — la migration du modèle est souvent plus significative que la migration de l’API.

Vérifiez la VRAM avant de démarrer vLLM

Un modèle qui tient dans la mémoire GPU ne signifie pas qu’il peut servir la charge de travail requise. La VRAM doit couvrir plus que les poids du modèle.

Le budget mémoire pratique comprend :

poids du modèle
+ cache KV
+ graphes CUDA et allocations d'exécution
+ espace de travail temporaire
+ caches de processeur multimodal, si utilisé
+ marge de sécurité

Les contextes longs et les séquences concurrentes élargissent principalement l’exigence de cache KV. Augmenter la longueur de contexte maximale réduit donc le nombre de requêtes simultanées qui peuvent tenir, même si la plupart des requêtes n’utilisent jamais la limite complète.

Commencez avec une valeur réaliste pour --max-model-len plutôt que la plus grande valeur annoncée par le modèle, et évitez de régler l’utilisation de la mémoire GPU de manière trop agressive au point que de légères variations de charge provoquent des échecs de mémoire insuffisante. Un service stable avec une capacité théorique légèrement moindre est plus utile qu’un service qui échoue à son premier pic de trafic.

Un déploiement minimal vLLM avec Docker Compose

L’exemple suivant démarre un serveur vLLM compatible OpenAI sur le port 8000 :

services:
  vllm:
    image: vllm/vllm-openai:latest
    container_name: vllm
    restart: unless-stopped
    ports:
      - "8000:8000"
    ipc: host
    gpus: all
    volumes:
      - ${HOME}/.cache/huggingface:/root/.cache/huggingface
    environment:
      HF_TOKEN: ${HF_TOKEN:-}
    command:
      - --model
      - Qwen/Qwen3-8B
      - --served-model-name
      - local-model
      - --max-model-len
      - "16384"
      - --gpu-memory-utilization
      - "0.90"
      - --api-key
      - ${VLLM_API_KEY:-change-me}

Créez un fichier d’environnement :

cat > .env <<'EOF'
HF_TOKEN=
VLLM_API_KEY=remplacez-par-une-valeur-aleatoire-longue
EOF

Démarrez le serveur :

docker compose up -d

Vérifiez les journaux :

docker compose logs -f vllm

Testez le point d’accès des modèles :

curl http://localhost:8000/v1/models \
  -H "Authorization: Bearer remplacez-par-une-valeur-aleatoire-longue"

Envoyez une requête de chat :

curl http://localhost:8000/v1/chat/completions \
  -H "Authorization: Bearer remplacez-par-une-valeur-aleatoire-longue" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-model",
    "messages": [
      {
        "role": "user",
        "content": "Expliquez le lot de requêtes continu en deux paragraphes."
      }
    ],
    "temperature": 0.2,
    "max_tokens": 300,
    "stream": false
  }'

Pour un déploiement maintenu, fixez l’image à une version testée de vLLM au lieu de la laisser sur latest. Consultez les notes de version avant la mise à niveau car les options en ligne de commande, les implémentations de modèles, les métriques et le comportement du moteur peuvent évoluer. Ce fichier Compose est intentionnellement minimal ; pour le guide de configuration plus complet — compatibilité API OpenAI, réglage de PagedAttention, et une comparaison plus approfondie de vLLM par rapport à Ollama — voir le Démarrage rapide vLLM.

La compatibilité de l’API OpenAI n’est pas une interchangeabilité complète

Ollama et vLLM fournissent tous deux des points d’accès compatibles OpenAI, ce qui peut rendre la migration de l’application relativement faible. Dans de nombreux clients, changer l’URL de base, la clé API et le nom du modèle suffit à établir une connexion.

Par exemple :

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="remplacez-par-une-valeur-aleatoire-longue",
)

response = client.chat.completions.create(
    model="local-model",
    messages=[
        {
            "role": "user",
            "content": "Que devrais-je surveiller sur un serveur LLM ?",
        }
    ],
    temperature=0.2,
)

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

La compatibilité devrait toujours être testée au niveau des fonctionnalités. Examinez :

• Comportement des événements en streaming
• Paramètres de requête pris en charge
• Sélection du modèle de chat
• Analyse des appels d’outils
• Gestion de la sortie de raisonnement
• Sortie contrainte par JSON ou schéma
• Points d’accès pour les embeddings
• Entrées multimodales
• Rapport d’utilisation des jetons
• Formats de réponse d’erreur
• Découverte du nom du modèle
• Application de la longueur de contexte

Un client qui n’envoie que des complétions de chat ordinaires sera généralement plus facile à migrer qu’un cadre d’agent qui dépend d’un analyseur d’appels d’outils particulier ou d’une extension non standard.

Les modèles de chat sont une cause fréquente d’échec de migration

Les modèles ajustés par instruction s’attendent à ce que les conversations soient sérialisées en utilisant un modèle de chat spécifique. Le modèle insère des marqueurs de rôle, des séparateurs, des jetons de contrôle et des prompts de génération dans le format utilisé pendant l’entraînement.

Ollama empaquette une grande partie de ce comportement dans sa définition de modèle. Avec vLLM, le modèle est normalement obtenu de la configuration du tokeniseur du modèle, bien qu’un opérateur puisse en fournir un explicitement.

Un serveur peut démarrer avec succès même lorsque le modèle sélectionné est incorrect. Les symptômes apparaissent dans le comportement du modèle :

• Le modèle répète les étiquettes de rôle
• Les réponses contiennent des jetons spéciaux
• Les instructions système sont ignorées
• Les appels d’outils sont malformés
• Le modèle continue le message de l’utilisateur
• La qualité de la sortie est beaucoup plus mauvaise que prévu

Avant de blâmer le moteur d’inférence, comparez le prompt entièrement rendu utilisé par chaque déploiement.

Utilisez une migration progressive

Remplacer un serveur local fonctionnel en une seule étape crée un risque inutile. Ollama et vLLM peuvent fonctionner côte à côte sur des ports différents pendant que vous validez le nouveau déploiement.

Étape 1 : Reproduire un modèle

Choisissez le modèle responsable de la plupart du trafic API et faites correspondre son ajustement par instruction, son exigence de contexte, ses paramètres de génération et son comportement de chat aussi étroitement que possible. Ne commencez pas par déplacer tous les modèles expérimentaux.

Étape 2 : Valider le comportement de l’API

Exécutez les tests d’intégration existants contre le point d’accès vLLM, y compris le streaming, l’annulation, les délais d’attente, les appels d’outils, les requêtes malformées, le débordement de contexte et l’accès concurrent. Enregistrez les différences comportementales plutôt que de les masquer derrière des reprises de client.

Étape 3 : Établir une ligne de base

Mesurez d’abord les performances d’une seule requête. Cela confirme que le modèle est chargé correctement et fournit une référence pour les tests ultérieurs.

Enregistrez les jetons de prompt par seconde, les jetons de sortie par seconde, le temps jusqu’au premier jeton, la latence totale et l’utilisation de la mémoire GPU.

Étape 4 : Ajouter une concurrence réaliste

Testez le nombre de requêtes simultanées attendu en fonctionnement normal et pendant un pic plausible, en utilisant des longueurs de prompt et de sortie représentatives plutôt que des requêtes synthétiques identiques. Surveillez la file d’attente, l’utilisation de la cache, les préemptions, le temps jusqu’au premier jeton et la latence de la queue (tail latency).

Étape 5 : Déplacer un client

Aiguillez une application non critique ou un petit pourcentage du trafic vers vLLM. Conservez Ollama disponible en guise de repli jusqu’à ce que le nouveau serveur ait fonctionné de manière fiable sous usage réel.

Étape 6 : Réglage à partir des mesures

Ajustez la longueur du modèle, l’utilisation de la mémoire, les séquences actives maximales, le cache préfixe, le parallélisme et la quantification seulement après avoir identifié une contrainte mesurée. Modifier plusieurs paramètres à la fois rend les régressions de performance difficiles à expliquer.

Une liste de vérification pratique de migration

Avant de basculer les clients, vérifiez les éléments suivants :

[ ] Le modèle cible est pris en charge par vLLM
[ ] Le point de contrôle et la quantification sélectionnés tiennent dans la VRAM
[ ] Sufficient VRAM remains for the required KV cache
[ ] La longueur de contexte maximale reflète l'usage réel
[ ] Le modèle de chat correct est disponible
[ ] Les jetons d'arrêt et les paramètres de génération par défaut sont testés
[ ] Le streaming fonctionne avec les clients existants
[ ] Les appels d'outils et la sortie structurée sont validés
[ ] L'alias public du modèle reste stable
[ ] L'authentification est activée
[ ] Le serveur n'est pas exposé directement à internet
[ ] Les métriques Prometheus sont collectées
[ ] Les métriques GPU sont collectées séparément
[ ] Les tests de charge incluent une concurrence réaliste
[ ] Les délais et les annulations sont gérés
[ ] Un chemin de repli vers Ollama existe

Cette liste est intentionnellement opérationnelle. Installer vLLM est généralement plus facile que de prouver qu’il se comporte correctement pour une application existante.

Sécurité et exposition réseau

Ni un point d’accès local Ollama ni un point d’accès vLLM ne devraient être exposés à la légère à l’internet public. Un serveur d’inférence non authentifié peut consommer une capacité GPU coûteuse, révéler le comportement du modèle et devenir une voie d’attaques par déni de service via des prompts ou des sorties très longs.

vLLM peut exiger une clé API pour ses points d’accès compatibles OpenAI, mais une clé API n’est pas une frontière de sécurité complète. Pour un accès partagé ou distant, placez le service derrière un proxy inverse ou une passerelle API qui fournit TLS, des restrictions de réseau, des limites de taille de requête, des limites de débit, la journalisation des accès et une authentification appropriée — le même modèle couvert dans Ollama derrière un proxy inverse avec Caddy ou Nginx s’applique tout aussi bien devant vLLM.

Envisagez également les risques spécifiques au modèle. Le chargement d’URL multimodales, le code de modèle personnalisé, les fichiers distants et l’exécution d’outils sans restriction peuvent étendre la surface d’attaque au-delà de la génération de texte ordinaire.

Quand ne pas migrer

Restez avec Ollama lorsque :

• Un ou deux utilisateurs accèdent au serveur
• Les requêtes sont principalement séquentielles
• Le modèle fournit déjà une latence acceptable
• La gestion facile des GGUF est importante
• Le déchargement CPU ou GPU partiel est requis
• Les modèles changent fréquemment
• Personne ne veut exploiter une infrastructure supplémentaire
• Il n’y a pas de problème mesuré de concurrence ou de débit

Un passage à vLLM devrait résoudre une limitation concrète. « Production » n’est pas un seuil magique qui invalide Ollama, en particulier pour un service interne avec un trafic modeste.

Inversement, ne conservez pas Ollama simplement parce qu’il était plus facile à installer. Si les utilisateurs attendent régulièrement dans une file d’attente, que des préfixes répétés consomment un temps de préremplissage important, ou qu’un plus grand modèle doit être distribué entre les GPU, le serveur plus simple peut être devenu le choix le plus coûteux sur le plan opérationnel.

Conservez Ollama pour le développement et ajoutez vLLM pour le service partagé

L’architecture la plus pratique est souvent un remplacement complet. Les développeurs peuvent conserver Ollama fonctionnant dans Docker Compose sur leurs postes de travail pour l’exploration de modèles, les tests GGUF et l’usage interactif privé, tandis qu’une instance vLLM partagée sert un modèle stable aux applications et aux équipes. Cette séparation est également importante pour la souveraineté de l’IA — en conservant les deux runtime auto-hébergés, les prompts, les poids et les journaux d’inférence restent sous votre contrôle, quel que soit le serveur qui traite une requête donnée.

Cela sépare deux flux de travail différents :

Ollama :
expérimentation -> changement de modèle -> outils personnels -> chat local

vLLM :
modèle sélectionné -> point d'accès partagé -> trafic concurrent -> surveillance

Cette disposition réduit également le risque de migration. Les modèles peuvent être testés localement avant qu’un point de contrôle approprié ne soit promu au déploiement vLLM partagé.

Flux de décision de migration

Le diagramme suivant résume les points de décision clés :

Conclusion

Ollama est difficile à battre en tant qu’exécuteur de modèles local. Il élimine suffisamment de travail d’emballage et de configuration pour que les développeurs puissent se concentrer sur le modèle et l’application plutôt que sur la pile d’inférence.

vLLM devient le choix plus robuste lorsque le serveur lui-même est le problème à ingénier. Le trafic concurrent, la file d’attente, les longs préfixes répétés, les modèles multi-GPU, la planification de la capacité et l’observabilité de production sont les signaux de migration qui comptent.

Ne migrez pas parce que vLLM a une liste de fonctionnalités plus longue. Migratez lorsque les mesures montrent que le modèle opérationnel plus simple d’Ollama ne correspond plus à la charge de travail. Jusqu’à ce point, la simplicité n’est pas une faiblesse technique ; c’est une optimisation.