Dimensionnement guide · 10 min de lecture

# Combien de personnes un GPU peut réellement servir.

Une machine qui tient votre modèle n’est pas une machine qui sert vos utilisateurs. Les poids sont un péage, payé une fois ; ce qui reste après eux est tout le budget dont vous disposez pour servir des utilisateurs. Ce reste — pas la taille de la carte — détermine votre capacité, et il évolue bien plus vite que la mémoire.

En bref

- **La capacité, c’est le reste, pas la carte:** **Llama 3.3 70B** en 4 bits réserve **40 GB** avant de servir qui que ce soit. Chaque requête simultanée supplémentaire coûte **2.9 GB** de plus.
- **C’est pourquoi la mémoire compte double:** Sur une seule et même carte, passer de 48 GB à 240 GB multiplie la mémoire par 5.0× et le nombre de places par **35×**. Les poids sont déjà payés.
- **Le pire achat de la présélection:** [NVIDIA L40S](https://gpuserver.io/fr/gpu/l40s) à **$714** par mois tient 2 requêtes simultanées — **$357.00** par place.
- **La meilleure coûte moins cher:** [4 × NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) à **$564** tient 19 — **$29.68** par place, pour une facture moins élevée.

## La version courte

Tout guide qui vous dit si un modèle *tient* répond à une question portant sur une seule requête. Un produit n’est pas une seule requête. Dès que deux personnes utilisent votre endpoint en même temps, la machine a besoin d’une deuxième copie de la conversation en mémoire — puis d’une troisième, puis d’une quarantième — alors que les poids, eux, ne sont stockés qu’une seule fois.

Le chiffre qui détermine combien de personnes vous pouvez servir n’est donc pas la taille de la carte. C’est la taille de la carte *moins* le modèle, divisée par ce que coûte une conversation. Ces deux termes sont connus avant même de passer commande, ce qui fait de la capacité l’une des rares choses, en machine learning, dont on peut être certain en se contentant d’un calcul sur le papier.

**Les poids sont un péage.** Payés une fois, à l’entrée, quel que soit votre trafic. Ils ne croissent pas avec vos utilisateurs et ne reviennent jamais.

**Le cache clef/valeur est le loyer.** Payé par requête simultanée, aussi longtemps que cette requête reste ouverte, et proportionnel à la longueur de la conversation.

**La capacité est ce qui reste, divisé par le loyer.** C’est pourquoi une machine avec deux fois plus de mémoire sert très souvent dix fois plus de monde, et non pas simplement deux fois plus.

**Et pourquoi la machine la moins chère qui tient est généralement celle qui offre le moins bon rapport qualité-prix.** Elle tient parce qu’il ne lui reste presque rien, et ce qui lui reste est la seule partie que vous achetez réellement.

Tout ce qui suit applique le même calcul que [le configurateur](https://gpuserver.io/fr/configure), sur le même catalogue, en 4 bits avec 8k de contexte. Si la formule de mémoire elle-même est nouvelle pour vous, [elle a son propre guide](https://gpuserver.io/fr/guides/vram-sizing) — cette page montre ce qu’il lui arrive dès que plus d’une personne se présente.

## Ce qui reste après les poids

Prenez le modèle de référence de ce site et placez-le sur chaque taille de nœud construite à partir de la même carte. Même puce, même prix par carte, tout est identique — seule la quantité de mémoire change. Observez les deux dernières colonnes évoluer à des vitesses complètement différentes.

**Requêtes simultanées pour Llama 3.3 70B en 4 bits et 8k de contexte, sur chaque nœud construit à partir de la même carte**

| Nœud | Mémoire | Ce qui reste après les poids | Requêtes simultanées | Par mois |
|---|---|---|---|---|
| [NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) | 24 GB | — | ne le tient pas | $125 |
| [2 × NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) | 48 GB | 8 GB | 2 | $285 |
| [4 × NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) | 96 GB | 56 GB | 19 | $564 |
| [8 × NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) | 192 GB | 152 GB | 52 | $1,106 |
| [10 × NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) | 240 GB | 200 GB | 69 | $1,371 |

La première ligne résume toute la leçon : une carte qui ne peut même pas contenir les poids ne sert personne, et ce n’est pas discutable. Les lignes suivantes gagnent de la mémoire par paliers égaux, mais gagnent des places à un rythme croissant, parce que le péage de 40 GB est payé sur la première ligne, et jamais plus.

**Le calcul, en une ligne.** `seats = (memory − weights) ÷ cache_per_request`. Pour Llama 3.3 70B en 4 bits, cela représente 40 GB de péage et 2.9 GB de loyer par conversation ouverte. Soustrayez avant de diviser — faire l’inverse, c’est ainsi qu’une machine achetée pour une démonstration se retrouve prise en défaut en production.

## Ce que coûte réellement un utilisateur

Voici maintenant les mêmes modèles, triés comme le ferait un acheteur : du moins cher au plus cher. La dernière colonne est le prix mensuel divisé par le nombre de personnes que la machine peut accueillir à la fois — la seule colonne qui compare deux machines honnêtement lorsque vous construisez autre chose qu’une démonstration.

Une hypothèse, énoncée parce qu’elle change tous les chiffres : chaque nombre de places correspond à *une seule* instance du modèle répartie sur l’ensemble du nœud, ce que donne `--tensor-parallel-size`. Les poids sont stockés une seule fois, et chaque carte apporte sa mémoire restante à un même réservoir de conversations. Faites plutôt tourner deux copies séparées sur le même nœud, et vous payez le péage deux fois, pour moins de places au total.

**Les dix nœuds les moins chers qui tiennent Llama 3.3 70B, avec ce que coûte chacun par utilisateur simultané**

| Nœud | Mémoire | Par mois | Requêtes simultanées | Par utilisateur |
|---|---|---|---|---|
| [2 × NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) 2 cartes · 24 GB chacune | 48 GB | $285 | 2 | $142.50 |
| [NVIDIA RTX A6000](https://gpuserver.io/fr/gpu/rtx-a6000) Une carte · 48 GB | 48 GB | $286 | 2 | $143.00 |
| [2 × NVIDIA RTX 4090](https://gpuserver.io/fr/gpu/rtx-4090) 2 cartes · 24 GB chacune | 48 GB | $416 | 2 | $208.00 |
| [4 × NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) 4 cartes · 24 GB chacune | 96 GB | $564 | 19 | $29.68 |
| [2 × NVIDIA RTX A6000](https://gpuserver.io/fr/gpu/rtx-a6000) 2 cartes · 48 GB chacune | 96 GB | $597 | 19 | $31.42 |
| [2 × NVIDIA RTX 5090](https://gpuserver.io/fr/gpu/rtx-5090) 2 cartes · 32 GB chacune | 64 GB | $692 | 8 | $86.50 |
| [NVIDIA L40S](https://gpuserver.io/fr/gpu/l40s) Une carte · 48 GB | 48 GB | $714 | 2 | $357.00 |
| [2 × NVIDIA A100 PCIe](https://gpuserver.io/fr/gpu/a100-40gb) 2 cartes · 40 GB chacune | 80 GB | $802 | 13 | $61.69 |
| [4 × NVIDIA RTX 4090](https://gpuserver.io/fr/gpu/rtx-4090) 4 cartes · 24 GB chacune | 96 GB | $814 | 19 | $42.84 |
| [NVIDIA A100 PCIe](https://gpuserver.io/fr/gpu/a100-80gb) Une carte · 80 GB | 80 GB | $1,091 | 13 | $83.92 |

Lisez les deux cellules colorées en regard de leur colonne de prix. NVIDIA L40S coûte $714 par mois et tient 2 ; 4 × NVIDIA L4 coûte $564 — *moins cher* — et tient 19. Cela représente 10× le nombre de places pour 0.79× la facture, et c’est pourtant la machine chère que la plupart des présélections retiennent, parce que c’est celle où le modèle tient sur une seule carte.

**Ceci n’est pas un argument contre les machines à une seule carte.** Un modèle qui tient sur une seule carte n’a besoin ni de répartition, ni d’interconnexion, ni d’options tensor-parallel, et il répond à un utilisateur seul plus vite que le même modèle réparti sur quatre cartes. Si votre charge se limite à une requête à la fois — une tâche par lots, un outil interne, une démonstration — cette machine est le bon achat, et la colonne par utilisateur ne vous concerne pas. Cette colonne ne commence à compter que lorsque plusieurs personnes arrivent en même temps, et alors, elle compte énormément.

Sur l’ensemble du catalogue, et pas seulement les dix premières lignes, le meilleur prix par place pour ce modèle est [8 × NVIDIA RTX A6000](https://gpuserver.io/fr/gpu/rtx-a6000) à $2,239 par mois : 119 requêtes simultanées, à $18.82 chacune. C’est une facture bien plus élevée que tout ce qui figure dans la présélection ci-dessus, et c’est pourtant le moyen le moins cher d’offrir une place à un utilisateur — la phrase même qui distingue le dimensionnement d’un produit de celui d’un prototype.

## La longueur de contexte est l’autre multiplicateur

Tout ce qui précède supposait 8k de contexte. Cette hypothèse pèse plus lourd que le choix de la machine. Le cache est payé par token autant que par utilisateur, si bien qu’un même nœud n’offre pas du tout le même nombre de places selon la longueur que vous laissez atteindre à une conversation.

Une machine, quatre modèles, quatre longueurs de contexte. Le nœud est [8 × NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4) à $1,106 par mois — le moins cher de notre catalogue à tenir les quatre modèles à la fois, de sorte que chaque chiffre ci-dessous est mesuré sur la même mémoire.

**Requêtes simultanées sur un nœud, par modèle et longueur de contexte, en 4 bits**

| Modèle | Cache par token | 4k | 8k | 32k | 128k |
|---|---|---|---|---|---|
| Llama 3.1 8B 4 GB de poids | 128 KiB | 325 | 162 | 40 | 10 |
| Qwen 3 32B 16 GB de poids | 256 KiB | 150 | 75 | 18 | 4 |
| Llama 3.3 70B 35 GB de poids | 320 KiB | 105 | 52 | 13 | 3 |
| Qwen 3 235B-A22B (MoE) 118 GB de poids | 188 KiB | 67 | 33 | 8 | 2 |

Sur une seule et même machine, Llama 3.3 70B passe de 105 à 3 utilisateurs simultanés — un facteur 35× — uniquement à cause d’un nombre que vous réglez en ligne de commande. Rien n’a changé côté matériel.

Deux conséquences en découlent. La première : la colonne de contexte à lire est celle que vous servez réellement, pas celle qu’annonce la fiche du modèle — un modèle qui *prend en charge* 128k ne vous oblige pas à le réserver en entier. La seconde : le cache par token varie énormément entre des modèles de taille comparable, car il est déterminé par la conception du mécanisme d’attention plutôt que par le nombre de paramètres ; [les plus gros modèles de ce tableau figurent aussi parmi ceux qui ont les plus petits caches](https://gpuserver.io/fr/guides/mixture-of-experts), ce qui est le fait le plus contre-intuitif de tout ce domaine.

## Quatre façons de racheter de la capacité

Par ordre décroissant de ce qu’elles vous rapportent pour ce qu’elles coûtent. La première est presque gratuite, et presque toujours négligée.

Plafonner le contexte déclaré Gratuit, et le plus gros gain Les piles d’inférence réservent le cache pour la longueur maximale que vous déclarez, pas celle que vous utilisez. Déclarer 128k et servir 8k gaspille seize fois la mémoire dont vous aviez besoin — et cette mémoire, c’était toute votre capacité en places. Réglez `--max-model-len` sur votre plafond réel dès le premier jour.

Quantifier le cache en 8 bits Double à peu près le nombre de places Quantifier les *poids* en 4 bits ne change rien au cache : il reste en 16 bits dans toutes les piles courantes, sauf demande explicite. Cela tient en une seule option, le coût en qualité est généralement invisible sur des usages de conversation, et le tableau ci-dessous montre ce que cela donne.

Quantifier davantage les poids Aide une fois, puis s’arrête Diviser les poids par deux transfère directement la différence au cache, ce qui achète des places sur une machine surchargée. Mais c’est un gain ponctuel face à un péage fixe, et cela coûte en qualité — [quel format coûte combien](https://gpuserver.io/fr/guides/awq-vs-gptq-vs-fp8) est une décision à part entière.

Louez le reste, pas la carte La solution structurelle Chacun des leviers ci-dessus agit à la marge. Passer à un nœud dont la mémoire dépasse largement vos poids change la nature même du problème, et c’est le seul des quatre qui continue de rapporter à mesure que vous grandissez.

**Requêtes simultanées sur le même nœud avec un cache 16 bits et avec un cache 8 bits, à 8k de contexte**

| Modèle | Cache 16 bits | Cache 8 bits | Places gagnées |
|---|---|---|---|
| Llama 3.1 8B | 162 | 325 | +163 |
| Qwen 3 32B | 75 | 150 | +75 |
| Llama 3.3 70B | 52 | 105 | +53 |
| Qwen 3 235B-A22B (MoE) | 33 | 67 | +34 |

Même nœud, mêmes poids, même prix. Le seul changement est la précision dans laquelle le cache est stocké, et c’est la différence entre une machine qui sert une équipe et une machine qui sert un produit.

## Les places ne sont pas le service

Une correction avant de dimensionner quoi que ce soit à partir des chiffres ci-dessus, et c’est grâce à elle que cette page reste honnête. Tout ce qui est compté ici, c’est combien de conversations la machine peut garder *ouvertes*. Cela ne garantit pas qu’elles sont toutes traitées rapidement.

La mémoire et la bande passante sont deux plafonds distincts. Sur [8 × NVIDIA L4](https://gpuserver.io/fr/gpu/nvidia-l4), Llama 3.3 70B a la place pour 52 conversations simultanées, alors qu’un utilisateur seul sur cette machine obtient environ 17 tokens par seconde. Remplir les 52 places ne donne pas 17 tokens par seconde à chacune d’elles — la génération partage la même bande passante mémoire, si bien que l’agrégat augmente avec le traitement par lots, tandis que le débit par utilisateur diminue. Le plafond de bande passante est atteint bien avant celui de la mémoire.

**Utilisez le nombre de places comme un plafond, pas comme un objectif.** Une machine remplie jusqu’à sa dernière place est une machine où tout le monde attend. Le nombre de places vous indique quel matériel est capable d’atteindre votre niveau de simultanéité — cela élimine les machines qui ne le peuvent pas, soit la plupart de la présélection — puis vous mesurez le débit que vous voulez réellement par utilisateur, et vous prenez de la marge par rapport au plafond. Dimensionner sur le plafond est la deuxième erreur la plus fréquente dans le choix d’une machine, juste après avoir ignoré le cache.

La bonne nouvelle, c’est que les deux plafonds évoluent ensemble : les machines auxquelles il reste beaucoup de mémoire une fois les poids déduits sont, à quelques exceptions près, aussi celles qui offrent le plus de bande passante. Privilégier la marge disponible coûte rarement en vitesse. [Configurer la pile d’inférence](https://gpuserver.io/fr/guides/serve-llama-70b) sur la machine que vous aurez choisie fait l’objet d’un guide séparé, et c’est dans les options qu’il couvre que ces chiffres se concrétisent.

## Choisir en fonction du nombre d’utilisateurs

Dans l’ordre. Arrêtez-vous à la première ligne qui décrit votre charge.

1. **Une requête à la fois.** Tâches par lots, outil interne, développeur unique. Achetez la machine la moins chère qui tient le modèle sur une seule carte, et arrêtez votre lecture ici — chaque colonne de cette page répond à une question que vous ne vous posez pas.
2. **Une poignée de personnes, occasionnellement.** Un outil d’équipe, un produit à ses débuts. Calculez votre pic de requêtes simultanées, pas votre nombre d’utilisateurs : une centaine d’utilisateurs inscrits ne signifie que rarement plus qu’une poignée d’utilisateurs simultanés. Prenez ensuite la machine la moins chère dont le nombre de places dépasse confortablement ce pic.
3. **Un produit réel avec un trafic réel.** Triez le catalogue par prix par place plutôt que par prix, plafonnez votre contexte à ce que vous servez réellement, passez le cache en 8 bits, et attendez-vous à ce que la gagnante soit une machine que vous n’auriez pas présélectionnée sur son prix mensuel.
4. **Documents longs ou conversations longues.** Lisez d’abord le tableau des contextes, puis celui des machines. À partir de 32k, le cache domine si complètement que le choix du modèle compte moins que la conception de son mécanisme d’attention.
5. **Trafic en pics, imprévisible.** Dimensionnez pour le pic que vous ne pouvez pas vous permettre de manquer, car le cache ne peut pas être emprunté une fois épuisé — une requête qui n’a nulle part où placer sa conversation attend dans une file. Si le pic est rare et énorme, [une API facturée au token pour l’excédent](https://gpuserver.io/fr/guides/api-vs-self-hosting) coûte moins cher qu’une machine dimensionnée pour un pic qui survient deux fois par mois.

Quelle que soit la ligne où vous vous êtes arrêté, faites la soustraction avant toute autre chose : prenez la mémoire de la machine, retranchez les poids de votre modèle dans la précision à laquelle vous allez servir, et regardez ce qui reste. Ce reste est le produit que vous louez. Le [configurateur](https://gpuserver.io/fr/configure) applique ce même calcul sur chaque nœud que nous exploitons, et [ce que coûte un mois de location](https://gpuserver.io/fr/guides/monthly-vs-hourly) est établi séparément.

## Dimensionnez la machine sur les utilisateurs, pas sur le modèle.

Le configurateur recense chaque nœud que nous louons, applique le même calcul de mémoire que cette page, et montre ce qui reste une fois votre modèle chargé — avant que vous ne payiez quoi que ce soit.

[Ouvrir le configurateur](https://gpuserver.io/fr/configure) [Lire les guides](https://gpuserver.io/fr/guides)

## Autres guides

- [Coût · 6 min Quand la location mensuelle l’emporte sur l’horaire Le seuil de rentabilité sur des chiffres réels, les trois coûts qu’un prix horaire cache jusqu’à la facture, et le piège du temps mort qui triple une estimation. Lire le guide](https://gpuserver.io/fr/guides/monthly-vs-hourly)
- [Coût · 9 min L’auto-hébergement contre une API facturée au token Le seuil de rentabilité entre payer une API au token et louer un GPU, calculé sur nos propres prix et débit — et les quatre points que l’arithmétique laisse de côté. Lire le guide](https://gpuserver.io/fr/guides/api-vs-self-hosting)
- [Pratique · 11 min Servir Llama 3.3 70B sur un nœud D’une machine livrée à un point de terminaison compatible OpenAI, avec les options qui comptent et les deux qui divisent silencieusement votre débit par deux. Lire le guide](https://gpuserver.io/fr/guides/serve-llama-70b)

---

Source : https://gpuserver.io/fr/guides/concurrent-users/. 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/.