Self-host d’agents IA : open weights, vLLM et TGI

Self-host : pourquoi on en parle (et pourquoi ça fait peur)

Self-host, c’est le moment où votre agent quitte le monde :

• “je mets une API key et ça marche”,

… pour entrer dans le monde :

• “je gère des GPU, des drivers, des déploiements, et des incidents.”

Donc avant de parler technique, clarifions les motivations.

Pourquoi self-host ?

1. Contrôle des données
   Certains flux (documents, voix, dossiers clients) exigent de limiter les sorties de votre périmètre.

2. Latence prévisible
   Une infra dédiée peut être plus stable que des API partagées (selon vos volumes et votre réseau).

3. Coût marginal à l’échelle
   Si vous avez du volume stable, le “coût par requête” peut baisser (mais attention à l’ops).

4. Personnalisation
   Fine-tuning, adapters, routers, policies internes, etc.

5. Résilience fournisseur
   Multi-provider + self-host = moins de dépendance à un seul upstream.

Pourquoi ne pas self-host ?

1. Complexité
   GPU, scheduling, capacity planning, monitoring, patching.

2. Mises à jour
   Les modèles évoluent. La sécurité évolue. Les vulnérabilités aussi.

3. Qualité vs coût
   L’API premium du moment peut être plus performante (sur vos tâches) que votre open-weight self-host, surtout sans tuning.

4. SLA
   “On-prem” ne signifie pas “SLA”. Ça signifie “vous êtes le SLA”.

Open-weight ≠ open-source : comprendre ce que vous achetez (vraiment)

Dans les discussions, on mélange tout :

• open-source (code + licence permissive),
• open-weight (poids disponibles sous conditions),
• et “gratuit” (spoiler : non).

Un modèle open-weight a :

• une licence,
• une politique d’usage (acceptable use),
• et parfois des restrictions.

Par exemple, le repo officiel Meta “llama-models” liste les modèles Llama, avec des liens vers Use Policy, License et Model Card (y compris pour Llama 4).¹

Ça ne disqualifie pas. Ça force juste à lire.

Choisir des modèles open-weight en 2026 : Llama, Mistral (et la logique derrière)

Vous n’avez pas besoin d’un inventaire complet. Vous avez besoin d’une stratégie.

Llama 4 (Meta) : open-weight, multimodal, et contraintes d’inférence

Le repo Meta meta-llama/llama-models liste explicitement la famille Llama 4 (Scout/Maverick) et indique des ordres de grandeur utiles :

• context length très élevé,
• exemples d’inférence,
• et des notes sur les exigences matérielles (ex. plusieurs GPUs à pleine précision, quantization FP8/Int4 pour réduire l’empreinte).¹

Ce point est central pour le self-host :

• la qualité d’un modèle est une chose,
• la capacité à le servir correctement en est une autre.

En pratique, vous aurez souvent une approche “2 vitesses” :

• open-weight “gros” pour les décisions rares,
• open-weight “petit” (ou distillé) pour le routing et l’extraction.

Mistral : modèles open-weight + outillage d’inférence

Mistral documente une page “Model weights” où la société indique open-sourcer des modèles pré-entraînés et instruction-tuned, et renvoie vers un package mistral-inference pour les exécuter.²

Le catalogue de modèles Mistral (docs) liste plusieurs modèles, avec une distinction “Open” vs “Premier”, ce qui est utile pour décider ce qui est self-hostable et ce qui est API-only.³

Là encore, la stratégie n’est pas “tout self-host”. La stratégie est “self-host ce qui bénéficie du contrôle”.

Servir un modèle : vLLM vs TGI vs Ollama vs llama.cpp (et pourquoi le choix compte)

Le self-host ne se résume pas à “télécharger un modèle”. Il faut un moteur d’inférence.

vLLM : throughput et efficacité mémoire

vLLM se présente comme un moteur d’inférence et de serving “high-throughput and memory-efficient”, avec des mécanismes comme continuous batching pour optimiser l’utilisation GPU.⁴

Le repo GitHub de vLLM met en avant des concepts comme continuous batching (et cite PagedAttention dans l’écosystème).⁵

Pourquoi c’est important ?

• parce que votre coût infra dépend de l’utilisation GPU,
• et que les LLMs sont des machines à gaspiller des cycles si vous ne batch pas.

TGI (Text Generation Inference) : toolkit de déploiement

Hugging Face documente TGI comme un toolkit pour déployer et servir des LLMs.⁶

TGI est souvent choisi quand :

• vous êtes déjà dans l’écosystème HF,
• vous voulez une stack standardisée,
• et vous privilégiez l’industrialisation.

