Quel GPU devez-vous utiliser pour l'inférence LLM

La mémoire est un premier critère de choix pour l’inférence. Vérifiez que les poids, le cache KV et les espaces de travail du moteur tiennent avec une marge suffisante. Cela ne garantit pas une latence stable : mesurez aussi le calcul, la bande passante mémoire et la file d’attente sous charge.

L'architecture GPU sous-jacente joue un rôle crucial dans la détermination des performances d'inférence et de l'adéquation du matériel au déploiement de LLM, car les différences architecturales ont un impact sur l'efficacité et l'évolutivité des grands modèles.

La documentation des GPU Compute indique des RTX 5090 avec 32 Go de VRAM par GPU ; la flotte RTX 4090 a été retirée. Vérifiez dans la console la configuration, la capacité régionale et le prix disponibles avant de lancer votre instance. La compatibilité du modèle et du moteur reste à vérifier.

Un chemin de décision rapide

1. Choisissez le plus petit modèle qui réussit vos évaluations. Comparez plusieurs tailles sur les mêmes tâches avant de dimensionner le matériel.
2. Estimez honnêtement le contexte et les résultats. Les longues conversations et les grandes invites mangent la mémoire.
3. Concurrence cible. Combien d'utilisateurs à la fois avec un TTFT/TPS acceptable ?
4. Choisissez VRAM pour adapter le modèle + le cache + le lot. Tenez compte de la quantité de mémoire GPU et de la quantité de mémoire requise pour la taille spécifique de votre modèle et les exigences en matière de lots : les modèles plus grands et les lots de plus grande taille nécessitent plus de mémoire. Si la limite est proche, passez à un niveau supérieur, utilisez la quantification ou envisagez des formats de moindre précision (tels que FP8 ou int8) comme compromis pour optimiser l'utilisation de la mémoire et le débit.
5. Un seul GPU ou plusieurs GPU. Utilisez plusieurs cartes si une seule ne répond pas aux besoins de mémoire ou de débit. Le moteur doit prendre en charge la répartition du travail ; la VRAM ne devient pas automatiquement un espace mémoire unique. Mesurez aussi le coût des communications.
6. Placez le terminal à proximité des utilisateurs. La latence régionale est plus importante que les micro-optimisations.

Évaluer Compute pour votre charge de travail

Vérifiez les configurations, les régions, les tarifs et les prérequis de déploiement actuels avant de choisir une instance.

Ouvrir la console Compute

Estimer la mémoire des poids

Ces ordres de grandeur concernent les poids uniquement, en Go décimaux : nombre de paramètres × bits par poids ÷ 8 ÷ 10⁹. Ils excluent les métadonnées de quantification, les tenseurs conservés à une autre précision, le cache KV et les espaces de travail du moteur. Ce ne sont pas des seuils de VRAM suffisante.

• 7B, FP16 : environ 14 Go pour les poids.
• 7B, INT8 : environ 7 Go pour les poids.
• 7B, INT4 : environ 3,5 Go pour les poids.
• 13B, FP16 : environ 26 Go pour les poids.
• 13B, INT8 : environ 13 Go pour les poids.
• 13B, INT4 : environ 6,5 Go pour les poids.

La gestion efficace des LLM (grands modèles de langage) nécessite une planification minutieuse de l'allocation de mémoire GPU à la fois pour le modèle et pour son cache, car l'inférence LLM est exigeante en termes de calcul et bénéficie d'un matériel spécialisé.

Ajoutez la mémoire du cache KV et du moteur. Leur coût dépend notamment de l’architecture, de la précision, des contextes et du nombre de requêtes actives. Un pourcentage élevé de VRAM réservée ne suffit pas à diagnostiquer un problème : examinez les préemptions, la file d’attente et les erreurs. Les réglages de vLLM décrivent ces compromis.

Un seul GPU ou plusieurs GPU

Processeur graphique unique est plus simple et souvent plus rapide pour les modèles de classe 7B avec un contexte modéré. Commencez ici si vous le pouvez.

Plusieurs processeurs graphiques est utile lorsque le modèle ou le contexte ne correspond pas, ou lorsque vous avez besoin de plus de débit pour le même objectif de latence. Utilisez le parallélisme des tenseurs ou des pipelines et testez les formes de lots. Le parallélisme augmente la charge de communication, alors mesurez en fonction de vos véritables instructions. Il est essentiel de mesurer les performances réelles et les frais de communication lors de l'optimisation des configurations multi-GPU.

Pièces destinées aux particuliers et pièces pour centres de données

GPU grand public. Les RTX 4090 et RTX 5090 sont des exemples de cartes pouvant servir certains modèles quantifiés ou de taille modérée, selon le contexte et la concurrence. Comparez leur coût par charge réellement servie ; leur catégorie ne garantit pas le meilleur rapport prix-débit. Citer une carte comme exemple matériel ne signifie pas qu’elle est proposée par Hivenet.

