Ollama vers vLLM : quand migrer votre serveur de 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 le moment où une expérience locale se transforme en service de déduction partagé nécessitant une meilleure planification et une meilleure observabilité.

C’est là que vLLM prend tout son sens. 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 groupement de requêtes, la gestion de la mémoire, la concurrence, la déduction distribuée et les opérations de production.

Ce guide couvre les signaux pratiques indiquant qu’une migration est justifiée, les risques d’un passage trop précoce, et une approche progressive qui permet de maintenir les deux serveurs en fonctionnement parallèle 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 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 direct pour les configurations courantes de postes de travail et de station de travail.

vLLM est un moteur de déduction et une plateforme de service. Ses préoccupations centrales sont la planification des requêtes à haut débit, la gestion efficace de la cache KV, le groupement de requêtes continu, le parallélisme des modèles et la compatibilité avec les applications construites pour les API de type OpenAI.

Cette distinction est importante car les deux serveurs peuvent paraître similaires en surface. Tous les 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ésumé utile :

La question n’est pas de savoir quel serveur est universellement meilleur. Elle porte sur le fait que votre charge de travail correspond toujours au modèle opérationnel qui rend Ollama attractif. Si vous souhaitez une image plus complète couvrant plus que ces deux moteurs d’exécution, notre comparaison d’Ollama, vLLM, LocalAI, Jan, LM Studio et d’autres outils locaux de LLM couvre le domaine plus large.

Signes que vous avez dépassé les limites d’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 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 paraître 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 incohérent, et un seul prompt volumineux peut affecter tous les utilisateurs partageant le modèle.

Ollama peut traiter des requêtes parallèles, et OLLAMA_NUM_PARALLEL contrôle le nombre de requêtes qu’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 besoins en mémoire augmentent avec le nombre de requêtes parallèles configurées 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 groupement continu. Au lieu de traiter chaque requête comme un travail de déduction isolé, il met continuellement à jour le groupe de travail à mesure que les séquences arrivent, génèrent des jetons et se terminent — un modèle de planification qui gagne généralement en valeur à mesure que la concurrence augmente.

Utilisation du GPU faible alors que des 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 groupement de requêtes continu permet aux séquences actives d’entrer et de quitter le groupe d’exécution dynamiquement.

Le résultat n’est pas garanti d’être une latence plus basse 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 de manière répétée de grands 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, et elle peut dominer le temps jusqu’au premier jeton.

vLLM prend en charge le préremplissage par morceaux et le cache automatique des préfixes. Le cache des préfixes 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é.

C’est particulièrement utile lorsque les requettes partagent :

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

Le cache des préfixes ne rend pas la génération de sortie plus rapide. Il réduit le calcul répété des prompts, de sorte que son bénéfice dépend du fait que les requêtes contiennent effectivement des préfixes identiques 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 tensoriel entre GPU et le parallélisme par pipeline entre plusieurs nœuds ou périphériques.

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

Néanmoins, vLLM offre un chemin délibéré pour la déduction distribuée. Ollama est généralement un meilleur choix pour un poste de travail unique ou une station de travail où le modèle choisi tient 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 de terminaison /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 dans le 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 rapide qu’Ollama sur toutes les machines. L’avantage significatif est qu’il donne à l’opérateur plus de mécanismes pour utiliser efficacement la mémoire et la puissance de calcul des accélérateurs coûteux à travers de nombreuses requêtes.

Groupement de requêtes continu

Le groupement de requêtes statique traditionnel fonctionne mieux lorsque les requêtes ont des longueurs d’entrée et de sortie similaires. Le trafic LLM interactif 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 groupement de requêtes continu modifie le groupe actif à 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 groupe sur des requêtes déjà terminées.

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

Gestion de la cache KV paginée

Pendant la génération, le serveur stocke les clés et 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 des contextes longs 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 mémoire et permet une utilisation plus flexible de la capacité de cache disponible.

