L'essor des LLM locaux : du laboratoire à la production industrielle

L'adoption des grands modèles de langage (LLM, large language models) en entreprise française s'est accélérée précisément parce que l'écosystème open weights a mûri. La Commission européenne relève que plus de la moitié des développeurs utilisent désormais régulièrement des modèles, jeux de données et outils ouverts, et que le coût de l'inférence a chuté de plus de 99 % en deux ans (Europe's Open-Source AI Landscape, Commission européenne, 2025). Cette bascule économique change la donne : héberger son propre LLM n'est plus réservé aux géants du cloud.

Mais un piège structurel guette les PME et ETI que j'accompagne. L'IA « personnelle », celle qu'un développeur lance sur son poste avec LM Studio ou Ollama pour tester Qwen ou Gemma en privé (Les Bases du numérique, ANCT, 2026), obéit à une logique radicalement différente de l'IA « partagée » qui doit servir un service comptable, un cabinet juridique ou une chaîne de production entière.

Pourquoi le passage à l'échelle change de paradigme

Un usage individuel traite une requête à la fois : le GPU calcule, l'utilisateur attend, puis relance. Une infrastructure partagée doit au contraire absorber des dizaines de requêtes concurrentes, garantir un temps de réponse stable et maintenir un taux d'occupation matériel élevé pour rentabiliser des cartes graphiques coûteuses. Ce n'est plus le même métier technique.

La maîtrise des poids de modèles — les fichiers de paramètres que vous téléchargez et hébergez vous-même — constitue le socle de cette approche. Ce sont eux qui garantissent que vos données sensibles ne transitent jamais par une API tierce américaine, condition sine qua non de la souveraineté numérique. Le choix du moteur d'inférence qui exploite ces poids détermine ensuite si votre déploiement tiendra la charge réelle de production. Pour les définitions techniques mobilisées ici, notre glossaire de l'IA détaille chaque brique.

Ollama : l'accélérateur d'agilité pour le prototypage et le développement

Ollama est la sportive du domaine : rapide, agréable, mais conçue pour transporter peu de monde. Red Hat résume l'analogie avec justesse — « pensez à Ollama comme une voiture de sport et à vLLM comme un train à grande vitesse » (vLLM vs. Ollama, Red Hat). Cette image structure tout l'arbitrage.

Un héritage llama.cpp et une friction quasi nulle

Ollama repose sur llama.cpp, le moteur d'inférence C++ optimisé pour tourner efficacement sur du matériel modeste, y compris sans GPU dédié. Cet héritage lui confère sa force : une installation en une commande, un catalogue de modèles pré-quantifiés téléchargeables instantanément, et une compatibilité native avec les cartes grand public. En phase de recherche et développement, cette absence de friction opérationnelle est un atout décisif.

Concrètement, un développeur peut comparer Mistral 7B, Llama 3 et un modèle spécialisé dans la même matinée, ajuster ses prompts, tester une pipeline RAG (Retrieval-Augmented Generation, génération augmentée par récupération) sans jamais toucher à une configuration serveur complexe. C'est exactement l'usage que documente le nœud EOSC de la Commission, qui propose Ollama couplé à OpenWebUI pour passer « de l'expérimentation à des services IA prêts pour la production » en quelques clics (EOSC EU Node, Commission européenne).

Les limites structurelles en usage multi-utilisateurs

La faiblesse d'Ollama n'est pas un défaut : c'est une conséquence de sa conception. Sa gestion des files d'attente reste linéaire et sa concurrence limitée. Quand plusieurs utilisateurs sollicitent simultanément le serveur, les requêtes s'empilent et se traitent de façon peu optimisée. La latence explose, le débit stagne, et l'expérience se dégrade brutalement. Pour un outil de prototypage, c'est sans importance. Pour un service métier ouvert à cinquante personnes, c'est rédhibitoire.

vLLM : le « bullet train » de l'inférence à haute performance

vLLM n'est pas un simple runtime : c'est une bibliothèque de code open source dont l'objectif explicite est de maximiser le débit — le nombre de tokens traités par seconde — afin de servir de nombreux utilisateurs en même temps. Cette différence de nature, et non de degré, explique tout.

Une architecture serveur + moteur

vLLM combine deux composants distincts, comme le détaille Red Hat. Le serveur d'inférence gère la file d'attente des utilisateurs et le trafic réseau externe : son rôle n'est pas de calculer, mais de faire entrer et sortir les données sans ajouter de latence inutile. Le moteur d'inférence, lui, accélère la génération en optimisant l'usage du GPU via des algorithmes comme PagedAttention et le continuous batching.

Cette séparation des responsabilités est précisément ce qui manque à un outil de prototypage. Elle permet à vLLM de découpler la gestion réseau de l'intensité calculatoire, et donc d'absorber des centaines de requêtes concurrentes sans effondrement.

Une solution taillée pour la production

Là où Ollama vous fait avancer vite mais seul, vLLM vous fait avancer vite avec beaucoup de monde à bord. C'est le moteur que nous déployons chez IAPRO dès qu'un client bascule d'un pilote vers un service ouvert à l'ensemble de ses collaborateurs. Le revers, assumé, est une exigence d'expertise supérieure au déploiement initial : configuration GPU, dimensionnement de la mémoire, orchestration. Un investissement technique qui se rentabilise dès que le volume monte, comme nous le verrons dans l'analyse du coût total de possession.

Décryptage technique : PagedAttention et Continuous Batching

La supériorité de vLLM sous charge repose sur deux innovations qu'il faut comprendre pour arbitrer en connaissance de cause.

PagedAttention : la gestion dynamique de la mémoire KV

Lorsqu'un LLM génère du texte, il maintient en mémoire GPU un cache dit KV (key-value), qui stocke le contexte de chaque requête en cours. Les approches classiques réservent des blocs de mémoire contigus et surdimensionnés par requête, gaspillant une part considérable de la VRAM disponible. PagedAttention emprunte le principe de la pagination des systèmes d'exploitation : la mémoire KV est découpée en petits blocs alloués dynamiquement, à la demande. Résultat, le gaspillage s'effondre et le GPU peut héberger bien plus de requêtes simultanées.

Continuous Batching : l'ordonnancement optimisé

Le second levier est le continuous batching. Au lieu d'attendre qu'un lot complet de requêtes se termine avant d'en démarrer un nouveau — l'approche statique classique —, vLLM injecte de nouvelles requêtes dans le lot en cours dès qu'une place se libère. Le GPU ne reste jamais inactif à attendre les traînards. Cette planification continue maximise le taux d'occupation matériel, ce qui est la clé économique de toute infrastructure d'inférence.

Face à cela, Ollama traite les requêtes de manière plus linéaire. En charge légère, la différence est invisible. En forte charge, elle devient le facteur discriminant entre un service fluide et un service saturé. C'est toute la logique de la matrice de décision que je détaille plus bas.

Benchmarks comparatifs : analyse des métriques TPS et latence P99

Les chiffres tranchent le débat mieux que n'importe quel argument d'autorité. Voici la confrontation factuelle, sur un scénario de charge concurrente.

Métrique Ollama vLLM Interprétation
Débit (TPS, tokens/seconde) ~41 ~793 vLLM traite près de 19× plus de tokens sous charge
Latence P99 ~673 ms ~80 ms 99 % des requêtes vLLM répondent en moins de 80 ms
Concurrence cible quelques utilisateurs centaines d'utilisateurs Deux échelles de déploiement distinctes
Friction d'installation quasi nulle expertise requise Ollama gagne en R&D, vLLM en production

Ce que ces chiffres signifient concrètement

Le débit (TPS) mesure le volume de production : environ 793 tokens par seconde pour vLLM contre 41 pour Ollama sous charge concurrente. Traduit en usage réel, cela fait la différence entre un assistant conversationnel qui répond instantanément à des milliers d'agents simultanés et un service qui s'engorge à la dizaine d'utilisateurs.

La latence P99 est encore plus parlante pour l'expérience utilisateur. Elle indique le temps de réponse pour 99 % des requêtes — donc la quasi-totalité, y compris les pics. Une P99 de 80 ms garantit une fluidité perçue comme instantanée ; une P99 de 673 ms produit des lenteurs visibles qui érodent l'adoption interne. Pour estimer l'impact de ces gains sur votre exploitation, notre calculateur de ROI IA intègre ces paramètres de latence et de volume.

L'intégration dans les pipelines RAG complexes

Le choix du moteur ne se juge pas isolément : il conditionne la fluidité de toute la chaîne RAG, aujourd'hui incontournable pour ancrer un LLM dans vos documents métier.

Pertinence et débit sont deux problèmes distincts

Une pipeline RAG performante mobilise plusieurs briques : le chunking augmenté, les modèles d'embedding et le reranking. Les travaux d'Etalab sur les données de service-public.fr montrent l'ampleur du travail d'optimisation : enrichissement des chunks avec titres, mots-clés TF-IDF et questions potentielles, comparaison des modèles d'embedding e5, BGE-M3 et surtout Solon, modèle français open source à l'état de l'art, puis reranking par cross-encodeur pour réordonner les documents récupérés (Étalab, numerique.gouv.fr, 2025).

Ces techniques améliorent la pertinence des réponses. Mais elles n'améliorent pas le débit de génération. Vous pouvez disposer du meilleur reranker et des embeddings Solon parfaitement calibrés : si votre moteur d'inférence sature à quarante utilisateurs, la pertinence n'arrive jamais assez vite à l'utilisateur final.

vLLM garantit la livraison de la pertinence

C'est là que le moteur reprend son rôle. Dans un déploiement RAG de production, chaque requête déclenche une récupération documentaire, une réinjection de contexte souvent volumineux, puis une génération. Le contexte long consomme lourdement le cache KV — précisément ce que PagedAttention optimise. vLLM assure que la pertinence construite par votre pipeline RAG soit délivrée sans goulot d'étranglement technique. Pour concevoir ces architectures documentaires métier, consultez nos déploiements IA sectoriels.

Souveraineté numérique : intégrer les modèles européens (EuroLLM, Mistral)

Le débat technique s'inscrit dans un enjeu stratégique : garder la maîtrise de vos données et de votre stack. Ollama comme vLLM sont des moteurs neutres qui exécutent le modèle de votre choix — y compris les alternatives souveraines aux géants américains.

EuroLLM et Mistral, socles d'une IA de confiance

EuroLLM, lancé en septembre 2024 sous licence Apache 2.0 et cofinancé par l'Union européenne, vise à couvrir les 24 langues officielles de l'UE avec des modèles à poids ouverts publiés sur HuggingFace (EuroLLM, Interoperable Europe, Commission européenne). Mistral, développé par la société française Mistral AI, complète ce paysage souverain. Ces modèles s'exécutent indifféremment sous Ollama pour le prototypage ou sous vLLM pour la production.

Déployer sur infrastructure française

L'intérêt décisif pour mes clients : ces poids ouverts se déploient sur des serveurs privés ou un cloud souverain hébergé en France, garantissant que les données sensibles — dossiers patients, pièces comptables, contrats juridiques — ne quittent jamais le périmètre juridique national. C'est la condition d'une conformité robuste, notamment au regard du RGPD. Le traitement de données personnelles par un LLM impose de documenter la base légale et les mesures de sécurité ; les repères sont détaillés par la CNIL. Cette exigence de maîtrise est renforcée par le Règlement (UE) 2024/1689, dit AI Act, dont les obligations de transparence et de gouvernance s'appliquent progressivement d'ici 2027 : nous en détaillons les implications opérationnelles dans notre hub dédié à la mise en conformité.

Matrice de décision : quand est-il temps de changer de moteur ?

Voici le guide pratique que je remets aux DSI. La bascule ne se décide pas au feeling mais sur des seuils objectifs.

Les quatre critères de bascule

Critère Rester sur Ollama Migrer vers vLLM
Utilisateurs simultanés moins de 10 plus de 10, jusqu'aux centaines
Exigence de latence tolérante, usage interne temps de réponse contractuel ou UX critique
Besoin de fine-tuning tests LoRA ponctuels service PEFT/LoRA en production continue
Budget GPU carte unique, mutualisée parc A100/H100 à rentabiliser

Phase d'expérimentation contre phase de déploiement métier

La distinction est nette. En phase d'expérimentation, vous cherchez le bon modèle et les bons prompts : Ollama est imbattable, la friction nulle prime sur la performance brute. Dès que vous entrez en phase de déploiement métier — service ouvert à une population d'utilisateurs, engagement de disponibilité, volume soutenu —, les seuils du tableau basculent en faveur de vLLM. Red Hat le formule sans ambiguïté : Ollama pour l'expérimentation locale, vLLM comme fondation pour servir les LLM à grande échelle de façon fiable et efficace. Notre glossaire précise chacune de ces notions pour les décideurs non techniques.

Coûts opérationnels et ROI : optimiser l'usage des ressources GPU

L'arbitrage final est économique. Un parc Ollama sous-dimensionné coûte paradoxalement plus cher qu'une infrastructure vLLM bien pensée.

Faire plus avec moins de GPU

Le taux d'occupation des cartes graphiques est le nerf de la guerre. Une A100 ou une H100 représente un investissement lourd, en achat comme en location cloud. Grâce à PagedAttention et au continuous batching, vLLM maintient un taux d'occupation élevé : la même carte sert davantage d'utilisateurs simultanés. À l'inverse, multiplier les instances Ollama pour absorber la charge revient à empiler des GPU sous-utilisés, chacun tournant loin de sa capacité optimale.

Le vrai calcul du coût total de possession

Le coût total de possession (TCO, total cost of ownership) tranche en faveur de vLLM à l'échelle. Oui, son déploiement initial exige une expertise technique supérieure — configuration, orchestration, tuning. Mais ce surcoût ponctuel est écrasé par la réduction drastique du coût d'inférence par token à grande échelle. Sur un service consommé par des centaines d'utilisateurs quotidiens, l'écart de débit de 41 à 793 TPS se traduit directement en nombre de GPU nécessaires, donc en facture mensuelle. Ce type d'investissement d'industrialisation peut par ailleurs mobiliser des dispositifs de financement : notre panorama des aides à la transformation numérique et le simulateur d'aides IAPRO vous aident à monter le dossier, en lien avec les programmes de Bpifrance et de France Num.

Conclusion : construire une roadmap de passage à l'échelle

La question « Ollama vs vLLM » appelle une réponse hybride, et c'est la vision que je défends dans chaque mission IAPRO. Ne choisissez pas un camp : orchestrez une séquence. Utilisez Ollama pour itérer vite sur le choix des modèles européens, calibrer vos prompts et prototyper votre pipeline RAG sans friction. Puis migrez vers vLLM dès que les KPI de production — latence P99, coût par token, taux d'occupation GPU — deviennent critiques pour la satisfaction de vos utilisateurs et la maîtrise de votre budget.

Cette roadmap de passage à l'échelle, du proof of concept agile à l'infrastructure industrielle souveraine, n'est pas un détail d'ingénierie. C'est le pilier qui distingue une expérimentation IA sans lendemain d'un avantage compétitif durable pour les entreprises françaises. Le bon moteur, au bon moment, sur vos propres poids et vos propres serveurs.

FAQ — Ollama vs vLLM en entreprise

Quelle est la différence fondamentale entre Ollama et vLLM en termes d'architecture ?

Ollama est un runtime local dérivé de llama.cpp, conçu pour l'exécution simple d'un modèle sur une machine. vLLM est une bibliothèque d'inférence articulant un serveur (gestion du trafic réseau et de la file d'attente) et un moteur (optimisation GPU). Cette séparation permet à vLLM de servir des centaines d'utilisateurs concurrents, là où Ollama vise l'usage individuel ou à faible charge.

