Bientôt disponibleL'Entraînement de modèles sera bientôt disponible dans Scalata Enterprise. Apprenez à un modèle à répondre comme votre équipe.Découvrir les nouveautés

Ressources/Entraînement du modèle/Test et déploiement d'un modèle

Concept

Inférence et déploiement

L'inférence consiste à utiliser un modèle pour générer des réponses. Un modèle entraîné doit d'abord être déployé — ses poids chargés sur du matériel derrière un point de terminaison — ce qui peut prendre plusieurs minutes, puis coûte de l'argent au token ou à l'heure.

Chapitre 94 min de lecture4 références

Définition

L'inférence englobe tout ce qui se passe après l'entraînement : un prompt est soumis, le modèle produit une réponse. Rien n'est appris ; les poids restent fixes. Chaque chat de test, chaque réponse d'évaluation, chaque verdict de juge et chaque réponse en production relève de l'inférence.

Fonctionnement

Un modèle génère du texte un token à la fois. D'abord, il lit l'intégralité du prompt en un seul passage (appelé pré-remplissage), ce qui est rapide car tous les tokens peuvent être traités en parallèle. Ensuite, il décode : il prédit le token suivant, l'ajoute, et répète l'opération jusqu'à produire un token de fin ou atteindre une limite de longueur. Chaque nouveau token nécessite un nouveau passage à travers le modèle, c'est pourquoi les réponses longues prennent plus de temps que les questions longues.

  • Le Délai avant le premier token correspond principalement au pré-remplissage : plus le prompt est long, plus l'attente est longue avant que quoi que ce soit n'apparaisse.
  • Les Tokens par seconde correspondent à la vitesse de décodage : cela détermine la rapidité avec laquelle la réponse s'affiche.
  • Les Paramètres d'échantillonnage, tels que la température, déterminent la façon dont le token suivant est choisi à partir des probabilités du modèle. Des valeurs faibles rendent les réponses plus prévisibles ; des valeurs élevées les rendent plus variées.
  • Le Traitement par lots : un serveur répond à plusieurs requêtes simultanément pour maintenir le GPU actif. Les systèmes de service comme vLLM gèrent si bien la mémoire qu'ils ont multiplié le débit par 2 à 4 par rapport aux systèmes antérieurs, à latence égale.

Déploiement

L'entraînement produit un ensemble de poids stockés chez le fournisseur. Pour répondre, ces poids doivent être déployés : chargés dans la mémoire d'un ou plusieurs GPU, derrière un point de terminaison qui accepte les requêtes. La mémoire nécessaire correspond approximativement au nombre de paramètres multiplié par les octets utilisés par paramètre :

pourquoi les grands modèles nécessitent un matériel puissant
memory for weights ≈ parameters × bytes per parameter

7B model  × 2 bytes (16-bit)  ≈ 14 GB
70B model × 2 bytes (16-bit)  ≈ 140 GB  → several GPUs

L'allocation de ce matériel, le téléchargement des poids et leur chargement dans la mémoire du GPU constituent le démarrage à froid. Pour les modèles gérés, il est généralement rapide ou invisible ; pour les modèles ouverts sur des GPU dédiés, il prend souvent 10 à 40 minutes. Une fois chargé, le déploiement reste actif et répond en quelques secondes — tant qu'il existe.

  1. 01Choisir la duréecoût horaire affiché à l'avance
  2. 02Déploiementchargement des poids · démarrage à froid
  3. 03En lignechat · le compteur tourne
  4. 04Suppressionarrêt de la facturation
