Accueil › Glossaire › TGI

TGI (Text Generation Inference)

TGI (Text Generation Inference) est un toolkit de déploiement et de serving de LLM développé par Hugging Face, écrit en Rust et Python, qui a été le premier moteur d’inférence production-grade à implémenter des optimisations comme Flash Attention et PagedAttention pour les LLM open source. TGI est aujourd’hui en mode maintenance : Hugging Face recommande d’utiliser vLLM, SGLang, llama.cpp ou MLX pour les nouveaux projets.

TGI a joué un rôle fondateur dans l’écosystème d’inférence LLM. C’est lui qui alimente Hugging Chat, l’API Inference de Hugging Face, et les Inference Endpoints. Il a initié le mouvement des moteurs d’inférence optimisés reposant sur les architectures de modèles Transformers. Cette approche a ensuite été adoptée par vLLM, SGLang et d’autres. Mais l’écosystème a mûri, et Hugging Face a fait le choix stratégique de contribuer aux moteurs en aval plutôt que de maintenir TGI comme solution principale.

Histoire et impact

TGI a été initialement publié en 2022, devenant l’une des premières solutions production-grade pour le serving de LLM. À une époque où faire tourner un modèle Llama ou BLOOM en production nécessitait du code custom et beaucoup de bricolage, TGI offrait une solution presque clé en main : vous pointiez vers un modèle sur le Hub Hugging Face, et TGI s’occupait des optimisations.

TGI a introduit ou popularisé plusieurs concepts qui sont devenus standard dans l’industrie : le continuous batching (regroupement dynamique des requêtes), le streaming de tokens via Server-Sent Events (SSE), l’intégration de Flash Attention et PagedAttention, et la quantification à la volée. Ces innovations ont posé les fondations pour les moteurs suivants.

Le projet a attiré des utilisateurs majeurs : IBM, Grammarly, l’initiative Open-Assistant, et bien sûr Hugging Face lui-même pour Hugging Chat et ses services d’inférence cloud. TGI a aussi été le premier moteur à proposer une architecture multi-backend, avec l’annonce fin 2024 de backends TensorRT-LLM, vLLM, llama.cpp, et AWS Neuron, le tout derrière une interface unifiée Rust.

Cependant, l’écosystème a évolué rapidement. vLLM, avec son écosystème communautaire massif et ses optimisations continues (PagedAttention v2, V1 engine, kernels Marlin), a pris une avance significative en termes de fonctionnalités et de performances. Plutôt que de dupliquer les efforts, Hugging Face a choisi de contribuer directement à vLLM et SGLang, et de placer TGI en mode maintenance.

Architecture

TGI est composé de trois éléments principaux :

Le Router (serveur web). Écrit en Rust, il reçoit les requêtes HTTP des clients, les met en buffer, crée des batches, et prépare les appels gRPC vers le model server. Rust assure la robustesse du serving via l’analyse statique et la sécurité mémoire au niveau du compilateur, permettant de scaler sur plusieurs cœurs CPU sans les overhead du garbage collector Python.

Le Launcher. Un composant helper qui lance un ou plusieurs model servers (si le modèle est distribué sur plusieurs GPU) et démarre le router avec les arguments compatibles.

Le Model Server. Écrit en Python, il reçoit les appels gRPC du router et exécute l’inférence sur le modèle. Si le modèle est distribué (tensor parallelism), les shards du model server se synchronisent via NCCL. Le model server intègre les optimisations Transformers optimisées : Flash Attention, PagedAttention, et les kernels de quantification.

Fonctionnalités principales

Continuous batching + streaming. Les requêtes entrantes sont dynamiquement regroupées et les tokens sont streamés via SSE. Pas besoin d’attendre la fin d’une génération pour commencer la suivante.

Quantification. TGI supporte les modèles pré-quantifiés (AWQ, GPTQ, Marlin) et la quantification à la volée via bitsandbytes (NF4, FP4, INT8), EETQ, ou FP8. La quantification se configure avec --quantize :

Guided generation (structured outputs). TGI peut forcer le modèle à produire des sorties conformes à un schéma JSON ou une grammaire, ce qui active le function calling et l’appel d’outils.

Zero-config (TGI v3). Introduit dans TGI v3, le mode zero-config analyse automatiquement le matériel au démarrage et sélectionne les valeurs optimales pour la longueur de contexte maximale, le nombre de tokens par batch, et les tokens de prefill. Cela élimine le trial-and-error habituel de la configuration manuelle.

Tensor Parallelism. TGI distribue automatiquement les modèles sur plusieurs GPU. Le nombre de GPU est détecté via CUDA_VISIBLE_DEVICES ou configuré explicitement.

Support multimodal. TGI supporte les modèles vision-language (Qwen 2.5 VL, etc.) avec prefill chunking pour les entrées multimodales.

Utilisation

La méthode la plus simple pour démarrer TGI est via Docker :

TGI expose des endpoints compatibles OpenAI et un Swagger UI documenté sur /docs. L’interaction peut se faire via curl, les SDKs Hugging Face (InferenceClient), ou tout client compatible OpenAI.

Matériel supporté

TGI a été porté sur une gamme de matériel plus large que la plupart des moteurs d’inférence :

Tous les backends n’offrent pas les mêmes fonctionnalités. Le backend NVIDIA CUDA est le plus complet, les autres ont des limitations spécifiques documentées.

Configuration et tuning

TGI expose plusieurs paramètres critiques pour ajuster les performances à votre cas d’usage. L’enjeu principal est le compromis entre longueur de contexte et concurrence : plus le contexte maximal est élevé, moins vous pouvez servir de requêtes simultanées avec la même VRAM.

