Comment auto-héberger un LLM sur un serveur GPU privé

Faire tourner un modèle de langage sur du matériel que vous louez est la seule façon d'être certain que vos prompts ne sont ni journalisés, ni conservés, ni lus par quiconque d'autre que vous. Chaque API hébergée — aussi bonne soit sa politique de confidentialité — reçoit chaque token que vous lui envoyez, et cette politique peut changer sans que vous en soyez informé. L'auto-hébergement déplace la frontière : les poids résident sur un disque que vous contrôlez, l'inférence tourne dans une VRAM que vous louez à l'heure, et rien ne quitte la machine à moins que vous ne l'envoyiez quelque part. Côté logiciel, c'est devenu réellement simple. Ce qui continue de piéger les gens, c'est le dimensionnement de la carte avant de la commander, et le fait de se rappeler qu'un port d'inférence ouvert reste un port d'inférence ouvert.

Ce que l'auto-hébergement vous apporte réellement — et ce qu'il n'apporte pas

Soyons précis sur le bénéfice réel, car « l'IA privée » se vend de façon assez vague. Un modèle sur votre propre GPU change certaines choses du tout au tout, et n'en change d'autres absolument pas.

• Vos prompts et leurs réponses restent sur la machine — aucune journalisation côté fournisseur, aucune fenêtre de rétention, aucun jeu de données construit à partir de ce que vous avez demandé.
• Aucun compte, aucune limite de débit par clé, et aucune couche de politique entre vous et les poids. Le modèle que vous avez déployé est le modèle que vous obtenez.
• Un coût prévisible à volume élevé. Au-delà de quelques millions de tokens par jour, une carte louée revient moins cher qu'une tarification au token, et le prix ne bouge pas quand un fournisseur révise ses tarifs.
• Cela ne rend pas un modèle faible plus fort. Un modèle à poids ouverts sur votre propre matériel reste ce même modèle — l'auto-hébergement achète du contrôle, pas des capacités de pointe.
• Cela ne cache rien à l'hébergeur. Quiconque a un accès physique à une machine en fonctionnement peut en principe lire sa mémoire — une question qui concerne l'hébergeur, pas le modèle.

La VRAM est tout l'enjeu : dimensionner un modèle pour une carte

Presque tous les échecs au premier essai viennent d'une erreur de calcul de VRAM. Les poids, le cache KV et la marge de travail doivent tous tenir dans la carte en même temps, et il n'y a pas de dégradation progressive — vous obtenez une erreur de mémoire insuffisante quelques secondes après le début du chargement. La règle empirique reste utilisable : un modèle a besoin d'environ 2 GB de VRAM par milliard de paramètres en précision 16 bits, d'environ 1 GB en 8-bit, et d'environ 0.6 GB en 4-bit. Ajoutez ensuite le cache KV, qui croît avec la longueur de contexte et le nombre de requêtes concurrentes, et qui est ce qui vous mord réellement en production plutôt qu'en test.

• Un modèle 7B à 8B : environ 16 GB en FP16, ou confortablement sous les 8 GB en 4-bit. C'est la classe qui tient sur une RTX A4000 16 GB avec de la marge.
• Un modèle 13B à 14B : environ 28 GB en FP16, environ 9 GB en 4-bit. Une RTX 4090 24 GB le fait tourner quantifié avec largement assez de contexte disponible.
• Un modèle 30B à 34B : environ 68 GB en FP16, près de 20 GB en 4-bit — le terrain naturel d'une RTX 5090 32 GB.
• Un modèle 70B : environ 140 GB en FP16, environ 40 GB en 4-bit. Cela impose un A100 ou un H100 80 GB, et en pleine précision, cela impose plus d'une carte.
• Un contexte long multiplie le cache KV, pas les poids. Une fenêtre de 128k tokens sur un grand modèle peut à elle seule réclamer des dizaines de gigaoctets — budgétez-le avant de commander, pas après.

Choisir le GPU : de l'A4000 au H100, et quand l'horaire l'emporte sur le mensuel

Chaque offre de la gamme de serveurs GPU vous donne une carte physique entière avec toute sa VRAM — aucun partitionnement MIG, aucun partage de temps — si bien que le chiffre indiqué sur la fiche technique est bien celui que vous pouvez réellement remplir. Adaptez la carte au modèle que vous comptez servir, pas à celui que vous essaierez peut-être un jour.