Pourquoi vLLM affiche-t-il un débit (TPS) nettement supérieur à celui d'Ollama ?

Sous charge concurrente, vLLM atteint environ 793 tokens par seconde contre 41 pour Ollama, soit près de 19 fois plus. Cet écart provient du continuous batching, qui injecte de nouvelles requêtes dans le lot en cours sans laisser le GPU inactif, et de PagedAttention, qui optimise la mémoire. Ollama traite les requêtes de façon plus linéaire, ce qui plafonne son débit en forte charge.

Est-il possible de faire tourner des modèles multilingues comme EuroLLM sur les deux plateformes ?

Oui. Ollama et vLLM sont des moteurs neutres qui exécutent des modèles à poids ouverts. EuroLLM, publié sous licence Apache 2.0 et couvrant les 24 langues officielles de l'UE, comme Mistral, se déploie indifféremment sur l'un ou l'autre. Vous prototypez sous Ollama, puis rechargez exactement le même modèle sous vLLM pour la production, sans changer de poids.

Quelles sont les compétences techniques requises pour déployer vLLM par rapport à Ollama ?

Ollama s'installe en une commande, sans expertise particulière : c'est son principal atout en R&D. vLLM exige des compétences supérieures au déploiement initial : configuration GPU, dimensionnement de la mémoire, orchestration du serveur d'inférence et tuning de la charge. Cet investissement technique ponctuel se rentabilise dès que le volume de production monte, via la baisse du coût par token.

