Quels modèles d’IA pouvez-vous auto-héberger ?

Ce qui détermine les modèles d’IA que vous pouvez auto-héberger

Les modèles d’IA que vous pouvez auto-héberger dépendent d’un seul chiffre : la RAM de la machine. La famille du modèle et le framework comptent beaucoup moins que le fait de savoir si les poids tiennent en mémoire avec une marge suffisante. Cet article présente les calculs nécessaires pour le déterminer. L’installation d’un runtime est une tâche distincte, décrite dans le guide pour exécuter Ollama sur un VPS.

Deux coûts déterminent la réponse. Les poids constituent le coût fixe, défini par le nombre de paramètres et la quantification. La fenêtre de contexte constitue le coût variable. C’est elle que l’on oublie jusqu’au jour où un modèle qui se chargeait hier refuse de se charger aujourd’hui.

Le calcul du dimensionnement : bits par paramètre

Un fichier de modèle contient presque uniquement des poids. Chaque poids est stocké avec un certain nombre de bits. La quantification consiste à les stocker avec moins de bits que la précision utilisée pendant l’entraînement. Cela entraîne une légère perte de précision, mais réduit fortement la mémoire nécessaire. La taille se déduit directement de cette règle :

weights in GB = (parameters in billions x bits per weight) / 8

Les modèles sont publiés en 16 bits, soit 2 GB par milliard de paramètres. C’est pourquoi presque personne n’exécute la précision d’origine sur un VPS. Voici les quantifications que vous rencontrerez réellement, avec leur nombre moyen réel de bits par poids :

• Q8_0 stocke environ 8.5 bits par poids, soit environ 1.1 GB par milliard de paramètres.
• Q6_K stocke environ 6.6 bits, soit environ 0.83 GB par milliard.
• Q5_K_M stocke environ 5.7 bits, soit environ 0.71 GB par milliard.
• Q4_K_M stocke environ 4.8 bits, soit environ 0.6 GB par milliard.

Utilisez 0.6 GB par milliard de paramètres comme valeur de référence. Q4_K_M est le choix par défaut raisonnable sur une machine limitée par la mémoire : la perte de qualité par rapport à 8 bits est faible pour la plupart des tâches, et le fichier fait presque la moitié de la taille. En dessous de 4 bits, la perte augmente rapidement. Un modèle 70B réduit à 2 bits répond donc généralement moins bien qu’un modèle 32B en 4 bits de la même génération. Lorsque la mémoire est limitée, choisissez une classe de taille inférieure avant de descendre sous 4 bits.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

La colonne des poids ci-dessus applique la règle de 0.6 GB par milliard de paramètres. Les fichiers GGUF réels restent à quelques pour cent près de cette valeur, car les couches d’embedding et de sortie sont conservées avec une précision supérieure à celle du reste du modèle. Un modèle 3B en 4 bits fait environ 1.8 GB. Un modèle 8B fait 4.8 GB. Un modèle 32B fait 19.2 GB, et un modèle 70B fait 42 GB.

Pourquoi la longueur du contexte consomme plus de RAM que les poids

Le cache KV (cache key-value, c’est-à-dire l’état d’attention que le modèle conserve pour chaque token actuellement présent dans la conversation) constitue le deuxième coût. Il est alloué au chargement du modèle, dimensionné selon la longueur de contexte demandée, puis augmente linéairement avec cette longueur.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Avec le contexte par défaut d’Ollama, ce modèle 8B consomme un demi-gigaoctet pour le cache. Avec 8192 tokens, il consomme 1 GB. Avec le contexte de 128k annoncé sur sa fiche, il consomme 16 GB, soit plus de trois fois la taille des poids. Le 70B présente le cas inverse : son cache à 128k fait 40 GB, soit moins que ses propres poids, car l’attention à requêtes groupées limite fortement l’augmentation du coût par token par rapport au nombre de paramètres.

