How much GPU memory does a large language model need?

The weights are the parameter count multiplied by the bytes per parameter: two bytes each at 16-bit, one at 8-bit, half at 4-bit. A 7-8 billion parameter model is 16 GB of weights at 16-bit, 8 GB at 8-bit and 5 GB at 4-bit; a 70 billion parameter model is 140 GB, 70 GB and 38 GB. Those figures are the weights alone and are a floor rather than a requirement -- budget a quarter to a half again on top for the runtime, the activations and the key-value cache.

What do I need to run a 70B model like Llama 3.3?

At 4-bit the weights are about 38 GB, so with serving head-room the answer is a card of 64 GB or more -- one card, one machine. At 8-bit the weights are 70 GB and an 80 GB card clears the bar. At full 16-bit precision no single card Primcast fits holds it, and it becomes a multi-card build that is quoted. The fit matrix on the page names the exact cards; the prices are at https://primcast.com/gpu.

Why does my model load but fail to serve?

Because the weights are not the only thing in card memory. The runtime and its buffers are resident, and every token in a conversation leaves an entry in the key-value cache so it does not have to be recomputed. That cache grows with the context length and again with each request served concurrently, so a model whose weights only just fit will hold roughly one short conversation. Size the card at one and a quarter to one and a half times the weights.

Which inference runtime can I install?

Any of them. The machine arrives with a clean operating system and root, and there is no vendor inference service in front of it. vLLM is the usual answer for serving real traffic because continuous batching lets one card answer many requests at once. llama.cpp is the usual answer when memory is tight or the card is older. TGI and SGLang run unchanged. Ollama is the shortest path from an empty machine to a model answering on a port -- and vLLM and Ollama both answer on an OpenAI-compatible endpoint, so existing client code points at your own machine by changing one base URL. You pin the driver, the CUDA or ROCm release and the framework to the versions your code was tested against.

Is self-hosting an LLM cheaper than a per-token API?

It depends entirely on volume, and the crossover is real: an API bills per token and costs nothing when idle; a dedicated machine is a flat monthly figure and costs nothing more when busy. Steady traffic, agents that run all day, batch pipelines and anything with a privacy requirement tend to come out ahead on their own hardware; a workload that fires ten times a day does not. The monthly figures to do that arithmetic with are at https://primcast.com/gpu -- the LLM page deliberately prices nothing.

How many tokens per second will I get?

Primcast does not publish a tokens-per-second figure, because every such number depends on the model, the quantisation, the runtime and its version, the batch size, the prompt length, the reply length and the concurrency, and changing any one moves it by a multiple. What governs it: reading the prompt is compute-bound and happens once per request; generating the reply is memory-bandwidth-bound because each token requires reading the weights; and batching amortises that reading across concurrent requests, which is what makes serving economical until the key-value cache runs out of room. Ask with the model, quantisation and expected concurrency for an answer based on what has actually been observed.

Is the GPU shared with anyone else?

No. One tenant per physical machine, and the card is passed through to your own operating system. There is no hypervisor, no MIG partition, no vGPU profile and no time-slicing scheduler, so nothing else runs on the card and inference latency does not move because of somebody else's batch job.

What if the model does not fit on one card?

Then it is a multi-card build, which is quoted rather than ordered from a checkout: how many cards fit depends on the physical width of the specific card and the power budget of the chassis. Two cards give you the sum of their memory only if the runtime can split the model across both, which every serious runtime supports at some cost in throughput. https://primcast.com/hpc covers what more than one card and more than one machine look like; 128 GB of memory the processor and GPU share in one machine is https://primcast.com/spark.

Does fine-tuning need more memory than serving?

Considerably more. Serving needs the weights; training needs the weights, the gradients and the optimiser state for every parameter being updated, all resident at once, plus the activations kept for the backward pass. A model that serves comfortably on one card can be several times too large to fully fine-tune on it. Parameter-efficient methods update a small fraction of the parameters and need a correspondingly small fraction of the extra memory, which is why most fine-tuning here uses one.

Can I run an AMD card, and does ROCm work?

Yes. The AMD Instinct parts are among the largest-memory cards fitted and are frequently the best value per gigabyte, but your stack has to support ROCm rather than CUDA. Most current inference runtimes do; some surrounding tooling still does not. Ask before ordering and it will be checked against your specific runtime rather than answered in general.

