Hébergement d'applications d'IA : dimensionnement des ressources CPU, GPU et de stockage

Commencez par délimiter la charge de travail liée à l'IA

Le choix du matériel commence par la tâche à accomplir, et non par un GPU. Lors de la Inférence Un modèle existant traite des données d'entrée et génère, par exemple, des réponses. Le « fine-tuning » permet d'adapter un modèle pré-entraîné à des données supplémentaires ou à une tâche spécifique ; l'entraînement complet, en revanche, établit les poids du modèle dans le cadre d'un cycle d'entraînement distinct.

Ces objectifs entraînent des profils de charge différents : un service de chat doit répondre aux requêtes, tandis qu'une tâche d'entraînement traite des données sur une longue période et enregistre des résultats intermédiaires. Pour Hébergement IA Tu devrais donc déterminer si ce sont le temps de réponse, le nombre de demandes traitées, la durée de la formation ou encore le coût d'une tâche donnée qui priment.

Documentez la version du modèle et la durée d'exécution, ainsi que le nombre de paramètres, l'architecture, la précision et la quantification prévue. Notez également les longueurs d'entrée et de sortie attendues, les requêtes simultanées ou les tailles de lots, ainsi que la charge de pointe. Cela permet de comparer les offres et les tests ultérieurs sur la base des mêmes hypothèses, plutôt que de se contenter de comparer les caractéristiques nominales du matériel.

Avec un assistant de chat interne, une seule requête brève peut s'exécuter sans problème, tandis que plusieurs longues conversations peuvent surcharger la mémoire. Le cache KV conserve des états supplémentaires lors de la génération de texte ; ses besoins dépendent notamment du modèle et du traitement. Prévoyez donc non seulement un dialogue moyen, mais aussi des contextes longs et une utilisation parallèle.

Précisez également quelles données sont traitées, où elles peuvent être stockées, ainsi que les niveaux de disponibilité et les délais de restauration requis. Ces objectifs opérationnels influencent le choix entre un serveur unique et une architecture plus complexe. Ces hypothèses ne constituent qu'un point de départ : seul un test avec une charge représentative permettra de vérifier si elles sont valables.

Processeur et mémoire vive en cours de développement

Même lorsqu'un modèle s'exécute sur un GPU, le CPU participe au traitement tout au long du chemin des données. Il peut recevoir des requêtes, tokeniser du texte, lire des fichiers et préparer les données d'entrée pour le traitement par le modèle. Si cette préparation est trop lente, le GPU reste en attente ; un accélérateur plus puissant ne résoudra alors pas nécessairement ce goulot d'étranglement.

Le Mémoire de travail En fonction de l'application, il intègre des composants du modèle, des données préparées et des caches de fichiers. À cela s'ajoute de la mémoire pour les processus qui chargent et transforment les données d'entraînement. Il faut donc prévoir non seulement le modèle lui-même, mais aussi le parcours depuis l'ensemble de données jusqu'au lot final, ainsi que des réserves suffisantes pour faire face aux pics de traitement.

Les DataLoaders PyTorch peuvent utiliser plusieurs workers pour le traitement parallèle des données. Cependant, les workers supplémentaires occupent également de la mémoire ; l'espace mémoire partagé peut lui aussi venir à manquer. Il est donc préférable d'augmenter leur nombre progressivement et de surveiller les temps d'attente des données ainsi que les besoins en mémoire, plutôt que d'adopter une valeur fixe comme recommandation universelle.

Un nombre accru de cœurs de processeur est particulièrement utile lorsque les tâches à traiter peuvent être exécutées en parallèle. En revanche, si le débit est limité par les accès au stockage, par une étape de traitement spécifique ou par le GPU lui-même, l'ajout de cœurs supplémentaires n'apporte guère d'amélioration. Le comportement en termes de fréquence d'horloge peut également jouer un rôle pour les requêtes courtes ; pour plus d'informations à ce sujet, consultez l'article consacré à Régulateur de CPU sur les serveurs d'hébergement.