La valeur pratique est une plus grande concurrence dans le même budget mémoire. Cela n’élimine pas le coût sous-jacent du 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 d’octets un contexte de longueur donnée a réellement besoin, et comment la précision de la cache (FP8, Q8_0, Q4_0) s’échange contre cela sur une carte de 16 Go — voir Cache KV sur GPU 16 Go.

Cache des préfixes

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

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

C’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.

Déduction parallèle et distribuée

vLLM prend en charge plusieurs formes de parallélisme, y compris le parallélisme tensoriel, par pipeline, par données, par experts et par contexte. Tous les déploiements n’ont 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 périphériques. Pour un service répliqué, le parallélisme par 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 la déduction distribuée paraît 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](https://www.glukhov.org/fr/llm-performance/optimization/speculative-decoding/ “Mécanique de brouillon-vérification, EAGLE-3, P-EAGLE, n-gramme, MTP et configuration pour llama.cpp, vLLM, SGLang et TensorRT-LLM”}), l’appel d’outils, la sortie structurée, les alias de modèles, les clés d’authentification et l’exécution distribuée.

Cette flexibilité rend le serveur plus facile à ajuster pour une charge de travail particulière, mais 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 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.

Stations de travail personnelles

Pour un développeur utilisant une interface de chat, un assistant de codage ou une API locale occasionnelle, les avantages opérationnels de vLLM ne compensent 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 aux modèles. Il est bien adapté à l’expérimentation et à l’utilisation de bureau privée.

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 des quantifications, adaptateurs, modèles, prompts système et paramètres soigneusement sélectionnés qui fonctionnent de manière fiable avec leur matériel.

vLLM prend en charge GGUF, mais sa voie la plus forte 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 fabricants. Déplacer un déploiement GGUF existant vers vLLM sans évaluer un format de point de contrôle plus natif peut préserver l’inconvenance de la migration tout en manquant certains avantages de performance.

Déchargement mixte CPU et GPU

La déduction de bureau repose parfois sur un déchargement partiel sur GPU parce que le modèle entier ne tient pas dans la VRAM. Cela peut être pratique pour une utilisation occasionnelle, 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 d’accélérateur disponible. Une charge de travail qui dépend fortement de la RAM système et du déchargement sur CPU peut être mieux adaptée à Ollama ou llama.cpp.

Changement rapide de modèles

Ollama rend facile de tirer, exécuter, arrêter et changer 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 généralement 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 délibérément d’opinion. Cela peut être une limitation sous charge, mais c’est un avantage lorsque personne ne veut maintenir une plateforme de déduction, et si le serveur local a un utilisateur, une latence acceptable et pas de file d’attente significative, la migration est susceptible de créer du travail plutôt que de l’éliminer.

Ne migrez pas sur la base des jetons par seconde uniquement

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 bout en bout de la requête
• Débit de traitement du prompt
• Débit de jetons de sortie
• Requêtes terminées par minute
• Temps d’attente en file
• Consommation mémoire GPU
• Utilisation du GPU
• Taux d’échec et de dépassement de délai

Exécutez la même famille de modèles, précision, longueur de contexte, ensemble de prompts, limite de sortie et niveau de concurrence sur les deux serveurs. Sinon, le test est plus susceptible de comparer l’emballage et la configuration du modèle 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 streaming et deux à huit sessions simultanées.

Planifiez d’abord la migration du modèle

Les noms de modèles Ollama ne se 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 jetons d’arrêt et des paramètres par défaut.

Avant de changer le 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é pour l’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 valeurs par défaut de génération
7. Les exigences d’appel d’outils ou de sortie structurée
8. Les adaptateurs LoRA ou prompts système personnalisés

Ensuite, choisissez un point de contrôle pris en charge par vLLM qui correspond au comportement prévu. Ne supposez pas qu’un point de contrôle AWQ ou FP8 se comportera de manière identique à la version GGUF utilisée 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és
+ marge de sécurité

Les contextes longs et les séquences concurrentes élargissent principalement l’exigence de cache KV. L’augmentation de 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 par une valeur réaliste de --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 pour que de légères variations de charge provoquent des défaillances de mémoire insuffisante. Un service stable avec une capacité théorique légèrement moindre est plus utile qu’un service qui échoue lors de 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=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 testée de vLLM au lieu de la laisser sur latest. Examinez 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 délibérément minimal ; pour le guide de configuration plus complet — compatibilité API OpenAI, ajustement de PagedAttention et comparaison approfondie vLLM vs Ollama — voir 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 pour é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é devrait toujours ê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
• Traitement de la sortie de raisonnement
• Sortie contrainte par JSON ou schéma
• Points de terminaison d’embeddings
• Entrées multimodales
• Signalement de l’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 framework 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 courante d’échec de migration

Les modèles ajustés pour l’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 package beaucoup de ce comportement à l’intérieur de 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 jetons 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 de déduction, comparez le prompt entièrement rendu utilisé par chaque déploiement.

Utilisez une migration progressive

Remplacer un serveur local fonctionnel en une é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 majorité du trafic API et faites correspondre son ajustement pour l’instruction, sa requête de contexte, ses paramètres de génération et son comportement de chat le plus étroitement 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 de terminaison vLLM, y compris le streaming, l’annulation, les dépassements de délai, les appels d’outils, les requêtes mal formé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 nouvelles tentatives du client.

Étape 3 : Établir une référence

Mesurez d’abord la performance d’une seule requête. Cela confirme que le modèle est correctement chargé 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 mémoire GPU.

Étape 4 : Ajouter une concurrence réaliste

Testez le nombre de requêtes simultanées attendues en opération normale et lors d’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 queue.

Étape 5 : Déplacer un client

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

Étape 6 : Ajuster à partir des mesures

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

Une liste de vérification de migration pratique

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
[ ] Il reste assez de VRAM pour la cache KV requise
[ ] La longueur de contexte maximale reflète l'utilisation réelle
[ ] Le modèle de chat correct est disponible
[ ] Les jetons 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épassements de délai et les annulations sont gérés
[ ] Un chemin de retour vers Ollama existe

Cette liste est délibérément opérationnelle. L’installation de 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 à l’Internet public. Un serveur de déduction non authentifié peut consommer une capacité GPU coûteuse, révéler le comportement du modèle et devenir une voie pour des attaques par déni de service via de très longs prompts ou sorties.

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 distant, placez le service derrière un proxy inversé ou une passerelle API qui fournit TLS, des restrictions réseau, des limites de taille de requête, des limites de débit, la journalisation d’accès et une authentification appropriée — le même modèle que celui couvert dans Ollama derrière un proxy inversé avec Caddy ou Nginx s’applique tout aussi bien devant vLLM.

Tenez également compte des risques spécifiques aux modèles. Le chargement d’URL multimodal, le code de modèle personnalisé, les fichiers distants et l’exécution d’outils non restreinte 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 des GGUF est importante
• Le déchargement sur 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 de concurrence ou de débit mesuré

Un passage vers 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 modéré.

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, si des 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 est souvent pas un remplacement complet. Les développeurs peuvent garder [Ollama fonctionnant dans Docker Compose](https://www.glukhov.org/fr/llm-hosting/ollama/ollama-in-docker-compose/ “Exécuter Ollama 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](https://www.glukhov.org/fr/llm-hosting/self-hosting/llm-selfhosting-and-ai-sovereignty/ “Auto-hébergement de LLM pour la souveraineté de l’IA”}) — le fait de garder les deux moteurs d’exécution auto-hébergés signifie que les prompts, les poids et les journaux de déduction 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 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 lanceur de modèles locaux. Il élimine assez 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 de déduction.

vLLM devient le choix plus fort 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.