VRAM de la RTX 5090 pour l'IA : que peut-on faire avec 32 Go ?

La RTX 5090 est équipée de 32 Go de VRAM GDDR7. Pour les charges de travail liées à l'IA, cela suffit pour des modèles de langage de 7B et 8B paramètres en haute précision, de nombreux modèles de 20B à 30B avec quantification, ainsi que pour des flux de génération d'images exigeants. Un modèle de 70B est généralement trop volumineux pour une seule carte de 32 Go, même en précision 4 bits.

Cette réponse simplifiée occulte l'aspect crucial en pratique. Les poids du modèle ne sont pas les seuls à occuper la mémoire GPU. La longueur du contexte, le cache KV, les requêtes simultanées, la surcharge du moteur d'inférence et la précision utilisée peuvent transformer un modèle qui semble tenir confortablement sur le papier en un modèle saturant la mémoire en conditions réelles.

Si vous choisissez un GPU cloud RTX 5090 pour l'IA, la question pertinente n'est donc pas seulement de savoir combien de paramètres il peut charger, mais quelle marge de manœuvre réelle il reste une fois le modèle en cours d'exécution.

Quelle est la capacité VRAM de la RTX 5090 ?

La NVIDIA GeForce RTX 5090 pour ordinateur de bureau dispose de 32 Go de VRAM GDDR7 avec 1 792 Go/s de bande passante mémoire. Elle repose sur l'architecture Blackwell de NVIDIA et prend en charge des formats de précision réduite conçus pour optimiser l'utilisation de la mémoire et accélérer les charges de travail IA.

Cet article concerne la RTX 5090 de bureau utilisée pour des charges de travail GPU dans le cloud, y compris les RTX 5090 disponibles via Compute with Hivenet. Les GPU pour ordinateurs portables portant des noms similaires ont des spécifications différentes et ne doivent pas être considérés comme du matériel équivalent.

Pour l'IA, la capacité VRAM et la bande passante mémoire répondent à des besoins distincts.

La capacité VRAM détermine ce qui peut être chargé. Les poids du modèle, le cache, l'environnement d'exécution et les données de travail doivent tous trouver leur place en mémoire.

La bande passante mémoire influence la vitesse de transfert des données. Une bande passante élevée peut améliorer les performances pour les charges de travail gourmandes en mémoire, mais elle ne peut compenser un modèle trop volumineux pour la carte.

Un GPU rapide de 32 Go reste un GPU de 32 Go.

Quelles tailles de modèles d'IA tiennent dans 32 Go de VRAM ?

Vous pouvez obtenir une première estimation utile grâce à un calcul simple :

nombre de paramètres × octets par paramètre = mémoire approximative pour les poids

Pour les précisions courantes, cela nous donne environ :

Il s'agit d' estimations basées uniquement sur les poids. Elles sont utiles pour valider ou écarter des configurations, mais ne garantissent en rien la consommation réelle de VRAM.

Un modèle de 32B en 8 bits en est un bon exemple. Le calcul donne environ 32 Go pour les poids. Cela n'en fait pas un choix judicieux pour un GPU de 32 Go, car il ne resterait aucune marge significative pour le moteur de service, le cache, les allocations temporaires ou la charge de travail elle-même.

La cible idéale est rarement un modèle qui remplit tout juste la mémoire.

Pourquoi les poids du modèle ne disent pas tout

Un LLM a besoin de mémoire pour ses paramètres, mais l'inférence génère également un état de fonctionnement.

La variable la plus importante est souvent le cache KV, qui stocke les informations des jetons déjà traités afin que le modèle n'ait pas à les recalculer à chaque étape de génération.

Un contexte plus long signifie un cache plus volumineux. Davantage de requêtes simultanées signifient encore plus de cache.

Les moteurs d'inférence comme vLLM doivent donc diviser la mémoire GPU disponible entre l'exécution du modèle et le cache KV, plutôt que de considérer les 32 Go comme un espace réservé uniquement aux poids. Si vous utilisez Hivenet, notre guide vLLM couvre la configuration du service lui-même.

C'est pourquoi deux personnes peuvent exécuter le même modèle sur le même GPU et rapporter des limites de mémoire différentes. L'une peut tester une courte requête utilisateur unique, tandis que l'autre peut gérer de longues conversations pour plusieurs utilisateurs.

Les deux résultats peuvent être corrects.

Les modèles 7B et 8B tiennent facilement

Les modèles à sept et huit milliards de paramètres constituent le cas le plus simple.

En BF16, leurs poids occupent environ 14 à 16 Go. Cela laisse une quantité confortable des 32 Go de la RTX 5090 pour le contexte, le cache et l'exécution de l'inférence.

