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

Serverless 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.

Chapitre 94 min de lecture3 références

De quoi s'agit-il

Il existe deux façons d'exécuter un modèle entraîné. Le sans serveur (également appelé au jeton ou à la demande) l'exécute sur une capacité que le fournisseur partage entre plusieurs clients : vous envoyez des requêtes et payez pour les jetons entrants et sortants, et lorsque vous n'envoyez rien, vous ne payez rien. Un déploiement dédié réserve du matériel uniquement pour votre modèle : il est toujours chargé et prêt, et vous payez pour chaque heure de son existence.

ServerlessDédié
Facturé parJetons d'entrée et de sortieHeures d'existence du déploiement
Coût d'inactivitéAucunPlein tarif horaire
DémarrageGénéralement immédiatUn démarrage à froid de plusieurs minutes lors de la création
CapacitéPartagée ; soumise à des limites de débitRéservée ; débit prévisible
DisponibilitéUniquement pour les modèles pris en charge de cette manière par le fournisseurLa plupart des modèles entraînés, y compris les modèles ouverts

Comparaison des coûts

le seuil de rentabilité
serverless cost per day  = tokens per day × price per token
dedicated cost per day   = 24 × hourly price               (used or not)
break-even tokens/day    = 24 × hourly price ÷ price per token
utilisation (jetons par jour)coût par jourSEUIL DE RENTABILITÉSERVERLESS MOINS CHERDÉDIÉ MOINS CHERdédié : heures × prix horaireserverless : jetons × prix
Le coût du serverless augmente avec chaque token ; un déploiement dédié coûte le même prix par heure, qu'il réponde à une question ou à un million. En dessous du seuil de rentabilité, le serverless est moins cher, au-dessus, c'est le dédié — et un déploiement dédié inactif se trouve tout à gauche du graphique, payant le prix fort pour rien.

L'idée principale : avec un déploiement dédié, le coût par jeton correspond au prix horaire divisé par le nombre de jetons que vous y traitez réellement au cours de cette heure. À pleine charge, cela peut s'avérer moins cher que le sans serveur. À faible charge, c'est beaucoup plus coûteux, et une heure d'inactivité a un coût par jeton infini. Le sans serveur présente un profil inverse : le prix par jeton est fixe, de sorte que le coût suit exactement l'utilisation.

Pourquoi tout n'est-il pas sans serveur ? Le service partagé fonctionne en gardant un modèle de base chargé pour de nombreux clients. Certains fournisseurs peuvent associer un petit adaptateur affiné à ce modèle partagé pour chaque requête, ce qui rend le service au jeton possible pour les modèles affinés. D'autres nécessitent que l'intégralité du modèle affiné soit chargée sur son propre matériel — ce qui est courant pour les modèles ouverts et les affinements complets — et le déploiement dédié devient alors la seule option. Certains fournisseurs vont plus loin et exigent une capacité réservée pour tout modèle personnalisé.

Exemple pratique : prix indicatifs, trois niveaux d'utilisation
  1. Supposons (à titre d'exemple, et non de devis réels) un modèle sans serveur à 0,60 $ par million de jetons et un déploiement dédié à 5 $ de l'heure, soit 120 $ par jour.
  2. Seuil de rentabilité : 120 $ ÷ 0,60 $ par million = 200 millions de jetons par jour.
  3. Une journée de test : 300 questions × 1 500 jetons = 450 000 jetons. Sans serveur : environ 0,27 $. Dédié : 120 $ pour la journée, ou 10 $ si vous le supprimez après deux heures.
  4. Un assistant interne très sollicité : 50 millions de jetons par jour. Sans serveur : 30 $. Dédié : toujours 120 $.
  5. Un produit à fort volume : 500 millions de jetons par jour. Sans serveur : 300 $. Dédié : 120 $, si un seul déploiement peut supporter la charge.

Comment choisir

  • Utilisez le sans serveur lorsqu'il est disponible et que l'utilisation est faible, incertaine ou irrégulière — tests, évaluations, projets pilotes.
  • Utilisez le dédié lorsque le modèle ne peut être déployé que de cette manière, lorsque le trafic régulier dépasse le seuil de rentabilité, ou lorsque vous avez besoin d'une capacité et d'une latence garanties.
  • Définissez toujours une heure de fin sur un déploiement dédié utilisé pour les tests, et supprimez-le une fois terminé. Les engagements de plusieurs semaines ou mois peuvent réduire le prix horaire, mais suppriment cette option.

Erreurs courantes

  • Oublier un déploiement de test dédié et payer pour des jours d'inactivité.
  • Comparer un prix horaire dédié avec un prix au jeton sans serveur sans effectuer la conversion en fonction de l'utilisation prévue.
  • Supposer qu'un modèle affiné peut être facturé au jeton simplement parce que son modèle de base le permet.
  • Signer un engagement de capacité à long terme pour un modèle qui est encore en phase d'itération.

Références et lectures complémentaires

Les sources externes s'ouvrent dans un nouvel onglet.

  1. 01Increase model invocation capacity with Provisioned Throughput in Amazon BedrockAmazon Bedrock User Guide · docs.aws.amazon.comUn exemple concret de capacité réservée : facturée à l'heure jusqu'à sa suppression, avec des engagements optionnels.
  2. 02Inference EndpointsHugging Face docs · huggingface.coPoints de terminaison dédiés pour les modèles ouverts, avec mise à l'échelle automatique.
  3. 03Serverless computingWikipedia · en.wikipedia.orgLe modèle général de paiement à l'usage, et ses compromis tels que les démarrages à froid.
ConceptInférence et déploiementL'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.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.ConceptCoûts : interpréter les chiffresLe travail des modèles est facturé de plusieurs manières différentes. Ainsi, chaque coût affiché par Scalata comporte un état — Définitif, Estimé, En attente ou Non facturé — qui indique sur quoi le chiffre est basé.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.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.MéthodeLoRA et adaptateurs (PEFT)LoRA gèle le modèle de base et entraîne deux petites matrices à côté des couches sélectionnées, dont le produit est ajouté aux poids gelés. Il réduit considérablement les poids entraînables et la mémoire et, s'il est bien configuré, égale un fine-tuning complet sur des jeux de données de fine-tuning typiques.

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