Feuille de dimensionnement · modèles de langage sur bare metal · depuis 2004

Ce qu’il faut pour faire tourner un modèle de langage sur bare metal.

Remplie depuis le haut, dans l’ordre de la décision : le modèle fixe les poids, la précision les met à l’échelle, la marge de sécurité couvre l’exécution et la conversation, et le total désigne la carte. Rien d’autre sur le bon de commande ne change la réponse — une carte à deux gigaoctets près ne tourne pas plus lentement, elle refuse de charger.

Dessiné par: Primcast LLC, fondée en 2004
Vérifié contre: Le catalogue de commandes, au moment de la mise en ligne
Cartes enregistrées · la plus grande: 56 · 96 GB GDDR7 ECC
Prix sur cette feuille: Aucun — voir /gpu

Remplir la feuille de calcul Pourquoi un ajustement peut quand même échouer Ce que j’installe dessus

Transformez vos GPU en revenu mensuel passif

Vous avez des configurations GPU de serveur ou de bureau inutilisées ? Mettez-les en ligne dès aujourd’hui sur la marketplace Primcast et percevez des loyers mensuels réguliers de la part d’équipes d’IA, de développeurs et d’entreprises qui ont besoin de calcul de qualité production.

Aller à la Marketplace

Feuille de calcul

Quatre lignes, un verdict.

Le modèle

La précision

La charge

70B: 38 GB × 1.5 = 57 GB

Smallest card on the schedule that clears it (3 larger ones also do):

Instinct MI21064 GB HBM2e

The link opens the machine it goes in. What it costs is on /gpu — not on this sheet.

Ligne 1 × ligne 2, ce sont les poids ; la ligne 3 est la règle publiée du site, un quart à la moitié de marge, traduite en arithmétique — un quart de plus pour un utilisateur à la fois sur llama.cpp ou Ollama, la moitié de plus pour servir du trafic avec du batching continu sur vLLM ou TGI. Le verdict nomme la plus petite carte du catalogue de commandes qui dépasse le total, et renvoie vers la machine dans laquelle elle s’installe. Ce que coûte cette machine est délibérément absent de cette feuille : tous les chiffres sont sur /gpu, en regard de la machine exacte à laquelle ils appartiennent.

Fig. 1

Ce que pèsent les poids.

Des paramètres multipliés par des octets par paramètre, et c’est là tout le calcul. Les poids en seize bits font deux octets chacun, en huit bits un octet, en quatre bits un demi-octet. La quantification est ce qui transforme une machine incapable de contenir un modèle en une machine qui le peut ; elle coûte de la qualité, et combien dépend bien plus du modèle et de la méthode que du seul nombre de bits. Si la précision est l’enjeu de l’exercice, testez les deux avant de vous engager sur le matériel — la différence coûte moins cher à découvrir maintenant qu’après la livraison.

Ces chiffres sont les poids et rien d’autre. Ils sont le plancher, pas l’exigence — la Fig. 2 est la partie qui piège les gens.

Weights only — the runtime, the activations and the conversation are extra, and are the subject of the next section.
Model	16-bit	8-bit	4-bit
7-8 billion parameters	16 GB	8 GB	5 GB
13-14 billion parameters	28 GB	14 GB	8 GB
30-34 billion parameters	68 GB	34 GB	19 GB
70 billion parameters	140 GB	70 GB	38 GB

Fig. 2 · interactive

La mémoire d’une carte, dessinée à l’échelle — et pourquoi un modèle qui tient peut quand même refuser de servir.

La façon la plus courante dont un achat de GPU tourne mal, toujours la même à chaque fois : le modèle fait trente-huit gigaoctets, la carte en fait quarante, il charge — et tient à peu près une courte conversation. Les poids ne sont pas seuls là-dedans. Faites glisser la charge et regardez ce que fait la conversation.

poids · fixes

exécution

cache clé-valeur · grandit

libre

la mémoire d’une carte, 100 %

La conversation · longueur de contexte × requêtes simultanées

Un utilisateur, contexte court : le multiplicateur serré (×1,25) couvre ce cas.