Comment le choix du moteur d'inférence impacte-t-il la latence dans une application RAG ?

Une pipeline RAG réinjecte un contexte documentaire volumineux à chaque requête, ce qui sollicite lourdement le cache mémoire KV du GPU. PagedAttention, propre à vLLM, gère dynamiquement cette mémoire et évite le goulot d'étranglement. Ainsi, même une excellente pertinence — obtenue par chunking augmenté, embeddings Solon et reranking — n'est utile que si le moteur la délivre rapidement, ce que vLLM garantit sous charge.

Ollama peut-il gérer des centaines de requêtes simultanées en mode entreprise ?

Non, ce n'est pas sa vocation. La gestion des files d'attente d'Ollama reste linéaire et sa concurrence limitée. Au-delà d'une dizaine d'utilisateurs simultanés, la latence P99 se dégrade fortement — de l'ordre de 673 ms contre 80 ms pour vLLM. Pour un service métier ouvert à des centaines de collaborateurs, vLLM est le choix architectural adapté.

Quelles techniques vLLM utilise-t-il pour optimiser la mémoire GPU (PagedAttention) ?

PagedAttention applique le principe de la pagination des systèmes d'exploitation au cache KV : la mémoire est découpée en petits blocs alloués dynamiquement à la demande, au lieu de blocs contigus surdimensionnés. Le gaspillage de VRAM s'effondre et le GPU héberge davantage de requêtes simultanées. Couplée au continuous batching, cette technique maximise le taux d'occupation matériel et donc la rentabilité de vos cartes A100 ou H100.