Un déploiement dédié est facturé pour chaque heure d'existence, qu'il soit utilisé ou non. Le cycle de vie se termine par sa suppression.
Exemple pratique : test d'un modèle ouvert affiné
  1. Une exécution supervisée sur un modèle ouvert de 8 milliards de paramètres est terminée. En précision 16 bits, ses poids occupent environ 16 Go, il nécessite donc un GPU avec plus de mémoire que cela, plus de l'espace pour les requêtes en cours de traitement.
  2. Vous lancez un chat de test pendant deux heures. Le prix horaire est affiché avant que quoi que ce soit ne soit créé.
  3. Déploiement : le GPU est alloué et les poids se chargent. Cela prend environ 15 minutes ; la facturation du déploiement a commencé.
  4. En direct : chaque question reçoit une réponse en une seconde ou deux. Vous essayez dix vraies questions de la semaine dernière.
  5. Vous terminez plus tôt et mettez fin à la session. L'état Suppression retire le déploiement et arrête la facturation. Coût : la durée d'existence du déploiement × le tarif horaire, quel que soit le nombre de questions posées.

Erreurs courantes

  • Laisser un déploiement dédié tourner toute la nuit « au cas où » — il est facturé à l'heure, qu'il soit utilisé ou non.
  • Évaluer un modèle sur sa première réponse après un démarrage à froid, ou sur son temps de réponse alors qu'il est encore en cours de chargement.
  • Tester avec des paramètres d'échantillonnage ou un prompt système différents de ceux utilisés lors de l'évaluation.
  • S'attendre à ce qu'un modèle affiné connaisse des événements survenus après son entraînement : l'inférence n'apprend rien.

Références et lectures complémentaires

Les sources externes s'ouvrent dans un nouvel onglet.

  1. 01Efficient Memory Management for Large Language Model Serving with PagedAttentionKwon et al., 2023 · arXiv · arxiv.orgL'article sur vLLM : comment les systèmes de service regroupent les requêtes et gèrent la mémoire GPU.
  2. 02Text Generation InferenceHugging Face docs · huggingface.coUne pile de service en production pour les modèles ouverts, avec l'explication de ses fonctionnalités.
  3. 03Inference EndpointsHugging Face docs · huggingface.coCe qu'implique le déploiement d'un modèle derrière un point de terminaison géré.
  4. 04Cold start (computing)Wikipedia · en.wikipedia.orgLe concept général du démarrage à froid.
ConceptServerless vs dédiéLe service serverless facture au jeton sur une capacité partagée sans coût d'inactivité ; un déploiement dédié réserve des GPU pour votre modèle et facture chaque heure de son existence. La solution la plus économique dépend de votre volume d'utilisation.Bonne pratiqueLe modèle tiendra-t-il ? Mémoire pour l'entraînementL'entraînement nécessite de l'espace pour les poids du modèle, ses gradients et l'état de l'optimiseur, en plus de la mémoire de travail. Une règle empirique simple, environ 2 Go par milliard de paramètres pour LoRA et 12 Go pour un réglage fin complet, vous indique avant de commencer si un modèle tiendra sur votre machine.ConceptPourquoi les tokens déterminent les coûtsComment le nombre de tokens se traduit par le prix de l'entraînement et de l'utilisation d'un modèle, avec des chiffres concrets, et quels leviers permettent réellement de réduire la facture.ParamètrePrompt systèmeLe prompt système est une instruction permanente placée avant chaque conversation. Ajouté lors de l'entraînement, il permet au modèle d'apprendre son comportement en présence de ce prompt exact, il doit donc rester identique lors de l'utilisation du modèle.ConceptModèle de base vs modèle affiné, côte à côteUne évaluation pose les mêmes questions mises de côté au modèle de départ et au modèle entraîné, puis compare leurs réponses, afin que vous puissiez voir si l'entraînement a réellement amélioré les réponses.ConceptMode de facturation de l'entraînementLa plupart des services de fine-tuning gérés sont facturés par token traité : les tokens du fichier d'entraînement multipliés par les époques et par un prix. Les tâches sur des GPU loués sont quant à elles facturées au temps. L'utilisation ultérieure du modèle constitue un coût distinct.

Transformez des semaines de travail d'expert en quelques minutes

Découvrez comment Scalata s'adapte à votre équipe, à vos données et à vos contrôles.

Contacter le service commercial