Chaque jeton d’une conversation laisse une entrée dans le cache clé-valeur pour ne pas être recalculé. Le cache grandit avec la longueur du contexte, et encore avec chaque requête servie en même temps.
Prévoyez un quart de plus par rapport aux poids pour un utilisateur à la fois, la moitié de plus pour servir du trafic — les deux multiplicateurs de la feuille de calcul, et la règle publiée du site.
Si c’est juste, demandez avant d’acheter : modèle, quantification, contexte, concurrence. Nous préférons vous dimensionner une carte maintenant plutôt que de recevoir une commande qui revient en demande de remboursement dès la première semaine.

Fig. 3

La matrice d’ajustement : quelle carte couvre quel modèle.

Lisez vers le bas jusqu’à votre modèle, puis en travers jusqu’à la précision. Chaque cellule nomme la plus petite carte du calendrier des pièces qui contient ces poids avec de la place pour servir, et renvoie vers la machine dans laquelle elle s’installe. Là où rien ne la couvre seule, la cellule le dit plutôt que de laisser un blanc.

The smallest card we fit that holds the weights with room left to serve — that is 1.5× the weights, the generous end of the quarter-to-a-half head-room rule below. No prices here on purpose: GPU dedicated servers holds every one.
If you want to run	at 16-bit	at 8-bit	at 4-bit
7-8 billion parameters	TESLA P40 / QUADRO P600024 GB16 GB of weights	TITAN V12 GB HBM28 GB of weights	TESLA P48 GB GDDR55 GB of weights
13-14 billion parameters	RTX A600048 GB GDDR6 ECC28 GB of weights	TESLA P40 / QUADRO P600024 GB14 GB of weights	TITAN V12 GB HBM28 GB of weights
30-34 billion parameters	More than one cardNothing we fit holds it alone68 GB of weights	Instinct MI21064 GB HBM2e34 GB of weights	Tesla V100 32GB32 GB HBM219 GB of weights
70 billion parameters	More than one cardNothing we fit holds it alone140 GB of weights	More than one cardNothing we fit holds it alone70 GB of weights	Instinct MI21064 GB HBM2e38 GB of weights

La plus petite carte qui convient n’est pas toujours la carte que vous voulez. La mémoire décide si un modèle tourne ; tout le reste de la carte décide à quelle vitesse, et pour combien de personnes à la fois. Si le débit compte plus que le budget, montez d’un cran dans le calendrier.
Les cartes plus anciennes ne parlent pas les formats numériques plus récents. Plusieurs pièces du calendrier sont antérieures au FP8 et au bfloat16, donc un runtime qui les attend retombera sur quelque chose de plus lent ou refusera. Il vaut la peine de poser la question pour une carte précise et un runtime précis avant de commander.
Une carte AMD fait tourner ROCm, pas CUDA. Les pièces Instinct offrent un excellent rapport valeur par gigaoctet et sont la réponse dans plus d’une cellule, mais votre pile doit prendre en charge ROCm. La plupart des runtimes actuels le font ; certains outils autour d’eux ne le font toujours pas. Vérifiez le vôtre, ou demandez et nous le vérifierons avec vous.
« Plus d’une carte » est une configuration que nous chiffrons, pas une option de paiement — combien de cartes tiennent dépend de la largeur de la carte précise et du budget d’alimentation du châssis. Multi-GPU et multi-nœuds, c’est cette feuille. L’autre réponse à cette taille, ce sont 128 Go de mémoire partagée entre le processeur et le GPU, dans une seule machine : louer un NVIDIA DGX Spark.

Calendrier A

Calendrier des pièces : chaque carte que nous montons avec un chiffre de mémoire publié.

La plus grande d’abord — cette feuille répond à « quelle est la plus grande chose que je peux faire tourner », l’inverse de GPU dedicated servers, qui trie le même catalogue par la machine complète la moins chère parce qu’il répond à « combien ça coûte ». Une carte dont le fabricant ne publie pas la mémoire est laissée de côté plutôt que devinée.

Plusieurs pièces apparaissent sur plus d’un châssis, parfois à des prix différents, et la génération de bus de la machine en dessous change ce qu’une carte moderne peut réellement faire — les deux sont sur GPU dedicated servers. Ce qui est monté en rack et prêt à l’instant est encore une autre question, à laquelle répondent les serveurs instantanés.

