Comprendre l'apprentissage automatique distribué moderne : des planificateurs HPC aux moteurs de service LLM
Les ingénieurs en apprentissage automatique jonglent aujourd'hui avec un ensemble diversifié d'outils et de concepts pour l'entraînement et le déploiement de modèles à grande échelle. Cet article offre un aperçu approfondi de plusieurs sujets clés : l'exécution de tâches avec les conteneurs d'apprentissage profond (DLC), l'utilisation de planificateurs de lots HPC tels que Volcano (VOLC) et SLURM, le service LLM efficace avec vLLM et SGLang, les cadres et paramètres d'entraînement typiques, les modes opérationnels (entraînement vs. inférence), les stratégies de parallélisation (DPTPPP – données, pipeline, parallélisation tensorielle), le rôle des routeurs et contrôleurs dans les systèmes distribués et les stratégies de chargement des données pour un débit élevé. Nous allons expliquer chaque concept, fournir des exemples (avec des échantillons de code et de configuration) et offrir des informations pratiques d'une manière technique et précise. Plongeons-nous dans le sujet.
Conteneurs d'apprentissage profond (DLC) et exécution des tâches d'apprentissage automatique
Les conteneurs d'apprentissage profond (DLC) font référence aux images de conteneurs Docker pré-construites qui sont livrées avec des cadres d'apprentissage profond populaires et des dépendances optimisées et prêtes à être exécutées. Par exemple, AWS fournit des DLC pour TensorFlow, PyTorch, MXNet, etc., qui incluent des versions optimisées (souvent avec prise en charge du GPU, des bibliothèques comme CUDA/cuDNN installées et même des optimisations réseau comme EFA pour l'entraînement multi-nœuds). Ces conteneurs garantissent un environnement cohérent afin que les chercheurs n'aient pas besoin d'installer manuellement des cadres sur chaque machine. Selon AWS, les DLC sont disponibles sous forme d'images Docker sur Amazon ECR (Elastic Container Registry), et chaque image est conçue pour une version et une tâche spécifiques du cadre (entraînement ou inférence) (Build high-performance ML models using PyTorch 2.0 on AWS – Part 1 | AWS Machine Learning Blog). Cela signifie que vous pouvez choisir un conteneur qui correspond au cadre souhaité (par exemple PyTorch 2.0 avec CUDA 11) et être sûr qu'il contient toutes les bibliothèques appropriées.
Comment cela fonctionne : En pratique, l'utilisation d'un DLC implique d'extraire l'image du conteneur et d'exécuter votre entraînement ou votre inférence à l'intérieur. Cela peut être fait sur une machine virtuelle cloud ou sur un serveur sur site avec Docker installé. Par exemple, après avoir lancé une instance GPU EC2, on pourrait faire :
# Étape 1 : Se connecter à AWS ECR public (si nécessaire) et extraire l'image du DLC
aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin <aws_account>.dkr.ecr.us-west-2.amazonaws.com
docker pull <aws_account>.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-gpu-py310-cu118-ubuntu20.04-ec2
# Étape 2 : Exécuter le conteneur avec un script d'entraînement
docker run --gpus all -v /data:/data -it <aws_account>.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.0.0-gpu-py310-cu118-ubuntu20.04-ec2 \
python /data/train.py --epochs 5 --batch-size 32
Dans l'exemple ci-dessus, nous avons extrait un DLC d'entraînement AWS PyTorch 2.0, puis nous avons exécuté un script d'entraînement (train.py) à l'intérieur. L'indicateur --gpus all donne au conteneur l'accès aux GPU NVIDIA sur l'hôte, et -v /data:/data monte un répertoire de données hôte dans le conteneur. Cette approche garantit que l'environnement à l'intérieur du conteneur possède la version correcte de PyTorch, CUDA, etc., ce qui simplifie l'exécution de la tâche. Il est également portable : le même conteneur peut être exécuté sur n'importe quelle machine avec Docker, de sorte que les expériences sont reproductibles.
Quand utiliser les DLC : Les DLC sont particulièrement utiles sur les plateformes cloud et les services gérés. Par exemple, les tâches d'entraînement Amazon SageMaker utilisent en coulisses des images DLC afin que vous puissiez simplement spécifier l'image et votre code d'entraînement, et la plateforme s'occupe du reste. Même sur les clusters HPC, les équipes utilisent parfois Singularity ou Docker pour exécuter des tâches dans un environnement conteneurisé pour plus de cohérence. En résumé, les DLC rationalisent le problème « cela fonctionne sur ma machine » en fournissant un environnement d'exécution cohérent pour les tâches d'apprentissage profond. Ils sont livrés avec des bibliothèques testées et optimisées (ce qui peut entraîner des améliorations de performances – par exemple, AWS a signalé une accélération allant jusqu'à 42 % en utilisant son DLC PyTorch 2.0 optimisé sur certaines instances (Build high-performance ML models using PyTorch 2.0 on AWS – Part 1 | AWS Machine Learning Blog)).
Volcano (VOLC) – Planification des lots Kubernetes pour les tâches d'IA
Volcano (VOLC) est un système de planification des lots construit sur Kubernetes, conçu pour exécuter des charges de travail de calcul haute performance (HPC) et d'IA dans un environnement natif du cloud. Bien que le planificateur par défaut de Kubernetes soit idéal pour les microservices, il lui manque certaines capacités nécessaires pour les tâches d'apprentissage profond (comme la planification de groupe, la gestion des files d'attente et la planification des priorités). Volcano résout ces problèmes en fournissant un planificateur personnalisé et des CRD (Custom Resource Definitions) de gestion des tâches au-dessus de Kubernetes (Volcano: Collision between containers and batch computing | CNCF). Essentiellement, Volcano permet à Kubernetes de se comporter davantage comme un planificateur de cluster HPC pour les tâches par lots.
Qu'est-ce que c'est : Volcano a été introduit pour relier les conteneurs et le calcul par lots. Il prend en charge les cadres tels que TensorFlow, PyTorch, Spark et MPI en permettant aux utilisateurs de soumettre des tâches qui nécessitent plusieurs ressources (par exemple, une tâche qui nécessite 8 GPU sur 2 nœuds) et en garantissant que ces ressources sont allouées ensemble avant le démarrage de la tâche (Volcano: Collision between containers and batch computing | CNCF). Cette « planification de groupe » garantit que les tâches d'entraînement distribuées (qui peuvent générer de nombreux pods) ne démarrent pas tant que tous les pods requis ne peuvent pas démarrer, ce qui évite une situation où la moitié de la tâche est en cours d'exécution et l'autre moitié est en attente (ce qui gaspillerait des ressources). Volcano fournit également des politiques d'équité, des files d'attente prioritaires et la possibilité de co-planifier des charges de travail mixtes.
Comment cela fonctionne : Volcano s'intègre à Kubernetes en tant que plugin de planification. Les utilisateurs définissent généralement un YAML de tâche Volcano, qui spécifie les tâches et leur nombre de réplicas, les besoins en ressources, etc. Par exemple, un YAML peut déclarer une tâche avec 4 réplicas, chacun nécessitant 1 GPU, et un minAvailable: 4 (ce qui signifie planifier cette tâche uniquement lorsque 4 pods peuvent être placés). Lors de la soumission, le planificateur de Volcano trouvera de l'espace sur le cluster pour les 4 pods et les lancera simultanément. Si seulement 3 GPU sont libres, il attendra qu'un 4e soit libre (plutôt que d'en démarrer 3 maintenant et 1 plus tard). Ceci est crucial pour les cadres d'entraînement distribués comme Horovod ou PyTorch DDP, qui s'attendent à ce que tous les rangs soient actifs en même temps pour la synchronisation.
L'architecture de Volcano comprend un contrôleur central et des plugins de planification. Il prend en compte les algorithmes de planification tels que le partage équitable, la priorité, etc., via un mécanisme de plugin. Par exemple, il peut appliquer des politiques de mise en file d'attente (afin que certaines tâches n'affament pas les autres) et une planification tenant compte de la topologie (répartissant les tâches sur les nœuds ou les racks pour améliorer les performances). Du point de vue de l'utilisateur, l'utilisation de Volcano ressemble à l'utilisation de Kubernetes, mais avec une API différente pour les tâches et l'assurance que votre tâche d'apprentissage automatique sera planifiée de manière globale. En bref, VOLC transforme Kubernetes en un planificateur compatible avec le HPC (Volcano: Collision between containers and batch computing | CNCF), unifiant la commodité des conteneurs avec la puissance de l'orchestration des tâches par lots.
Cas d'utilisation : Supposons que vous ayez un cluster Kubernetes avec des nœuds GPU et que vous souhaitiez exécuter une tâche d'entraînement distribuée basée sur MPI. Avec Volcano, vous pouvez soumettre une tâche MPI (Volcano s'intègre à MPI Operator) demandant (par exemple) 2 pods chacun avec 4 GPU. Volcano s'assurera que les deux pods démarrent ensemble sur deux nœuds et disposent de 4 GPU chacun. Il gérera également si un pod échoue, en replanifiant l'ensemble de la tâche si nécessaire, pour maintenir la sémantique de groupe. De cette façon, votre commande MPI mpirun à l'intérieur des pods peut se lancer de manière fiable sur les deux pods. Sans Volcano, le planificateur par défaut pourrait démarrer un pod, puis retarder le second jusqu'à ce que les ressources se libèrent, ce qui entraînerait le blocage ou l'expiration du processus MPI du premier pod.
SLURM : Planification de tâches HPC classique (plongée en profondeur)
SLURM (Simple Linux Utility for Resource Management) est un planificateur de tâches open source largement utilisé pour les clusters HPC. Il fonctionne comme le « système d'exploitation » d'un cluster, allouant des ressources (cœurs de CPU, GPU, mémoire, nœuds) aux tâches, mettant les tâches en file d'attente jusqu'à ce que les ressources soient disponibles, et démarrant et surveillant ces tâches. Slurm est hautement évolutif et est utilisé dans de nombreux superordinateurs de pointe. Il fournit un outil de gestion de cluster et de planification de tâches qui se concentre sur la mise en correspondance efficace des tâches avec les ressources disponibles (Choosing the Right Orchestration Tool for ML Workloads: Slurm vs. Kubernetes | Nscale).
Comment SLURM fonctionne : Un cluster Slurm se compose d'un contrôleur central (slurmctld) qui gère la file d'attente et la planification, et de démons d'agent (slurmd) s'exécutant sur chaque nœud de calcul pour lancer et superviser les tâches. Les utilisateurs interagissent avec Slurm via des commandes comme sbatch (pour soumettre un script de tâche par lots), salloc (pour demander une allocation interactive) ou srun (pour lancer des tâches parallèles). Slurm maintient une liste de partitions (considérez-les comme des files d'attente nommées ou des groupes de nœuds), chacune avec certaines limites ou caractéristiques matérielles, et il planifie les tâches sur les nœuds de ces partitions en fonction des politiques configurées (priorité, équité, planification de remplissage, etc.).
Exemple de soumission de tâche : Voici un exemple de script de tâche par lots Slurm (train.sbatch), qui demande des ressources et exécute un programme d'entraînement :
#!/bin/bash
#SBATCH --job-name=train_model # Nom de la tâche
#SBATCH --nodes=1 # Exécuter sur un seul nœud
#SBATCH --ntasks=4 # Nombre total de tâches (processus) = 4
#SBATCH --gres=gpu:4 # Demander 4 GPU (sur un seul nœud)
#SBATCH --cpus-per-task=4 # 4 cœurs de CPU par tâche (16 cœurs au total)
#SBATCH --mem=64G # 64 Go de mémoire pour la tâche
#SBATCH --time=02:00:00 # Délai hh:mm:ss
#SBATCH --partition=ml_gpu # Nom de la partition (file d'attente)
module load anaconda/2023a # Charger tous les modules nécessaires (par exemple, Anaconda)
source activate myenv # Activer l'environnement virtuel si nécessaire
echo "Exécution sur $SLURM_NNODES nœud(s) avec $SLURM_NTASKS tâches..."
srun python train.py --epochs 10 --batch-size 128
Dans ce script, les lignes #SBATCH sont des directives à Slurm. Nous demandons 1 nœud avec 4 GPU et configurons la tâche pour exécuter python train.py via srun. Lorsque nous exécutons sbatch train.sbatch, Slurm mettra la tâche en file d'attente. Une fois qu'un nœud dans la partition ml_gpu avec 4 GPU libres et 16 cœurs de CPU libres est disponible, Slurm allouera ce nœud à la tâche, démarrera la tâche et srun lancera 4 tâches (puisque --ntasks=4). S'il s'agissait d'un scénario d'entraînement distribué utilisant MPI ou PyTorch distribué, ces 4 tâches pourraient correspondre à 4 workers (chacun étant affecté à un GPU). Slurm se charge de les lancer avec les variables d'environnement appropriées pour MPI ou pour torch.distributed (si configuré pour le faire).
Utilisation efficace de Slurm : Slurm fournit de nombreuses fonctionnalités telles que les tableaux de tâches (pour soumettre facilement de nombreuses tâches similaires), les chaînes de dépendances (démarrer la tâche B après la fin de la tâche A) et le profilage des ressources. Pour l'apprentissage automatique, un modèle courant consiste à demander --gres=gpu:N pour obtenir N GPU et à utiliser srun ou MPI pour générer N processus. Slurm garantit que tous ces processus s'exécutent sur les nœuds alloués et peuvent communiquer (souvent, il configure les noms d'hôtes dans SLURM_HOSTNAMES et MPI peut les utiliser). Slurm permet également des politiques de planification ; par exemple, les tâches peuvent être préemptées ou remplies. La planification de remplissage est utile dans le HPC pour maximiser l'utilisation : une tâche courte peut sauter en avant dans la file d'attente si elle peut s'insérer dans un intervalle entre les grandes tâches. En tant qu'ingénieur, lorsque vous avez de grandes tâches d'entraînement, vous pouvez demander un temps d'exécution plus long ; mais si vous pouvez diviser le travail en blocs plus courts ou mettre en place un point de contrôle et redémarrer, vous pouvez utiliser le remplissage pour les faire exécuter plus tôt en plusieurs parties.
En résumé, Slurm est un outil puissant pour exécuter des tâches d'apprentissage automatique par lots sur des clusters. Il est de niveau inférieur à Kubernetes ou aux services cloud – vous vous connectez généralement en SSH à un nœud de connexion et utilisez sbatch pour soumettre – mais il donne un contrôle précis. De nombreux chercheurs exécutent PyTorch ou TensorFlow sur des clusters Slurm en écrivant simplement des scripts Slurm qui lancent leur code d'entraînement, bénéficiant ainsi de la planification des ressources GPU du cluster.
vLLM : Moteur d'inférence LLM à haut débit
Alors que les grands modèles de langage (LLM) sont passés de la recherche à la production, leur service efficace est devenu un défi. vLLM est une bibliothèque et un moteur open source conçus pour une inférence LLM rapide et économique. Développé au Sky Computing Lab de l'UC Berkeley, vLLM introduit une nouvelle technique de gestion de la mémoire appelée PagedAttention pour optimiser la façon dont le cache clé-valeur d'attention du modèle est stocké et accédé (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). Le résultat est un débit significativement plus élevé (requêtes par seconde) par rapport aux implémentations traditionnelles. En fait, vLLM atteint jusqu'à 24 fois plus de débit que la bibliothèque de base Hugging Face Transformers sur le service de modèles de style GPT (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog), sans nécessiter de modifications à l'architecture du modèle.
Comment vLLM fonctionne : Dans la génération autorégressive (la façon typique dont les LLM génèrent du texte jeton par jeton), un cache des clés et des valeurs d'attention passées est maintenu pour chaque séquence. Ce cache KV croît avec la longueur de la séquence et peut consommer beaucoup de mémoire GPU (par exemple, ~1,7 Go pour une seule longue séquence sur LLaMA-13B (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog)). La plupart des cadres allouent un bloc contigu pour la longueur maximale possible, ce qui entraîne beaucoup d'espace inutilisé (fragmentation). La PagedAttention de vLLM traite plutôt le cache KV comme des pages de mémoire virtuelle, l'allouant en blocs et permettant un stockage non contigu (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). De cette façon, la mémoire peut être gérée de manière flexible : les séquences qui terminent la génération libèrent leurs pages qui peuvent être réutilisées pour de nouvelles séquences. Cela réduit considérablement le gaspillage de mémoire (de 60 à 80 % dans les cas typiques) et permet à vLLM de gérer plus de séquences concurrentes que les autres systèmes.
De plus, vLLM implémente le batching continu : il peut ajouter de nouvelles requêtes entrantes dans le lot à la volée, même lorsque d'autres requêtes sont à mi-chemin de la génération. Les systèmes traditionnels traitent souvent un lot fixe de requêtes du début à la fin pour chaque étape de génération ; le planificateur de vLLM est plutôt affiné pour fusionner les requêtes chaque fois que possible, gardant ainsi les GPU occupés. Il utilise également des graphiques CUDA optimisés pour éviter la surcharge Python dans la boucle de service, prend en charge les GPU NVIDIA et AMD, et s'intègre à Hugging Face Transformers (vous pouvez donc charger les modèles par nom et les servir).
Exemple d'utilisation : L'utilisation de vLLM est similaire à l'utilisation d'un serveur d'inférence de haut niveau. Vous pouvez soit l'utiliser par programmation, soit via un serveur API. Par exemple, par programmation :
from vllm import LLM, SamplingParams
# Charger un modèle 7B (en supposant que les poids sont disponibles localement ou via HuggingFace Hub)
llm = LLM(model="facebook/opt-6.7b", tensor_parallel_size=1) # tensor_parallel_size peut être >1 pour diviser le modèle sur les GPU
prompts = [
"User: Hello, how are you?\nAssistant:",
"User: What is the capital of France?\nAssistant:"
]
# Générer avec certains paramètres de décodage
outputs = llm.generate(prompts, sampling_params=SamplingParams(top_p=0.95, max_tokens=100))
for out in outputs:
print("Prompt:\n", out.prompt)
print("Completion:\n", out.outputs[0].text)
Ce code crée une instance LLM et génère des réponses pour deux invites dans un lot. En coulisses, vLLM utilisera PagedAttention pour gérer le cache KV pour ces invites et peut même les mettre en lot ensemble si possible. Les outputs contiendront les complétions pour chaque invite. On pourrait également lancer vLLM en tant que serveur (qui fournit une API REST compatible OpenAI) en utilisant une commande comme python -m vllm.entrypoints.openai.api_server --model your_model_name. Cela facilite l'intégration de vLLM avec les applications qui s'attendent à une API OpenAI (il suffit de les pointer vers ce serveur).
Pourquoi c'est important : vLLM repousse essentiellement les limites de débit du service LLM. Si vous avez un budget GPU fixe, servir plus de requêtes par seconde signifie un coût par requête plus faible. L'amélioration de 24 fois signalée se produit dans les scénarios où de nombreuses requêtes concurrentes sont générées avec des sorties relativement longues (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). Même dans des cas moins extrêmes, vLLM produit souvent des accélérations multiples par rapport aux implémentations naïves, et environ 3 fois plus que le serveur TGI de Hugging Face dans de nombreux paramètres (vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention | vLLM Blog). Il prend également en charge les algorithmes de décodage avancés (comme la recherche de faisceau, l'échantillonnage parallèle) efficacement (vLLM and PagedAttention: A Comprehensive Overview | by Abonia Sojasingarayar | Medium). Pour un ingénieur, adopter vLLM peut être aussi simple que de modifier votre code d'inférence pour utiliser l'API de vLLM (ou d'exécuter son serveur). L'avantage est de gérer plus d'utilisateurs ou de réduire la latence sans acheter plus de GPU.
SGLang : Langage de génération structurée et cadre de service
Alors que vLLM se concentre sur le débit brut de la complétion d'invite en une seule étape, SGLang s'attaque au problème de l'orchestration efficace des interactions complexes et structurées avec les LLM. SGLang (abréviation de Structured Generation Language) est un système qui combine un DSL frontal (langage spécifique au domaine) pour décrire les programmes LLM multi-étapes avec un runtime backend hautement optimisé pour les exécuter ([2312.07104] SGLang: Efficient Execution of Structured Language Model Programs) (SGLang: A Deep Dive into Efficient LLM Program Execution - DEV Community). C'est comme si SGLang était à la fois un langage de programmation pour l'invite (avec des fonctionnalités telles que les boucles, les conditionnelles et les appels parallèles) et un moteur de service qui garantit que ces programmes s'exécutent rapidement.
Qu'est-ce que c'est : L'idée de base derrière SGLang est que de nombreuses applications réelles nécessitent plusieurs appels à un LLM et des sorties structurées. Par exemple, un agent d'IA peut planifier des étapes et appeler le LLM pour chaque étape, ou vous pouvez exiger que le LLM génère du JSON avec un schéma spécifique. Faire cela naïvement peut être lent : plusieurs appels entraînent une surcharge et le LLM peut répéter le traitement des mêmes parties d'invite, etc. Le frontend de SGLang vous permet d'écrire un seul « script » qui peut inclure plusieurs appels de génération, une logique de branchement et l'intégration d'outils externes. Le compilateur/runtime de SGLang exécutera ensuite cela efficacement. Le runtime introduit des optimisations telles que RadixAttention (un algorithme pour réutiliser le cache KV à travers les préfixes d'invite, similaire dans l'esprit à la pagination de vLLM mais axé sur les parties d'invite partagées) et une machine à états finis compressée pour la grammaire de sortie (pour gérer les sorties structurées plus rapidement) ([2312.07104] SGLang: Efficient Execution of Structured Language Model Programs). En termes simples, RadixAttention signifie que si vous avez de nombreuses requêtes partageant un préfixe commun (par exemple, une invite système ou quelques exemples), SGLang calculera cette partie une seule fois et la réutilisera, ce qui rendra les chatbots ou la génération augmentée par récupération beaucoup plus rapides en évitant le travail redondant (What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium). La sortie structurée FSM signifie que si vous vous attendez, par exemple, à un JSON avec des clés fixes, SGLang peut sauter la génération de la ponctuation/des clés fixes jeton par jeton et sauter en avant, car il sait que ces parties sont déterministes (What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium). Cela donne un gain de vitesse de 3x+ pour la génération de longues sorties JSON ou XML (What is SGLang and Why Does It Matter? | by Emad Dehnavi | Medium).
Comment cela fonctionne : SGLang se compose de deux parties – un DSL basé sur Python et un runtime. Le DSL permet aux utilisateurs d'écrire quelque chose comme :
from sglang import sg # interface hypothétique
# Pseudocode : définir un flux de génération structuré
with sg.session(model="Llama-2-13b-chat") as sess:
# Un programme simple avec deux appels LLM séquentiels et une sortie structurée
user_input = "Translate the following English text to French and give sentiment: I love this product."
sg.prompt(f"User asks: {user_input}\nYou are a translator and sentiment analyzer.")
translation = sg.generate("First, translate to French:")
sentiment = sg.generate("Now, analyze the sentiment of the original text:")
sg.return_json({"translation": translation, "sentiment": sentiment})
(Remarque : Ce qui précède est un pseudocode illustratif. La syntaxe réelle de SGLang peut différer, mais conceptuellement, elle permet la génération séquentielle et parallèle et le retour de données structurées.)
Lorsque ce « programme » SGLang s'exécute, le runtime prendra le relais : il peut exécuter le premier appel de génération pour traduire, puis le second pour le sentiment, et enfin assembler un JSON. En coulisses, il utilise un ou plusieurs backends d'inférence LLM (avec des optimisations similaires à vLLM). Étant donné que les deux invites partagent le contexte d'instruction initial, SGLang peut réutiliser le calcul de ce préfixe pour le deuxième appel. Et lors du retour de JSON, si les clés et le format JSON sont prédéterminés par sg.return_json, il peut s'assurer que ceux-ci sont générés sans dépenser plusieurs jetons sur des accolades/virgules.
Principales fonctionnalités : Les auteurs de SGLang mettent en évidence des fonctionnalités telles que le planification sans surcharge (son planificateur pour orchestrer plusieurs appels n'ajoute pratiquement aucune latence supplémentaire), l'équilibrage de charge conscient du cache (il peut acheminer les requêtes vers les workers d'une manière qui maximise les accès au cache) et la prise en charge multi-modale (il peut également gérer les modèles de vision-langage, par exemple, LLaVA pour les images) (GitHub - sgl-project/sglang: SGLang is a fast serving framework for large language models and vision language models.) (GitHub - sgl-project/sglang: SGLang is a fast serving framework for large language models and vision language models.). Il prend également en charge les astuces d'efficacité courantes : la quantification (int8/4 bits, etc.), le décodage spéculatif (générant plusieurs jetons à l'avance pour ensuite vérifier, ce qui peut accélérer les longues générations) et l'orchestration multi-modèle (par exemple, en utilisant un modèle pour une partie du programme et un autre modèle pour une autre partie). Essentiellement, il s'agit d'un cadre tout-en-un pour écrire des applications basées sur LLM et les exécuter avec des performances élevées.
Performances et cas d'utilisation : SGLang a montré jusqu'à 6,4 fois plus d'améliorations de débit par rapport aux systèmes de pointe sur des tâches complexes ([2312.07104] SGLang: Efficient Execution of Structured Language Model Programs). Considérez un pipeline de génération augmenté par récupération (RAG) : normalement, vous pouvez rechercher un contexte vectoriel, puis le préfixer à une invite, puis générer une réponse. Avec SGLang, vous pouvez exprimer toute cette séquence (résultat de recherche vectorielle alimentant un modèle d'invite, puis génération) comme un seul programme. Le runtime pourrait paralléliser certaines étapes si possible et réutiliser les composants mis en cache. De même, pour les chatbots qui ont un historique de conversation