Meilleures GPU Cloud pour le déploiement et la mise en service de grands modèles de langage

Ce que l’hébergement d’un LLM exige réellement d’un GPU loué

L’hébergement d’un grand modèle de langage est une charge de travail fondamentalement différente de son entraînement. L’entraînement est limité par le débit et tolère la latence ; l’hébergement est sensible à la latence, limité par la mémoire et irrégulier. Lorsque vous louez un GPU pour déployer un LLM derrière une API, le goulot d’étranglement n’est que rarement la puissance brute en FLOPS. C’est la quantité du modèle et de son cache KV que vous pouvez stocker en VRAM, la vitesse à laquelle cette mémoire peut être lue, et le nombre de requêtes simultanées que vous pouvez regrouper avant que le nombre de tokens par seconde par utilisateur ne s’effondre.

Le cache KV est la partie que la plupart des gens sous-estiment. Chaque requête active stocke les clés et valeurs d’attention pour son contexte, et cette empreinte augmente avec la longueur de la séquence et le nombre d’utilisateurs simultanés. Un modèle qui tient confortablement au repos peut manquer de mémoire dès que vous poussez un trafic réel avec des invites longues. C’est pourquoi les déploiements d’hébergement nécessitent souvent plus de marge en VRAM que ce que suggèrent les seuls poids du modèle.

Comment dimensionner le GPU par rapport au modèle

La première question pratique est de savoir si le modèle tient sur un seul GPU ou doit être réparti sur plusieurs. En lisant la comparaison ci-dessus par rapport à votre modèle, pesez ces facteurs :

• La capacité VRAM détermine quels modèles peuvent tenir. Un modèle quantifié de 7B à 13B en FP8 ou INT8 peut être servi à partir d’un seul accélérateur de milieu de gamme, tandis qu’un modèle de 70B en BF16 nécessite généralement une carte à haute mémoire ou un nœud multi-GPU. Les modèles très grands de classe frontière nécessitent effectivement plusieurs GPU haut de gamme reliés ensemble.
• La bande passante mémoire fixe la vitesse de génération des tokens. Le décodage autorégressif lit l’ensemble des poids pour chaque token produit, donc la mémoire de classe HBM (comme sur les cartes de centre de données) génère des tokens bien plus rapidement que les cartes grand public basées sur GDDR à taille de modèle équivalente. Pour le chat interactif, la bande passante importe souvent plus que la puissance de calcul.
• Les précisions supportées déterminent à quel point vous pouvez réduire la taille du modèle. Les cartes avec support tensoriel FP8 et INT8 vous permettent de servir des modèles plus grands avec moins de VRAM et à un débit plus élevé, à condition que votre pile d’hébergement et le schéma de quantification du modèle soient compatibles.
• L’interconnexion est importante dès qu’un modèle s’étend sur plusieurs GPU. L’hébergement en parallèle tensoriel échange des activations entre les GPU à chaque couche, donc des liens de classe NVLink à l’intérieur d’un nœud offrent une latence nettement meilleure que les configurations PCIe seules. Pour les déploiements sur un seul GPU, l’interconnexion est sans importance.

Hébergement sur un seul GPU versus multi-GPU

Si votre modèle et son cache KV maximal tiennent sur un seul GPU, gardez-le là. L’hébergement sur un seul GPU évite totalement les surcoûts de communication entre appareils et est plus simple à gérer. Ne passez au parallélisme tensoriel ou à l’hébergement multi-nœuds que lorsque le modèle ne peut vraiment pas tenir, car chaque GPU ajouté introduit un coût de synchronisation et complique l’autoscaling. Quand vous avez besoin de plusieurs GPU, préférez les instances dans la liste ci-dessus qui associent des cartes à haute mémoire avec une interconnexion rapide dans le nœud plutôt que d’assembler des cartes faiblement couplées.

Fonctionnalités du fournisseur importantes pour l’hébergement, pas pour l’entraînement

Au-delà du silicium, le modèle opérationnel du fournisseur décide si un déploiement est viable. En examinant la comparaison ci-dessus pour une charge d’hébergement plutôt qu’une session d’entraînement, priorisez différemment :

