llama-3-3-70b-gpu-requirements

Llama 3.3 70B est trop volumineux pour une seule RTX 5090 de 32 Go.

En BF16, ses 70 milliards de paramètres nécessitent environ 140 Go rien que pour les poids du modèle. En FP8, ce chiffre tombe à environ 70 Go. Une représentation 4 bits commence autour de 35 Go, bien que les points de contrôle quantifiés réels nécessitent davantage que ce simple calcul.

Cela rend la décision matérielle plus claire qu'il n'y paraît au premier abord :

‍

‍

Il existe une nuance importante derrière ce tableau :

La VRAM répartie sur plusieurs GPU n'est pas automatiquement regroupée en un seul espace mémoire géant.

Le moteur d'inférence doit diviser, ou fragmenter, le modèle entre ces GPU. Avec vLLM, une méthode courante pour y parvenir est le parallélisme tensoriel.

Pour un modèle 70B, la différence entre « j'ai 64 Go sur deux cartes » et « mon logiciel peut réellement distribuer le modèle sur deux cartes » est celle qui sépare un serveur fonctionnel d'une erreur de mémoire insuffisante.

Si vous souhaitez d'abord consulter le calcul pour un seul GPU, notre guide de la VRAM de la RTX 5090 explique pourquoi la mémoire des poids et la mémoire d'inférence utilisable sont deux choses différentes.

Qu'est-ce que Llama 3.3 70B ?

Llama 3.3 70B Instruct est le modèle de texte de 70 milliards de paramètres optimisé pour les instructions de Meta.

Meta l'a publié en décembre 2024 avec une fenêtre de contexte de 128 000 jetons, une attention par groupes de requêtes (GQA), une prise en charge multilingue, ainsi qu'une génération de texte et de code. Il s'agit d'un transformeur autorégressif entraîné et post-entraîné pour les usages conversationnels. La fiche technique officielle du modèle indique que les langues prises en charge sont l'anglais, l'allemand, le français, l'italien, le portugais, l'hindi, l'espagnol et le thaï.

Le modèle est disponible sous le nom :

meta-llama/Llama-3.3-70B-Instruct

via le dépôt officiel des modèles Meta.

Sa taille de 70 milliards de paramètres est l'élément déterminant pour le matériel.

Contrairement à un modèle de mélange d'experts (MoE) comme DeepSeek-R1 complet, Llama 3.3 70B est un modèle dense. Vous ne pouvez pas vous baser sur un nombre de « paramètres actifs » beaucoup plus faible pour définir les besoins en mémoire.

Le modèle compte environ 70 milliards de paramètres, et ces poids doivent être stockés quelque part.

De combien de VRAM Llama 3.3 70B a-t-il besoin ?

Commençons par la même approximation utile que celle utilisée ailleurs dans cette série :

paramètres × octets par paramètre = mémoire approximative des poids

Pour 70 milliards de paramètres :

BF16 :
70B × 2 octets ≈ 140 Go

8 bits / FP8 :
70 G × 1 octet ≈ 70 Go

4 bits :
70 G × 0,5 octet ≈ 35 Go

Cela nous donne :

La dernière ligne est importante.

‍

‍

La quantification réelle ne consiste pas simplement à regrouper 70 milliards de valeurs parfaites sur quatre bits sans aucune autre donnée.

Les points de contrôle quantifiés peuvent inclure :

• des facteurs d'échelle
• des métadonnées
• des composants de plus haute précision
• une tête de sortie non quantifiée
• des données de configuration du modèle et du jetonneur

Ensuite, le serveur d'inférence a toujours besoin de mémoire GPU pour :

• le cache KV
• les noyaux CUDA
• les tampons temporaires
• les séquences actives
• traitement par lots
• surcharge du framework

Le modèle actuel de NVIDIA point de contrôle Llama 3.3 70B NVFP4, par exemple, pèse environ 42,7 Go sur le disque au lieu des 35 Go théoriques. NVIDIA indique que son optimisation FP4 réduit les besoins en mémoire GPU d'environ 3,3 fois par rapport au modèle 16 bits.

C'est suffisamment compact pour faire de deux RTX 5090 de 32 Go un point de départ réaliste.

Une seule carte reste insuffisante.

Pourquoi le modèle 70B diffère de ceux que nous avons déjà abordés

Un modèle quantifié de 14B ou 27B peut laisser une mémoire de travail substantielle sur une seule RTX 5090.