La longueur de contexte par défaut d’Ollama est de 4096 tokens sur un serveur utilisant uniquement le CPU. Lorsqu’un GPU est présent, Ollama choisit la valeur par défaut selon la VRAM : 32k entre 24 et 48 GiB, et 256k à partir de 48 GiB. Augmentez cette valeur avec la variable OLLAMA_CONTEXT_LENGTH sur le serveur, puis vérifiez la valeur réellement attribuée à un modèle en cours d’exécution dans la colonne CONTEXT de ollama ps. Le calcul de mémoire associé à ce paramètre est détaillé dans l’article sur num_ctx et la longueur du contexte.

Deux méthodes permettent de réduire le cache. Demandez la longueur de contexte dont vous avez besoin plutôt que celle annoncée sur la fiche du modèle, car la plupart des usages de chat et de programmation tiennent entre 8k et 32k. Vous pouvez aussi quantifier le cache lui-même sur 8 bits, ce qui le réduit de moitié, au prix d’une perte de rappel sur les contextes longs.

Un modèle résident reste en RAM jusqu’à son déchargement

Ollama conserve un modèle en mémoire pendant 5 minutes après la dernière requête, puis le décharge. Cette valeur par défaut convient à un ordinateur portable, mais pas à un serveur : la première requête après chaque période d’inactivité doit de nouveau attendre le chargement du modèle.

ollama ps
ollama stop qwen3:4b

ollama ps affiche les modèles résidents. La colonne SIZE indique la quantité de mémoire utilisée, et la colonne UNTIL indique quand le modèle expire. Pour conserver un modèle en permanence, définissez OLLAMA_KEEP_ALIVE=-1 sur le service. La valeur 0 le décharge dès que chaque réponse est terminée.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Envoyez un prompt, puis exécutez de nouveau ollama ps dix minutes plus tard. Le modèle est toujours listé, ce qui est précisément le but : il occupe cette RAM, que quelqu’un l’utilise ou non. Un modèle conservé en mémoire ne constitue pas une capacité disponible. Sur un VPS de 16 GB, un modèle 8B avec un contexte de 8k utilise environ 6 GB aussi longtemps que le service fonctionne. Dimensionnez donc le serveur en fonction du modèle et de votre application, et non du modèle seul. Conserver un modèle en mémoire présente le compromis avec la latence de démarrage à froid.

Ce qui fonctionne sur un VPS de 4 GB

Réservez environ 1 GB pour le système d’exploitation et le model server. Il reste donc environ 3 GB. Cela permet d’utiliser un modèle de 1B à 4B en 4 bits, avec le contexte par défaut de 4096 tokens. En août 2026, cette catégorie comprend Llama 3.2 en 3B, Qwen 3 en 1.7B et 4B, ainsi que les petites versions de Gemma et Phi. Considérez ces modèles comme des exemples de taille, pas comme des recommandations. Les noms changent tous les quelques mois, mais le calcul reste le même.

Comptez environ 6 à 14 tokens par seconde. Ces petits modèles sont efficaces pour des tâches ciblées : classification, extraction de tags, résumés courts et réécriture d’un paragraphe selon une charte éditoriale. Ils sont peu performants pour le raisonnement en plusieurs étapes et pour le code réparti sur plusieurs fichiers. Aucun prompt ne corrige ces limites.

Le principal problème à ce niveau est le swap. Si le modèle ne tient pas en mémoire, Linux refuse rarement de le charger. Il déplace plutôt des pages mémoire vers le disque. Comme la génération de chaque token lit tous les poids une fois, elle ralentit alors jusqu’à plusieurs secondes par token. Surveillez free -h ainsi que les colonnes si et so de vmstat 1 pendant que le modèle répond. Des valeurs non nulles pour les entrées et sorties du swap pendant la génération indiquent que le modèle est trop volumineux pour ce plan.

Ce qui fonctionne sur un VPS de 8 à 16 Go

C’est à partir de cette capacité qu’un modèle auto-hébergé devient généralement utile. Avec 8 Go, vous pouvez exécuter un modèle 7B ou 8B en 4 bits, avec environ 4.8 Go de poids et un contexte de 8k. Avec 16 Go, vous pouvez exécuter un modèle 13B ou 14B en 4 bits, avec environ 8.4 Go, ou conserver un modèle 8B en 8 bits si vous préférez consacrer la mémoire à la précision plutôt qu’au nombre de paramètres.

