How do I calculate the VRAM a self-hosted LLM needs?

Three terms. Model weights are parameters multiplied by bytes per parameter — a 70B model at FP16 is about 140GB, at INT8 about 70GB, at INT4 about 35GB. The KV cache is 2 (one key, one value) x layers x KV heads x head dimension x bytes per element, per token, and that whole figure is multiplied again by your context length and by the number of sequences in flight. Then subtract 10-20% for CUDA context, activations, fragmentation and the runtime itself. Weights are a fixed cost you pay once; the KV cache is the term that scales with traffic, and it is the one that decides your concurrency ceiling.

Why does grouped-query attention matter so much for concurrency?

Because the KV cache scales with the number of KV heads, not attention heads. A model with 64 attention heads but only 8 KV heads — standard grouped-query attention in current open-weight models — has an eight-times smaller KV cache than the equivalent multi-head model, which translates almost one-for-one into eight times the concurrent sequences on identical hardware. This is why a modern 70B model can serve more simultaneous users than an older 13B model in some configurations. If you are sizing hardware from a parameter count alone you will get the answer badly wrong; enter the KV head count from the model's config file.

When is self-hosting actually cheaper than paying per token?

Only at high, sustained utilisation. A rented GPU bills every hour whether or not a request arrives, so your effective cost per million tokens is the hourly rate divided by the tokens you actually generate in that hour. At full saturation the economics are often excellent; at 20% duty cycle your real cost per million tokens is five times the headline figure and almost always loses to an API. The break-even throughput shown by this calculator is the number of tokens per second you must sustain, on average and not at peak, for self-hosting to beat the API rate you entered. If your traffic is bursty, compare against that average rather than your peak.

LLM VRAM et calculateur de concurrence | Dimensionnement du cache KV jusqu'à 1 million de dollars de jetons

LLM VRAM et calculateur de concurrence

✓ Dernière vérification : 2026-07-23· Source : configurations de modèles publiées + tarifs de location de GPU publics· signaler un changement →

Chaque décision d'auto-hébergement commence par la même question et presque personne n'y répond correctement : combien de personnes ce GPU peut-il réellement servir à la fois, et combien coûte réellement un million de jetons une fois que le matériel est facturé à l'heure, que vous l'utilisiez ou non.

Les poids sont la partie la plus facile. L'ajustement du modèle est un calcul sur une seule ligne et il ne vous dit presque rien. Ce qui décide si vous pouvez servir huit ou quatre-vingts utilisateurs, c'est le cache KV – une mémoire qui évolue en fonction de la longueur du contexte. et avec chaque séquence simultanée en vol. Cet outil dimensionne les deux, puis convertit la capacité résultante en un coût par million de jetons que vous pouvez détenir contre une facture API.

Ajuster le modèle n’est pas la même chose que le servir

Le conseil que vous trouverez partout est qu'un modèle 70B sur INT4 a besoin d'environ 35 Go, il tient donc sur une seule carte de 80 Go avec de l'espace disponible. C’est vrai et c’est presque inutile, car cela décrit un modèle inactif. Au moment où les demandes arrivent, chaque séquence en vol alloue son propre cache KV : deux tenseurs par couche, dimensionnés par les têtes KV multipliées par la dimension de la tête, conservés pour chaque jeton dans le contexte de cette séquence. Avec 80 couches, 8 têtes KV, 128 dimensions et FP16, soit 327 680 octets par jeton – un tiers de mégaoctet – ce qui dans un contexte 8K représente environ 2,7 Go. par demande simultanée. Les 45 Go de marge qui semblaient si confortables représentent environ une douzaine d'utilisateurs, et le treizième est mis en file d'attente. La planification de la capacité pour l'inférence est la planification du cache KV ; les poids fixent simplement les frais d’entrée.

L’effectif KV est le nombre qui bouge réellement