Est-ce que le passage à vLLM nécessite un changement de matériel ou seulement logiciel ?

Le passage est d'abord logiciel : vLLM remplace le moteur d'inférence tout en réutilisant les mêmes poids de modèle. En revanche, vLLM est pensé pour exploiter pleinement des GPU serveur type A100 ou H100. Si votre pilote Ollama tournait sur du matériel grand public, la production sous vLLM justifiera d'aligner l'infrastructure GPU sur les volumes visés et les objectifs de latence.

Comment assurer la souveraineté des données lors du déploiement de vLLM sur un cloud privé ?

En hébergeant vLLM et les poids du modèle sur une infrastructure française — serveur privé ou cloud souverain — vous garantissez que les données sensibles ne quittent jamais votre périmètre juridique. Aucun appel à une API tierce n'a lieu. Cette maîtrise conditionne la conformité RGPD et s'inscrit dans les exigences de gouvernance du Règlement (UE) 2024/1689. C'est le socle de notre méthode d'installation souveraine chez IAPRO.

Quand une entreprise doit-elle envisager de migrer d'Ollama vers vLLM ?

Dès que trois signaux apparaissent : plus d'une dizaine d'utilisateurs simultanés, une exigence de latence contractuelle ou d'expérience utilisateur critique, et un besoin de rentabiliser un parc GPU. Concrètement, la migration s'impose au passage de la phase d'expérimentation à la phase de déploiement métier permanent. Avant ces seuils, Ollama reste le meilleur choix pour son agilité.

Pour aller plus loin avec IAPRO

Vous avez validé un proof of concept sous Ollama et vous vous demandez si votre infrastructure tiendra la charge en production ? C'est exactement le moment où notre accompagnement crée le plus de valeur. IAPRO conçoit et installe votre architecture d'inférence souveraine — du choix du moteur au dimensionnement GPU, jusqu'au déploiement des modèles Mistral ou EuroLLM sur vos serveurs français. Contactez-nous pour un audit de passage à l'échelle, et estimez au préalable votre retour sur investissement avec notre calculateur de ROI IA.

Liens utiles