Pratique guide · 11 min de lecture # Servir Llama 3.3 70B sur un seul nœud. D’une machine livrée il y a cinq minutes à un point de terminaison compatible OpenAI qui répond aux requêtes — avec les deux options qui divisent silencieusement votre débit par deux, et celle qui provoque une compromission. En bref - **Mémoire nécessaire:** 43 GB en 4 bits, 82 GB en FP8, 164 GB en BF16 — tout à 8k de contexte - **Machine la plus simple:** Une seule carte de 80 GB. Pas de répartition, pas d’interconnexion, pas de synchronisation - **Délai jusqu’au premier token:** Moins de quinze minutes depuis la livraison, l’essentiel étant le téléchargement des poids - **L’unique erreur:** Publier le port 8000 sur une adresse publique. Il n’y a aucune authentification ## Ce dont vous avez besoin 70 milliards de paramètres. En 4 bits, cela représente 35 GB de poids ; le cache clef/valeur ajoute 2.5 GB à 8k de contexte pour une seule requête, et la surcharge d’exécution est d’environ 15 %. Tout le reste découle de ces trois chiffres — le [guide de dimensionnement](https://gpuserver.io/fr/guides/vram-sizing) explique d’où ils viennent. **Mémoire nécessaire pour Llama 3.3 70B, par précision et contexte** | Précision | Poids | Total à 8k | Total à 32k | Total à 128k | |---|---|---|---|---| | BF16 / FP16 Qualité de référence | 140 GB | 164 GB | 173 GB | 207 GB | | FP8 Proche de la référence, Hopper et Blackwell | 70 GB | 82 GB | 86 GB | 103 GB | | 4-bit (AWQ, GPTQ) Poids minimaux, cache toujours en FP16 | 35 GB | 43 GB | 52 GB | 86 GB | Notez la ligne 4 bits à 128k : les poids se réduisent à 35 GB mais le cache ne diminue pas du tout, car AWQ et GPTQ ne quantifient que les poids. Ce seul fait détermine l’essentiel du choix de machine ci-dessous. ## Choisir le nœud Les machines les moins chères de notre catalogue qui tiennent ce modèle sur une *seule* carte, la configuration à privilégier si possible — pas de répartition signifie pas de synchronisation, et une chose de moins à déboguer. **Nœuds qui tiennent Llama 3.3 70B sur une seule carte** | Nœud | La précision qui tient | Mémoire de la carte | tok/s estimés | Par mois | |---|---|---|---|---| | [NVIDIA RTX A6000](https://gpuserver.io/fr/gpu/rtx-a6000) PCIe 5.0 · 768 GB/s | 4-bit (AWQ, GPTQ) | 48 GB | ~10 | $286/mois | | [2 × NVIDIA RTX A6000](https://gpuserver.io/fr/gpu/rtx-a6000) PCIe 5.0 ×16 · 768 GB/s | 4-bit (AWQ, GPTQ) | 48 GB | ~10 | $597/mois | | [NVIDIA L40S](https://gpuserver.io/fr/gpu/l40s) PCIe 5.0 · 864 GB/s | 4-bit (AWQ, GPTQ) | 48 GB | ~11 | $714/mois | | [NVIDIA A100 PCIe](https://gpuserver.io/fr/gpu/a100-80gb) PCIe 5.0 · 1,935 GB/s | 4-bit (AWQ, GPTQ) | 80 GB | ~25 | $1,091/mois | Le débit correspond à une génération en flux unique, limitée par la bande passante mémoire, et volontairement conservatrice. Avec le traitement par lots continu, le total *agrégé* sur l’ensemble des requêtes simultanées est plusieurs fois supérieur — c’est tout l’intérêt de vLLM. ## Dix minutes d’installation Rien ici n’est spécifique à nous, hormis l’adresse. Docker, le NVIDIA Container Toolkit et une pile de pilotes fonctionnelle sont déjà présents sur la machine. Confirmez la machine, puis donnez aux poids un endroit où résider ``` $ ssh root@203.0.113.42 $ nvidia-smi --query-gpu=name,memory.total --format=csv # Weights on the fast local NVMe, not the system volume. $ mkdir -p /scratch/models $ df -h /scratch # A gated model needs a token. Skip if yours is open. $ export HF_TOKEN=hf_xxxxxxxxxxxxxxxxxxxx ``` ## Démarrer le serveur Un seul conteneur. Le premier lancement télécharge environ 40 GB de poids quantifiés, ce qui, sur un port 1 Gbit/s, prend quelques minutes ; chaque redémarrage suivant ne prend que quelques secondes. vLLM, carte unique, 4 bits ``` $ docker run -d --name vllm --restart unless-stopped \ --gpus all --ipc=host \ -v /scratch/models:/root/.cache/huggingface \ -e HF_TOKEN="$HF_TOKEN" \ -p 127.0.0.1:8000:8000 \ vllm/vllm-openai:latest \ --model casperhansen/llama-3.3-70b-instruct-awq \ --quantization awq_marlin \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 # Watch it load. "Application startup complete" is the signal. $ docker logs -f vllm ``` Première requête ``` $ curl -s http://127.0.0.1:8000/v1/models | head $ curl -s http://127.0.0.1:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{"model":"casperhansen/llama-3.3-70b-instruct-awq", "messages":[{"role":"user","content":"In one sentence: what is a KV cache?"}], "max_tokens":80}' ``` ## Les options qui comptent --max-model-len Réglez-le sur le contexte que vous servez vLLM réserve le cache clef/valeur pour le maximum déclaré. Déclarer 131072 alors que vous servez 8192 gaspille seize fois la mémoire dont vous avez besoin, et le symptôme est « pas assez de concurrence », pas une erreur. --gpu-memory-utilization 0.90 à 0.95 La fraction de la carte que vLLM peut réclamer. Tout ce qu’il ne réclame pas est gaspillé ; laisser la valeur par défaut de 0.90 sur une machine dédiée vous coûte de la concurrence réelle. Ne dépassez pas 0.95. --ipc=host Obligatoire, pas optionnel Sans cela, la mémoire partagée du conteneur est plafonnée à 64 MB. Sur une seule carte, cela peut passer inaperçu ; sur un modèle réparti, NCCL se bloque sans erreur exploitable. --tensor-parallel-size Seulement quand le modèle ne tient pas Répartir un modèle qui tient sur une seule carte le rend *plus lent*. Voir le [guide de l’interconnexion](https://gpuserver.io/fr/guides/nvlink-vs-pcie) — c’est la façon la plus courante de faire qu’un nœud coûteux soit moins performant qu’un nœud bon marché. --kv-cache-dtype fp8 Réduit votre cache de moitié Sur Hopper et Blackwell. Double le contexte ou la concurrence que vous pouvez tenir, pour un coût de qualité généralement non mesurable. Le gain le plus facile de cette liste. --max-num-seqs Limitez-la à votre concurrence réelle Le laisser à 256 sur une machine qui sert huit utilisateurs signifie que vLLM prévoit pour 256 et accepte des requêtes qu’il ne peut pas tenir, ce qui se traduit par des pics de latence plutôt que par des refus. ## Ne pas le publier au monde entier **L’API compatible OpenAI n’a aucune authentification par défaut.** Lié à `0.0.0.0` sur une adresse publique, c’est un serveur d’inférence ouvert, et les scanners les trouvent en quelques heures. Notez le `-p 127.0.0.1:8000:8000` dans la commande ci-dessus — cette adresse en tête est ce qui le tient à l’écart d’internet, et c’est le caractère le plus souvent oublié en copiant une commande depuis ailleurs. Atteignez-le depuis votre propre machine via un tunnel SSH — aucun port ouvert, aucun certificat à gérer, rien à mal configurer : Depuis votre ordinateur portable ``` $ ssh -N -L 8000:127.0.0.1:8000 root@203.0.113.42 # Now http://127.0.0.1:8000 on your laptop is the server. ``` Si cela doit vraiment être public, placez un reverse proxy devant, avec TLS et une clef API, et restreignez également les adresses source dans le pare-feu. La [documentation](https://gpuserver.io/fr/docs#firewall) propose un jeu de règles minimal. Ceinture et bretelles est la posture correcte pour un point de terminaison qui répondra à quiconque le sollicite. ## Augmenter le débit Dans l’ordre où cela vaut la peine d’essayer. Les deux premières sont gratuites et apportent généralement les gains les plus importants. 1. **Réduisez `--max-model-len` à votre contexte réel.** C’est presque toujours le gain le plus important à lui seul, et cela ne coûte rien que vous utilisiez déjà. 2. **Augmentez `--gpu-memory-utilization` à 0.95.** C’est une machine dédiée ; rien d’autre sur la carte ne nécessite qu’on lui laisse de la place. 3. **Activez le cache clef/valeur en FP8** si la carte le prend en charge. Double ce que vous pouvez tenir. 4. **Regroupez les requêtes côté client.** Le traitement par lots continu n’aide que si les requêtes arrivent simultanément. Des requêtes envoyées une par une laissent la majeure partie de la carte inactive, quelle que soit la configuration. 5. **Alors, et alors seulement, envisagez une carte plus rapide.** La génération est limitée par la bande passante mémoire : une H200 à 4 800 GB/s est environ 2,4× plus rapide qu’une H100 PCIe à 2 000 pour le même modèle — un gain réel, et le plus coûteux de cette liste. Mesurez avant et après — ne devinez pas ``` $ docker exec vllm python -m vllm.entrypoints.openai.api_server --help | head -1 $ docker exec vllm vllm bench serve \ --model casperhansen/llama-3.3-70b-instruct-awq \ --num-prompts 200 --request-rate 8 # And watch the card while it runs: if utilisation sits below 90%, # the bottleneck is your client, not the GPU. $ nvidia-smi dmon -s um ``` ## Le garder en service Trois choses à faire dès le premier jour, car les trois sont pénibles à découvrir le quatorzième. ### Politique de redémarrage `--restart unless-stopped` figure dans la commande ci-dessus. Après un redémarrage, le conteneur revient et les poids sont déjà sur `/scratch`, il est donc opérationnel en moins d’une minute. ### Surveillez la carte, pas le processus Un GPU tombé du bus laisse un conteneur d’apparence saine. `nvidia-smi -q -d PERFORMANCE` dans un contrôle de santé le détecte ; un contrôle de port, non. ### Les poids ne sont pas sauvegardés Ils se trouvent sur votre NVMe local, et nulle part ailleurs. Ce n’est pas un problème — ils sont retéléchargeables. Vos adaptateurs de fine-tuning, eux, ne le sont pas ; placez-les donc ailleurs, hors de la machine. Et à la fin de la durée d’engagement, les disques sont effacés dans l’heure, sans délai de grâce. Tout ce qui se trouve sur `/scratch` disparaît avec eux. C’est délibéré — c’est la même garantie qui assure que la machine qui vous a été livrée ne contenait les données de personne d’autre — mais cela signifie que le dernier jour d’une durée d’engagement n’est pas le moment de commencer à tout copier ailleurs. ## Vérifiez ce modèle sur chacun des nœuds que nous louons. Le configurateur indique quelles configurations le tiennent sur une seule carte, lesquelles doivent le répartir, et ce que chacune coûte. [Ouvrir le configurateur](https://gpuserver.io/fr/configure) [Lire les guides](https://gpuserver.io/fr/guides) ## Autres guides - [Pratique · 10 min Fine-tuning d’un modèle 70B sur une seule carte QLoRA sur un seul GPU de 48 GB : ce qui tient, ce que cela coûte pour un mois, et pourquoi le fine-tuning complet est une tout autre catégorie de machine. Lire le guide](https://gpuserver.io/fr/guides/lora-finetune) - [Paiement · 8 min Payer un serveur en crypto Ce qui se passe entre le clic sur payer et l’obtention du root, quelle monnaie choisir, et les quatre erreurs qui font perdre de l’argent sur un premier paiement. Lire le guide](https://gpuserver.io/fr/guides/pay-in-crypto) - [Dimensionnement · 9 min Combien de VRAM un modèle utilise réellement L’arithmétique derrière « est-ce que ça tient » : poids, cache clef/valeur, et les deux endroits où une règle empirique se trompe d’un facteur trois. Lire le guide](https://gpuserver.io/fr/guides/vram-sizing) --- Source : https://gpuserver.io/fr/guides/serve-llama-70b/. Ce fichier est généré à partir des mêmes données que le site ; si un chiffre ici diffère d’une page, la page fait foi et ce fichier est obsolète — la source canonique est https://gpuserver.io/.