La vitesse constitue le principal compromis. Un modèle 8B sur CPU génère environ 3 à 7 tokens par seconde, et un modèle 14B environ 1.5 à 3.5. Une personne lit environ 5 à 10 tokens par seconde. Un modèle 8B sur un VPS avec CPU donne donc l’impression d’observer un dactylographe lent. C’est acceptable pour une tâche en arrière-plan, mais fatigant pour une conversation interactive. Des tests mesurés de Qwen 3 en 8B et avec des modèles plus grands sur un VPS montrent le résultat en pratique.

Ce qui fonctionne sur un VPS de 32 à 64 GB

Un modèle 32B en 4 bits occupe environ 19.2 GB. Il tient donc sur une offre de 32 GB avec un contexte court et fonctionne confortablement sur 48 GB ou 64 GB. Un modèle 70B en 4 bits occupe environ 42 GB. Il lui faut donc 64 GB avant même d’ajouter le moindre cache.

Examinez ensuite honnêtement la vitesse. Un modèle 32B exécuté sur CPU produit environ 0.6 à 1.5 tokens par seconde. Un modèle 70B produit 0.2 à 0.5 tokens par seconde. Une réponse de 500 tokens générée par ce modèle 70B prend environ vingt minutes. Ces outils sont adaptés au traitement par lots. Alimentez-les pendant la nuit avec une file de documents : la vitesse importe peu. Placez-les derrière une interface de chat : elle devient alors déterminante.

Le routage par mixture of experts modifie ces calculs. C’est le seul détail d’architecture qu’il est vraiment utile de connaître. Un modèle MoE ne fait passer chaque token que par une petite partie de ses poids. Un modèle qui possède 30B paramètres au total et 3B paramètres actifs par token nécessite la mémoire d’un modèle 30B et produit des tokens à une vitesse proche de celle d’un modèle dense 3B, car chaque token ne consulte que les experts actifs. Sur une machine de 32 GB, un modèle MoE de cette configuration est beaucoup plus exploitable qu’un modèle dense 30B. La règle à retenir est simple : le nombre total de paramètres détermine la mémoire, et le nombre de paramètres actifs détermine la vitesse.

À quelle vitesse fonctionne l’inférence CPU, réellement ?

Générer un token nécessite de lire une fois en mémoire tous les poids actifs. Rien ne permet d’éviter cette lecture. La vitesse de génération sur un CPU dépend donc de la bande passante mémoire, et non du nombre de cœurs. Le plafond se calcule ainsi : bande passante mémoire utilisable divisée par la taille des poids en octets. Un petit VPS mutualisé fournit généralement entre 10 et 25 GB par seconde sur l’ensemble de ses vCPU. Un modèle de 4.8 GB atteint donc au maximum environ 2 à 5 tokens par seconde.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Ces valeurs correspondent aux fourchettes couramment observées sur du matériel VPS ordinaire, et non à un benchmark réalisé sur une machine précise. Votre résultat dépend de la génération de la mémoire, du nombre de canaux disponibles sur l’hôte et du nombre de voisins qui se la partagent. Mesurez votre propre résultat avec n’importe quel tag de modèle que vous avez déjà :

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

Le récapitulatif affiché après la réponse se termine par une ligne contenant eval rate: ... tokens/s. Il s’agit de votre vitesse de génération. Ignorez le premier lancement d’une session, car load duration dans le même récapitulatif inclut la lecture des poids depuis le disque. Mesurer correctement les tokens par seconde explique comment obtenir une valeur réellement comparable.

Deux résultats surprennent souvent. Ajouter des vCPU cesse rapidement d’être utile, car au-delà d’environ 8 cœurs, les cœurs supplémentaires attendent la mémoire au lieu d’effectuer des calculs. Avec une offre mutualisée, la même commande peut aussi renvoyer des valeurs différentes d’une heure à l’autre. Il s’agit alors du temps de vol CPU causé par un voisin bruyant, et non d’un problème dans votre configuration.

