De Ollama à vLLM : quand migrer votre serveur LLM local

Ollama est l’un des moyens les plus simples pour exécuter un modèle de langage localement, mais cette commodité peut masquer le moment où une expérimentation locale devient un service d’inférence partagé nécessitant une meilleure planification et une meilleure observabilité.

C’est là que vLLM devient pertinent. La migration d’Ollama vers vLLM n’est pas une mise à niveau automatique. C’est un compromis : vous échangez une partie de la simplicité d’Ollama contre un contrôle accru sur le regroupement (batching), la gestion de la mémoire, la concurrence, l’inférence distribuée et les opérations en production.

Ce guide couvre les signaux pratiques qui indiquent qu’une migration est justifiée, les risques d’une migration trop précoce, et une approche par étapes qui permet de faire fonctionner les deux serveurs 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 moteurs d’exécution, consultez Hébergement de LLM en 2026 : Infrastructure Locale, Auto-Hébergée et Cloud Comparée.

Ollama et vLLM Résolvent des Problèmes Différents

Ollama est principalement optimisé pour la 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 straightforward pour les configurations de bureau et de station de travail courantes.

vLLM est un moteur d’inférence et une plateforme de service. Ses préoccupations centrales sont la planification des requêtes à haut débit, la gestion efficace du cache KV, le regroupement continu (continuous batching), le parallélisme des modèles et la compatibilité avec les applications construites pour des API de style OpenAI.

La distinction est importante car les deux serveurs peuvent sembler similaires de l’extérieur. Les deux peuvent exposer une API de chat, diffuser des tokens, 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ésumé utile :

La question n’est pas quel serveur est universellement meilleur. Il s’agit de savoir si votre charge de travail correspond toujours au modèle opérationnel qui rend Ollama attrayant. Si vous souhaitez une vue d’ensemble plus complète couvrant plus de deux moteurs d’exécution, notre comparaison d’Ollama, vLLM, LocalAI, Jan, LM Studio et d’autres outils LLM locaux couvre le champ plus large.

Signes Que Vous Avez Dépassé Ollama

Une réponse lente ne justifie pas, à elle seule, 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 les capacités du GPU plutôt que par le moteur de service, et les signaux de migration les plus forts n’apparaissent que lorsque la forme de la charge de travail commence à avoir de l’importance.

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 token devient inconstant, et un seul 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 gérer simultanément — voir comment Ollama gère les requêtes parallèles pour la file d’attente et la mécanique mémoire derrière ce paramètre. Ce parallélisme n’est pas gratuit : les exigences en mémoire augmentent avec 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 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 via le regroupement continu. Au lieu de traiter chaque requête comme un travail d’inférence isolé, il met continuellement à jour le batch au fur et à mesure que les séquences arrivent, génèrent des tokens et se terminent — un modèle de planification qui devient généralement plus valuable à mesure que la concurrence augmente.

L’Utilisation du GPU est Faible Tandis Que les Requêtes Sont en File d’Attente

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

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

Le résultat n’est pas garanti d’être une latence inférieure pour chaque requête individuelle. Sous charge, cependant, cela peut produire un débit agrégé substantiellement meilleur et une utilisation des ressources plus prévisible.

Les Prompts Longs Dominent le Temps Jusqu’au Premier Token

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

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

Cela est particulièrement utile lorsque les requêtes partagent :

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

La mise en cache des préfixes ne rend pas la génération de sortie plus rapide. Elle réduit le calcul des prompts répétés, donc son avantage dépend de savoir si les requêtes contiennent effectivement des préfixes réutilisables identiques.

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 tensoriel entre les GPU et le parallélisme en pipeline entre plusieurs nœuds ou appareils.

Cela ne rend pas l’inférence multi-GPU sans effort. La bande passante d’interconnexion des GPU, la topologie PCIe, l’architecture du modèle, la mémoire partagée des conteneurs et la surcharge de communication affectent toujours les performances.

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

Vous Avez Besoin d’Observabilité de Niveau Production

Les réponses API d’Ollama exposent des champs de temporisation utiles tels que la durée de chargement du modèle, la durée d’évaluation du prompt, le nombre de tokens 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 de terminaison /metrics. Cela facilite le suivi du volume de requêtes, de la mise en file d’attente, du temps jusqu’au premier token, de la latence inter-token, de l’utilisation du cache, des préemptions, du débit et des résultats des requêtes au fil du temps.

Une fois 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 rapidement qu’Ollama sur chaque machine. L’avantage significatif est qu’il donne à l’opérateur plus de mécanismes pour utiliser efficacement la mémoire et le calcul des accélérateurs coûteux sur de nombreuses requêtes.

Regroupement Continu (Continuous Batching)

Le regroupement statique traditionnel fonctionne 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 tokens, et un troisième génère plusieurs milliers de tokens de code.

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

Cela améliore le débit lorsque le trafic est concurrent et irrégulier. Cela offre peu d’avantages lorsqu’un seul utilisateur envoie une requête à la fois.

Gestion du Cache KV Paginé (Paged KV Cache Management)

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

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

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 du long contexte, mais il réduit le gaspillage évitable autour de ce coût.

