La VRAM qu’un modèle nécessite réellement.

La formule

Aucune règle empirique ne survit ici à l’épreuve d’un second modèle. Le calcul complet tient en trois lignes, et il vaut mieux les faire que de se fier à un multiplicateur.

# 1. Weights
weights_gb   = parameters_in_billions × bytes_per_parameter

# 2. KV cache, per token — then multiplied by the context you serve
bytes_per_tok = 2 × layers × kv_heads × head_dim × cache_bytes
cache_gb      = bytes_per_tok × context_tokens × batch / 1024³

# 3. Everything else
total_gb      = (weights_gb + cache_gb) × 1.15

Le 2 s’explique par la présence de deux tenseurs par token, K et V. bytes_per_parameter vaut 2 pour BF16, 1 pour FP8, 0,5 pour 4-bit. cache_bytes est un nombre distinct, et cette séparation est la source d’erreur la plus fréquente — voir ci-dessous.

Poids

La moitié facile. Elle est exactement linéaire par rapport au nombre de paramètres, et la seule décision à prendre est la précision.

La quantification en 4-bit coûte de la qualité, et l’ampleur de cette perte dépend bien plus du modèle que de la méthode. C’est le bon compromis quand cela fait la différence entre une carte et quatre ; c’est un mauvais compromis quand vous êtes déjà à l’aise.

Le cache clef/valeur

La moitié difficile, celle qui décide si une machine est adaptée à 4k et inadéquate à 128k. Elle dépend des couches et des têtes KV — pas de la taille du modèle.

Lisez la dernière colonne avant la première. À un contexte de 4k, le cache est une erreur d’arrondi pour chaque modèle ici ; à 128k, il dépasse le poids d’un modèle 70B en 4-bit. DeepSeek V3 fait exception parce que son attention latente compresse le cache par conception — c’est ce qui le rend utilisable à contexte long malgré le fait qu’il soit le plus gros modèle de la liste.

Où les estimations se trompent

Exemples détaillés

Mémoire totale nécessaire, poids plus cache plus marge, avec un contexte de 8k et une requête. C’est le même calcul que le configurateur applique à chaque configuration du catalogue.

La dernière colonne indique le nœud le moins cher de notre catalogue qui contient le modèle en 4-bit et avec un contexte de 8k, avec le débit de génération en flux unique que permet la bande passante mémoire. Les chiffres de débit sont délibérément prudents et calibrés sur des mesures publiées — considérez-les comme un plancher, pas une promesse.

Servir plus d’une requête

C’est ici qu’une machine dimensionnée pour une démonstration devient une machine incapable de servir un produit. Les poids se paient une fois ; le cache se paie par séquence simultanée.

Llama 3.3 70B en 4-bit pèse 35 GB de poids, quoi que vous fassiez. Tout ce qui dépasse 35 GB dans ce tableau est du cache. C’est pourquoi « ça tournait bien sur mon ordinateur portable » et « ça s’est effondré en production » désignent le même modèle sur la même carte.

Quelle machine cela implique

Trois règles pratiques qui découlent de tout ce qui précède, dans l’ordre de leur importance.

1. Une seule carte vaut mieux que plusieurs, chaque fois que c’est possible. Pas de répartition, pas de synchronisation entre les couches, pas d’interconnexion à prendre en compte. Si votre modèle, à votre contexte, tient sur une seule carte, achetez cette carte.
2. Dimensionnez pour votre contexte réel et votre concurrence réelle, pas pour le maximum annoncé du modèle. Le maximum annoncé est une capacité, pas une obligation.
3. Quand vous devez répartir, préférez NVLink. Répartir sur quatre cartes PCIe fonctionne ; répartir sur quatre cartes NVLink fonctionne et est nettement plus rapide. Le guide suivant explique précisément quand cette différence justifie son coût.

Le configurateur effectue ce calcul en direct sur les 41 configurations : choisissez un modèle, une précision et une longueur de contexte, et il indique quels nœuds le contiennent, lesquels le contiennent sur une seule carte, et ce que coûte chacun par mois. Il applique la formule de cette page, donc si vous contestez notre calcul, vous pouvez désormais dire exactement où.