Pour les petits modèles ou les requêtes peu fréquentes, l'inférence sur CPU constitue une alternative à envisager par rapport à un système GPU disponible en permanence. Comparez les deux options en utilisant le même modèle, avec la précision appropriée et en tenant compte du profil de charge prévu. Le facteur décisif est de savoir si le processeur parvient à respecter le temps de réponse requis, même en cas de pics de charge, et quels sont les coûts réels associés.

Bien comprendre le GPU et la VRAM

Dans le cas d'une inférence entièrement résidant sur le GPU, les poids du modèle doivent tenir dans la mémoire disponible du GPU. Le Besoins en VRAM Mais cela ne s'arrête pas là : le runtime a besoin d'autres zones pour les résultats intermédiaires et les zones tampons temporaires. Une carte sur laquelle les poids tiennent juste mathématiquement ne constitue donc pas encore une base sûre pour une exploitation en production.

Dans le cas de la génération de texte autorégressive, il faut ajouter le cache KV. Celui-ci stocke les états de clés et de valeurs déjà calculés afin qu’ils puissent être réutilisés lors des étapes de génération suivantes. Les contextes longs et les requêtes traitées simultanément peuvent accroître ce besoin supplémentaire en mémoire ; l’ampleur de cette augmentation dépend du modèle et du traitement.

La documentation de Transformers 4.48.2 décrit notamment la quantification du cache et le déchargement comme des moyens d'économiser de la VRAM. L'intérêt de ces techniques dépend toutefois de la mise en œuvre et de la charge ; un traitement supplémentaire ou des transferts de données peuvent réduire la vitesse. Il convient donc d’évaluer conjointement la consommation de mémoire et le temps de réponse, plutôt que de considérer automatiquement une économie de mémoire comme un gain de performances.

Lors de l'entraînement, le calcul d'inférence est d'autant plus insuffisant. Outre les poids, il faut prévoir de l'espace de stockage pour les gradients, les états de l'optimiseur et les activations enregistrées. L'importance de ces éléments dépend notamment de l'optimiseur, de la précision et de la méthode d'apprentissage ; des séquences plus longues ou des lots plus volumineux peuvent notamment augmenter l'espace de stockage nécessaire aux activations.

Pour une exécution entièrement résidante sur le GPU, la mémoire VRAM disponible doit pouvoir contenir les poids et les données d'exécution nécessaires. Les méthodes hybrides peuvent conserver une partie du traitement ou des poids du modèle en dehors du GPU ; leur pertinence et le coût des transferts de données dépendent de la durée d'exécution. Il convient de distinguer cela de la mise en cache KV décrite dans Transformers 4.48.2.

Examinez conjointement le modèle, la durée d'exécution et le parallélisme prévu, et vérifiez les pics de mémoire sous une charge représentative. Une mémoire suffisante pour le mode d'exécution choisi ne garantit pas pour autant le temps de réponse ou le taux d'utilisation souhaités.

Calculer approximativement la mémoire nécessaire pour les modèles

Une première estimation de la mémoire nécessaire dépend du nombre de paramètres du modèle et du format dans lequel leurs poids sont effectivement stockés. Elle fournit une limite inférieure pour cette part de mémoire, mais ne constitue pas encore un dimensionnement complet du serveur GPU. En particulier, elle ne précise pas la quantité de mémoire requise par une requête spécifique lors de l'exécution.

Exemple de calcul à titre illustratif, il ne s'agit pas d'une mesure : Sept milliards de paramètres multipliés par deux octets donnent 14 milliards d'octets pour les poids. Divisé par 1 073 741 824 octets par GiB, cela représente environ 13,0 GiB. Cela suppose que tous les poids considérés soient effectivement représentés de manière uniforme avec deux octets par paramètre ; d'autres formats ou représentations supplémentaires modifieraient ce calcul.

Ne sont pas inclus : le Cache KV pour la génération de texte, les tampons temporaires et la surcharge d'exécution. Le cache peut augmenter considérablement, notamment avec des contextes longs ; le nombre de requêtes traitées simultanément a également une incidence sur la réserve nécessaire. La documentation relative au cache de Transformers 4.48.2 décrit également des méthodes permettant d'économiser de la mémoire, mais qui, selon la méthode choisie, peuvent nuire à la vitesse.