La lecture de votre prompt est une tâche différente de la génération de la réponse. Le traitement du prompt dépend des capacités de calcul. Il évolue donc avec le nombre de cœurs, et c’est à ce stade qu’un GPU prend le plus nettement l’avantage. Un document long demande plusieurs minutes de lecture à un CPU, contre quelques secondes à un GPU. C’est le premier goulet d’étranglement rencontré lorsque vous dirigez un agent de programmation vers un modèle que vous hébergez, car chaque tour renvoie le contexte du fichier et les définitions des outils avant même que le premier token de la réponse ne soit généré.

Ce qui change avec l’ajout d’un GPU

Les calculs ne changent pas. Seule la capacité à laquelle ils s’appliquent change. La VRAM est une limite stricte. Déterminez donc ce qui tient dans la mémoire avant de louer la machine :

• 8 GB de VRAM permettent d’exécuter un modèle 7B ou 8B en 4 bits avec un contexte court.
• 16 GB permettent d’exécuter un modèle 14B en 4 bits avec un contexte réel, ou un modèle 8B en 8 bits.
• 24 GB permettent d’exécuter un modèle 32B en 4 bits avec un contexte court.
• 48 GB et plus permettent d’exécuter un modèle 70B en 4 bits, avec de la marge pour le cache et la concurrence.

Lorsqu’un modèle ne tient pas dans la VRAM, Ollama le répartit : certaines couches sont placées sur le GPU et les autres sur le CPU. ollama ps indique cette répartition dans sa colonne PROCESSOR, sous une forme telle que 78%/22% CPU/GPU. Considérez cela comme un avertissement, pas comme une fonctionnalité. La partie exécutée sur le CPU impose le rythme, car chaque token doit toujours attendre ces couches. Un modèle dont un quart des couches s’exécute sur le CPU fonctionne donc beaucoup plus près de la vitesse du CPU que de celle du GPU. Si vous voyez une répartition que vous n’aviez pas prévue, réduisez d’abord la longueur du contexte. C’est généralement le cache qui a fait dépasser la limite.

La concurrence est l’autre raison de choisir une capacité supérieure. Les poids sont partagés entre les requêtes simultanées, mais chaque requête active nécessite son propre KV cache. Dix utilisateurs simultanés d’un modèle 8B avec un contexte de 8k nécessitent donc dix fois 1 GB de cache, en plus des poids. Servir plusieurs utilisateurs simultanés depuis un même modèle auto-hébergé explique où se situe cette limite.

La question de savoir si la location d’un GPU est rentable est également une question de calcul. Elle dépend du nombre réel de tokens que vous générez chaque mois. Le seuil de rentabilité entre un GPU VPS et les tokens d’une API présente ces chiffres.

Ce que vous ne pouvez pas auto-héberger

Il existe ici deux limites différentes. Il est utile de savoir laquelle vous rencontrez.

La première concerne les poids fermés. Les modèles commerciaux de pointe ne sont pas distribués. Il n’existe donc aucun fichier à télécharger, et aucune quantité de RAM ne peut changer cela. Vous pouvez auto-héberger tout ce qui les entoure : l’interface, la couche de retrieval, la boucle d’agent et les logs. Le modèle lui-même reste accessible via une API distante. La possibilité d’auto-héberger Claude examine ce point en détail.

La seconde concerne les poids ouverts qui sont simplement trop volumineux. Les plus gros modèles open disponibles sont des architectures mixture of experts comptant des centaines de milliards de paramètres au total. La même règle s’applique : un modèle de 400B paramètres au total, avec une quantification sur 4 bits, nécessite environ 240 GB uniquement pour les poids, avant même de compter le cache. Il faut alors du matériel spécialisé, dont la location mensuelle coûte bien plus cher que ce que la plupart des utilisateurs dépensent en tokens d’API sur une année. Ce qu’il faut pour auto-héberger un modèle de la classe Kimi présente les besoins réels.