Mise en Cache des Préfixes

De nombreuses requêtes de production partagent un début substantiel. Les agents dotés d’outils peuvent envoyer des schémas de fonction identiques, les bots de support peuvent utiliser les mêmes documents de politique, et les assistants de codage peuvent inclure répétitivement les mêmes instructions de dépôt.

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

Elle est moins utile lorsque les modèles, les horodatages, l’ordre des documents ou les métadonnées générées dynamiquement changent près du début de chaque prompt. De petites différences de 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 tensoriel, en pipeline, de données, d’experts et de contexte. Chaque déploiement n’a pas besoin de ces modes, mais leur disponibilité est importante lorsqu’un service dépasse un seul GPU.

Pour une station de travail avec deux GPU appropriés, le parallélisme tensoriel peut permettre à un modèle plus grand de s’exécuter sur les deux appareils. Pour un service répliqué, le parallélisme de données peut créer plusieurs répliques de 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, le 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 aussi plus d’opportunités pour une configuration invalide ou inefficace. Migrer vers vLLM signifie prendre la responsabilité de ces décisions.

Où Ollama Gagne Toujours

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.

Stations de Travail Personnelles

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 des 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’utilisation privée sur poste de travail.

Collections de Modèles GGUF

Ollama a un flux de travail naturel autour des modèles GGUF et des Modelfiles. Les utilisateurs existants peuvent avoir curé des quantifications, 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 fort est généralement via les dépôts de modèles Hugging Face supportés et les 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 l’inconvénient de la migration tout en manquant certains des avantages de performance.

Déchargement Mixte CPU et GPU

L’inférence de bureau repose parfois sur le déchargement partiel du GPU car le modèle entier ne tient pas dans la VRAM. Cela peut être pratique pour une utilisation occasionnelle, particulièrement lorsque la latence n’est pas critique.

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

Commutation Rapide de Modèles

Ollama facilite le tirage, l’exécution, l’arrêt et la commutation entre de nombreux modèles locaux. C’est utile pour l’évaluation, l’écriture, le codage, les embeddings, la vision et l’expérimentation ad hoc.

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

Administration Minimale

Ollama est intentionnellement avisé (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 utilisateur, une latence acceptable et aucune file d’attente significative, la migration est susceptible de créer du travail plutôt que de l’éliminer.

Ne Migrez Pas Basé Uniquement sur les Tokens par Seconde

La vitesse de génération de tokens 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 token
• Latence inter-token
• Latence de bout en bout de la requête
• Débit de traitement des prompts
• Débit des tokens de sortie
• Requêtes complétées par minute
• Temps d’attente en file d’attente
• Consommation de mémoire GPU
• Utilisation du GPU
• Taux d’échec et de délai d’attente

Exécutez la même famille de modèles, la même précision, la même longueur de contexte, le même ensemble de prompts, la même limite de sortie et le même niveau de concurrence sur les deux serveurs. Sinon, le test est plus susceptible de comparer le packaging et la configuration des modèles 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 de longs prompts système, des préfixes répétés, des réponses en flux continu et deux à huit sessions simultanées.

Planifiez la Migration du Modèle en Premier

Les noms de modèles Ollama ne correspondent pas automatiquement aux identifiants de modèles vLLM équivalents. Un package Ollama peut contenir une quantification GGUF particulière, un modèle de prompt, une configuration de token 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 ajusté par instructions
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 tokens d’arrêt et les valeurs par défaut de génération
7. Les exigences d’appel d’outils ou de sortie structurée
8. Tout adaptateur LoRA ou prompt système personnalisé

Choisissez ensuite un point de contrôle pris en charge par vLLM qui correspond au comportement souhaité. Ne supposez pas qu’un point de contrôle AWQ ou FP8 se comportera identiquement à la version GGUF précédemment utilisée 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 inclut :

poids du modèle
+ cache KV
+ graphiques CUDA et allocations d'exécution
+ espace de travail temporaire
+ caches de processeur multimodal, si utilisés
+ 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 un --max-model-len réaliste plutôt que la plus grande valeur annoncée par le modèle, et évitez de définir l’utilisation de la mémoire GPU si agressivement qu’une variation mineure de la charge de travail provoque des échecs de mémoire. Un service stable avec une capacité théorique légèrement inférieure est plus utile qu’un service qui échoue lors de son premier pic de trafic.

Un Déploiement Docker Compose vLLM Minimal

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=replace-with-a-long-random-value
EOF

Démarrez le serveur :

docker compose up -d

Vérifiez les journaux :

docker compose logs -f vllm

Testez le point de terminaison des modèles :

curl http://localhost:8000/v1/models \
  -H "Authorization: Bearer replace-with-a-long-random-value"

Envoyez une requête de chat :

curl http://localhost:8000/v1/chat/completions \
  -H "Authorization: Bearer replace-with-a-long-random-value" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-model",
    "messages": [
      {
        "role": "user",
        "content": "Explain continuous batching in two paragraphs."
      }
    ],
    "temperature": 0.2,
    "max_tokens": 300,
    "stream": false
  }'