Ollama : local/edge, et compatibilité OpenAI (utile pour intégrer)

Ollama documente une compatibilité avec une partie de l’API OpenAI (Responses API) pour connecter des applications existantes à un backend local.⁷

Ce point est pragmatique :

• vous pouvez tester rapidement,
• brancher des outils,
• et migrer certains workloads vers le local.

llama.cpp : local/CPU, quantization, GGUF

llama.cpp vise l’inférence LLM avec minimal setup sur différents hardwares, et sa doc/repo explique l’usage du format GGUF (modèles quantifiés) et des outils associés.⁸

Ce n’est pas votre “prod cloud” par défaut, mais c’est une excellente option pour :

• POCs offline,
• edge,
• ou certains environnements contraints.

Hardware & performance : la réalité du GPU (et pourquoi vos coûts naissent ici)

Self-hosting, c’est aussi accepter une vérité simple :

• votre LLM est une application GPU,
• et les GPU ont des contraintes physiques (VRAM, bande passante, scheduling).

Donc, deux erreurs fréquentes :

1. Choisir un modèle sans penser au serving
2. Penser que “quantization” est un détail

Context length : une promesse, et un coût

Le repo Meta llama-models liste des context lengths très élevés pour Llama 4 (par exemple, Scout et Maverick sont listés avec des context lengths respectifs), ce qui illustre une réalité : plus le contexte est grand, plus le serving devient exigeant (mémoire, latence).¹

La question “prod” n’est pas “combien de tokens max”. C’est :

• combien de tokens vous utilisez réellement,
• sur combien de requêtes simultanées,
• avec quel P95/P99.

Un contexte gigantesque peut être un superpouvoir… ou un piège qui vous fait payer pour du contexte inutile.

Quantization : quand la précision devient une décision financière

Le même repo Meta donne des notes concrètes sur l’inférence :

• exigences matérielles plus élevées à pleine précision,
• options FP8 ou int4 pour réduire l’empreinte et le nombre de GPUs requis (avec des recommandations selon les cas).¹

Ce genre de détail est précieux parce qu’il transforme une discussion abstraite (“self-host coûte combien ?”) en question d’ingénierie :

• quel niveau de quantization est acceptable sur vos tâches,
• quelles métriques se dégradent (si elles se dégradent),
• et quel gain infra vous obtenez.

Throughput : la différence entre “ça marche” et “ça scale”

Servir un LLM n’est pas seulement exécuter un forward pass. C’est gérer :

• la concurrence,
• la file d’attente,
• et la fragmentation de mémoire.

vLLM met en avant continuous batching et une approche d’inférence orientée throughput/efficacité mémoire.⁴⁵

Traduction : si vous self-host et que vous ne batch pas, vous sous-utilisez votre GPU. Et si vous sous-utilisez votre GPU, vous payez cher pour un radiateur.

Accélération NVIDIA : Triton / TensorRT-LLM (option “heavy duty”)

Quand vous poussez le volume, vous regardez souvent des stacks d’inférence plus “hardcore”.

NVIDIA documente Triton Inference Server comme un serveur d’inférence optimisé pour le déploiement de modèles à grande échelle (multi-framework).⁹

Et NVIDIA maintient TensorRT-LLM, un projet orienté optimisation et serving des LLMs.¹⁰

Vous n’en avez pas besoin pour un POC. Vous en aurez peut-être besoin pour une prod très volumique.

MLOps pour agents : le vrai chantier (et ce que personne ne met dans la démo)

Self-host devient “réel” quand vous gérez :

1) Versioning (modèles, prompts, outils)

• version du modèle,
• version du prompt,
• version des outils (schemas),
• version des politiques.

Sans versioning, chaque incident devient “on ne sait pas ce qui a changé”.

2) Observabilité

Même en self-host, vous devez tracer :

• latence P95/P99,
• GPU utilization,
• queue depth,
• erreurs par outil,
• et coût infra par tâche.

Sinon, vous perdez l’avantage principal du self-host (contrôle).

3) Sécurité

Self-host ne vous immunise pas :

• prompt injection (documents non fiables),
• exfiltration via outils,
• secrets dans les logs.

Au contraire : vous avez plus de surface (serveurs, endpoints, credentials).

Voir : /blog/agents-ia/securite/securite-agents-prompt-injection-dlp-secrets.

4) Routing et fallback

Le pattern prod le plus robuste :

• routeur (petit modèle) → modèle cible,
• fallback vers un second modèle si latence/pannes,
• et mode dégradé si aucune dépendance n’est fiable.

Self-host n’empêche pas le multi-provider. Il le rend plus facile… si vous concevez pour.