L'attention aux requêtes groupées est la raison pour laquelle les modèles modernes à poids ouvert sont utilisables, et elle est systématiquement manquée par quiconque dimensionne le matériel à partir d'un nombre de paramètres. Un modèle avec 64 têtes d'attention et 8 têtes KV stocke un huitième du cache d'une conception multi-têtes équivalente, ce qui convertit presque linéairement en huit fois la simultanéité sur la même carte. Essayez le préréglage multi-têtes 13B ci-dessus par rapport au préréglage 70B : le modèle le plus petit est souvent celui qui manque de mémoire en premier, ce qui n'est pas intuitif tant que vous ne voyez pas où vont les octets. Réduire de moitié la précision KV à FP8 double à nouveau la simultanéité pour un coût de précision modeste. Ces deux commutateurs déplacent la capacité bien plus que l’achat d’une carte plus grande, et ils ne coûtent rien.

L'utilisation décide de l'économie, pas du matériel

La table finale est celle qui met fin honnêtement à la plupart des projets auto-hébergés. Un H100 loué coûte le même prix de 2,50 $ de l'heure à 3 heures du matin sans trafic qu'en période de pointe, donc votre coût réel par million de jetons est le chiffre global divisé par votre cycle de service moyen. Servez à 20 % d'utilisation et vous payez cinq fois ce que suggère le chiffre optimiste du calculateur - et par rapport aux tarifs de l'API de base pour un petit modèle, ce n'est pas proche. L'auto-hébergement gagne sur un volume soutenu, saturé et prévisible, sur des charges de travail avec des contraintes de résidence des données ou de latence qu'une API ne peut pas respecter, et sur des modèles que personne ne vend par jeton. Il perd en cas de trafic intense, et il perd en douceur, car la facture est plate et la capacité gaspillée n'apparaît jamais comme un élément de campagne. Recoupez la conclusion avec le calculateur LLM vs API auto-hébergé, évaluez le matériel lui-même avec le Calculateur de coût d'inférence GPU, et si la réponse est marginale, regardez un modèle plus petit distillé ou mise en cache rapide avant d'acheter un support.

Comment fonctionne cette calculatrice

Les poids sont des paramètres × octets par paramètre. Le cache KV par jeton est de 2 × couches × têtes KV × dimension de tête × octets KV ; multiplié par la longueur du contexte qui donne la mémoire que contient chaque séquence concurrente. La mémoire utilisable correspond à la VRAM totale sur vos GPU moins un pourcentage de surcharge d'exécution, et ce qui reste après les pondérations est divisé par le chiffre par séquence pour donner le plafond de simultanéité. Le coût par million de jetons correspond à la facture horaire du GPU divisée par les jetons que vous générez réellement en une heure, c'est pourquoi le tableau d'utilisation est aussi important que celui de la mémoire.

Questions fréquemment posées

Comment calculer la VRAM dont un LLM auto-hébergé a besoin ?

Trois termes : poids du modèle (paramètres × octets par paramètre), le cache KV (2 × couches × têtes KV × dimension de tête × octets, par jeton, multiplié par la longueur du contexte, multiplié par les séquences simultanées) et 10 à 20 % de surcharge pour le contexte CUDA, les activations et la fragmentation. Les poids sont des frais d'entrée fixes ; le cache KV est le terme qui évolue avec le trafic et définit votre plafond de concurrence.

Pourquoi l’attention aux requêtes groupées est-elle si importante pour la concurrence ?

Parce que le cache KV évolue avec les têtes KV, pas avec les têtes d'attention. Un modèle avec 64 têtes d'attention mais 8 têtes KV a un cache huit fois plus petit que l'équivalent multi-têtes, qui convertit presque une pour une en huit fois les séquences simultanées sur la même carte. Taille issue du fichier de configuration du modèle, et non de son nombre de paramètres.

Quand l’auto-hébergement est-il réellement moins cher que de payer par token ?

Uniquement en cas d'utilisation élevée et prolongée. Un GPU loué facture toutes les heures, qu'une demande arrive ou non, donc avec un cycle de service de 20 %, votre coût réel par million de jetons est cinq fois supérieur au chiffre global. Le seuil de rentabilité ci-dessus correspond au nombre de jetons par seconde que vous devez maintenir en moyenne (et non au maximum) pour que l'auto-hébergement batte le taux d'API que vous avez entré.