L’ensemble des 6 centres de données opérationnels

Payé en crypto · Sans vérification d’identité · Accès root en moins de 5 minutes

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 explique d’où ils viennent.

Mémoire nécessaire pour Llama 3.3 70B, par précision et contexte
PrécisionPoids Total à 8kTotal à 32kTotal à 128k
BF16 / FP16Qualité de référence 140 GB 164 GB 173 GB 207 GB
FP8Proche 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œudLa précision qui tientMémoire de la cartetok/s estimésPar mois
NVIDIA RTX A6000PCIe 5.0 · 768 GB/s 4-bit (AWQ, GPTQ) 48 GB ~10 $286/mois
2 × NVIDIA RTX A6000PCIe 5.0 ×16 · 768 GB/s 4-bit (AWQ, GPTQ) 48 GB ~10 $597/mois
NVIDIA L40SPCIe 5.0 · 864 GB/s 4-bit (AWQ, GPTQ) 48 GB ~11 $714/mois
NVIDIA A100 PCIePCIe 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-lenRéglez-le sur le contexte que vous servezvLLM 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-utilization0.90 à 0.95La 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=hostObligatoire, pas optionnelSans 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-sizeSeulement quand le modèle ne tient pasRépartir un modèle qui tient sur une seule carte le rend plus lent. Voir le guide de l’interconnexion — 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 fp8Ré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-seqsLimitez-la à votre concurrence réelleLe 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 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.

Se connecter

Console, factures et accès hors bande.

Pas encore de compte ?

Il n’y a pas d’inscription séparée. Votre compte est créé au moment où vous passez votre première commande — vous choisissez l’e-mail et le mot de passe à l’étape de paiement, et la console est ouverte au moment où la machine l’est.

Configurer un serveur

Language