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 élément : la quantité de RAM du serveur. La famille du modèle et le framework comptent beaucoup moins que la possibilité de charger les poids en mémoire tout en conservant une marge disponible. Cet article explique les calculs à effectuer. Installer un runtime est une tâche distincte, traitée dans le guide pour exécuter Ollama sur un VPS.

Deux coûts déterminent le résultat. 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 celui que l’on oublie jusqu’au jour où un modèle chargé la veille refuse de se charger.

Le calcul du dimensionnement : bits par paramètre

Un fichier de modèle contient presque exclusivement des poids. Chaque poids est stocké sur un certain nombre de bits. La quantification consiste à les stocker sur moins de bits que la précision utilisée pendant l’entraînement. Elle entraîne une légère perte de précision, mais économise beaucoup de mémoire. La taille se déduit directement de ce nombre :

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’utilise 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, passez à 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 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, et augmente linéairement avec cette longueur.

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

Avec la longueur de contexte par défaut d’Ollama, ce modèle 8B consomme un demi-gigaoctet pour le cache. À 8192 tokens, il consomme 1 Go. Avec le contexte de 128k indiqué sur sa fiche, il consomme 16 Go, soit plus de trois fois la taille de ses poids. Le 70B présente le cas inverse : son cache à 128k fait 40 Go, soit moins que ses propres poids, car l’attention à requêtes groupées empêche le coût par token d’augmenter presque aussi vite que le 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 plutôt 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 de contexte.

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

Un modèle résident conserve sa place 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. Ce réglage par défaut convient à un ordinateur portable, mais pas à un serveur : après chaque période d’inactivité, la première requête doit de nouveau attendre le chargement du modèle.

ollama ps
ollama stop qwen3:4b

ollama ps affiche les modèles résidents. Sa colonne SIZE indique la quantité de mémoire utilisée et sa colonne UNTIL indique quand le modèle expire. Pour conserver un modèle en mémoire en permanence, définissez OLLAMA_KEEP_ALIVE=-1 sur le service. Une valeur de 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 une requête, 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 conserve cette RAM, que quelqu’un l’utilise ou non. Un modèle épinglé 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, pas du modèle seul. Conserver un modèle en mémoire explique 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 serveur de modèles. Il reste environ 3 GB. Cela correspond à 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.

Prévoyez 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 un style éditorial défini. Ils sont faibles en raisonnement en plusieurs étapes et pour le code réparti sur plusieurs fichiers. Aucun prompt ne peut corriger ces limites.

À ce niveau, le principal problème 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 peut alors prendre plusieurs secondes par token. Surveillez les colonnes si et so de vmstat 1, ainsi que free -h, pendant que le modèle répond. Des valeurs non nulles pour le swap entrant et sortant pendant la génération indiquent que le modèle est trop volumineux pour cette offre.

Ce qui fonctionne sur un VPS de 8 à 16 GB

C’est à partir de cette capacité qu’un modèle auto-hébergé devient réellement utile. Avec 8 GB, vous pouvez exécuter un modèle 7B ou 8B en 4 bits, avec environ 4.8 GB de poids et un contexte de 8k. Avec 16 GB, vous pouvez exécuter un modèle 13B ou 14B en 4 bits, avec environ 8.4 GB, 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 est 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 de regarder un dactylographe lent. C’est acceptable pour une tâche en arrière-plan, mais fatigant pour une conversation interactive. Exécutions mesurées de Qwen 3 en 8B et dans des tailles supérieures sur un VPS montrent ce que cela donne 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 dispose d’une marge confortable sur 48 GB ou 64 GB. Un modèle 70B en 4 bits occupe environ 42 GB. Il nécessite donc 64 GB avant même d’ajouter le moindre cache.

Lisez ensuite les performances de façon réaliste. Un modèle 32B sur CPU produit environ 0.6 à 1.5 tokens par seconde, et un modèle 70B environ 0.2 à 0.5. Une réponse de 500 tokens générée par ce modèle 70B prend environ vingt minutes. À cette vitesse, la requête échoue généralement avant la fin de la génération, car le délai d’expiration d’un client ou d’un proxy placé devant Ollama est atteint en premier. C’est l’origine de l’erreur context deadline exceeded. Ces outils sont conçus pour le traitement par lots. Si vous leur fournissez une file de documents à traiter pendant la nuit, la vitesse importe peu. Si vous les placez derrière une interface de chat, elle devient un facteur déterminant.

Le routage des mixture of experts modifie ce calcul. C’est le seul détail d’architecture qui mérite vraiment d’être connu. Un modèle MoE ne fait passer chaque token que par une petite partie de ses poids. Un modèle comptant 30B paramètres au total et 3B paramètres actifs par token nécessite la mémoire d’un modèle 30B, mais produit des tokens à une vitesse proche de celle d’un modèle dense 3B, car chaque token ne lit que les experts actifs. Sur une machine de 32 GB, un modèle MoE de cette configuration est bien plus utilisable qu’un modèle dense de 30B. La règle à retenir est simple : le nombre total de paramètres détermine la mémoire requise, et le nombre de paramètres actifs détermine la vitesse.