La distinction honnête entre les deux est la suivante : auto-hébergez lorsque la charge est stable et que les données ne doivent pas quitter votre serveur. Achetez des tokens lorsque la charge est variable, ou lorsque vous avez réellement besoin de la qualité de réponse d’un modèle de pointe.

Vérifiez ce dont vous disposez avant de choisir

free -h
nproc
lscpu | grep 'Model name'

Basez votre choix sur la colonne available de free -h, et non sur la colonne total, car total inclut la mémoire déjà utilisée par le système. Soustrayez environ 1 GB pour le système d’exploitation et le serveur de modèles. Divisez le résultat par 0.6 pour obtenir le plus grand nombre de paramètres, en milliards, que vous pouvez charger en 4 bits. Soustrayez ensuite la KV cache correspondant au contexte réellement souhaité. Le résultat vous donne la réponse. Contrairement à une liste de noms de modèles, il ne devient pas obsolète.

FAQ

De quelle quantité de RAM ai-je besoin pour exécuter un modèle 8B ?

Comptez environ 4.8 Go pour les poids avec une quantification sur 4 bits, plus le cache KV correspondant à la longueur du contexte, ainsi qu’environ 1 Go pour le système d’exploitation et le model server. Avec un contexte de 8192 tokens, le cache ajoute environ 1 Go. Une offre avec 8 Go convient donc, contrairement à une offre avec 4 Go. Si vous voulez utiliser le contexte complet de 128k annoncé dans la fiche du modèle, le cache occupe à lui seul 16 Go. Il vous faut alors une offre avec 32 Go.

Pourquoi mon modèle est-il lent alors que le VPS dispose de nombreux vCPU ?

Parce que la génération est limitée par la bande passante mémoire, et non par le nombre de cœurs. Pour générer chaque token, le système doit charger l’ensemble des poids actifs depuis la RAM. Lorsque quelques cœurs saturent les canaux mémoire, les autres attendent. Le swap est l’autre cause fréquente. Si vmstat 1 affiche une valeur non nulle pour si et so pendant que le modèle répond, les poids ne tiennent pas dans la RAM. Une partie de chaque token est alors lue depuis le disque, ce qui coûte beaucoup plus cher qu’il n’y paraît.

Une fenêtre de contexte plus longue nécessite-t-elle vraiment plus de mémoire ?

Oui, et la consommation augmente linéairement avec le nombre de tokens. Un modèle 8B courant utilise environ 128 KiB de cache KV par token. 8192 tokens nécessitent donc 1 Go, et 131072 tokens nécessitent 16 Go. Le cache est alloué au chargement du modèle, et non au fur et à mesure que la conversation s’allonge. Demander un contexte de 128k réserve donc immédiatement cette mémoire, même si chaque prompt envoyé ne contient que 200 tokens.

Dois-je exécuter un grand modèle en 2 bits ou un modèle plus petit en 4 bits ?

Choisissez le modèle plus petit en 4 bits. La qualité diminue lentement entre 8 et 4 bits, puis rapidement en dessous de 4 bits. Un modèle 70B réduit à 2 bits fournit donc généralement de moins bonnes réponses qu’un modèle 32B en 4 bits issu de la même génération de modèles. Une quantification agressive se manifeste par des répétitions et des instructions ignorées, plutôt que par un message d’erreur. Il est alors facile d’accuser votre prompt. Considérez 4 bits comme la limite basse et modifiez plutôt le nombre de paramètres.

Puis-je auto-héberger un modèle aussi performant que les grands modèles commerciaux ?

Pas sur un VPS ordinaire. Les modèles open weight les plus performants atteignent plusieurs centaines de milliards de paramètres. En 4 bits, ils nécessitent plus de 200 Go de RAM, avant même de compter le cache KV. Les modèles commerciaux les plus performants ne sont pas distribués du tout. Le matériel courant convient surtout à l’exécution d’un bon modèle 8B à 32B pour une tâche précise. Dans ce cas, un petit modèle avec un prompt bien conçu égale souvent un modèle généraliste. Si vous avez besoin d’une qualité de niveau frontier, comparez le prix de l’API à celui du matériel avant d’acheter l’un ou l’autre.