Un modèle 70B franchit une limite architecturale importante.

Même avec une quantification agressive, les poids consomment plus que la mémoire d'une seule carte. Au lieu de vous demander :

Quelle précision permet à ce modèle de tenir sur mon GPU ?

vous devez désormais vous demander :

Comment répartir ce modèle sur plusieurs GPU ?

C'est pourquoi les charges de travail 70B marquent le moment où le parallélisme tensoriel cesse d'être une optimisation optionnelle pour devenir un élément essentiel de la conception du déploiement.

C'est aussi la raison pour laquelle notre Guide des tailles de modèles DeepSeek-R1 redirige les lecteurs intéressés par les modèles 70B vers cette page, plutôt que de prétendre que les mêmes conseils pour un seul GPU s'appliquent quel que soit le nombre de paramètres.

Qu'est-ce que le parallélisme tensoriel ?

Le parallélisme tensoriel répartit les opérations individuelles du modèle sur plusieurs GPU.

Pour simplifier, au lieu de placer une couche entière sur le GPU 0 et la suivante sur le GPU 1, le parallélisme tensoriel divise les tenseurs impliqués dans ces opérations afin que plusieurs GPU travaillent dessus simultanément.

Pour vLLM, vous configurez cela avec :

--tensor-parallel-size

Si vous disposez de deux GPU :

--tensor-parallel-size 2

Pour quatre :

--tensor-parallel-size 4

Pour huit :

--tensor-parallel-size 8

La documentation actuelle de vLLM utilise Llama 3.3 70B comme exemple de modèle déployé avec le parallélisme tensoriel.

L'avantage est simple : le modèle n'a plus besoin de tenir dans la VRAM d'un seul GPU.

Le coût est tout aussi réel : les GPU doivent désormais communiquer pendant l'inférence.

Cette communication impacte les performances.

Deux RTX 5090 constituent le point de départ pratique en FP4

Deux GPU RTX 5090 dans le cloud offre :

2 × 32 Go = 64 Go de VRAM totale

Le point de contrôle NVFP4 quantifié actuel de Llama 3.3 70B de NVIDIA pèse environ 42,7 Go, et NVIDIA rapporte une réduction d'environ 3,3 fois des besoins en mémoire GPU par rapport au modèle 16 bits.

Cela confère à deux 5090 une capacité totale suffisante pour le point de contrôle, ainsi qu'une marge de mémoire supplémentaire significative.

Le qualificatif utile est point de départ.

Un déploiement à deux GPU ne signifie pas que vous devez immédiatement configurer le contexte complet de 128 000 jetons du modèle et vous attendre à de grands lots de requêtes.

La mémoire restante doit encore prendre en charge le cache KV et la surcharge liée au service.

Pour une inférence interactive ou avec un contexte modéré, deux 5090 et un point de contrôle de classe FP4 constituent un point de départ raisonnable.

Pour un budget de contexte de production important ou une concurrence plus élevée, quatre GPU vous offrent beaucoup plus de marge.

Quatre RTX 5090 constituent une configuration FP8 utile

Quatre RTX 5090 offrent :

4 × 32 Go = 128 Go de VRAM totale

C'est largement au-dessus des environ 70 Go requis pour les poids d'un modèle 70B en FP8.

NVIDIA publie un document officiel :

nvidia/Llama-3.3-70B-Instruct-FP8

point de contrôle créé avec NVIDIA Model Optimizer.

Selon NVIDIA, la version FP8 réduit les besoins en mémoire GPU d'environ 50 % par rapport au modèle 16 bits. Ce point de contrôle est compatible avec vLLM, SGLang et TensorRT-LLM, y compris sur les GPU NVIDIA Blackwell.

Il s'agit d'une configuration intéressante si vous souhaitez conserver une précision numérique élevée tout en évitant l'empreinte mémoire du BF16.

Quatre GPU offrent également beaucoup plus de mémoire globale pour le cache KV que si l'on tentait de forcer un modèle FP8 dans la configuration la plus restreinte possible.

Qu'en est-il du BF16 ?

Les poids seuls nécessitent environ 140 Go.

Quatre RTX 5090 fournissent 128 Go.

Quatre cartes sont donc déjà insuffisantes avant même que le serveur ne commence l'inférence.

La configuration Hivenet standard suivante utilise huit GPU :

