Servir son propre LLM sur un GPU loué : vLLM, Ollama et la facture
Ou : pourquoi un H100 loué ne coûte presque rien au million de tokens, à condition de ne jamais le laisser se reposer.
La réponse courte : servir un LLM sur un GPU loué se fait en une commande, vllm serve ou ollama run, et coûte le prix de l’heure de la carte, quelle que soit la quantité de texte produite. À pleine charge, c’est très bon marché : gpt-oss-120b sur une H100 produit près de 2 900 tokens par seconde avec vLLM, soit environ 0,26 $ le million de tokens de sortie au tarif Community Cloud de Runpod. À faible charge, c’est ruineux : un modèle de 70 milliards servi à un seul utilisateur revient à plus de dix dollars le million. L’auto-hébergement ne bat une API qu’avec une carte occupée presque en permanence. C’est l’option la plus souveraine pour un modèle ouvert servi en Europe, et la plus exigeante en volume.
Les deux logiciels ne visent pas le même usage. vLLM, né à Berkeley et publié sous licence Apache 2.0, est un serveur d’inférence de production : sa gestion de la mémoire, PagedAttention, et son regroupement continu des requêtes lui permettent de servir des dizaines d’utilisateurs en parallèle sur une seule carte. Ollama, sous licence MIT et bâti sur llama.cpp, est pensé pour la simplicité : il télécharge un modèle quantifié et le sert en une ligne, mais traite une requête à la fois par défaut, avec une file de 512 requêtes au-delà de laquelle il répond par une erreur.
Les deux exposent une API compatible OpenAI, ce qui permet de basculer une application d’une API commerciale vers votre propre serveur sans réécrire le code. Chez Runpod, vLLM existe en worker serverless officiel, configuré par variables d’environnement comme MODEL_NAME ou MAX_MODEL_LEN, et Ollama se lance sur un pod PyTorch en exposant le port 11434.
Pour qui : une équipe qui a un volume de requêtes régulier et élevé, ou un modèle qu’aucune API ne propose, et veut le servir elle-même sur un GPU loué.
À partir de : 0,34 $ de l’heure pour une RTX 4090 en Community Cloud, 1,19 $ pour une A100 de 80 Go, 2,69 $ pour une H100 SXM, facturés à la seconde.
Pour démarrer : ouvrir un compte Runpod, déployer le worker vLLM depuis le Hub pour un usage irrégulier, ou lancer un pod pour une charge continue.
Héberger un LLM avec vLLM ou Ollama : le coût réel selon la charge
La commande de base, pour vLLM comme pour Ollama :
| |
Le coût, lui, dépend entièrement du débit obtenu. Les mesures publiques donnent des ordres de grandeur très différents selon le moteur et la charge, et le calcul se fait en divisant le prix de l’heure par le nombre de millions de tokens produits en une heure.
| Configuration mesurée | Débit de sortie | Carte chez Runpod | Coût par million de tokens produits |
|---|---|---|---|
| gpt-oss-120b, vLLM, 1 000 requêtes en parallèle, H100 SXM | 2 901 tokens/s | 2,69 $/h en Community | environ 0,26 $ |
| Qwen3 8B, vLLM, 4 requêtes en parallèle, H100 SXM | 497 tokens/s | 2,69 $/h en Community | environ 1,50 $ |
| Llama 3 8B en 4 bits, llama.cpp, un seul utilisateur, RTX 4090 | 128 tokens/s | 0,34 $/h en Community | environ 0,74 $ |
| Llama 3 70B en 4 bits, llama.cpp, un seul utilisateur, A100 | 22 tokens/s | 1,19 $/h en Community | environ 15 $ |
Sources des débits : mesures du GPUStack Performance Lab pour vLLM, dépôt de benchmarks de XiongjieDai pour llama.cpp. Le tableau montre l’essentiel : sur la même H100, gpt-oss-120b servi à mille requêtes en parallèle revient près de six fois moins cher par token que Qwen3 8B servi à quatre. C’est la charge, bien plus que la taille du modèle, qui fait le prix, et un grand modèle servi à un seul utilisateur est un luxe.
Comparons maintenant avec une API. OVHcloud vend gpt-oss-120b 0,08 € en entrée et 0,40 € en sortie, soit environ 0,14 € par million de tokens pour un usage qui envoie quatre fois plus qu’il ne reçoit. Une H100 louée en continu coûte environ 1 940 $ par mois en Community Cloud. Pour qu’elle revienne moins cher que l’API, il faudrait lui faire traiter plus de dix milliards de tokens par mois, soit 4 000 à 5 000 tokens par seconde selon le cours du dollar, jour et nuit : à peu près sa capacité totale mesurée. Autrement dit, l’auto-hébergement d’un modèle servi par les API européennes ne devient rentable qu’à pleine charge permanente.
Il existe pourtant de bonnes raisons de le faire. Un modèle affiné sur vos propres données, qu’aucune API ne propose. Un modèle que les API européennes ne servent pas. Des données qui ne doivent passer par aucune API tierce. Ou une charge qui dépasse les limites de débit des fournisseurs. Pour ces cas, la règle est simple : vLLM en production, sur un pod si la charge est continue, en worker serverless si elle est irrégulière, et Ollama pour le développement ou un usage personnel.
Si le modèle ne tient pas sur la carte
Un modèle de 70 milliards en 16 bits demande 140 Go de mémoire. La quantisation le fait tenir sur une seule carte de 48 ou 80 Go, avec une perte mesurée, détaillée dans quantifier un modèle pour réduire la VRAM.
Si vous hésitez sur le modèle à servir
gpt-oss, Qwen, Gemma, Mistral ou Llama : licence, qualité en français et taille décident du modèle avant la carte. Le choix est détaillé dans le modèle ouvert selon l’usage.
Si votre volume reste modeste
À moins d’occuper la carte en permanence, une API coûte moins cher. Les prix au million de tokens de six fournisseurs sont dans le coût des API LLM comparé.