• Le démarrage à froid et le temps de configuration deviennent des préoccupations majeures. Un point de terminaison d’hébergement qui se met à l’échelle à zéro entre les pics de trafic paie le coût du démarrage à froid à chaque montée en charge, donc un provisionnement rapide et la mise en cache des images affectent directement la latence en queue.
• La granularité de facturation modifie l’économie du trafic irrégulier. Une facturation à la seconde ou à la minute convient aux points de terminaison autoscalés qui lancent et arrêtent des instances ; une facturation grossière à l’heure pénalise ce modèle.
• La fiabilité à la demande plutôt que spot est généralement le bon choix. Les instances interruptibles ou spot sont excellentes pour l’entraînement et les tâches par lots mais risquées pour un point de terminaison orienté utilisateur, où une reprise en main en cours de requête fait chuter le trafic en direct. Le spot peut néanmoins bien servir pour l’inférence par lots non interactive.
• Le stockage persistant et le chargement rapide du modèle réduisent la douleur des redémarrages. Des poids de plusieurs gigaoctets qui se rechargent depuis un stockage objet froid à chaque redémarrage ajoutent des minutes d’indisponibilité ; les volumes mis en cache ou attachés raccourcissent cela.
• Le réseau et la sortie de données impactent le coût à grande échelle. Une inférence à haut débit peut déplacer beaucoup de données vers l’extérieur ; vérifiez les conditions de sortie avant de vous engager dans un déploiement à fort trafic.

Traitement par lots versus temps réel, et où se situe le coût

Décidez tôt quel mode vous optimisez. L’hébergement interactif en temps réel valorise un temps faible jusqu’au premier token et des taux de tokens stables par utilisateur, ce qui favorise une mémoire à haute bande passante et des tailles de lots modestes. L’inférence par lots ou hors ligne valorise le débit total et peut regrouper de grands lots sur du matériel moins cher ou interruptible, échangeant la latence par requête contre un coût par token bien meilleur. Beaucoup d’équipes utilisent les deux : un niveau réactif à la demande pour les utilisateurs en direct et un niveau par lots soutenu par spot pour la génération en masse.

En termes de coût de location, l’hébergement couvre tout le spectre. Un petit modèle quantifié sur une carte de milieu de gamme est peu coûteux et largement disponible ; les modèles de pointe sur des nœuds multi-GPU à haute mémoire sont rares, plus chers et parfois limités en capacité lors des pics de demande. Comme les tarifs évoluent constamment et varient selon la région et l’engagement, considérez la comparaison en direct ci-dessus comme source de vérité plutôt que tout chiffre fixe, et comparez les instances sur la VRAM, la classe de bande passante, l’interconnexion et le modèle de facturation ensemble plutôt que sur le prix affiché seul.

Questions fréquemment posées

De combien de VRAM ai-je besoin pour héberger un LLM ?

Prévoyez la mémoire pour les poids du modèle à la précision choisie plus une marge substantielle pour le cache KV, qui croît avec la longueur du contexte et le nombre d’utilisateurs simultanés. À titre indicatif, les petits et moyens modèles quantifiés peuvent être servis à partir d’une seule carte de milieu de gamme, tandis que les grands modèles en haute précision nécessitent une carte à haute mémoire ou plusieurs GPU. Dimensionnez toujours pour la concurrence maximale, pas pour l’inactivité.

Les GPU spot ou interruptibles conviennent-ils pour l’hébergement de LLM ?

Pour les points de terminaison en temps réel orientés utilisateur, généralement non, car une reprise en main peut interrompre les requêtes en cours et forcer des redémarrages à froid. Les instances spot conviennent bien à l’inférence hors ligne ou par lots, où les interruptions ne font que retarder le débit sans casser une session interactive. Beaucoup d’équipes gardent une capacité à la demande pour le trafic en direct et utilisent le spot pour les tâches en masse.

Pourquoi la bande passante mémoire importe-t-elle plus que la puissance de calcul pour l’hébergement ?

Le décodage token par token lit les poids du modèle en mémoire pour chaque token généré, donc la vitesse de génération est limitée par la rapidité avec laquelle le GPU peut lire la mémoire plutôt que par ses FLOPS maximaux. C’est pourquoi les cartes de centre de données équipées de HBM produisent des tokens plus rapidement que les cartes grand public tenant le même modèle, et pourquoi la bande passante est une colonne clé à comparer ci-dessus.

Dois-je héberger sur un seul GPU ou répartir sur plusieurs ?

Utilisez un seul GPU chaque fois que le modèle et son cache KV maximal tiennent, car cela évite la communication entre appareils et simplifie la mise à l’échelle. Passez au parallélisme tensoriel multi-GPU seulement lorsque le modèle ne peut vraiment pas tenir, et dans ce cas, choisissez des instances qui combinent des cartes à haute mémoire avec une interconnexion rapide dans le nœud.