Référence

Modèles nommés, reportés sur les lignes.

Les familles à poids ouverts que les gens apportent ici, avec le nombre de paramètres publié qui dit quelle ligne de la Fig. 1 s’applique. Les nombres de paramètres sont ceux des éditeurs ; rien d’autre dans un modèle n’importe pour la question de l’ajustement. Un modèle qui n’est pas sur cette liste se dimensionne exactement de la même façon — paramètres × octets par paramètre, plus la marge de sécurité. De nouvelles familles sortent chaque mois ; l’arithmétique, elle, ne bouge pas.

Note 1 · mélange d’experts

Un modèle « 30B avec 3B actifs » a besoin de la mémoire d’un modèle 30B et tourne plus près de la vitesse d’un modèle 3B : chaque expert doit être résident, parce que des jetons différents en réveillent des différents. Dimensionnez toujours à partir du nombre total de paramètres.

Famille	Tailles	Ligne
Llama 3.1 / 3.3 Meta	8B · 70B	7–8B, et 70B pour la version 3.3
Qwen3 Alibaba	8B · 14B · 32B	Les trois premières lignes
DeepSeek-R1 distills	7B – 70B	Un par ligne — choisissez le distillat que votre carte peut contenir
Mistral Small 3 Mistral AI	24B	Entre les lignes 2 et 3 ; dimensionnez-le à partir de l’arithmétique, pas de l’étiquette
Gemma 3 Google	12B · 27B	Ligne 2, et juste sous la ligne 3
Phi-4 Microsoft	14B	Ligne 2
gpt-oss OpenAI	20B · 120B	Publié nativement en 4 bits : une carte de 16 Go, et une carte de 80 Go

Notes d’installation

Le runtime est à vous. C’est tout l’intérêt du bare metal.

La machine arrive avec un système d’exploitation propre et un accès root. Pas de service d’inférence du fournisseur devant votre modèle, pas de runtime géré qui se met à jour tout seul la semaine avant une échéance. vLLM et Ollama répondent tous deux sur un endpoint compatible OpenAI — du code écrit contre un fournisseur d’API pointe vers votre propre machine en changeant une seule URL de base. Figez le pilote, la version CUDA ou ROCm et le framework sur les versions contre lesquelles votre code a été testé ; rien ne bouge sous vos pieds. Si vous préférez que le pilote soit installé avant la remise, dites-le sur la commande et indiquez la version.

vLLM — servir du vrai trafic. Le batching continu et l’attention paginée permettent à une carte de répondre à de nombreuses requêtes à la fois : la différence entre une démo et un service. Exige une carte raisonnablement moderne.
llama.cpp — mémoire juste, ou carte plus ancienne. Ses formats quantifiés sont la raison pour laquelle un grand modèle tient sur une petite carte ; il utilisera le processeur et la carte ensemble quand les poids ne tiennent pas tout à fait.
TGI · SGLang — des serveurs de production de la même famille, avec des atouts différents autour de la sortie structurée, de la réutilisation de préfixes et du service multi-modèles. Tournent ici sans modification.
Ollama — le chemin le plus court d’une machine vide à un modèle qui répond sur un port. Dix minutes vous disent si votre dimensionnement était le bon.

Conditions du site

Ce que votre propre machine fait qu’une API ne peut pas faire.

Les prompts ne quittent jamais le bâtiment

Les poids, les prompts, les documents récupérés et chaque jeton généré restent sur du matériel auquel vous seul pouvez vous connecter. Amsterdam ou Bucarest et les données restent dans l’UE ; New York, Miami ou San Francisco et elles restent aux États-Unis. Pour des charges de travail qui répondent à un responsable de la protection des données, cette phrase est tout l’argumentaire.

Le compteur ne tourne jamais

Une API au jeton facture chaque jeton, et un agent ou un pipeline par lots génère des jetons toute la journée. Une machine dédiée, c’est le même chiffre chaque mois à n’importe quel volume, avec de la bande passante non mesurée en dessous — les poids qui entrent et les jetons qui sortent ne coûtent rien au-delà du port. Quel est ce chiffre, c’est à /gpu de le remplir, pas à cette feuille.