8 × 32 Go = 256 Go de VRAM totale

Cela offre une capacité suffisante pour les poids en BF16 ainsi que pour l'état de l'inférence.

C'est l'exemple le plus frappant de l'impact majeur de la précision sur l'infrastructure :

Il s'agit de configurations de planification raisonnables, et non de garanties de performance universelles.

‍

‍

La longueur du contexte, l'objectif de concurrence, le moteur d'inférence, le format de quantification et la charge de travail déterminent toujours si un déploiement spécifique sera efficace.

Devriez-vous utiliser le FP4, le FP8 ou le BF16 ?

Partez de la qualité dont votre application a besoin plutôt que du nom de la précision.

FP4/NVFP4 offre l'empreinte mémoire la plus réduite et rend l'inférence 70B beaucoup plus économique sur le matériel Blackwell.

FP8 utilise davantage de mémoire mais préserve une meilleure précision numérique tout en restant nettement plus léger que le BF16.

BF16 évite la quantification des poids mais exige beaucoup plus de ressources matérielles.

L'évaluation publiée par NVIDIA pour son point de contrôle Llama 3.3 70B FP8 montre des différences très minimes par rapport à la référence BF16 sur les benchmarks indiqués. Par exemple, son score MMLU passe de 83,3 en BF16 à 83,2 en FP8.

C'est une preuve utile.

Ce n'est toutefois pas votre propre évaluation.

Si votre modèle a pour but de générer du code valide, de classer des documents d'assurance, de respecter une politique de support spécifique ou de répondre à des questions techniques dans un domaine précis, testez ces aspects.

La précision doit être une décision basée sur la qualité et le coût, en fonction de votre charge de travail.

Étape 1 : choisissez le déploiement dont vous avez réellement besoin

Pour ce guide, nous utiliserons :

• 2 × RTX 5090
• Le point de contrôle FP4/NVFP4 Llama 3.3 70B de NVIDIA
• vLLM
• parallélisme tensoriel sur les deux GPU
• une limite de contexte initiale volontairement réduite
• une API compatible avec OpenAI

Il s'agit de la configuration pratique la plus économique de notre flotte actuelle de RTX 5090 pour cette catégorie de modèles.

Si vous souhaitez spécifiquement utiliser le format FP8, choisissez quatre GPU et modifiez le point de contrôle du modèle en conséquence.

Créez l'instance via Calcul avec Hivenet.

Hivenet prend en charge les instances RTX 5090 avec un, deux, quatre ou huit GPU.

Étape 2 : vérifiez les deux GPU

Connectez-vous à l'instance et exécutez :

nvidia-smi

Vous devriez voir les deux RTX 5090.

Une vérification rapide en Python est également utile :

python - <<'PY'
import torch

print("CUDA available:", torch.cuda.is_available())
print("GPU count:", torch.cuda.device_count())

for i in range(torch.cuda.device_count()):
   print(i, torch.cuda.get_device_name(i))
PY

Pour la configuration à deux GPU, vous devez avoir :

Nombre de GPU : 2

Effectuez cette opération avant de déboguer vLLM.

Le parallélisme tensoriel ne peut pas répartir la charge sur un GPU qui n'est pas détecté par le système d'exploitation.

Étape 3 : utilisez une version actuelle de vLLM

vLLM propose désormais une recette pour Llama 3.3 70B destinée au matériel NVIDIA Blackwell et Hopper, incluant le déploiement en FP8 et NVFP4.

Il s'agit d'une source plus fiable qu'une ancienne commande de blog copiée avant l'existence du support pour Blackwell.

Si vous utilisez déjà le workflow vLLM de Hivenet, consultez le guide vLLM de Hivenet.

Pour un environnement manuel, utilisez une version actuelle de vLLM compatible avec le point de contrôle et la pile CUDA.

Par exemple :

python3 -m venv ~/llama70b-env
source ~/llama70b-env/bin/activate

pip install --upgrade pip
pip install --upgrade vllm

Pour la production, fixez une version testée après avoir validé le déploiement plutôt que de laisser chaque redémarrage récupérer un ensemble de dépendances différent.

Étape 4 : servez le modèle quantifié sur deux GPU

La recette actuelle de vLLM pour Llama 3.3 fournit le point de contrôle Blackwell FP4 de NVIDIA sous le nom :

nvidia/Llama-3.3-70B-Instruct-FP4