• RTX A4000 16 GB à $89/mo — 8 vCPU et 64 GB RAM. Suffisant pour un assistant 7B à 13B quantifié, un service d'embeddings, ou un pipeline de classification qui tourne toute la journée.
• RTX 4090 24 GB à $189/mo — 16 vCPU, 128 GB et 2 TB NVMe. Le meilleur rapport qualité-prix par token pour des modèles 13B à 34B en 4-bit, et le choix habituel pour un petit endpoint de production.
• RTX 5090 32 GB à $279/mo — 24 vCPU et 192 GB. Ces 8 GB supplémentaires font souvent la différence entre un modèle 34B qui tient avec un vrai contexte et un autre qui n'y arrive pas.
• A100 80 GB à $690/mo — 32 vCPU, 256 GB et 4 TB NVMe. Une bande passante HBM2e et assez de mémoire pour un 70B en 4-bit avec une longue fenêtre de contexte, ou pour du service fortement batché.
• H100 80 GB à $1190/mo — 48 vCPU, 384 GB, 8 TB NVMe et un port 10 Gbps. Le support FP8 et la bande passante HBM3 en font le seul choix raisonnable pour un débit sérieux ou pour l'entraînement.

La facturation est horaire ou mensuelle à partir du même solde prépayé, et cela change le calcul plus qu'on ne le pense. Une évaluation qui prend deux après-midi sur un H100 coûte les heures d'utilisation, pas un mois. Un endpoint de chat qui doit répondre à trois heures du matin veut une machine mensuelle. Si vous avez besoin de plusieurs cartes dans une même machine, ou d'un GPU installé à côté de beaucoup de stockage local, un serveur dédié est la forme la plus adaptée — et le cas général du paiement en cryptomonnaie est couvert par notre guide sur louer un serveur GPU avec des cryptomonnaies.

Étape par étape : d'un rechargement en crypto à un endpoint opérationnel

1. 01Créez un compte avec un email jetableUn email et un mot de passe. Aucun nom, téléphone ou pièce d'identité, si bien que rien de notre côté ne relie le modèle que vous faites tourner à vous.
2. 02Rechargez votre solde en cryptoAlimentez un solde prépayé en Bitcoin, Monero ou l'une des 8 cryptomonnaies proposées. Il n'expire jamais et n'est jamais gelé.
3. 03Déployez une instance GPU sur une image CUDAChoisissez la carte, une région et une image prête pour CUDA avec des pilotes récents et PyTorch. La machine est prête en quelques minutes.
4. 04Vérifiez que la carte est bien visible avant de récupérer quoi que ce soitUn simple appel à nvidia-smi indique le GPU, la version du pilote et la VRAM libre. C'est une vérification de dix secondes qui évite une heure de confusion.
5. 05Récupérez les poids sur le NVMe localTéléchargez le modèle sur le disque propre de l'instance plutôt que sur un montage réseau. Les poids représentent des dizaines de gigaoctets et vous les chargerez plus d'une fois.
6. 06Démarrez le serveur lié à localhostLancez vLLM ou Ollama sur 127.0.0.1, vérifiez une complétion en local, et ce n'est qu'ensuite que vous déciderez comment y accéder depuis l'extérieur.

vLLM, Ollama ou llama.cpp : choisir sa stack de service

Trois stacks couvrent presque tous les cas, et la bonne dépend du nombre de requêtes que verra l'endpoint plutôt que de laquelle est techniquement la plus impressionnante.

• Ollama — le chemin le plus court entre rien du tout et un endpoint fonctionnel. Une seule commande récupère un modèle quantifié et le sert derrière une API compatible OpenAI. Idéal pour un seul utilisateur, un prototype, ou un assistant privé.
• vLLM — la réponse pour la production. Le batching continu et la paged attention permettent à une seule carte de servir de nombreuses requêtes concurrentes avec un débit plusieurs fois supérieur à celui d'une boucle naïve. C'est la différence entre un endpoint pour vous et un endpoint pour une application.
• llama.cpp — le pragmatique. Des quantifications GGUF jusqu'en 4-bit et en dessous, un déchargement CPU pour les couches qui ne tiennent pas, et le plancher mémoire le plus bas des trois. C'est ce qui permet à un modèle surdimensionné de tourner malgré tout sur une carte sous-dimensionnée.
• TGI, SGLang et TensorRT-LLM sont encore plus rapides dans des configurations spécifiques. Tournez-vous vers eux une fois que vous avez mesuré un goulot d'étranglement, pas avant.

Les trois exposent une route chat-completions compatible OpenAI, si bien qu'un code applicatif écrit pour une API commerciale n'a généralement besoin que d'un changement d'URL de base, rien de plus. Cette compatibilité est la raison concrète pour laquelle l'auto-hébergement a cessé d'être un projet pour devenir un simple choix de configuration.

Garder l'endpoint privé : n'exposez jamais le port d'inférence