GPU de centre de données. Les A100, H100 et L40S proposent des configurations différentes de mémoire, de calcul et d’interconnexion. Vérifiez le modèle exact et son format plutôt que de supposer que toutes les cartes offrent les mêmes fonctions. Par exemple, la fiche NVIDIA du L40S indique 48 Go avec ECC, mais aucune prise en charge de NVLink ni de MIG.

Si vous avez besoin d’ECC, de partitionnement ou d’une interconnexion particulière, vérifiez ces fonctions sur la carte et le serveur retenus. Le coût par jeton dépend du modèle, du moteur et du trafic ; aucune famille de GPU n’est gagnante dans tous les cas.

Latence et débit, en bref

• TTFT. Le délai jusqu’au premier jeton inclut notamment l’attente, le préremplissage et le réseau côté client. Une invite plus longue peut l’augmenter ; une marge mémoire plus grande ne l’augmente pas par elle-même.
• Jetons par seconde (TPS). Distinguez le débit total du serveur de celui d’une réponse. Davantage de VRAM peut permettre plus de requêtes actives, sans garantir un gain de débit ni préserver la latence. Comparez les définitions des métriques avant de comparer les résultats.
• Placement réseau. Mesurez le temps aller-retour entre vos utilisateurs et les régions disponibles. Son effet dépend du trajet réel ; un nombre fixe de millisecondes ne convient pas à tous les déploiements.

Puissance, température et fiabilité

Une carte peut réduire sa fréquence lorsqu’elle atteint ses limites thermiques ou électriques. Pour une charge soutenue, vérifiez le refroidissement, l’alimentation et les conditions d’exploitation du serveur. Surveillez les températures, les fréquences et les événements de limitation.

Placement régional

Choisissez parmi les régions réellement disponibles pour le service utilisé, puis mesurez la latence depuis les utilisateurs. Les emplacements Compute et ceux des modèles de l’Inference API peuvent différer ; ne déduisez pas la disponibilité d’une ancienne liste de régions.

Une approche budgétaire que vous pouvez réutiliser

1. Estimez les jetons de sortie par jour et gardez un profil représentatif des longueurs d’entrée, de sortie et de la concurrence.
2. Divisez ce volume de sortie par le débit agrégé mesuré du déploiement, en jetons de sortie par seconde, avec le même profil de requêtes et les mêmes objectifs de latence.
3. Vous obtenez des secondes de fonctionnement. Divisez par 3 600 pour obtenir des heures, puis multipliez par le nombre de GPU actifs pour estimer les heures-GPU. Appliquez le tarif correspondant sans compter deux fois les GPU si le prix est déjà celui de l’instance. Ajoutez les périodes d’inactivité facturées.
4. Effectuez un contrôle de sensibilité. Variez le contexte et le nombre maximum de jetons ; ce sont ces swings qui coûtent le plus cher.
5. Décidez de la redondance et testez le basculement. Une capacité de secours peut réduire les interruptions, sans garantir à elle seule la continuité du service.

Une surveillance rentable

• TTFT p50/p95 sous charge croissante
• TPS p50/p95 à trafic constant
• Occupation du cache KV, mémoire allouée et préemptions ; taux de réutilisation des préfixes si cette fonction est activée
• Événements d'étranglement thermique
• Taux d'erreur (OOM, délais d'attente, 5xx)

Liste de contrôle rapide

• Commencez par le plus petit modèle qui passe les évaluations.
• Choisissez la VRAM avec espace libre pour le contexte et le batch.
• Préférez un processeur graphique unique jusqu'à ce que vous deviez changer d'échelle.
• Diffusez les réponses et plafonnez max_tokens.
• Placez les terminaux dans la région où vivent les utilisateurs.
• Regardez le TTFT/TPS, la mémoire, la température et les erreurs.

Préparer un test sur Compute

Pour un serveur autogéré, choisissez une instance et un moteur compatibles, puis configurez l’accès, l’authentification et TLS avant d’envoyer du trafic. Consultez les instructions Compute actuelles ; un ancien tutoriel ne garantit pas qu’une image ou une configuration soit encore disponible.

Recommandations finales pour choisir le meilleur GPU pour l'inférence LLM

Choisissez d'abord les GPU par VRAM, puis par vitesse, puis par prix. Gardez les terminaux à proximité des utilisateurs, diffusez les réponses et regardez le TTFT et la mémoire. Laissez les mesures propres, et non les fiches techniques, entraîner les mises à niveau.

Comparez les mesures TTFT/TPS sous charge avant de passer à une carte plus grande. Pour le reste du déploiement, consultez le guide de l’inférence LLM en production.

FAQ

Quel GPU peut convenir à un modèle de 7 milliards de paramètres ?

Une carte de 24 Go peut convenir à certaines configurations 7B, mais ce n’est pas une garantie. Additionnez poids, cache et espaces de travail, puis testez les contextes et la concurrence prévus. La quantification peut réduire les besoins en mémoire.

Quand ai-je besoin de plusieurs GPU ?