Commencez avec un budget de contexte conservateur :

vllm serve nvidia/Llama-3.3-70B-Instruct-FP4 \
 --tensor-parallel-size 2 \
 --max-model-len 32768 \
 --kv-cache-dtype fp8 \
 --port 8000

Le paramètre important est :

--tensor-parallel-size 2

Cela indique à vLLM de fragmenter le modèle sur les deux GPU.

Le serveur expose une API compatible avec OpenAI à l'adresse suivante :

http://localhost:8000/v1

Si votre environnement utilise le nom de dépôt NVFP4 plutôt que l'alias plus court FP4, utilisez le nom de point de contrôle exact actuellement documenté par NVIDIA et vLLM.

Les formats de modèles quantifiés évoluent. Ne renommez pas un point de contrôle dans un script de déploiement simplement parce que deux noms semblent équivalents.

Pourquoi commencer avec un contexte de 32K ?

Llama 3.3 prend en charge un contexte de 128K.

Il s'agit d'une capacité du modèle, et non d'une instruction visant à réserver 128K de mémoire de service à chaque déploiement.

Les recommandations de performance de vLLM pour Llama 3.3 conseillent de réduire max-model-len lorsque vos longueurs d'entrée et de sortie réelles sont inférieures au maximum du modèle.

C'est important car le cache KV consomme de la mémoire.

Si votre application reçoit habituellement :

• 4 000 jetons en entrée
• et produit 1 000 jetons en sortie

alors configurer chaque requête sur la base d'un maximum théorique de 128 000 peut gaspiller de la mémoire qui pourrait servir à prendre en charge davantage de requêtes simultanées.

Un point de départ à 32 000 laisse déjà une marge importante pour les longs documents et les conversations.

Mesurez d'abord.

Augmentez cette valeur lorsque la charge de travail démontre que vous en avez besoin.

Étape 5 : tester l'API

Installez le client OpenAI :

pip install --upgrade openai

Créez :

test_llama.py

avec :

from openai import OpenAI

client = OpenAI(
   base_url="http://localhost:8000/v1",
   api_key="EMPTY",
)

response = client.chat.completions.create(
   model="nvidia/Llama-3.3-70B-Instruct-FP4",
   messages=[
       {
           "role": "user",
           "content": (
               "Expliquez la différence entre la VRAM d'un GPU "
               "et la VRAM globale dans un déploiement en parallélisme de tenseurs."
           ),
       }
   ],
   max_tokens=500,
   temperature=0.2,
)

print(response.choices[0].message.content)

Exécution :

python test_llama.py

Vous disposez désormais d'un point de terminaison 70B opérationnel.

L'étape suivante ne consiste pas à ajouter davantage d'options.

Il s'agit de vérifier si le déploiement se comporte correctement face aux requêtes que vous prévoyez d'envoyer.

Étape 6 : surveiller les deux GPU

Pendant l'envoi des requêtes, exécutez :

watch -n 1 nvidia-smi

Vous devriez constater une allocation de mémoire sur les deux GPU.

L'allocation ne sera pas nécessairement identique à chaque instant, mais un déploiement en parallélisme de tenseurs doit clairement utiliser les deux cartes.

vLLM indique également les informations de chargement du modèle et du cache KV dans ses journaux de démarrage.

Surveillez :

• l'utilisation de la mémoire GPU
• la capacité du cache KV
• les échecs de chargement du modèle
• les erreurs de communication NCCL
• les erreurs de mémoire insuffisante (out-of-memory)
• les estimations de concurrence maximale

Le démarrage réussi du serveur marque le début des tests de déploiement, et non leur fin.

Pourquoi la communication entre GPU est importante

Une fois qu'un modèle est réparti sur plusieurs GPU, ces derniers doivent échanger des résultats intermédiaires.

Cela génère une surcharge de communication.

C'est l'une des raisons pour lesquelles doubler le nombre de GPU ne réduit pas automatiquement la latence de moitié.

La relation dépend de :

• l'architecture du modèle
• degré de parallélisme tensoriel
• interconnexion
• taille de lot
• longueur de séquence
• moteur de service
• utilisation du GPU

Hivenet a mesuré le comportement de NCCL AllReduce sur un hôte unique avec 8 GPU RTX 5090 dans le cadre de nos travaux d'analyse comparative sur machines virtuelles GPU et serveurs dédiés.