Un serveur d'inférence sans authentification est l'équivalent moderne d'une base de données ouverte. Les scanners trouvent les nouvelles IP en quelques heures à peine, et un endpoint exposé signifie que quelqu'un d'autre dépense vos heures de GPU — ou lit tout ce que votre application y fait transiter.

Si l'endpoint doit réellement être public — un produit plutôt qu'un assistant privé — terminez le TLS au niveau d'un reverse proxy, exigez un bearer token que vous renouvelez régulièrement, et limitez le débit par clé. Placer ce proxy sur un petit VPS séparé et ne laisser la machine GPU joignable que via le tunnel est l'arrangement le plus propre. C'est le même raisonnement que pour héberger un site web sans KYC : la machine exposée à internet doit contenir le moins de choses possible.

Fine-tuning : quand un après-midi sur une carte louée vaut mieux qu'une facture mensuelle

Le fine-tuning est l'argument le plus solide en faveur de la location plutôt que de l'abonnement. Un entraînement LoRA ou QLoRA sur un modèle 7B à 13B — quelques milliers d'exemples, une poignée d'epochs — se termine en quelques heures sur une 4090 et coûte exactement les heures d'utilisation. L'adaptateur obtenu ne pèse que quelques centaines de mégaoctets, si bien que vous pouvez conserver le checkpoint, détruire l'instance, et charger plus tard cet adaptateur sur une carte plus petite pour le service. Un fine-tuning complet d'un modèle 70B, c'est un tout autre budget, qui demande un A100 ou un H100 avec de la marge pour l'état de l'optimiseur, mais cela se compte encore en jours plutôt qu'en contrat.

Le workflow que rend possible la facturation horaire est simple : déployer, entraîner, copier l'adaptateur hors de la machine, la détruire. Vous payez le calcul que vous avez utilisé, et il n'y a aucune carte qui reste inactive entre deux. Gardez le dataset sur le NVMe de l'instance pendant que vous travaillez, et récupérez-le une fois terminé — rien de ce que vous laissez sur une machine louée ne devrait jamais être l'unique copie.

Le compromis honnête sur la confidentialité d'un GPU que vous ne possédez pas

L'auto-hébergement supprime la fuite la plus importante et la plus concrète : un tiers qui reçoit chaque prompt, le conserve pendant une certaine fenêtre de rétention, et décide seul de ce qu'il en fait. Sur une carte louée, le modèle et vos données vivent dans une machine qui ne répond qu'à votre clé. Ce que la location ne peut pas supprimer, c'est l'hébergeur lui-même. Quiconque a un accès physique à un serveur en fonctionnement peut en principe lire sa mémoire, et le chiffrement intégral du disque sur une machine distante vous protège contre un disque volé, pas contre un disque en cours de fonctionnement.

La question utile n'est donc pas « l'hébergeur peut-il le voir » mais « l'hébergeur sait-il qui je suis ». L'hébergement sans KYC répond précisément à cela : un email et un mot de passe, aucune vérification, rien à faire fuiter ou à transmettre sur assignation. Payer depuis un solde en crypto élimine la banque. Jusqu'où pousser le volet paiement est une question de modèle de menace — Bitcoin est pseudonyme, pas anonyme, si bien que des pièces retracées jusqu'à un exchange vérifié mènent quand même quelque part, tandis que se recharger en Monero comble cet écart au niveau du protocole.

Les erreurs qui gaspillent silencieusement des heures de GPU

• Dimensionner en se basant uniquement sur les poids et oublier le cache KV, si bien que le modèle charge sans problème puis meurt à la première requête longue.
• Servir en FP16 sur une carte qui ferait tourner le même modèle en 4-bit avec trois fois plus de contexte, par crainte d'une perte de qualité que personne n'a jamais réellement mesurée.
• Télécharger quarante gigaoctets de poids sur un montage réseau, puis se demander pourquoi chaque redémarrage prend vingt minutes.
• Laisser le serveur lié à 0.0.0.0 « juste pour tester depuis mon laptop », ce qui, sur une IP publique, est découvert le jour même.
• Payer au mois pour une carte qui reste inactive vingt heures par jour, alors que la charge de travail a toujours été un traitement par lots.
• Faire des benchmarks une requête à la fois, en conclure que vLLM n'en vaut pas la peine, et passer à côté du fait que tout son avantage apparaît sous concurrence.

Aucune de ces défaillances n'est exotique. Ce sont celles qui surviennent quand la carte est choisie avant le modèle. Décidez d'abord du modèle et de la quantification, faites le calcul de VRAM honnêtement, gardez le port fermé, et un LLM auto-hébergé devient l'une des choses les moins exigeantes que vous puissiez laisser tourner.