Pour l'entraînement, le calcul du poids est encore moins suffisant. La documentation relative à Transformers 4.35.0 estime, pour une configuration type en précision mixte avec AdamW, 18 octets par paramètre, auxquels s'ajoutent les activations. Ce chiffre tient compte d'autres éléments tels que les gradients et les états de l'optimiseur ; les activations dépendent notamment de la longueur de la séquence et de la taille du lot.

Ces 18 octets ne constituent pas un multiplicateur universel applicable à tous les entraînements : l'optimiseur, la précision et la méthode d'entraînement peuvent modifier les besoins. Ni ce chiffre, ni les 13,0 GiB ne permettent donc de formuler une recommandation concernant une taille spécifique de VRAM. Pour faire ce choix, la durée d'exécution concrète et les pics de mémoire attendus sous une charge représentative sont déterminants.

Comparer les charges de travail et les goulots d'étranglement

À poids de modèle égal, les exigences peuvent varier considérablement selon la tâche. Le tableau présente les points de contrôle possibles, sans ordre de priorité ni goulots d'étranglement garantis. La ressource qui constitue réellement le goulot d'étranglement dépend, entre autres, du modèle, du pipeline de données, du parallélisme et de la charge.

Dans le cas d'un assistant de chat interne, le modèle et la génération ne constituent qu'une partie de la planification. Définissez une longueur maximale de saisie, une longueur de sortie attendue et le nombre d'utilisateurs simultanés. Vous pouvez ensuite vérifier si le temps de réponse reste acceptable en cas de pic de charge et si les poids, le cache et la mémoire tampon tiennent tous ensemble dans la mémoire disponible.

Une recherche de documents avec réponse générative suit un parcours de données plus long : les documents sont importés et préparés, des représentations sont générées, un index est interrogé et les contenus pertinents sont transmis au modèle linguistique. L’importation et la recherche peuvent avoir des exigences en matière de CPU, de RAM et de stockage différentes de celles de la génération. C’est pourquoi il est utile de mesurer séparément les durées et les besoins en mémoire de ces étapes.

Lors du réglage fin, il est possible de Accumulation de gradient permettre d'obtenir une taille de lot effective plus importante, même si seuls de petits lots individuels sont traités simultanément. Les gradients de plusieurs étapes sont cumulés avant la mise à jour des paramètres. Cela peut s'avérer utile lorsque la mémoire est limitée, mais ne garantit pas un gain de débit ; les étapes de traitement supplémentaires peuvent prendre du temps.

L'alimentation en données mérite également qu'on s'y attarde : si le prétraitement ou le chargement sont plus lents que le traitement du modèle, un GPU plus puissant n'est pas forcément d'une grande aide. À l'inverse, un pipeline de données rapide ne peut pas compenser une mémoire VRAM insuffisante. Comparez donc les différentes options avec les mêmes données d'entrée et un profil de charge clair.

Planifier le stockage et les connexions GPU

Pour la planification du stockage, il est utile de distinguer les données en fonction de leur type et de leur mode d'accès : les ensembles de données d'entraînement sont lus à plusieurs reprises, tandis que les poids du modèle sont chargés avant utilisation. Ces deux éléments nécessitent une source fiable à partir de laquelle ils pourront être à nouveau mis à disposition après un changement d'hôte. La capacité à elle seule ne suffit pas ; le temps de chargement et les modèles d'accès influencent également le fonctionnement.

Les données de travail temporaires peuvent être stockées sur un disque NVMe local lorsqu'un espace de travail rapide est nécessaire. Vérifiez auprès du fournisseur si ces données résistent aux redémarrages et aux changements d'hôte. Les points de contrôle et les sauvegardes nécessitent en revanche une stratégie de conservation soigneusement planifiée et un processus de restauration validé ; un répertoire de travail local ne constitue pas automatiquement une sauvegarde indépendante.