Ce type de mesure est plus important pour l'inférence d'un modèle 70B que pour un modèle tenant entièrement sur une seule carte.

Avec un seul GPU, il n'y a rien à coordonner.

Avec huit, la communication fait partie intégrante de la charge de travail.

L'ajout de GPU peut réduire la latence tout en diminuant l'efficacité

Cela semble contradictoire jusqu'à ce que l'on distingue deux indicateurs.

La latence mesure le temps nécessaire pour traiter la requête d'un utilisateur.

Le débit mesure la quantité de travail accomplie par le système sur une période donnée.

Les recommandations actuelles de vLLM pour Llama 3.3 70B indiquent qu'augmenter le parallélisme tensoriel peut améliorer la latence par utilisateur tout en réduisant le débit par GPU pour une même taille de lot.

C'est logique.

Davantage de GPU collaborent sur l'exécution d'un même modèle, ce qui permet à une requête individuelle d'être traitée plus rapidement.

Cependant, cela mobilise plus de matériel pour traiter cette requête, et la communication entre les GPU génère une surcharge.

La configuration idéale dépend donc de votre produit.

Un assistant privé utilisé par dix personnes n'a pas les mêmes exigences qu'une API traitant des milliers de requêtes simultanées.

Deux ou quatre GPU pour le modèle FP4 ?

Deux GPU constituent le point de départ économique.

Quatre peuvent toutefois s'avérer plus adaptés à votre service.

Un déploiement FP4 sur quatre GPU alloue une plus petite partie du modèle à chaque processeur et libère davantage de mémoire pour le cache. Cela peut également améliorer la latence d'une requête unique dans les conditions appropriées.

Le coût est une capacité GPU doublée.

La question devient alors :

Le gain en débit, en capacité de contexte ou en latence justifie-t-il le surcoût de 1,50 € par heure d'utilisation ?

C'est un point que vous pouvez évaluer directement par des tests de performance.

Ne choisissez pas quatre GPU simplement parce que 70B semble imposant.

Optez pour quatre GPU si votre déploiement sur deux GPU ne répond pas à une exigence précise que vous avez identifiée.

De combien de mémoire vive système Llama 3.3 70B a-t-il besoin ?

La mémoire vive système et la VRAM des GPU répondent à des besoins différents.

Pour un déploiement vLLM résidant sur GPU, les poids du modèle doivent principalement être stockés dans la mémoire du GPU.

La mémoire vive système reste nécessaire pour :

• Linux
• Python
• vLLM
• téléchargement et chargement de modèles
• cache du système de fichiers
• tokenisation
• processus applicatifs
• surveillance
• autres services

Si vous utilisez le déchargement sur CPU, la mémoire vive du système peut également contenir une partie du modèle.

Cela peut vous permettre d'exécuter une configuration qui ne tient pas entièrement dans la VRAM.

Ce sera généralement plus lent, car ces poids doivent désormais transiter entre la mémoire du CPU et le GPU.

Ajouter de la RAM n'équivaut donc pas à ajouter de la VRAM.

Si la performance est une priorité, considérez le déchargement sur CPU comme un compromis délibéré plutôt que comme une capacité supplémentaire gratuite.

Le modèle Llama 3.3 70B peut-il fonctionner sur un seul GPU ?

Oui, si ce GPU dispose de suffisamment de mémoire.

Le problème n'est pas que « 70B nécessite plusieurs GPU » comme s'il s'agissait d'une loi de la nature.

Le problème est qu'une RTX 5090 de 32 Go ne dispose pas de suffisamment de mémoire pour un point de contrôle 70B utile résidant entièrement sur le GPU.

Un seul accélérateur doté d'une mémoire bien plus importante peut exécuter des configurations qui nécessiteraient plusieurs 5090.

La recette vLLM actuelle de NVIDIA, par exemple, démontre un déploiement de Llama 3.3 70B en FP4 sur un seul accélérateur Blackwell de classe B200.

Ce matériel dispose d'une capacité mémoire totalement différente.

Traduisez toujours « runs on one GPU » par :

Quel GPU, avec quelle quantité de VRAM et quelle précision ?

Sans ces précisions, cette affirmation ne vous apprend pas grand-chose.

Peut-on exécuter Llama 3.3 70B avec Ollama ?

Oui. Ollama propose Llama 3.3 70B dans sa bibliothèque de modèles.

