Choisir un GPU pour votre modèle

Dans la console, ouvrez Catalog, puis Launch by workload. Indiquez ce que vous voulez faire, avec quel modèle, ainsi que votre budget et vos préférences. Vous obtenez les machines adaptées à votre charge de travail, de la moins chère à la plus chère, chacune avec la raison pour laquelle elle convient.

La réponse est un calcul, identique à chaque fois pour les mêmes données. Rien n’est réservé tant que vous n’appuyez pas sur Launch pour une machine.

Les trois étapes

1. Ce que vous voulez faire : exécuter un modèle, faire le fine-tuning d’un modèle, générer des images ou ouvrir un notebook.
2. Quel modèle : choisissez-le dans la liste, puis sa précision (16 bits, 8 bits ou 4 bits), le contexte par requête et le nombre de requêtes simultanées. Pour un notebook sans modèle, saisissez la mémoire GPU nécessaire.
3. Budget et préférences : un budget, un prix horaire maximal, le niveau (Secure, Community ou l’un ou l’autre) et les pays où la machine doit tourner. EU couvre tous les États membres de l’Union européenne.

Chaque modèle affiche son nombre de paramètres, sa licence et un lien vers les données qui ont servi à son dimensionnement.

Calcul de la mémoire GPU

Pour un modèle de langage, la mémoire nécessaire est la somme de quatre lignes :

Chaque valeur provient de la configuration publiée du modèle : paramètres, couches, têtes KV, dimension de tête, contexte maximal. Le résultat affiche chaque ligne avec sa formule appliquée.

Exemple : Llama 3.1 8B en 16 bits

Avec un contexte de 4 096 jetons et une requête à la fois :

Un GPU de 24 GiB le contient. Un GPU de 16 GiB, non. En 4 bits, le même modèle demande environ 6,1 GiB.

Le cache KV croît avec le contexte et avec le nombre de requêtes : à 128 000 jetons pour une requête, il occupe à lui seul 15,6 GiB. Dimensionnez le contexte selon l’usage réel de vos requêtes.

Fine-tuning

Fine-tune a model dimensionne un entraînement LoRA. Le modèle de base reste figé et de petits adaptateurs sont entraînés :

• LoRA sur une base en 16 bits ou 8 bits : les poids de base, plus des adaptateurs de rang 16 sur les projections d’attention, à 16 octets par paramètre entraînable (poids, gradient et états AdamW).
• QLoRA sur une base en 4 bits : la base en 4-bit NormalFloat, 4,127 bits par paramètre avec double quantification, plus les mêmes adaptateurs.

Les activations sont ajoutées selon la longueur de séquence et la taille de lot saisies, avec le gradient checkpointing activé. Le champ du contexte devient Sequence length et celui des requêtes devient Batch size.

Les formules proviennent de travaux publiés : LoRA, QLoRA, ZeRO pour les états de l’optimiseur, et recalcul des activations.

Génération d’images

Un pipeline d’images charge plusieurs réseaux : le débruiteur, ses encodeurs de texte et un autoencodeur. Les poids de chacun sont comptés exactement, puis la marge et le runtime. La marge vaut pour une image à la résolution native du modèle. Les images plus grandes et les lots demandent davantage. D’où la faible confiance des résultats pour les images.

Parole

Pour Whisper, le cache KV du décodeur est dimensionné sur sa fenêtre de 30 secondes, pour chaque flux audio simultané.

Vérification d’une machine

Une machine convient quand sa mémoire GPU contient le total :

• Sur un seul GPU, quand un seul suffit.
• Sur plusieurs GPU de la même machine, pour un modèle de langage trop grand pour un seul : les poids et le cache KV sont répartis à parts égales par parallélisme de tenseurs. Le nombre de têtes d’attention du modèle doit alors être divisible par le nombre de GPU.
• Les modèles d’images, les modèles de parole et le fine-tuning sont vérifiés sur un seul GPU.

La mémoire GPU d’une machine Secure provient du centre de données ou de la fiche technique du fabricant. Sur une machine Community, c’est la valeur signalée par la machine du fournisseur, non vérifiée par Node Lodge.

Quand une donnée manque (la machine ne signale pas sa mémoire GPU, ou une caractéristique du modèle n’est pas publiée), la machine est écartée. Aucune machine n’est recommandée sur une supposition.

Lire le résultat

• GPU memory needed : le total, ligne par ligne, avec les hypothèses retenues.
• Recommended machines : les machines qui conviennent, de la moins chère à la plus chère. Ouvrez une ligne pour voir Why it fits et ses Limits : l’origine de la valeur de mémoire, une marge étroite, une limite de réservation, une machine interruptible.
• Budget covers : la durée que votre budget couvre sur cette machine, à son tarif.
• Confidence : élevée, moyenne ou faible. Élevée pour un modèle de langage en 16 bits sur une machine dont la mémoire provient du centre de données. Plus faible quand les poids sont quantifiés, quand le modèle est réparti sur plusieurs GPU, quand la valeur provient du signalement d’un fournisseur, quand la marge est étroite, ou pour la génération d’images et le fine-tuning, plus sensibles aux paramètres.
• Alternatives : les machines qui conviennent mais enfreignent une préférence (au-dessus de votre prix, autre niveau), et le même modèle en précision réduite quand cela ouvre davantage de machines ou une machine moins chère.
• Constraints applied : tout ce dont la réponse a tenu compte.

Les machines situées hors des pays choisis ne sont jamais proposées, pas même en alternative. Une machine dont l’emplacement est inconnu n’est pas considérée comme située dans ces pays.

Limites

• La vitesse n’est pas estimée. Les jetons par seconde ou les images par minute n’apparaissent qu’une fois mesurés sur la machine.
• L’adéquation est un calcul. Les frameworks diffèrent : un serveur d’inférence peut réserver plus de mémoire que nécessaire, un script d’entraînement peut conserver des copies supplémentaires. Si vous modifiez les réglages du framework, tenez compte de la marge.
• Machines disponibles maintenant. Seules les machines Community en ligne et les machines Secure en stock sont vérifiées.
• Les machines Community tournent sur le matériel du fournisseur. Le fournisseur peut lire la mémoire de la session. Voir Secure et Community.