Du laptop à la production : self-host vos LLMs avec Ollama et vLLM, puis distribuez-les comme un pro avec Odock

Deux outils, deux métiers très différents

Ollama et vLLM sont constamment comparés en 2026, et cette comparaison sous-entend en général qu'il faut choisir l'un ou l'autre. En pratique, ils résolvent des problèmes différents, et la plupart des déploiements sérieux finissent par utiliser les deux, à différents moments de la vie d'un même model.

Ollama est conçu pour une simplicité en une commande. Vous pullez un model, vous le lancez, et vous disposez d'un endpoint local en quelques minutes, sans configuration de cluster GPU ni tuning du serving framework. C'est le choix par défaut pour le développement local, le prototypage d'une feature face à un vrai model, ou l'exploitation d'un outil interne à faible trafic où quelques requêtes par minute constituent toute la charge. Les benchmarks 2026 situent Ollama autour de 62 tokens par seconde sur un model comme Llama 3.1 8B pour un seul utilisateur, ce qui convient parfaitement à une personne qui itère, mais qui devient de plus en plus tendu dès que la vraie concurrency apparaît.

vLLM se situe à l'autre extrémité de ce spectre. Sa gestion mémoire PagedAttention réduit considérablement le gaspillage mémoire qui limite le nombre de requêtes concurrentes qu'un GPU peut servir, et son architecture disaggregated prefill/decode, introduite au fil des releases 2025 et 2026, sépare la phase de traitement du prompt, gourmande en calcul, de la phase de génération de tokens, gourmande en bande passante mémoire, afin que chacune puisse être ordonnancée et associée au hardware indépendamment. Le résultat se voit directement dans les benchmarks : vLLM soutient environ 920 tokens par seconde avec 50 utilisateurs concurrents sur la même catégorie de model où Ollama plafonne à 62, soit un avantage de throughput d'environ 6x, qui dépasse 16x sur les GPU récents de génération Blackwell à grande échelle. Si Ollama est l'endroit où vous confirmez qu'un model fonctionne, vLLM est ce que vous placez devant du trafic réel.

Quand le self-hosting devient réellement rentable

Le self-hosting n'est pas automatiquement moins cher, et prétendre le contraire mène à de mauvaises décisions de capacité. L'économie en 2026 pointe vers un seuil de rentabilité assez net : à partir d'environ 500 requêtes par heure ou plus, avec des longueurs de sortie typiques, un seul GPU de classe A100 bien utilisé faisant tourner vLLM coûte environ 70% de moins qu'un volume équivalent de trafic vers une API frontier hosted, le point de bascule se situant généralement autour de 150-200 requêtes par heure. En dessous de ce volume, vous payez généralement pour une capacité GPU inutilisée, et une API hosted l'emporte sur le coût, même avant de prendre en compte l'effort opérationnel de faire tourner votre propre stack d'inference.

C'est également précisément là que la montée en puissance de models open-weight réellement compétitifs change le calcul. Il y a quelques années, self-hoster signifiait accepter un écart de capacité par rapport aux options propriétaires frontier. En 2026, cet écart s'est suffisamment réduit, avec des models comme GLM-5.2 en tête de catégories de benchmark spécifiques et Gemma 4 tournant de façon crédible sur du hardware modeste, pour que le self-hosting devienne autant une décision de capacité qu'une décision de coût pour un nombre croissant de workloads.

L'étape que la plupart des guides oublient : la distribution

C'est ici que s'arrête le tutoriel type sur le self-hosting, et c'est là que commence le vrai problème business. Un endpoint vLLM ou Ollama, à lui seul, n'est qu'une API à bearer-token unique, sans notion de qui l'appelle, sans budget par appelant, sans access grant par appelant, et sans ledger d'usage que vous pourriez remettre à la finance ou à un client. Cela convient parfaitement au laptop d'un seul développeur. Cela s'effondre dès que vous voulez :

• permettre à plusieurs équipes internes d'appeler le model sans partager un seul token et un seul blast radius,
• proposer le model comme un tier « pro » payant à des clients avec des niveaux d'accès différents,
• suivre qui dépense quoi, afin qu'un workload incontrôlé n'épuise pas silencieusement votre budget GPU,
• appliquer les mêmes guardrails et le même audit trail que ceux déjà exigés pour le trafic vers des providers hosted.

Résoudre tout cela vous-même implique de construire une couche d'auth, une couche de metering, une couche de pricing et une couche de logging au-dessus d'un serveur d'inference qui n'a jamais été conçu pour remplir ces fonctions. C'est précisément le vide qu'une gateway comble.

Enregistrer un model self-hosted comme provider dans Odock

La couche de routing d'Odock traite déjà vllm comme une famille de provider native, au même titre qu'OpenAI, Anthropic, Gemini et Mistral, ce qui signifie que votre endpoint self-hosted n'est pas un cas particulier greffé sur la gateway, mais un provider de premier rang. Le chemin entre « un model tourne sur mon hardware » et « un model que mon organisation ou mes clients peuvent appeler en toute sécurité » ressemble à ceci :

1. Pointez Odock vers votre endpoint d'inference. Qu'il s'agisse d'un serveur vLLM exposant une API compatible OpenAI ou d'une instance Ollama, vous l'enregistrez de la même manière que n'importe quel provider, en stockant l'endpoint et les credentials sous forme de provider key chiffrée qui ne transite jamais par le code applicatif.