Cela ne supprime pas pour autant les besoins en mémoire.

Ollama peut répartir un modèle sur les GPU disponibles et placer certaines couches dans la mémoire CPU lorsque le modèle ne tient pas entièrement dans la VRAM.

Cela le rend pratique pour l'expérimentation.

Pour un service d'API en production où le débit, le traitement par lots, la configuration du parallélisme tensoriel et l'observabilité sont essentiels, je choisirais généralement vLLM.

Nous aborderons le comportement GPU d'Ollama séparément dans notre futur guide de déploiement d'Ollama sur GPU et dans le cloud.

La distinction utile n'est pas « Ollama pour les débutants, vLLM pour les experts ».

Ce sont des outils de service différents avec des priorités différentes.

Comment Llama 3.3 70B se compare-t-il à DeepSeek-R1 70B ?

DeepSeek-R1-Distill-Llama-70B utilise Llama 3.3 70B Instruct comme modèle de base.

DeepSeek l'a ensuite affiné à l'aide de données de raisonnement produites par le modèle complet DeepSeek-R1.

Cela signifie que les deux modèles appartiennent approximativement à la même classe matérielle en termes de nombre de paramètres.

Un modèle distillé DeepSeek 70B ne devient pas magiquement une charge de travail 32B simplement parce qu'il provient de R1.

Les mêmes calculs de mémoire s'appliquent :

~140 Go en BF16
~70 Go en 8 bits
~35 Go théoriques en 4 bits

Leur comportement est différent.

Leur classe matérielle est similaire.

Consultez notre guide des tailles de modèles DeepSeek-R1 et de la VRAM pour le reste de la famille.

Combien coûte Llama 3.3 70B sur des RTX 5090 ?

Hivenet propose actuellement le calcul sur RTX 5090 à partir de 0,75 € par heure et par GPU, avec une facturation à la seconde.

Cela donne :

Ainsi, une expérience en FP4 sur deux GPU tournant pendant deux heures coûte environ :

‍

‍

2 heures × 1,50 € = 3,00 €

Un serveur FP8 à quatre GPU laissé en fonctionnement continu pendant 24 heures coûte :

24 × 3,00 € = 72,00 €

C'est pourquoi l'économie du déploiement ne peut se limiter au prix horaire.

Pour un point de terminaison en production, vous devez mesurer la quantité de travail utile effectuée par chaque configuration.

Les indicateurs pertinents incluent :

• temps jusqu'au premier jeton
• jetons par seconde
• débit total de jetons
• requêtes par seconde
• concurrence
• latence p50 et p99
• utilisation du GPU
• coût par million de jetons de sortie utiles

vLLM inclut vllm bench serve spécifiquement pour mesurer les performances de service plutôt que de se baser sur des estimations à partir des spécifications.

Comment évaluer le déploiement

Un benchmark vLLM de base peut ressembler à ceci :

vllm bench serve \
 --host 127.0.0.1 \
 --port 8000 \
 --model nvidia/Llama-3.3-70B-Instruct-FP4 \
 --dataset-name random \
 --random-input-len 1024 \
 --random-output-len 512 \
 --num-prompts 500

Pour une comparaison interne, maintenez la charge de travail constante.

Si vous comparez deux GPU avec des prompts de 1 024 jetons et quatre GPU avec des prompts de 8 000 jetons, vous mesurez essentiellement deux charges de travail différentes.

Comparez :

• le même modèle
• le même point de contrôle
• le même contexte
• la même distribution de prompts
• la même longueur de sortie
• la même concurrence

Ensuite, modifiez une seule variable d'infrastructure.

C'est ainsi que vous découvrirez si l'ajout de deux GPU vous apporte réellement un gain.

Avez-vous besoin de la totalité des 128 000 jetons de contexte ?

Probablement pas pour chaque requête.

Meta dote Llama 3.3 d'une fenêtre de contexte de 128 000 jetons.

C'est un atout précieux lorsque vous avez réellement besoin de traiter de longs documents, un historique de conversation étendu ou d'importants volumes de contexte récupéré.

Cela a toutefois un coût.

Un contexte long augmente l'utilisation du cache KV, le travail de pré-remplissage et le délai avant le début de la génération.

Un service en production qui envoie 100 000 jetons à chaque requête sous prétexte que le modèle en supporte 128 000 paiera le prix fort en termes de latence et de capacité.