Personne ne vous limite le débit, ne déprécie ni ne remplace le modèle sous vos pieds

Le modèle que vous figez répond sans changement dans six mois. Pas de plafond de requêtes par minute, pas de file d’attente à l’heure de pointe de quelqu’un d’autre, pas d’avis de fin de vie. L’échange est honnête : les mises à niveau sont les vôtres, selon votre calendrier.

Le travail à côté du modèle a un chez-soi

La récupération veut un modèle d’embedding, un magasin de vecteurs et du disque rapide ; les agents veulent de la place pour faire tourner des outils. Du NVMe pour le magasin, des cœurs de processeur pour le pipeline, la carte pour les jetons — une seule machine porte tout cela.

Note 2 · débits

Aucun chiffre de jetons par seconde n’apparaît sur cette feuille.

Délibérément. Chaque nombre de ce genre dépend du modèle, de la quantification, du runtime et de sa version, de la taille du lot, de la longueur du prompt, de la longueur de la réponse et de la concurrence — changez-en un seul et il bouge d’un multiple. Un chiffre vedette qui ne porte pas tout cela est un chiffre choisi pour faire bonne figure, et on nous le ressortirait. Ce qui le gouverne : lire le prompt est lié au calcul et se produit une fois par requête ; générer la réponse est lié à la bande passante mémoire, parce que chaque jeton exige de lire les poids ; le batching amortit cette lecture sur des requêtes concurrentes, jusqu’à ce que le cache clé-valeur n’ait plus de place. Encore la marge de sécurité.

Demandez plutôt une vraie réponse

Dites-nous le modèle, la quantification que vous comptez utiliser, la longueur de contexte et à peu près combien de requêtes simultanées. Si nous avons fait tourner quelque chose de comparable, nous vous dirons ce que nous avons vu et sur quoi. Si ce n’est pas le cas, nous vous le dirons aussi.

Toutes les heures de tous les jours — téléphone, chat et tickets. Support a les délais de réponse par écrit.

Note 3 · fine-tuning

L’entraînement demande considérablement plus de place que le service.

Le service a besoin des poids. L’entraînement a besoin des poids, des gradients et de l’état de l’optimiseur pour chaque paramètre qu’il met à jour, tous résidents en même temps, plus les activations conservées pour la passe arrière — un modèle qui se sert confortablement sur une carte peut être plusieurs fois trop grand pour y être entièrement fine-tuné. Les méthodes à efficacité de paramètres mettent à jour une petite fraction des paramètres et ont besoin d’une fraction correspondante de la mémoire supplémentaire, ce qui explique pourquoi la plupart des fine-tunings ici en utilisent une. La boucle d’entraînement fait aussi circuler des lots en continu sur la liaison processeur-carte, donc la génération PCIe de la machine en dessous est une vraie contrainte là, d’une façon qu’elle n’est pas pour le service — quelle plateforme donne quelle liaison à une carte se trouve sur GPU dedicated servers. Dites-nous le modèle, la méthode, la longueur de séquence et la taille du jeu de données et nous le dimensionnerons plutôt que de vous laisser le découvrir après la livraison ; plus d’une carte, c’est la feuille multi-GPU et multi-nœuds.

Feuilles adjacentes

Les pages de part et d’autre de celle-ci.

Cette feuille possède une seule question : ce qu’il faut pour faire tourner un modèle. Tout ce qui est adjacent a sa propre page, et voici toutes.

Questions soulevées

Posées lors des révisions précédentes de cette fiche.

Tirées de ce que les gens nous demandent réellement par chat et par ticket, à peu près dans l’ordre où ils le demandent. Les trois premières sont celles qui déterminent si un achat fonctionne.