Déploiement : canary, rollbacks, et l’art de ne pas casser un lundi

Le self-host change votre rythme de release.

Avec une API, vous “subissez” parfois des changements upstream. Avec du self-host, vous “choisissez” vos changements… mais vous devez les déployer.

Un rollout robuste ressemble à :

• canary : 1% du trafic sur le nouveau modèle (ou la nouvelle quantization),
• observabilité : latence/cout/erreurs + métriques métier,
• rollback : revenir au modèle précédent en minutes,
• compatibilité : mêmes schémas d’outils, mêmes formats de sortie,
• tests : replay sur un dataset de traces.

Et surtout : ne changez pas tout en même temps.

Si vous changez :

• le modèle,
• la quantization,
• le prompt,
• et les outils…

… vous perdez la causalité.

Vous saurez juste “ça a cassé”, sans savoir quoi.

Le self-host n’est pas compliqué parce que le modèle est compliqué. Il est compliqué parce que vous gérez des changements.

Et ça implique une conséquence très concrète : l’on-call. Quand le modèle ne répond plus, ce n’est pas “le support du fournisseur”. C’est vous. Si cette phrase vous donne des sueurs froides, vous venez peut-être de trouver votre réponse à la question “faut-il self-host ?”.

Architecture de référence : multi-modèle + router + garde-fous

Voici une architecture “simple” qui marche :

1. Ingress : API + auth + rate limiting
2. Router : modèle small/fast (classification + risk)
3. Execution graph : workflow (graph-first)
4. LLM nodes : open-weight self-host (vLLM/TGI)
5. Tools : APIs internes, DB, OCR, etc (permissions minimales)
6. HITL : gating sur actions rouges
7. Observabilité : traces + replay + dashboards

Notez l’idée : l’agent n’est pas “le modèle”. C’est l’ensemble.

Checklist de décision : faut-il self-host ?

Avant d’acheter des GPU, posez-vous ces questions :

1. Ai-je une contrainte données (DPA, on-prem, souveraineté) ?
2. Ai-je un volume stable qui justifie du capacity planning ?
3. Ai-je une équipe pour opérer (MLOps/infra) ?
4. Ai-je un plan de mise à jour (modèles, sécurité) ?
5. Ai-je un plan de fallback (provider API ou autre modèle) ?
6. Ai-je une observabilité complète (latence, erreurs, traces) ?
7. Ai-je un modèle de gouvernance (HITL, audit) ?
8. Ai-je une stratégie de caching/batching ?
9. Ai-je une stratégie de quantization (si nécessaire) ?
10. Ai-je des tests/evals (régressions) ?

Si vous cochez “non” à 7 questions, self-host devient un hobby. Si vous cochez “oui” à 7 questions, self-host devient un avantage compétitif.

FAQ

Questions frequentes

Open-weight = gratuit ?+

Non. Les poids peuvent être accessibles, mais vous payez en hardware, en ops, et en maintenance. Et il y a des licences/politiques d’usage à respecter (cf. repos officiels).¹

vLLM ou TGI : lequel choisir ?+

Les deux sont des options sérieuses pour du serving LLM. vLLM met l’accent sur throughput/efficacité mémoire et continuous batching, TGI sur un toolkit standardisé de déploiement. Choisissez selon votre stack et votre besoin d’industrialisation.⁴⁶

Ollama peut aider en entreprise ?+

Oui pour prototyper, pour certains usages locaux/edge, et pour intégrer via compatibilité OpenAI. Pour un serving GPU à gros volume, vous utiliserez plus souvent vLLM/TGI.⁷

Self-host règle-t-il la sécurité ?+

Non. Il déplace le risque. Vous gagnez du contrôle sur la donnée, mais vous devez gérer la surface infra et les risques agentiques (outils, prompt injection, secrets). Voir notre article sécurité.

Sources et references

1. [1]GitHub, Meta, “llama-models” (Llama 4 models list, use policy/license/model card links, inference notes).
2. [2]Mistral Docs, “Model weights” (open-source weights + mistral-inference).
3. [3]Mistral Docs, “Models” (Open vs Premier catalog).
4. [4]vLLM website, “High-throughput and memory-efficient inference and serving engine” (continuous batching).
5. [5]GitHub, vllm-project/vllm (continuous batching, serving).
6. [6]Hugging Face docs, “Text Generation Inference (TGI)”.
7. [7]Ollama docs, “OpenAI compatibility” (Responses API).
8. [8]GitHub, ggml-org/llama.cpp (GGUF, local inference).
9. [9]NVIDIA, “Triton Inference Server”.
10. [10]GitHub, NVIDIA/TensorRT-LLM.