Utilisez un contexte long uniquement lorsque la tâche l'exige.

Pour les applications traitant de nombreux documents, la récupération d'informations (RAG) peut s'avérer plus efficace que de copier un corpus entier dans chaque invite. Notre page RAG avec Hivenet détaille cette approche infrastructurelle.

Llama 3.3 70B est-il encore pertinent en 2026 ?

C'est possible.

L'existence de modèles plus récents ne rend pas un modèle plus ancien inutile.

La question est de savoir si Llama 3.3 70B offre toujours la combinaison dont vous avez besoin :

• un comportement éprouvé
• une large compatibilité avec les outils
• des capacités multilingues
• un support de déploiement mature
• points de contrôle quantifiés établis
• une licence adaptée à votre organisation
• des performances conformes à vos critères d'évaluation

Son ancienneté peut même s'avérer utile sur le plan opérationnel.

Les moteurs de service, les quantificateurs, les recettes de déploiement et les outils ont eu le temps de se stabiliser autour du modèle.

C'est un point crucial lorsque vous privilégiez la fiabilité d'une charge de travail plutôt que le test du dernier point de contrôle publié cette semaine.

Ne le choisissez pas simplement parce que « 70B » semble impressionnant.

Ne le rejetez pas simplement parce qu'une nouveauté est sortie.

Évaluez le modèle en fonction de la tâche à accomplir.

Vérifiez la licence Llama avant tout déploiement

Llama 3.3 n'est pas publié sous licence Apache 2.0 ou MIT.

Meta le distribue sous la licence communautaire Llama 3.3.

La licence autorise l'utilisation commerciale et la recherche selon ses conditions, mais elle impose des exigences concernant la redistribution, l'attribution, les modèles dérivés et certains usages commerciaux à grande échelle.

La fiche technique officielle du modèle Llama 3.3 renvoie directement à l'accord en vigueur.

Lisez-le avant de distribuer le modèle ou de créer une version dérivée.

« Poids ouverts » ne signifie pas « absence de conditions de licence ».

Quand choisir un modèle plus petit ?

Un modèle de 70B est un mauvais choix d'infrastructure lorsqu'un modèle de 14B ou 27B réussit la même évaluation produit.

Les modèles plus petits vous offrent généralement :

• une latence plus faible
• une concurrence plus élevée
• un coût réduit
• un déploiement simplifié
• une plus grande marge de contexte par GPU
• moins d'éléments mobiles

Notre guide de déploiement de Qwen3.6-27B montre comment un modèle quantifié de 27B peut tenir sur une seule RTX 5090.

C'est un déploiement radicalement plus simple qu'un serveur 70B en parallélisme tensoriel.

Utilisez les 43 milliards de paramètres supplémentaires uniquement s'ils améliorent le résultat dont vous avez besoin.

Sinon, vous payez pour déplacer davantage de poids inutilement.

Quand choisir Llama 3.3 70B ?

Un déploiement 70B devient plus facile à justifier lorsque :

• un modèle plus petit n'atteint pas systématiquement votre seuil de qualité
• les performances multilingues sont importantes
• le modèle est déjà validé au sein de votre organisation
• vous avez besoin d'un modèle open-weight mature bénéficiant d'une large prise en charge à l'exécution
• vous souhaitez garder le contrôle sur l'intégralité de la pile de service
• la charge de travail permet d'occuper efficacement plusieurs GPU

Si votre service reçoit cinq requêtes par jour, il est difficile de justifier l'utilisation permanente d'un serveur à quatre GPU.

Si une équipe envoie un flux d'inférence soutenu vers le modèle, le calcul change.

L'infrastructure fait partie intégrante du choix du modèle.

Inférence 70B autogérée ou point de terminaison managé ?

Ce tutoriel suppose que vous souhaitez garder le contrôle sur la couche de service.

Calcul avec Hivenet vous permet de gérer :

• le point de contrôle exact du modèle
• la précision
• le nombre de GPU
• la version de vLLM
• le parallélisme tensoriel
• les limites de contexte
• le traitement par lots
• la configuration de l'API

Ce contrôle est utile lorsque vous en avez besoin.

Si vous recherchez simplement un point de terminaison compatible avec OpenAI sans avoir à gérer un serveur d'inférence multi-GPU, API d'inférence Hivenet est la voie la plus appropriée.