De quelle quantité de mémoire GPU un grand modèle de langage a-t-il besoin ?: Les poids correspondent au nombre de paramètres multiplié par les octets par paramètre : deux octets chacun en 16 bits, un en 8 bits, la moitié en 4 bits. Un modèle de 7–8 milliards de paramètres représente 16 Go de poids en 16 bits, 8 Go en 8 bits et 5 Go en 4 bits ; un modèle de 70 milliards de paramètres représente 140 Go, 70 Go et 38 Go. Ces chiffres concernent uniquement les poids et constituent un plancher plutôt qu’une exigence — prévoyez un quart à la moitié en plus pour l’exécution, les activations et le cache clé-valeur.
De quoi ai-je besoin pour exécuter un modèle 70B comme Llama 3.3 ?: En 4 bits, les poids font environ 38 Go, donc avec la marge de service, la réponse est une carte de 64 Go ou plus — une carte, une machine. En 8 bits, les poids font 70 Go et une carte de 80 Go franchit la barre. En pleine précision 16 bits, aucune carte unique que nous installons ne peut le contenir, et cela devient une configuration multi-cartes que nous chiffrons. La Fig. 3 ci-dessus nomme les cartes exactes ; les prix sont sur Serveurs dédiés GPU.
Pourquoi mon modèle se charge mais ne parvient pas à servir ?: Parce que les poids ne sont pas la seule chose dans la mémoire de la carte. L’exécution et ses tampons sont résidents, et chaque jeton d’une conversation laisse une entrée dans le cache clé-valeur afin de ne pas avoir à être recalculé. Ce cache croît avec la longueur du contexte et encore avec chaque requête servie simultanément, donc un modèle dont les poids tiennent tout juste ne tiendra qu’environ une courte conversation. Dimensionnez la carte à une fois et quart à une fois et demie les poids.
Quel moteur d’inférence puis-je installer ?: N’importe lequel. La machine arrive avec un système d’exploitation propre et un accès root, et aucun service d’inférence de fournisseur ne se trouve devant elle. vLLM est la réponse habituelle pour servir un trafic réel car le traitement par lots continu permet à une carte de répondre à plusieurs requêtes à la fois. llama.cpp est la réponse habituelle lorsque la mémoire est limitée ou que la carte est plus ancienne. TGI et SGLang fonctionnent sans modification. Ollama est le chemin le plus court d’une machine vide à un modèle répondant sur un port — et vLLM comme Ollama répondent tous deux sur un point de terminaison compatible OpenAI, donc le code client existant pointe vers votre propre machine en changeant une seule URL de base. Vous figez le pilote, la version CUDA ou ROCm et le framework aux versions contre lesquelles votre code a été testé.
L’auto-hébergement d’un LLM est-il moins cher qu’une API par jeton ?: Cela dépend entièrement du volume, et le point de bascule est réel : une API facture par jeton et ne coûte rien au repos ; une machine dédiée est un montant mensuel fixe et ne coûte rien de plus lorsqu’elle est occupée. Un trafic régulier, des agents qui tournent toute la journée, des pipelines par lots et tout ce qui a une exigence de confidentialité ont tendance à être plus avantageux sur leur propre matériel ; une charge de travail qui se déclenche dix fois par jour ne l’est pas. Les chiffres mensuels pour faire ce calcul se trouvent sur Serveurs dédiés GPU — cette fiche ne fixe délibérément aucun prix.
Combien de jetons par seconde vais-je obtenir ?: Nous ne publions pas de chiffre de jetons par seconde, car chaque nombre de ce type dépend du modèle, de la quantification, du moteur d’exécution et de sa version, de la taille du lot, de la longueur de l’invite, de la longueur de la réponse et de la concurrence, et changer l’un d’eux le déplace d’un multiple. Ce qui le gouverne : la lecture de l’invite est limitée par le calcul et se produit une fois par requête ; la génération de la réponse est limitée par la bande passante mémoire car chaque jeton nécessite la lecture des poids ; et le traitement par lots amortit cette lecture sur les requêtes simultanées, ce qui rend le service économique jusqu’à ce que le cache clé-valeur soit plein. Demandez avec le modèle, la quantification et la concurrence attendue pour une réponse basée sur ce que nous avons réellement observé.
Le GPU est-il partagé avec quelqu’un d’autre ?: Non. Un locataire par machine physique, et la carte est transmise à votre propre système d’exploitation. Il n’y a ni hyperviseur, ni partition MIG, ni profil vGPU, ni ordonnanceur à découpage temporel, donc rien d’autre ne s’exécute sur la carte et la latence d’inférence ne bouge pas à cause du travail par lots de quelqu’un d’autre.
Que se passe-t-il si le modèle ne tient pas sur une seule carte ?: Il s’agit alors d’une configuration multi-cartes, qui est chiffrée plutôt que commandée depuis un panier : le nombre de cartes qui tiennent dépend de la largeur physique de la carte spécifique et du budget énergétique du châssis. Deux cartes ne donnent la somme de leur mémoire que si le moteur d’exécution peut répartir le modèle entre les deux, ce que tout moteur sérieux prend en charge avec un certain coût en débit. Plus d’une carte ou machine explique à quoi ressemble cette configuration.
Le réglage fin nécessite-t-il plus de mémoire que le service ?: Considérablement plus. Le service nécessite les poids ; l’entraînement nécessite les poids, les gradients et l’état de l’optimiseur pour chaque paramètre mis à jour, tous résidents en même temps, plus les activations conservées pour la passe arrière. Un modèle qui tient confortablement sur une carte peut être plusieurs fois trop grand pour y être entièrement affiné. Les méthodes à efficacité paramétrique mettent à jour une petite fraction des paramètres et nécessitent une fraction correspondante de la mémoire supplémentaire, c’est pourquoi la plupart des réglages fins ici en utilisent une.
Puis-je utiliser une carte AMD, et ROCm fonctionne-t-il ?: Oui. Les pièces AMD Instinct comptent parmi les cartes à plus grande mémoire que nous installons et offrent souvent le meilleur rapport qualité-prix par gigaoctet, mais votre pile doit prendre en charge ROCm plutôt que CUDA. La plupart des moteurs d’inférence actuels le font ; certains outils périphériques ne le font toujours pas. Demandez avant de commander et nous vérifierons par rapport à votre moteur d’exécution spécifique plutôt que de répondre en général.