Un stockage partagé ou basé sur les objets peut faciliter la distribution et la conservation des enregistrements, des poids et des points de contrôle. Il est essentiel de vérifier si l'application prend en charge le mode d'accès choisi et si les données peuvent être chargées et restaurées dans les délais prévus. Un espace de travail local supplémentaire peut s'avérer utile, mais il ne remplace pas le stockage permanent.

GPUDirect Storage permet, sous certaines conditions liées au matériel, aux logiciels et au système de fichiers, d'établir un chemin d'accès plus direct entre le stockage et la mémoire du GPU. Cela s'avère particulièrement intéressant lorsque les opérations d'entrée et de sortie se situent sur le chemin critique et que l'application utilise le chemin pris en charge. Si le processeur doit d'abord décoder ou prétraiter les données, cela peut limiter les avantages.

En cas d'utilisation de plusieurs GPU, il convient de faire la distinction entre la réplication et la répartition. La réplication fournit des copies du modèle afin de répartir les requêtes ; elle ne transforme pas automatiquement les zones de VRAM distinctes en une mémoire partagée. La documentation relative à vLLM 0.20.1 décrit ce type de mise à disposition parallèle des données ; cela n'implique aucune conclusion concernant les autres versions d'exécution.

Le parallélisme tensoriel et le parallélisme en pipeline, en revanche, répartissent certaines parties du traitement et génèrent des besoins de communication. Vérifie à cet effet les connexions entre les GPU ainsi que, dans le cas de plusieurs serveurs, la topologie du réseau et la prise en charge par le modèle et l'environnement d'exécution. La documentation relative à vLLM 0.8.5 aborde ces stratégies de service distribué ; ses recommandations concrètes dépendent de la version.

Détecter les goulots d'étranglement sous charge

Une comparaison pertinente commence par une analyse documentée profil de charge. Indiquez la version du modèle, la précision, le type de matériel utilisé et la version du moteur d'exécution. Précisez les longueurs de contexte typiques et maximales, les longueurs de sortie ainsi que le nombre de requêtes simultanées. Cela permettra de vérifier ultérieurement si une modification de l'infrastructure est possible dans les mêmes conditions.

Lors de l'inférence, mesurez le temps nécessaire pour obtenir le premier token et la vitesse de génération. Enregistrez également les erreurs et les temps de réponse en charge normale et lors des pics de trafic prévus. Un débit moyen élevé ne suffit pas si certaines requêtes, en cas de contextes longs ou de parallélisme élevé, doivent attendre trop longtemps ou échouent.

Pour l'entraînement et le réglage fin, il est conseillé de prendre comme point de départ des étapes ou des exemples traités par unité de temps. Observez également le temps d'attente du pipeline de données avant le prochain lot. Les DataLoaders PyTorch peuvent être préparés à l'aide de plusieurs workers ; leurs besoins en mémoire et la charge exercée sur la mémoire partagée doivent également être pris en compte dans l'évaluation.

Enregistrez les pics d'utilisation de la mémoire GPU et de la RAM, ainsi que l'utilisation du stockage et les temps d'attente. Sur un système NVIDIA existant, la commande de lecture nvidia-smi en fonction du périphérique et du pilote, notamment l'état du GPU et l'utilisation de la mémoire. Il ne modifie aucune configuration de production, mais ne remplace pas les mesures effectuées par l'application.

Une faible utilisation du GPU ne prouve pas en soi l'existence d'un problème au niveau du processeur ou du stockage. Comparez-la dans le temps avec les temps d'attente des données, l'historique des requêtes et l'occupation de la mémoire, et ne modifiez si possible qu'un seul paramètre pertinent par comparaison. Documentez également les limites du test, par exemple si des pics de charge rares ou des saisies particulièrement longues ne sont pas encore pris en compte.

Assurer un fonctionnement fiable de l'infrastructure d'IA

La planification opérationnelle implique une combinaison vérifiable entre le modèle de GPU, le pilote, le framework et la durée d'exécution du modèle. Avant toute mise à jour, vérifiez quelles versions sont compatibles entre elles et comment revenir à la combinaison précédente en cas de problème. Pour les chemins d'accès aux données spécifiques, tels que GPUDirect Storage, le matériel, les logiciels et le système de fichiers doivent également être adaptés à l'utilisation prévue.