Vous pouvez toujours les quantifier. Cela permet de libérer de la mémoire pour une meilleure concurrence ou des contextes plus longs, et peut améliorer le débit sur le matériel gérant efficacement les précisions inférieures.

Mais vous n'avez généralement pas besoin d'une quantification agressive simplement pour charger un modèle 8B sur le GPU.

Cela rend cette gamme de taille utile lorsque la latence et la prévisibilité du service importent plus que l'exécution du plus gros modèle que le matériel peut techniquement supporter.

Les modèles 14B tiennent, mais le BF16 laisse peu de marge

Un modèle 14B nécessite environ 28 Go pour les poids en BF16.

C'est en dessous des 32 Go, mais la différence n'est pas suffisante pour considérer la mémoire restante comme un espace de travail confortable. Une fois que le cache et la surcharge d'exécution entrent en ligne de compte, les limites sont vite atteintes.

En 8 bits, le besoin en poids tombe à environ 14 Go. Cela donne au même GPU beaucoup plus d'espace pour le contexte et les requêtes simultanées.

Cela illustre une différence importante entre pouvoir exécuter et exécuter de manière optimale.

Si votre application nécessite des prompts courts et une expérimentation mono-utilisateur, une configuration serrée peut être acceptable. Si vous développez une API qui doit rester réactive sous des requêtes simultanées, laisser une marge de mémoire fait partie intégrante de la conception de l'infrastructure.

Les modèles 27B et 32B sont ceux pour lesquels la quantification change la donne

Sans quantification, cette gamme de modèles est trop volumineuse pour une seule RTX 5090.

Un modèle 27B nécessite environ 54 Go pour les poids en BF16. Un modèle 32B atteint environ 64 Go.

En 4 bits, l'arithmétique de base ramène ces chiffres à environ 13,5 Go et 16 Go.

Les points de contrôle quantifiés réels nécessitent davantage que ce calcul simpliste, car les formats de quantification peuvent inclure des échelles, des métadonnées et certains composants conservés dans une précision supérieure. Malgré tout, la réduction de la mémoire est suffisamment importante pour rendre ces modèles exploitables sur un GPU de 32 Go.

C'est également là que la quantification spécifique à Blackwell devient intéressante.

Par exemple, notre HivenetQuant Qwen3.6-27B-NVFP4 utilise la quantification NVFP4 W4A4 pour le MLP, tout en conservant les couches d'attention et DeltaNet récurrentes en FP8. La répartition des couches est choisie en fonction de la sensibilité des poids plutôt que d'imposer la même précision à chaque partie du modèle.

Nous détaillerons la configuration réelle et les compromis de performance dans notre guide sur le GPU cloud Qwen3.6-27B.

Le point essentiel dépasse le cadre d'un format unique : la quantification est un choix d'ingénierie spécifique au modèle, et non un bouton de compression magique.

Un bon point de contrôle quantifié peut économiser une quantité importante de mémoire avec peu de perte pratique pour une charge de travail donnée. Un mauvais peut économiser de la mémoire au détriment d'une qualité dont vous avez réellement besoin.

Testez le modèle que vous prévoyez de déployer.

Une RTX 5090 peut-elle faire tourner un modèle de 70B ?

Pas confortablement sur un seul GPU.

En 4 bits, 70 milliards de paramètres nécessitent environ 35 Go pour les poids, avant même de prendre en compte le format de quantification ou la mémoire d'exécution. Cela dépasse déjà la capacité de 32 Go de la RTX 5090.

Le déchargement sur CPU (offloading) peut permettre de faire tourner certains modèles trop volumineux en conservant une partie du modèle dans la mémoire vive du système, mais cela modifie considérablement les caractéristiques de performance. Les données doivent circuler entre la mémoire du CPU et celle du GPU, et le GPU ne peut plus traiter l'intégralité du modèle localement.

Pour une inférence soutenue, l'utilisation de plusieurs GPU est généralement la solution la plus propre.

Calculez avec Hivenet prend en charge les configurations multi-GPU, permettant ainsi de répartir les modèles volumineux sur plusieurs cartes plutôt que de les forcer sur une seule ne disposant pas de suffisamment de mémoire.

Notre futur guide des besoins GPU pour Llama 3.3 70B abordera la quantification, le parallélisme tensoriel et la différence concrète entre faire tenir un modèle 70B et le servir efficacement.

La longueur de contexte peut rendre un modèle qui tenait en mémoire inutilisable

La longueur de contexte maximale est facile à lire sur la fiche d'un modèle. La question plus complexe est de savoir si votre matériel peut la gérer efficacement.

