QDNA Écrire un message

Triton Inference Server

Runtime d’inférence

Triton Inference Server

Triton sert des modèles issus de plusieurs cadres sur une même infrastructure. Il gère la mise en lot dynamique, les instances concurrentes et le suivi des métriques. Il s’intègre à la pile NVIDIA AI Enterprise.

Points clés : Multi-cadres · Mise en lot dynamique · Instances concurrentes · Métriques · NVIDIA AI Enterprise.

Rôle

Triton Inference Server sert des modèles issus de plusieurs cadres sur une même infrastructure, au-delà des seuls grands modèles de langage.

Fonctionnement

Il gère la mise en lot dynamique, les instances concurrentes et le suivi des métriques, avec un ordonnancement fin des requêtes.

Cas d’usage

Triton convient aux parcs hétérogènes qui mêlent modèles de langage, vision et modèles classiques, sous une console unique.

Intégration

Il s’intègre à la pile NVIDIA AI Enterprise et, par son backend TensorRT-LLM, sert les modèles au format NVFP4 sur GPU Blackwell (documentation Triton et matrice de quantification TensorRT-LLM, relues le 2 septembre 2026).

Modèles d’ensemble (Triton Ensemble) : chaînage de pipelines sans surcoût réseau

L’un des atouts déterminants de Triton Inference Server réside dans son architecture de modèles d’ensemble (Ensemble Models). Un ensemble compose plusieurs modèles en un graphe acyclique direct (DAG), sans nécessiter de microservices intermédiaires ni de sérialisation JSON sur le réseau local.

Les tenseurs de sortie du premier modèle sont directement transmis en entrée du modèle suivant via la mémoire partagée (CUDA IPC sur GPU ou mémoire système épinglée) :

  • Étape 1 · Prétraitement et tokenisation : exécution d'un tokenizer en C++ ou Python léger convertissant le texte brut en identifiants de tokens (input_ids).
  • Étape 2 · Filtrage et garde-fous (Guardrails) : passage immédiat dans un modèle de classification compact (ex. DeBERTa ou RoBERTa sous backend ONNX Runtime) pour intercepter injections de prompt et données sensibles (PII).
  • Étape 3 · Inférence générative haute performance : routage des tokens validés vers le backend TensorRT-LLM ou vLLM, exploitant le parallélisme de tenseur et la quantification NVFP4 sur GPU Blackwell.
  • Étape 4 · Post-traitement et validation de schéma : décodage des tokens de sortie et vérification de la conformité du format JSON avant réponse au client.

Cette composition élimine les transferts réseau inter-services, réduisant la latence globale de 15 à 35 % par rapport à un chaînage orchestré par une couche applicative externe.

Business Logic Scripting (BLS) : logique conditionnelle et routage dynamique

Pour les scénarios où le graphe statique d'un modèle d’ensemble ne suffit pas, Triton propose le Business Logic Scripting (BLS). Un modèle BLS (écrit en Python ou en C++) prend le contrôle algorithmique complet sur l'ordonnancement :

  • Routage conditionnel de complexité : le script BLS analyse la requête et interroge d'abord un modèle compact et rapide (ex. Qwen 2.5 7B) ; si l'indice d'incertitude ou de perplexité dépasse un seuil, il sollicite dynamiquement le grand modèle d'inférence (ex. DeepSeek V3/V4 ou GLM).
  • Exécution parallèle asynchrone : exécution simultanée de modèles d’embedding et de classification sur des streams CUDA distincts, mutualisant la mise en lot dynamique (dynamic batching).
  • Gestion fine des erreurs et replis (fallbacks) : bascule transparente vers une variante de secours en cas de saturation de la file d'attente GPU.

Licence et code source

Triton Inference Server est publié sous licence BSD-3-Clause. Son cœur est écrit en C++ (dépôt core) ; le dépôt server, que GitHub classe en Python, porte l'assemblage, les scripts et les tests (relu le 2 septembre 2026). Le code étant public, le moteur peut être audité, corrigé et figé sur un commit connu, plutôt que d'être cru sur parole.

Dépôt : triton-inference-server/server. La licence et le langage sont relus à cette source par la base de faits QDNA. Le numéro de version n'est volontairement pas publié ici : il deviendrait faux entre deux sorties amont sans que rien ne le signale.

Questions fréquentes sur Triton

Quelle est la différence entre un modèle d’ensemble Triton et le BLS ?

Un modèle d’ensemble connecte des modèles de manière statique via un fichier de configuration config.pbtxt sans code applicatif. Le Business Logic Scripting (BLS) permet d'écrire du code Python ou C++ pour prendre des décisions conditionnelles et appeler dynamiquement les modèles en cours d'exécution.

Pourquoi utiliser Triton Ensemble plutôt qu’un orchestrateur comme FastAPI ?

Triton Ensemble partage directement les pointeurs de mémoire GPU (CUDA IPC) entre les modèles sans copie mémoire ni sérialisation réseau HTTP/JSON, ce qui divise la latence de transit par dix et maximise le débit de mise en lot.

Quels backends d'inférence Triton supporte-t-il ?

Triton prend en charge TensorRT-LLM, vLLM, ONNX Runtime, PyTorch (LibTorch), OpenVINO, TensorFlow ainsi que des backends personnalisés en C++ et Python.

Quels modèles servir avec Triton Inference Server ?

Voir l’ensemble des combinaisons de moteur et de modèle.