For the record

Everything on this sheet, as figures.

Card memory is the manufacturers’ published figure; which cards exist is read from the order catalogue when this page was served. No monthly price appears here on purpose — GPU dedicated servers holds every one, against the exact machine it belongs to.

What decides whether a model runs: Card memory, and almost nothing else on the order form. The weights either fit or they do not — a card a couple of gigabytes short does not run slower, it fails to load. Clock speed and core count decide how fast it is once it fits.
How much memory a model needs: Parameters multiplied by bytes per parameter: two bytes each at 16-bit, one at 8-bit, half at 4-bit. That is the WEIGHTS. The runtime, the activations and the key-value cache for the conversation live in the same memory, so budget a quarter to a half again on top before choosing a card.
Largest model on a single card here: 70 billion parameters at 4-bit, with room left to serve. Past that the answer is more than one card in one machine, which is a build we quote rather than a checkout option — multi-GPU and multi-node is the page for it.
Biggest card we fit: RTX PRO 6000 Blackwell 96GB, 96 GB GDDR7 ECC. Card memory figures are the manufacturers' published ones; a card whose figure we could not source is left out of the comparison rather than guessed at.
Which runtime: Yours. The machine arrives with a clean operating system and root, and you install vLLM, llama.cpp, TGI, SGLang, Ollama or anything else, pinned to the version your code was tested against. Nothing upgrades underneath you, and there is no vendor runtime you have to go through.
Throughput: We publish no tokens-per-second figure, deliberately, because we have not measured one under conditions we would be willing to have quoted back at us. What governs it is the card's memory bandwidth while generating, its arithmetic while reading the prompt, and how many requests you batch. Ask with the model, the quantisation and the expected concurrency and we will say what we have actually seen.
Fine-tuning and training: Both are ordinary work here, and both need considerably more memory than serving the same model: gradients and optimiser state sit alongside the weights. A parameter-efficient method needs a fraction of what a full fine-tune does. Tell us the method and the model and we will size it rather than have you find out after delivery.
Tenancy: One tenant per physical machine and the card passed straight through to your operating system. No hypervisor, no MIG partition, no vGPU profile, no time-slicing scheduler, and nobody else's workload on the card. What you measure on the first afternoon is what you keep.
Bandwidth: Unmetered in both directions at every port speed, with no transfer allowance and no egress line on any invoice. Pulling weights down and serving tokens back out costs nothing beyond the port.
What this page does not price: Cards, or anything else. Every card we fit, what each adds per month and what the machine under it costs are on GPU dedicated servers, each figure against the exact machine it belongs to.