Le cache KV augmente avec la quantité de contexte actif. Sa taille réelle dépend de l'architecture du modèle, de la précision du cache, de la taille des lots, de la longueur de séquence et du moteur d'inférence.

Imaginons qu'un modèle 27B quantifié laisse beaucoup de mémoire libre après le chargement de ses poids. Avec des prompts courts et une seule requête à la fois, la configuration peut sembler confortable.

Augmentez considérablement le contexte et servez plusieurs utilisateurs simultanément, et le cache pourra consommer une part bien plus importante de la VRAM restante.

Cela signifie que la fenêtre de contexte maximale annoncée par un modèle et celle qui est réellement viable sur un GPU donné sont deux choses différentes.

Planifiez en fonction de la charge de travail que vous prévoyez de servir plutôt que du chiffre le plus élevé affiché sur la page du modèle.

DeepSeek rend le problème de la taille des modèles particulièrement visible

« Puis-je faire tourner DeepSeek-R1 ? » ressemble à une question matérielle, mais elle est incomplète.

DeepSeek-R1 existe aux côtés de modèles distillés beaucoup plus petits, et ces configurations ont des besoins en mémoire radicalement différents. Considérer « DeepSeek-R1 » comme une charge de travail unique et fixe est la raison pour laquelle les gens finissent avec des recommandations GPU trompeuses.

Sur une RTX 5090 de 32 Go, la question pertinente est de savoir quel modèle distillé et quelle précision conviennent à la charge de travail.

Nous détaillerons ces choix séparément dans notre guide sur la taille et les besoins en mémoire de DeepSeek-R1.

La même rigueur s'applique à toute famille de modèles. Utilisez le point de contrôle exact, la précision, les besoins en contexte et la configuration de service lors du calcul de la mémoire.

32 Go sont-ils suffisants pour Stable Diffusion et FLUX ?

Pour de nombreuses charges de travail liées à la génération d'images, oui, mais le calcul de la mémoire diffère de celui de l'inférence LLM.

Les modèles d'image ne correspondent pas aussi précisément au tableau de nombre de paramètres ci-dessus, car le pipeline peut inclure plusieurs composants volumineux et l'utilisation de la mémoire varie en fonction de la résolution, de la taille des lots, de la mise à l'échelle, des ajouts de type ControlNet, ainsi que de l'interface ou du flux de travail utilisé.

NVIDIA indique que FLUX.1 [dev] nécessite plus de 23 Go de VRAM en opération FP16 standard. C'est un seuil intéressant, car il place la charge de travail au-delà de la zone de confort d'un GPU de 24 Go, tout en laissant une marge sur une RTX 5090 de 32 Go.

La prise en charge du FP4 par Blackwell peut réduire davantage les besoins en mémoire pour les flux de travail compatibles.

Nous traitons déjà la question matérielle plus large dans notre guide des exigences GPU et VRAM pour Stable Diffusion. Nous publierons également un guide pratique des GPU cloud pour FLUX.1 [dev] pour le flux de travail réel.

Encore une fois, faire tenir le modèle de base n'est qu'une partie du travail. Un flux de travail qui ajoute des résolutions plus élevées, plusieurs modèles, une mise à l'échelle ou un conditionnement supplémentaire peut consommer considérablement plus de mémoire.

Le réglage fin nécessite plus de VRAM que l'inférence

Un modèle qui convient parfaitement à l'inférence peut être beaucoup trop volumineux pour un entraînement complet des paramètres sur le même GPU.

L'entraînement doit stocker bien plus que les poids du modèle. Selon la méthode, la mémoire est également consommée par les gradients, les états de l'optimiseur, les activations, les lots et d'autres données d'entraînement.

C'est pourquoi le réglage fin complet devient si rapidement coûteux en VRAM.

Les approches efficaces en termes de paramètres telles que LoRA et QLoRA réduisent les besoins en entraînant un ensemble de paramètres beaucoup plus restreint tout en laissant la majeure partie du modèle de base inchangée.

Cela en fait une solution bien plus adaptée à l'expérimentation sur un seul GPU.

Notre page de formation et de réglage fin couvre l'aspect infrastructure. Le prochain guide de réglage fin LoRA détaillera les compromis réels en matière de mémoire et le processus d'entraînement.

Quelle marge de manœuvre devez-vous prévoir ?

Il n'existe pas de pourcentage universel adapté à chaque modèle et à chaque moteur d'inférence.

Une règle plus pertinente consiste à éviter de choisir un point de contrôle dont les poids occupent la quasi-totalité de la VRAM disponible avant même le début de votre charge de travail.

La marge nécessaire dépend de la nature de vos activités :