Quelle est honnêtement la vitesse de l’inférence CPU ?

Générer un token nécessite de lire une fois chaque poids actif depuis la mémoire. 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. La limite correspond à une division : la bande passante mémoire utilisable par la taille des poids en octets. Un petit VPS partagé fournit généralement 10 à 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 plages couramment observées sur du matériel VPS standard, et non à un benchmark réalisé sur une machine précise. Votre résultat dépend de la génération de mémoire, du nombre de canaux de l’hôte et du nombre de voisins qui se la partagent. Mesurez votre propre vitesse avec n’importe quel tag de modèle dont vous disposez déjà :

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

Le résumé affiché après la fin de 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ésumé inclut la lecture des poids depuis le disque. Mesurer correctement les tokens par seconde explique comment obtenir une valeur utile pour les comparaisons.

Deux résultats surprennent souvent. Ajouter des vCPU cesse rapidement d’améliorer les performances, car au-delà d’environ 8 cœurs, les cœurs supplémentaires attendent la mémoire au lieu d’effectuer des calculs. Sur une offre partagée, la même commande renvoie aussi des valeurs différentes selon l’heure. Il s’agit du temps de steal CPU causé par un voisin bruyant, et non d’une erreur 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 est limité par la puissance de calcul. Il évolue donc avec le nombre de cœurs, et c’est dans ce domaine qu’un GPU prend le plus d’avance. Un long document demande plusieurs minutes de lecture à un CPU, contre quelques secondes à un GPU. C’est le premier goulot 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 que le moindre token de la réponse ne soit généré.

Ce qui change lorsque vous ajoutez un GPU

Les calculs ne changent pas. Seul le pool auquel ils s’appliquent change. La VRAM est une limite stricte. Déterminez donc ce qui tient dans la mémoire avant de louer le serveur :

• 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 ou 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 en mémoire, Ollama le répartit : certaines couches sont exécuté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, et non comme une fonctionnalité. La moitié 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écutent sur le CPU fonctionne donc beaucoup plus près de la vitesse du CPU que de celle du GPU. Si vous constatez 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 dépassé 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 a besoin de son propre cache KV. 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 avec un même modèle auto-hébergé explique où se situe cette limite.

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

Ce que vous ne pouvez pas auto-héberger

Il existe ici deux obstacles différents. Il est utile de savoir lequel vous rencontrez.

Le premier concerne les modèles dont les poids sont 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 changera cela. Vous pouvez auto-héberger tout ce qui les entoure : l’interface, la couche de retrieval, la boucle de l’agent et les journaux. Le modèle lui-même reste accessible via une API distante. L’article sur la possibilité d’auto-héberger Claude traite ce sujet en détail.

Le second concerne les modèles à poids ouverts qui sont simplement trop volumineux. Les plus grandes releases open source utilisent des architectures mixture of experts avec plusieurs centaines de milliards de paramètres au total. La même règle s’applique : un modèle de 400B paramètres au total, en 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 détaille les besoins réels. La même distinction apparaît dans la propre bibliothèque d’Ollama : GLM 5.2 est proposé uniquement comme modèle cloud, tandis qu’un modèle dérivé beaucoup plus petit est celui qui se télécharge réellement sur un VPS.

La distinction honnête 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 irrégulière, ou lorsque la qualité des réponses d’un modèle de pointe est précisément ce dont vous avez besoin.

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 reste par 0.6 pour obtenir le nombre maximal de paramètres, en milliards, que vous pouvez charger en 4 bits. Soustrayez ensuite la KV cache correspondant au contexte dont vous avez réellement besoin. 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, et environ 1 Go pour le système d’exploitation et le serveur de modèle. 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 actif des poids depuis la RAM. Dès que quelques cœurs saturent les canaux mémoire, les autres attendent. L’autre cause fréquente est le swap. Si vmstat 1 affiche une valeur non nulle pour si et so pendant que le modèle répond, les poids ne tiennent pas en 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. La consommation augmente linéairement avec le nombre de tokens. Un modèle 8B typique utilise environ 128 KiB de cache KV par token. 8192 tokens consomment donc 1 Go, et 131072 tokens consomment 16 Go. Le cache est alloué au chargement du modèle, et non à 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 traduit 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 minimale 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 par ailleurs pas distribués. Un matériel ordinaire permet surtout d’exécuter un bon modèle de 8B à 32B pour une tâche précise. Dans ce cas, un petit modèle spécialisé et correctement guidé peut souvent égaler un modèle généraliste. Si vous avez besoin d’une qualité de niveau frontier, comparez le prix de l’API au coût du matériel avant de choisir l’une ou l’autre solution.