Pour un déploiement maintenu, fixez l’image à une version vLLM testée au lieu de la laisser sur latest. Consultez les notes de version avant de mettre à niveau car les options de 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 vLLM-vs-Ollama — consultez le Démarrage Rapide vLLM.

La Compatibilité API OpenAI N’est Pas une Interchangeabilité Complète

Ollama et vLLM fournissent tous deux des points de terminaison compatibles OpenAI, ce qui peut rendre la migration de l’application relativement petite. 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="replace-with-a-long-random-value",
)

response = client.chat.completions.create(
    model="local-model",
    messages=[
      {
          "role": "user",
          "content": "What should I monitor on an LLM server?",
      }
    ],
    temperature=0.2,
)

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

La compatibilité doit toutefois être testée au niveau des fonctionnalités. Examinez :

• Comportement des événements de 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 JSON ou contrainte par schéma
• Points de terminaison d’embeddings
• Entrées multimodales
• Rapport d’utilisation des tokens
• 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 framework d’agent qui dépend d’un analyseur d’appel d’outils particulier ou d’une extension non standard.

Les Modèles de Chat (Chat Templates) Sont une Cause Courante d’Échec de Migration

Les modèles ajustés par instructions 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 tokens de contrôle et des prompts de génération dans le format utilisé pendant l’entraînement.

Ollama package beaucoup de ce comportement dans sa définition de modèle. Avec vLLM, le modèle est normalement obtenu à partir de la configuration du tokenizer 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 tokens spéciaux
• Les instructions système sont ignorées
• Les appels d’outils sont mal formés
• Le modèle continue le message de l’utilisateur
• La qualité de la sortie est beaucoup pire 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 Par Étapes

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 correspondez son ajustement d’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 chaque modèle expérimental.

Étape 2 : Valider le Comportement de l’API

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

Étape 3 : Établir une Base de Référence

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 tokens de prompt par seconde, les tokens de sortie par seconde, le temps jusqu’au premier token, 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 attendues lors d’un 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 du cache, les préemptions, le temps jusqu’au premier token et la latence de queue.

Étape 5 : Déplacer un Client

Routez une application non critique ou un petit pourcentage de trafic vers vLLM. Gardez Ollama disponible comme solution de repli jusqu’à ce que le nouveau serveur ait fonctionné de manière fiable sous une utilisation réelle.

Étape 6 : Régler à Partir des Mesures

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

Une Checklist de Migration Pratique

Avant de basculer les clients, vérifiez ce qui suit :

[ ] 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
[ ] Il reste suffisamment de VRAM pour le cache KV requis
[ ] La longueur de contexte maximale reflète l'utilisation réelle
[ ] Le modèle de chat correct est disponible
[ ] Les tokens d'arrêt et les valeurs par défaut de génération 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 d'attente et les annulations sont gérés
[ ] Un chemin de retour à Ollama existe

Cette liste est délibérément 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 de terminaison Ollama local ni un point de terminaison vLLM ne devraient être exposés négligemment à 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 route pour les attaques par déni de service via des prompts ou des sorties très longs.

vLLM peut exiger une clé API pour ses points de terminaison compatibles OpenAI, mais une clé API n’est pas une limite de sécurité complète. Pour un accès partagé ou à distance, placez le service derrière un proxy inverse ou une passerelle API qui fournit TLS, des restrictions réseau, des limites de taille de requête, des limites de taux, une journalisation d’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 également devant vLLM.

Considérez également les risques spécifiques au modèle. Le chargement d’URL multimodal, le code de modèle personnalisé, les fichiers distants et l’exécution d’outils sans restriction peuvent élargir 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 offre déjà une latence acceptable
• La gestion facile de GGUF est importante
• Le déchargement CPU ou partiel GPU est requis
• Les modèles changent fréquemment
• Personne ne veut opérer une infrastructure supplémentaire
• Il n’y a aucun problème de concurrence ou de débit mesuré

Un passage à vLLM doit résoudre une limitation concrète. “Production” n’est pas un seuil magique qui invalide Ollama, surtout 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 en file d’attente, si les préfixes répétés consomment un temps de préremplissage significatif, ou si un modèle plus grand doit être distribué sur plusieurs GPU, le serveur plus simple peut être devenu le choix le plus coûteux opérationnellement.

Gardez Ollama pour le Développement et Ajoutez vLLM pour le Service Partagé

L’architecture la plus pratique n’est souvent pas un remplacement complet. Les développeurs peuvent garder Ollama fonctionnant dans Docker Compose sur leurs stations de travail pour l’exploration de modèles, les tests GGUF et l’utilisation interactive privée, 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 — garder les deux moteurs auto-hébergés signifie que les prompts, les poids et les journaux d’inférence restent sous votre contrôle, indépendamment du serveur qui traite une requête donnée.

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

Ollama:
expérimentation -> commutation de modèles -> outils personnels -> chat local

vLLM:
modèle sélectionné -> point de terminaison 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 que runner de modèle local. Il élimine suffisamment de travail de packaging 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 fort lorsque le serveur lui-même est le problème à ingénierier. Le trafic concurrent, la file d’attente, les préfixes longs 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. Migrez 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.