Lorsque le modèle ou le contexte ne convient pas à une seule carte avec marge de manœuvre, ou lorsque vous avez besoin d'un débit plus élevé avec la même cible de latence.

Ai-je besoin de NVLink ?

Utile pour les très grands modèles et les longs contextes utilisant plusieurs GPU. Pour 7B—13B avec un contexte modéré, vous pouvez souvent vous en tenir à une seule carte.

4090 contre A100 contre H100 : que dois-je en penser ?

Comparez d’abord la mémoire utilisable, le moteur, la précision, les interconnexions et le coût sur votre charge. Les gains publiés pour un H100 face à un A100 dépendent d’une configuration de benchmark ; ils ne constituent pas un multiplicateur universel applicable au RTX 4090 ou à votre service.

Qu'est-ce qui change pour le contexte long (plus de 32 000) ?

La croissance du cache domine. Passez à plus de VRAM par nœud, réduisez les instructions via RAG ou répartissez-les avec soin sur les GPU.

La quantification me permettra-t-elle de supprimer un niveau de GPU ?

La quantification peut réduire les besoins en mémoire, sans garantir un passage à une carte plus petite. Vérifiez la compatibilité du format avec le moteur et le GPU, puis mesurez la qualité, le débit et la mémoire sur vos tâches.

Avez-vous besoin d'un GPU pour l'inférence LLM ?

Non, un GPU n’est pas obligatoire. Des moteurs tels que llama.cpp prennent aussi en charge le CPU et des configurations hybrides. Choisissez selon la mémoire disponible, la taille du modèle et vos objectifs de latence et de débit.

De quel processeur graphique ai-je besoin pour LLM ?

Dimensionnez le GPU pour le modèle, sa précision, le contexte et la concurrence. Les poids d’un modèle 13B en FP16 représentent déjà environ 26 Go décimaux, avant le cache : ils ne tiennent pas intégralement dans 24 Go. La quantification ou une répartition du modèle peut changer ce calcul. L’entraînement et le fine-tuning ont des besoins supplémentaires.

Comment choisir le GPU pour l'inférence ?

Tenez compte de la taille du modèle, de la VRAM requise, des besoins en débit, des cibles de latence et du budget. Commencez par vous assurer que le GPU dispose de suffisamment de mémoire pour le modèle et son cache, puis évaluez les facteurs de performance tels que les cœurs CUDA, les cœurs tenseurs et la bande passante mémoire. Envisagez également des configurations à GPU unique ou multi-GPU en fonction de l'échelle de charge de travail.

Comment comparer les performances de l’A100 et du RTX 4090 ?

Utilisez le même modèle, la même précision, le même moteur et le même profil de requêtes. Mesurez le débit, les latences et le coût, en documentant la mémoire et les interconnexions. Une fiche technique seule ne permet pas de désigner le plus rapide pour votre service.

Quelle est la différence entre le H100 et l'A100 par rapport au RTX 4090 ?

Les H100 et A100 sont des GPU de centre de données optimisés pour les charges de travail d'IA avec des fonctionnalités telles qu'une VRAM plus élevée, des cœurs tenseurs, NVLink et la prise en charge des GPU multi-instances. Le RTX 4090 est un GPU grand public offrant des performances et une efficacité excellentes pour les modèles plus petits, mais il ne dispose pas de certaines fonctionnalités professionnelles et de grands pools de mémoire que l'on retrouve dans le H100/A100. Le H100 et l'A100 sont tous deux idéaux pour les charges de travail d'IA à grande échelle, tandis que le RTX 4090 convient mieux aux tâches plus petites.

Le Nvidia A100 est-il toujours d'actualité ?

L’A100 peut rester adapté à certaines charges. Comparez sa capacité mémoire, sa compatibilité logicielle, sa disponibilité et son coût mesuré aux alternatives, sans déduire sa pertinence de son ancienneté seule.

Le RTX 4090 est-il encore proposé sur Compute ?

Non. Hivenet indique que sa flotte RTX 4090 a été retirée. Cela décrit l’offre Compute, pas le statut mondial de fabrication ou de vente de cette carte.

De quelle quantité de VRAM un modèle 7B a-t-il besoin ?

Pour 7 milliards de paramètres exactement, les poids FP16 représentent environ 14 Go décimaux. Le besoin total inclut aussi le cache KV et le moteur. La quantification réduit la taille des poids, mais ne supprime pas ces autres coûts.

Quel GPU exécutera le modèle 7B ?

Le nombre de paramètres ne suffit pas à fixer un minimum de VRAM. Choisissez la précision, la longueur du contexte et la concurrence, puis mesurez le besoin total et la performance sur le matériel envisagé.

De quel GPU avez-vous besoin pour Mistral 7B ?

Pour Mistral 7B, vérifiez le checkpoint exact, sa précision et le moteur utilisé. Le cache dépend aussi du contexte et de la concurrence. Une version quantifiée peut fonctionner avec moins de mémoire qu’une version FP16 ; un seuil universel de 16 Go serait trompeur.

‍