Un point de terminaison géré et la location de GPU répondent à des besoins différents.

Ne faites pas de l'administration serveur une obligation si celle-ci n'apporte aucune valeur ajoutée à votre projet.

FAQ Llama 3.3 70B

Combien de paramètres possède Llama 3.3 70B ?

Llama 3.3 70B compte environ 70 milliards de paramètres. Il s'agit d'un modèle transformer autorégressif dense et non d'un modèle de type Mixture-of-Experts.

De combien de VRAM Llama 3.3 70B a-t-il besoin ?

Les poids du modèle nécessitent environ 140 Go en BF16, 70 Go en FP8 et théoriquement 35 Go en 4 bits. L'inférence réelle requiert de la VRAM supplémentaire pour les métadonnées de quantification, le cache KV, les tampons temporaires et les requêtes actives.

Llama 3.3 70B peut-il fonctionner sur une seule RTX 5090 ?

Non, pas dans le cadre d'un déploiement standard entièrement résident sur GPU. La RTX 5090 dispose de 32 Go de VRAM, alors que le besoin théorique pour les poids en 4 bits est d'environ 35 Go.

Llama 3.3 70B peut-il fonctionner sur deux RTX 5090 ?

Oui, un point de contrôle FP4/NVFP4 adapté peut être fragmenté sur deux RTX 5090 de 32 Go. Le parallélisme tensoriel est nécessaire pour distribuer le modèle plutôt que de traiter les cartes comme des mémoires indépendantes.

Combien de RTX 5090 me faut-il pour Llama 3.3 70B ?

En pratique, prévoyez deux GPU pour un déploiement FP4/NVFP4, quatre pour du FP8 avec une marge de manœuvre confortable, et huit pour du BF16. Les besoins exacts dépendent du point de contrôle, du contexte, de la concurrence et du moteur d'inférence.

Ajouter deux RTX 5090 crée-t-il un GPU de 64 Go ?

Non. Cela offre au serveur 64 Go de VRAM agrégée sur deux GPU distincts. Le framework d'inférence doit explicitement fragmenter le modèle entre eux.

Qu'est-ce que le parallélisme tensoriel ?

Le parallélisme tensoriel répartit les opérations tensorielles du modèle sur plusieurs GPU afin qu'ils travaillent de concert sur une même requête d'inférence. Dans vLLM, il se configure avec --tensor-parallel-size.

Llama 3.3 70B prend-il en charge un contexte de 128K ?

Oui. Meta indique une fenêtre de contexte de 128K pour Llama 3.3 70B. L'utilisation de la totalité du contexte nécessite une capacité de cache KV nettement supérieure à celle requise pour une limite de contexte plus réduite.

Llama 3.3 70B est-il multilingue ?

Oui. Meta liste explicitement l'anglais, l'allemand, le français, l'italien, le portugais, l'hindi, l'espagnol et le thaï comme langues prises en charge.

Llama 3.3 70B est-il open source ?

Les poids du modèle sont accessibles au public sous la licence Llama 3.3 Community de Meta. Le terme « open-weight » est plus précis, car l'utilisation et la redistribution restent soumises aux conditions de la licence.

vLLM peut-il servir Llama 3.3 70B ?

Oui. vLLM prend en charge le modèle et propose une recette de déploiement actuelle pour Llama 3.3 70B sur les GPU NVIDIA Blackwell et Hopper, incluant les configurations FP8 et NVFP4.

Le FP4 est-il toujours préférable au FP8 pour Llama 70B ?

Non. Le FP4 permet d'économiser davantage de mémoire et peut réduire les besoins matériels, tandis que le FP8 conserve une meilleure précision. Évaluez le point de contrôle pertinent sur votre charge de travail avant de décider.

Dois-je utiliser deux ou quatre GPU ?

Commencez avec deux GPU pour un point de contrôle FP4 adapté si le coût est un facteur déterminant et que vos besoins en contexte et en concurrence sont modérés. Passez à quatre lorsque vos mesures indiquent un besoin accru en capacité de cache, une latence plus faible, une concurrence plus élevée ou la précision du FP8.

Combien coûte un serveur Llama 3.3 70B à deux GPU sur Hivenet ?

Au tarif actuel publié de 0,75 € par heure et par GPU pour la RTX 5090, deux GPU coûtent 1,50 € par heure de fonctionnement. Le calcul est facturé à la seconde.

‍