Max Input Tokens / Max Total Tokens. Ces paramètres contrôlent la longueur maximale du prompt et la longueur totale (prompt + génération). Un modèle avec 128K tokens de contexte natif sur un GPU où il ne tient que 3 fois en mémoire ne peut servir que 3 requêtes concurrentes à plein contexte. Réduire le contexte max à 64K double la concurrence à 6 requêtes.

Quantification. Le choix de quantification impacte directement la VRAM et le throughput. FP8 (sur Hopper) et bitsandbytes NF4 sont les options les plus simples. Pour les modèles pré-quantifiés en AWQ ou GPTQ, TGI les détecte automatiquement au chargement.

Sharded deployment. Pour les modèles trop gros pour un seul GPU, TGI gère automatiquement le tensor parallelism. Configurez CUDA_VISIBLE_DEVICES ou utilisez --num-shard pour spécifier le nombre de GPU. La communication inter-GPU utilise NCCL, et NVLink est fortement recommandé pour les performances.

Profiling. TGI inclut un outil de benchmarking intégré qui mesure non seulement le throughput mais aussi la latence (TTFT, inter-token latency), le P50/P95/P99, et les effets du batching. C’est un outil précieux pour comprendre les compromis de votre déploiement et ajuster les paramètres en conséquence.

TGI vs vLLM : pourquoi migrer

Hugging Face recommande désormais de migrer vers vLLM pour les déploiements production. Voici les raisons principales :

TGI v3 : les dernières innovations avant le mode maintenance

TGI v3 a introduit plusieurs fonctionnalités notables avant le passage en mode maintenance :

Performance sur longs contextes. TGI v3 revendiquait une accélération de 13× par rapport à vLLM sur les prompts très longs (200K+ tokens), grâce au caching intelligent des tours de conversation précédents. Les temps de réponse descendaient à environ 2 secondes pour des prompts de 200K+ tokens, contre 27,5 secondes avec vLLM à l’époque. Depuis, vLLM a rattrapé une grande partie de cet écart avec le chunked prefill et l’async scheduling.

Capacité en tokens 3× supérieure. Les optimisations mémoire agressives de TGI v3 permettaient de traiter 3× plus de tokens que vLLM sur le même matériel, ouvrant la voie à des applications long-contexte sur du matériel limité.

Zero-config automatique. Au démarrage, TGI v3 analyse le GPU disponible et configure automatiquement les paramètres optimaux. Si vous laissez les valeurs par défaut, TGI utilise votre matériel à pleine capacité. Vous pouvez ajuster manuellement si nécessaire (par exemple, réduire le contexte max pour augmenter la concurrence).

Architecture multi-backend. Le trait Rust Backend permettait d’intégrer différents moteurs d’inférence (TensorRT-LLM, vLLM, llama.cpp) derrière la même interface TGI. Cette vision d’un « frontend unifié » reste pertinente, même si son développement est suspendu.

Quand utiliser TGI malgré le mode maintenance

Bien que TGI soit en mode maintenance, il reste un choix valide dans certains scénarios :

Déploiements existants stables. Si vous avez un déploiement TGI en production qui fonctionne bien, il n’y a pas d’urgence à migrer. TGI continue de recevoir des correctifs de sécurité et des mises à jour de dépendances (Torch 2.7, CUDA 12.8 dans la dernière release).

Hugging Face Inference Endpoints. TGI reste disponible et supporté comme moteur dans les Inference Endpoints. Le zero-config v3 simplifie le déploiement pour les utilisateurs qui ne veulent pas configurer manuellement.

Matériel non-NVIDIA spécialisé. TGI dispose de backends pour Intel Gaudi, AWS Neuron, et Google TPU qui ne sont pas tous disponibles nativement dans vLLM. Si vous ciblez ces plateformes, vérifiez si le backend TGI correspondant offre le support dont vous avez besoin.

Pour tout nouveau projet ou toute migration planifiée, vLLM est le choix recommandé par Hugging Face.

L’héritage de TGI dans l’écosystème

Même en mode maintenance, l’influence de TGI sur l’écosystème reste considérable. Plusieurs concepts qu’il a popularisés sont désormais des standards de l’industrie :

Continuous batching comme norme. Avant TGI, la plupart des serveurs d’inférence utilisaient le static batching (attendre qu’un batch soit complet avant de le traiter). TGI a démontré en production que le continuous batching, où les requêtes sont ajoutées et retirées dynamiquement du batch en cours, offre un throughput bien supérieur. Tous les moteurs modernes (vLLM, SGLang, TensorRT-LLM) utilisent désormais cette approche.

Architectures Transformers optimisées comme base. L’approche de TGI consistait à prendre les implémentations de modèles de la bibliothèque Transformers de Hugging Face et à les optimiser pour l’inférence (remplacement des couches d’attention par Flash Attention, ajout de PagedAttention, optimisation des kernels). Cette stratégie est désormais la norme dans vLLM et SGLang, qui s’appuient aussi sur les architectures Transformers comme point de départ.

Serveur Rust + modèles Python. L’architecture hybride de TGI (serveur HTTP robuste en Rust, flexibilité des modèles en Python, communication gRPC entre les deux) a influencé le design de plusieurs moteurs. La séparation des responsabilités entre la couche réseau (qui bénéficie de la sécurité mémoire de Rust) et la couche modèle (qui bénéficie de la flexibilité de Python/PyTorch) est un pattern architectural qui a fait ses preuves.

Quantification intégrée au serving. TGI a été l’un des premiers moteurs à proposer la quantification à la volée (--quantize bitsandbytes-nf4) directement au démarrage, sans étape de pré-quantification séparée. Cette simplicité d’accès à la quantification a contribué à sa démocratisation.