Déterminez qui est autorisé à consulter ou à modifier les modèles, les données d'entraînement, les protocoles et les interfaces d'administration. Pour les données sensibles, il convient également de s'assurer que l'emplacement de stockage, le transfert des données et la durée de conservation sont conformes aux exigences en matière de protection des données. Vérifiez ces points pour tous les services concernés, et pas uniquement pour le serveur sur lequel le modèle s'exécute.

A Point de contrôle enregistre l'état d'entraînement en vue d'une reprise ultérieure. Déterminez les états dont votre logiciel d'entraînement a besoin à cette fin, la fréquence à laquelle ils doivent être enregistrés et la durée pendant laquelle ils doivent être conservés. Les poids de modèle destinés à la livraison et les points de contrôle pour la reprise ont des objectifs différents et doivent être identifiés en conséquence.

L'espace de stockage local n'est pas automatiquement permanent et ne remplace pas une sauvegarde indépendante. Renseignez-vous auprès du fournisseur pour savoir ce qu'il advient des données locales en cas de redémarrage, de changement d'hébergeur ou de fin de contrat. Conservez les données nécessaires indépendamment de l'espace de travail et testez concrètement la restauration, y compris le délai nécessaire pour que les données soient à nouveau opérationnelles.

Dans le cas des tâches distribuées, la surveillance porte non seulement sur les GPU individuels, mais aussi sur les nœuds, les connexions réseau et la progression de l'application dans son ensemble. Prévoyez à partir de quel état enregistré une tâche redémarrera après une panne et quelles ressources doivent être disponibles à cet effet. Lorsque des parties du modèle sont réparties sur plusieurs serveurs, leurs connexions influencent également le fonctionnement ; les remarques de la documentation vLLM 0.8.5 sont spécifiques à cette version.

Choisir un modèle d'hébergement et un serveur GPU

Dans le cas de missions ponctuelles, un employé engagé à titre temporaire peut Serveur GPU Cela peut s'avérer judicieux : tu paies en fonction des conditions concrètes de l'offre pour la mise à disposition dont tu as besoin, au lieu de maintenir en permanence une capacité en réserve. Compare également les délais de mise en service, la disponibilité à la date souhaitée ainsi que les coûts liés au stockage et au transfert des données.

En cas de charge régulière, le calcul de contrepartie est intéressant pour une infrastructure réservée en permanence. Il peut offrir un meilleur contrôle sur la durée d'exécution et le chemin des données, mais nécessite une planification spécifique pour les mises à jour, la surveillance et la restauration. Un service d'inférence géré prend en charge une partie de ces opérations ; vérifie toutefois quels modèles, paramètres et chemins de données y sont réellement disponibles.

Pour le choix de l'infrastructure d'apprentissage automatique, veuillez fournir des informations sur variante spécifique de GPU notamment : la capacité de la VRAM, la bande passante mémoire, les formats de calcul pris en charge et la forme de la puce. Ne transposez pas sans vérification les valeurs maximales d'une gamme de produits à chaque variante. Comparez les performances uniquement en fonction de leurs conditions de test et du modèle prévu, plutôt que de vous baser uniquement sur une valeur théorique maximale.

Le type de mise à l'échelle fait également partie de l'offre : les instances répliquées peuvent répartir les requêtes, tandis qu'une partitionnement du modèle nécessite la prise en charge par le runtime et la topologie des connexions. La documentation de vLLM traite du parallélisme des données dans la version 0.20.1 et du service distribué dans la version 0.8.5 ; ces informations ne doivent pas être transposées à une autre version sans vérification préalable.

Définissez d'abord le modèle et le profil de charge, puis évaluez la capacité de stockage et le chemin d'accès aux données, et demandez des devis adaptés. Vérifiez ensuite le temps de réponse, les erreurs et les besoins en ressources à l'aide de requêtes représentatives ou de données d'entraînement. Vous trouverez d'autres éléments d'aide à la décision sur le site Hébergement GPU pour applications web. Sans cette comparaison des charges de travail, il est impossible de formuler une recommandation générale concernant les GPU.