2. Ajoutez le model. Utilisez add a model manually pour associer un nom stable, visible côté client, à votre model self-hosted, afin que les appelants n'aient jamais besoin de savoir, ni de se soucier, quel GPU, quelle instance vLLM ou quelle révision du model sert réellement la requête.

3. Définissez un pricing, même pour une infrastructure que vous possédez. Le model pricing ne sert pas uniquement à mesurer les dépenses d'API hosted : c'est le moyen d'attribuer le coût réel de votre propre capacité GPU entre les équipes ou les clients qui l'utilisent, et c'est le mécanisme qui transforme un model self-hosted en quelque chose que vous pouvez réellement facturer dans un tier pro.

4. Émettez des virtual API keys scopées par consommateur. Plutôt qu'un seul token partagé vers votre serveur d'inference, chaque équipe, application ou client reçoit sa propre virtual API key avec des model access grants explicites, afin que l'accès puisse être révoqué ou restreint pour un appelant sans affecter les autres.

5. Ajoutez des budgets et des quotas par tier. Un tier gratuit et un tier pro qui appellent le même model self-hosted sous-jacent peuvent avoir des budgets et des quotas entièrement différents, afin que votre propre capacité GPU soit protégée de n'importe quel appelant, de la même manière qu'un provider hosted protège sa capacité de vous.

6. Activez les mêmes guardrails que pour le reste. Self-hosted ne veut pas dire non surveillé. L'inspection des prompts et des réponses via SafetySec s'applique à votre propre model exactement comme à un model hosted.

7. Surveillez l'usage par key. Chaque appel produit un usage record avec l'identité, les tokens, la latency et le coût, ce qui vous permet de réellement reporter et facturer une offre « pro » self-hosted, plutôt que de deviner l'utilisation GPU à partir des seules métriques d'infrastructure.

À quoi ressemble « distribuer vos models comme un pro », de bout en bout

En assemblant les pièces, le pattern est simple : vous prototypez sur Ollama, vous promouvez le model validé vers un déploiement vLLM dimensionné pour la concurrency attendue, vous enregistrez cet endpoint vLLM comme provider dans Odock, puis vous émettez des virtual keys scopées pour quiconque doit pouvoir l'appeler, que ce soit votre propre équipe produit, un outil interne, ou un client externe qui paie pour un accès élevé. Le client ou l'équipe ne parle jamais directement à votre GPU. Il parle à une virtual key, scopée exactement au model et au quota que vous avez décidés, avec chaque appel loggé et facturé.

C'est aussi ce qui permet à un déploiement self-hosted de rester cohérent avec le reste de votre parc IA, plutôt que de devenir un second système, non gouverné, vivant en dehors de celui-ci. Si vous routez déjà le trafic vers des providers hosted via Odock pour les budgets, les guardrails et les audit records, un déploiement vLLM self-hosted s'intègre dans le même catalogue, la même politique d'access grants et la même observability — un point détaillé dans la vue d'ensemble du self-host stack si vous envisagez également de self-hoster la gateway elle-même en plus de votre couche d'inference.

Les limites honnêtes

Le self-hosting déplace l'effort, il ne le supprime pas. Vous échangez une facture au token contre l'achat de GPU, la planification de capacité et le travail opérationnel nécessaire pour maintenir un service d'inference en bonne santé, ce qui représente un coût réel même quand l'économie par requête joue en votre faveur. Un mauvais dimensionnement, dans un sens comme dans l'autre, est fréquent : une capacité sous-dimensionnée réintroduit les problèmes de latency que vous cherchiez à fuir, une capacité surdimensionnée érode silencieusement l'avantage de coût qui justifiait le self-hosting au départ. Rien de tout cela ne change selon la gateway placée devant le déploiement : c'est une véritable décision d'infrastructure, qui mérite son propre plan de capacité.

Là où Odock.ai intervient

J'ai conçu la couche provider d'Odock pour qu'un déploiement vLLM ou Ollama self-hosted ne soit jamais un citoyen de seconde zone face à une API hosted, donc gardez ce contexte en tête. Une fois votre model enregistré comme provider, il bénéficie des mêmes virtual keys, budgets, quotas, guardrails et usage records qu'OpenAI, Anthropic ou n'importe quel autre provider de votre catalogue, ce qui est précisément ce qui transforme « distribuer ce model dans un tier pro » en une décision sûre, facturable et auditable, plutôt qu'un token partagé et un espoir.

Si vous avez déjà un model qui tourne sur Ollama ou vLLM et que vous cherchez le moyen le plus rapide d'en faire quelque chose que vos équipes ou vos clients peuvent utiliser sans surveiller un endpoint partagé, demandez une démo ou commencez avec le self-hosting chez Odock, et placez votre propre infrastructure derrière le même control plane que tout ce que vous exploitez déjà.

Sources

• The 2026 Definitive Guide to Running Local LLMs in Production, SitePoint
• vLLM vs Ollama: Which LLM Framework Should You Use in 2026?, Kanerika
• Local LLM Deployment 2026: Ollama vs vLLM Tuning, QubitTool
• Provider Hugging Face Odock
• Virtual API keys Odock
• Vue d'ensemble self-host Odock