• Une inférence courte et mono-utilisateur peut tolérer une configuration plus serrée.
• Un contexte long nécessite davantage de cache.
• Une concurrence élevée requiert plus de mémoire pour les requêtes actives.
• Les flux de travail liés aux images nécessitent de l'espace pour le reste du pipeline.
• Le réglage fin présente un profil de mémoire totalement différent de celui de l'inférence.

Commencez par définir la charge de travail prévue, puis choisissez le modèle le plus grand qui s'y adapte confortablement.

Si vous comparez des configurations, nos benchmarks Hivenet regroupent les résultats de performance que nous publions, vous évitant ainsi de devoir déduire les performances uniquement à partir des spécifications matérielles.

Alors, 32 Go de VRAM sont-ils suffisants pour l'IA ?

Pour une grande partie des travaux actuels en IA, oui.

Les 32 Go de VRAM de la RTX 5090 permettent de faire tourner des LLM de petite taille avec une haute précision, de nombreux modèles de 20 à 30 milliards de paramètres après une quantification adaptée, des pipelines de génération d'images exigeants, ainsi que des expérimentations efficaces en termes de paramètres.

Cela ne supprime pas pour autant la nécessité de planifier l'utilisation de la mémoire.

Les modèles de grande taille de classe 70B, le réglage fin (fine-tuning) complet des paramètres, les longueurs de contexte extrêmes et le service à haute concurrence peuvent tous nécessiter plus d'une carte.

C'est la limite utile à garder à l'esprit.

La RTX 5090 n'est pas intéressante parce que 32 Go permettraient de tout faire tourner. Elle est intéressante parce que ses 32 Go, sa bande passante mémoire élevée et la prise en charge de la basse précision par l'architecture Blackwell couvrent un large éventail de charges de travail IA concrètes sur un seul GPU. Lorsqu'une tâche nécessite réellement plus de mémoire, utiliser plusieurs GPU est une meilleure décision technique que de faire comme si cette limite n'existait pas.

FAQ sur la VRAM de la RTX 5090

Quelle est la quantité de VRAM de la RTX 5090 ?

La NVIDIA GeForce RTX 5090 pour ordinateur de bureau dispose de 32 Go de VRAM GDDR7.

32 Go de VRAM sont-ils suffisants pour l'IA ?

C'est suffisant pour de nombreuses charges de travail liées à l'IA. Les LLM plus petits peuvent fonctionner avec une précision élevée, tandis que de nombreux modèles de la gamme 20B-30B deviennent exploitables grâce à la quantification. Les modèles plus grands de classe 70B nécessitent généralement plus d'un GPU de 32 Go.

Une RTX 5090 peut-elle faire tourner un LLM de 32B ?

Oui, avec une quantification adaptée. Un modèle de 32B nécessite environ 64 Go rien que pour les poids en BF16, tandis qu'une représentation en 4 bits commence autour de 16 Go, avant de prendre en compte la surcharge de quantification, le cache et la mémoire d'exécution.

Une RTX 5090 peut-elle faire tourner un modèle de 70B ?

Une seule RTX 5090 est généralement trop limitée. Même une estimation simple des poids en 4 bits pour un modèle de 70B avoisine les 35 Go, sans compter la surcharge d'exécution. L'inférence multi-GPU est l'approche la plus pratique.

Quelle quantité de VRAM nécessite un modèle de 14B ?

Un modèle de 14B nécessite environ 28 Go pour des poids en BF16, 14 Go en 8 bits, ou 7 Go en 4 bits, avant toute utilisation de mémoire supplémentaire. Le format BF16 peut donc être juste sur un GPU de 32 Go, tandis qu'une précision inférieure laisse beaucoup plus de marge de manœuvre.

La quantification réduit-elle l'utilisation de la VRAM ?

Oui. La quantification représente tout ou partie des poids du modèle en utilisant moins de bits, ce qui réduit l'utilisation de la mémoire. L'économie réelle et l'impact sur la qualité dépendent du format de quantification et du modèle.

Une fenêtre de contexte plus longue consomme-t-elle plus de VRAM ?

Oui. Un contexte actif plus long augmente les besoins en KV-cache lors de l'inférence LLM. La concurrence, l'architecture du modèle, la précision du cache et le moteur de service influencent également la quantité de mémoire nécessaire.

La RTX 5090 est-elle adaptée au fine-tuning LoRA ?

Il s'agit d'un GPU performant pour le fine-tuning efficace en paramètres, selon le modèle et la configuration d'entraînement. LoRA et QLoRA nécessitent beaucoup moins de mémoire qu'un fine-tuning complet, car ils ne mettent à jour qu'une petite partie du modèle.