12 novembre 2026 · Équipe VRAMfarm
Faire tourner Llama 70B sur un seul GPU : 4 bits ou FP8, 48 ou 80 Go, et vitesses réelles
La première tentative se passe généralement ainsi : une carte de 24 Go, ollama run llama3.3:70b, et une réponse qui sort au compte-gouttes, à deux ou trois tokens par seconde. Rien n’est cassé. Le modèle en 4 bits pèse 43 Go, et Ollama en a discrètement placé près de la moitié dans la RAM système. Une seule carte ne fait tourner un modèle 70B à la vitesse de lecture que si le modèle entier y tient : une carte de 48 Go pour une personne avec un contexte normal (environ 12 à 18 tokens par seconde), ou une carte de 80 Go pour les longs documents, plusieurs utilisateurs ou la qualité FP8 (25 à 50 tokens par seconde).
Tout ce qui suit utilise Llama 3.3 70B, et les chiffres valent pour les autres modèles 70B denses construits dessus, comme DeepSeek R1 Distill Llama 70B. Un modèle 72B comme Qwen2.5 72B pèse quelques gigaoctets de plus (environ 47 Go en Q4_K_M), ce qui ne laisse presque aucune place au cache sur une carte de 48 Go.
Choisissez d’abord le format
Chaque moteur a son propre format de fichier, et le format détermine la taille, donc la carte.
| Format | Taille d’un modèle 70B | Tourne dans | Cartes | Qualité par rapport à l’original |
|---|---|---|---|---|
| BF16 (original) | 141 Go | vLLM, Transformers | B200 seule, ou 2 × 80 Go | Référence |
| FP8 | ~71 Go | vLLM, SGLang | 80 à 96 Go : H100, RTX PRO 6000, H200 | Pratiquement identique |
| GGUF Q8_0 | ~75 Go | llama.cpp, Ollama | 80 à 96 Go | Pratiquement identique |
| GGUF Q5_K_M | ~50 Go | llama.cpp, Ollama | 80 Go (trop gros pour 48 Go avec le moindre cache) | Très proche |
| GGUF Q4_K_M | ~43 Go | llama.cpp, Ollama | 48 Go | Légère perte |
| AWQ ou GPTQ, 4 bits | ~40 Go | vLLM, SGLang | 48 Go | Légère perte |
| GGUF Q2/IQ2 | 21 à 26 Go | llama.cpp | 24 à 32 Go | Nettement moins bon |
GGUF est le format de llama.cpp, qu’Ollama utilise aussi. Un seul fichier contient les poids, et le moteur peut garder certaines couches sur le CPU si le GPU manque de place : c’est à la fois sa force et le piège du premier paragraphe. Q4_K_M est le choix habituel pour un 70B.
AWQ et GPTQ sont des formats 4 bits destinés aux serveurs GPU. vLLM fait tourner les deux avec des noyaux rapides sur toutes les cartes à partir de la génération Ampere, ce qui couvre tout notre catalogue. Leur qualité est comparable ; choisissez une version issue d’une source entretenue et beaucoup téléchargée.
FP8 divise l’original par deux, presque sans perte. Les cartes le calculent nativement à partir de la génération Ada (RTX série 40, L40S), ainsi que sur Hopper (H100, H200) et Blackwell (RTX série 50, RTX PRO 6000, B200). Un modèle 70B en FP8 demande environ 71 Go : en pratique, FP8 signifie une H100 de 80 Go, une RTX PRO 6000 de 96 Go ou une H200. L’A100 peut charger des poids FP8 dans vLLM mais calcule en 16 bits : elle économise de la mémoire sans gagner en vitesse. Les cartes Blackwell calculent aussi le NVFP4, un format 4 bits d’environ 40 Go qui, dans les comparaisons publiées, reste souvent plus proche de la qualité FP8 que les anciennes méthodes 4 bits ; sa prise en charge par les moteurs est plus récente, vérifiez donc que votre version de vLLM le mentionne.
48 ou 80 Go : c’est le contexte qui décide
Les poids ne sont qu’une partie de la facture. Llama 3.3 70B garde environ 0,33 Mo de KV cache par token en 16 bits : 8 000 tokens de conversation occupent donc 2,7 Go, et le contexte complet de 128 000 tokens en occupe 43, autant que les poids en 4 bits. Le guide de la VRAM explique la formule ; voici ce qu’elle donne carte par carte.
| Configuration | Poids | Reste pour le cache | Contexte, cache 16 bits | Contexte, cache 8 bits |
|---|---|---|---|---|
| Carte de 48 Go, GGUF Q4_K_M | ~43 Go | 3 à 4 Go | 8 à 12 000 tokens | 16 à 24 000 |
| Carte de 48 Go, AWQ dans vLLM | ~40 Go | 3 à 5 Go | 8 à 12 000 | 16 à 24 000 |
| 2 cartes de 24 Go, AWQ ou Q4 | ~40 à 43 Go | 3 à 5 Go | 8 à 12 000 | 16 à 24 000 |
| Carte de 80 Go, AWQ ou Q4 | ~40 à 43 Go | 30 à 35 Go | environ 100 000 au total | les 128 000 complets pour un utilisateur, ou de nombreuses conversations plus courtes |
| Carte de 80 Go, FP8 | ~71 Go | 4 à 8 Go | 12 à 25 000 | 25 à 50 000 |
| RTX PRO 6000 de 96 Go, FP8 | ~71 Go | ~20 Go | ~60 000 | environ 120 000 |
| H200 de 141 Go, FP8 | ~71 Go | ~60 Go | 128 000 et plusieurs utilisateurs | beaucoup de marge |
Ce sont des fourchettes, car la mémoire utilisable varie d’un ou deux gigaoctets d’une carte à l’autre, chaque moteur garde ses propres tampons, et vLLM n’utilise que la part de la carte fixée par --gpu-memory-utilization. Le « au total » compte pour le service : le cache est partagé entre tous ceux qui parlent au modèle en même temps, donc 100 000 tokens sur une carte de 80 Go, c’est un long document ou une douzaine de conversations de 8 000 tokens.
La règle pratique : une carte de 48 Go comme la L40S ou la RTX A6000 suffit pour une personne qui discute ou résume quelques pages. Prenez une carte de 80 Go si vous collez de longs documents, si vous servez une équipe ou si vous voulez du FP8. Deux cartes de 24 Go dans une même machine accueillent aussi un 70B en 4 bits. Comparez deux RTX 3090 à 0,60 € de l’heure avec une RTX A6000 à 0,72 € ; les machines à plusieurs cartes apparaissent séparément dans le catalogue.
Ollama ou llama.cpp : un utilisateur, le moins d’étapes possible
Ollama est le chemin le plus court. Sur un serveur PyTorch vide, ouvrez le terminal Jupyter ou connectez-vous en SSH :
curl -fsSL https://ollama.com/install.sh | sh
OLLAMA_CONTEXT_LENGTH=8192 OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve > /workspace/ollama.log 2>&1 &
ollama run llama3.3:70bLe tag par défaut llama3.3:70b correspond au Q4_K_M de 43 Go. Il est important de fixer délibérément la longueur du contexte : si le contexte demandé ne tient pas, Ollama n’échoue pas, il déplace des couches vers le CPU. Vérifiez avec ollama ps dans un second terminal. La colonne PROCESSOR doit indiquer 100% GPU ; quelque chose comme 20%/80% CPU/GPU signifie que la vitesse vient d’être divisée par cinq à dix, et la solution est un contexte plus court ou une carte plus grande. Avec le cache 8 bits ci-dessus, un contexte de 16 000 tokens tient aussi sur une carte de 48 Go.
llama.cpp vous donne plus de contrôle : fichiers de quantification précis, types de cache, répartition des couches entre deux cartes. Il faut d’abord le compiler avec CUDA ; la comparaison des moteurs donne les étapes de compilation. Ensuite :
pip install -U huggingface_hub
hf download bartowski/Llama-3.3-70B-Instruct-GGUF Llama-3.3-70B-Instruct-Q4_K_M.gguf --local-dir /workspace/models
./build/bin/llama-server -m /workspace/models/Llama-3.3-70B-Instruct-Q4_K_M.gguf \
-ngl 99 -c 16384 --flash-attn on -ctk q8_0 -ctv q8_0 \
--host 127.0.0.1 --port 8081-ngl 99 place toutes les couches sur le GPU. Sur nos serveurs, le port 8080 est pris par Jupyter : utilisez-en un autre et ouvrez-le par un tunnel SSH, ssh -p <port> -L 8081:localhost:8081 root@<address>, avec le port et l’adresse indiqués sur la fiche du serveur, puis allez sur http://localhost:8081 pour la page de chat intégrée à llama.cpp. Le guide de la clé SSH explique la clé. Sur deux cartes, llama.cpp répartit lui-même les couches entre elles.
vLLM : une API pour plusieurs utilisateurs
vLLM s’impose quand d’autres programmes ou d’autres personnes envoient des requêtes, car il les regroupe en lots et son débit total augmente avec le nombre de requêtes parallèles. Notre serveur vLLM a déjà vLLM installé et le port 8000 publié. Il démarre de lui-même un petit modèle Qwen 7B : arrêtez-le d’abord, puis lancez le 70B :
pkill -f "vllm serve"
# carte de 48 Go : AWQ 4 bits, contexte court
vllm serve casperhansen/llama-3.3-70b-instruct-awq \
--max-model-len 8192 --gpu-memory-utilization 0.95 --max-num-seqs 8 \
--host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &# H100 de 80 Go : FP8, qualité proche de l'original
vllm serve RedHatAI/Llama-3.3-70B-Instruct-FP8-dynamic \
--max-model-len 16384 --gpu-memory-utilization 0.95 \
--host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &# deux cartes de 24 Go dans une machine : chaque couche est répartie sur les deux
vllm serve casperhansen/llama-3.3-70b-instruct-awq \
--tensor-parallel-size 2 --max-model-len 8192 --gpu-memory-utilization 0.95 \
--host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &Le chargement prend plusieurs minutes après le téléchargement ; tail -f /workspace/vllm.log affiche la progression. Au démarrage, vLLM vérifie qu’au moins une requête de --max-model-len tokens peut tenir et refuse de démarrer sinon, avec un message qui indique le plus grand contexte possible. Baissez la valeur ou ajoutez --kv-cache-dtype fp8, qui double la place sur les cartes Ada, Hopper et Blackwell. La version FP8 sur une H100 est le cas serré : ses poids occupent environ 72 Go, donc les 16 000 tokens ci-dessus exigent le réglage 0.95, et des contextes plus longs exigent le cache fp8 ou une carte plus grande. Gardez --api-key : l’adresse de l’API est accessible de partout, et sans clé, n’importe qui la trouvant peut utiliser votre GPU. Notre serveur vLLM fige une version de vLLM adaptée au pilote CUDA des machines ; si vous installez une version plus récente sur un serveur vide, vérifiez d’abord la version de CUDA affichée avant le lancement.
Quelle vitesse : tokens par seconde selon la carte
Pour un seul utilisateur, chaque nouveau token oblige à relire tout le modèle en mémoire une fois : la vitesse vaut donc à peu près la bande passante mémoire divisée par la taille du modèle, moins les pertes. Voici les tokens générés pour une seule conversation, d’après le calcul de bande passante et des retours publics de la communauté, et non nos propres benchmarks :
| Carte | VRAM | Bande passante | 4 bits (Q4_K_M, AWQ) | FP8 |
|---|---|---|---|---|
| RTX A6000 | 48 Go | 768 Go/s | 12 à 16 tokens/s | ne tient pas |
| L40S | 48 Go | 864 Go/s | 13 à 18 | ne tient pas |
| 2 × RTX 3090 | 2 × 24 Go | 936 Go/s chacune | 14 à 18 (répartition par couches), 18 à 25 (vLLM, tensor parallel) | ne tient pas |
| RTX PRO 6000 | 96 Go | 1 792 Go/s | 25 à 35 | 15 à 22 |
| A100 80 Go | 80 Go | 2 039 Go/s | 25 à 35 | aucun gain de vitesse, prenez le 4 bits |
| H100 | 80 Go | 3 350 Go/s | 35 à 50 | 25 à 38 |
| H200 | 141 Go | 4 800 Go/s | 45 à 65 | 35 à 55 |
On lit à environ 5 à 8 tokens par seconde : même la ligne la plus lente paraît fluide dans un chat. Deux autres chiffres comptent en pratique. La lecture du prompt est bien plus rapide que l’écriture de la réponse, de quelques centaines à quelques milliers de tokens par seconde selon la carte : un document de 10 pages prend donc de quelques secondes à une demi-minute avant le premier mot. Et avec de nombreuses requêtes parallèles, le débit total de vLLM monte à plusieurs centaines, voire plus d’un millier de tokens par seconde sur une H100. L’article sur le coût par million de tokens convertit ces débits en lots en euros.
Ce que coûte une première soirée, et quand un modèle plus petit suffit
Le téléchargement passe en premier : environ 40 à 43 Go pour une version 4 bits et environ 72 Go pour le FP8. C’est du trafic facturé au tarif par Go de la machine affiché avant le lancement, plus les minutes que cela prend, de moins de dix minutes sur une ligne rapide à une demi-heure sur une ligne plus lente. Deux heures avec Ollama sur une L40S coûtent 2,12 € de temps GPU, deux heures en FP8 sur une H100 7,80 €. Les prix évoluent en direct, et le prix par minute est fixé au lancement.
Si vous revenez souvent, vous pouvez garder le modèle dans le dossier enregistré : 43 Go coûtent 43 × 0,03 € par mois. Le restaurer sur le serveur suivant compte aussi comme du trafic : comparez avec un simple nouveau téléchargement ; l’article sur les fichiers après l’arrêt fait le calcul dans les deux cas.
Avant d’opter pour un 70B, essayez un modèle 32B sur une carte de 24 Go. Qwen3 32B en 4 bits tient sur une RTX 4090 à 0,59 € de l’heure, répond environ deux fois plus vite, et pour une bonne partie du chat et de l’écriture au quotidien, la différence avec un 70B est faible. Soumettez les mêmes cinq vrais prompts aux deux dans une même session ; le 70B justifie sa carte plus grande quand le 32B se trompe sur vos faits ou vos consignes. La page du modèle Llama indique la mémoire nécessaire pour chaque taille.