Ollama ou llama.cpp sur un VPS : lequel choisir ?

Ollama ou llama.cpp : quelle couche voulez-vous exécuter ?

Ollama et llama.cpp ne sont pas des concurrents au sens où la question le laisse entendre. llama.cpp est le moteur d’inférence : il charge un fichier de modèle et transforme un prompt en tokens. Ollama est un gestionnaire de modèles, un daemon en arrière-plan et une API HTTP qui s’appuie sur ce moteur. Le README d’Ollama référence toujours llama.cpp comme backend d’inférence (vérifié le 27 octobre 2026). La vraie question est donc de savoir quelle couche vous voulez exploiter sur votre VPS, et non laquelle est la plus rapide.

Utilisez Ollama si vous voulez un service qui récupère les modèles par leur nom et continue de fonctionner sans intervention. Utilisez directement llama.cpp si votre machine est peu puissante et que vous devez choisir précisément le fichier de modèle, la taille exacte du contexte et le nombre exact de threads, car sur un petit VPS chacun de ces paramètres consomme une mémoire dont vous ne disposez pas.

Ce que fait réellement chaque projet

llama.cpp est une implémentation en C et C++ de l’inférence de transformeurs, basée sur la bibliothèque ggml. Il lit les fichiers GGUF. GGUF (GGML universal file format) est un conteneur monofichier qui contient les poids, le tokenizer et les métadonnées nécessaires à l’exécution du modèle. Le projet fournit des binaires distincts pour des tâches distinctes. llama-server est un serveur HTTP, llama-cli est une invite interactive et llama-bench mesure le débit. Le projet publie désormais des releases suivant le versionnage sémantique (MAJOR.MINOR.PATCH) ; v0.7.0, publiée le 15 October 2026, était la dernière au 27 October 2026. Des tags nightly numérotés par build continuent d’être publiés en parallèle, plusieurs par jour ; le plus récent au 27 October 2026 était b11913.

Ollama est un programme Go. Un daemon en arrière-plan, démarré avec ollama serve, charge les modèles et répond aux requêtes HTTP, tandis qu’un client en ligne de commande communique avec ce daemon. Les deux s’appuient sur un registry situé sur ollama.com, qui contient des modèles prépackagés. Ollama utilise le versionnage sémantique. v0.32.5 a été publié le 27 July 2026, et v0.40.12 est sorti le 27 October 2026 à 00:07 UTC. ollama pull récupère un fichier GGUF avec un prompt template et un ensemble de paramètres par défaut, puis le stocke sous /usr/share/ollama/.ollama/models sur Linux. Ces fichiers se trouvent sur le disque root et occupent plusieurs gigaoctets chacun. Sur un VPS doté d’un volume root de 25 GB, il est donc utile de savoir ce que le téléchargement laisse sur le disque et comment déplacer le répertoire des modèles ailleurs avant que le troisième téléchargement ne le remplisse.

C’est toute la différence entre ces deux modes de packaging. Ollama choisit pour vous la quantisation, le template et la longueur du contexte, et vous fournit un seul nom à retenir. llama.cpp expose ces choix sous forme de flags, avec des valeurs par défaut automatiques pour les paramètres que vous laissez non définis.

Axe 1 : contrôle du modèle et de la quantification

La quantification stocke les poids avec moins de bits que les 16 ou 32 bits du modèle d’origine. Les builds GGUF courants utilisent en moyenne environ 4, 5 ou 8 bits par poids. La précision n’est pas uniforme dans le fichier. Dans le code source du quantificateur de llama.cpp (lu le 27 October 2026), un build Q4_K_M conserve la plupart des tenseurs en 4 bits, mais utilise à la place la quantification Q6_K en 6 bits pour la couche de sortie ainsi que pour les tenseurs de valeur de l’attention et de descente du feed-forward dans environ la moitié des couches. Les petits tenseurs, comme les normes, ne sont pas quantifiés. C’est ce qui permet à un modèle de 8 milliards de paramètres de tenir dans la RAM d’un VPS ordinaire. La nomenclature GGUF devient lisible une fois que vous en connaissez le format : Q4_K_M signifie quantification K sur 4 bits, de taille moyenne. Un nombre plus élevé conserve davantage de précision et consomme plus de mémoire.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

Ce sont les tailles de fichiers publiées dans le dépôt bartowski/Meta-Llama-3.1-8B-Instruct-GGUF sur Hugging Face, relevées le 2 August 2026 et converties des octets en GiB. Il existe 6 builds d’un même modèle, et le plus petit fait 2.96 GiB contre 7.95 GiB pour le plus grand. Le choix courant par défaut, Q4_K_M, fait 4.58 GiB. Sur un VPS de 4 GiB, ce choix détermine à lui seul si le modèle se charge ou non. La taille ne représente que la moitié de la décision, car une ligne que vous pouvez vous permettre n’est pas automatiquement une ligne qui mérite d’être utilisée, et ce que Q4, Q8 et fp16 vous coûtent réellement en qualité de réponse vous indique si les gigaoctets supplémentaires apportent quelque chose que vous remarquerez.

Avec llama.cpp, vous indiquez le nom du fichier et choisissez donc vous-même cette ligne.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c est la taille du contexte en tokens, -t est le nombre de threads et -ngl définit le nombre de couches transférées vers un GPU (0 sur une machine équipée uniquement d’un CPU). Les paramètres non définis ont des valeurs par défaut, et --fit est activé par défaut pour ajuster les arguments non définis à la mémoire disponible sur le périphérique.

Avec Ollama, la quantification est incluse dans le tag que vous récupérez, et ollama ls affiche ce qui se trouve réellement sur le disque. Lorsque le registre ne contient pas le build souhaité, importez vous-même un GGUF. Écrivez un Modelfile :

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

Construisez-le ensuite et vérifiez le résultat :

ollama create llama31-q4 -f ./Modelfile
ollama ls

La taille du contexte est le paramètre à surveiller. Ollama choisit sa valeur par défaut en fonction de la VRAM disponible, et une machine sans GPU tombe dans la plus petite catégorie : 4096 tokens. Si vous lui envoyez un document de 20,000 tokens, les tokens supplémentaires sont supprimés avant même que le modèle ne les voie. La réponse peut donc être affirmée tout en étant erronée au sujet d’un fichier dont il n’a lu que la moitié. Augmentez cette valeur avec OLLAMA_CONTEXT_LENGTH sur le daemon, ou avec PARAMETER num_ctx dans un Modelfile. Si une seule tâche a besoin d’une fenêtre plus grande, num_ctx peut être défini par requête plutôt qu’à l’échelle du serveur, ce qui évite d’ajouter ce cache supplémentaire à toutes les autres tâches demandées au daemon. llama.cpp n’a pas non plus de valeur par défaut à laquelle vous pouvez raisonnablement vous fier. Définissez -c explicitement et sachez quelle valeur vous avez définie.

L’arithmétique de la mémoire que personne ne vous montre

Le fichier du modèle ne représente pas le coût total. Le cache KV (cache clé/valeur) conserve une entrée par couche et par token de contexte, et il augmente avec la longueur de la conversation.

Faisons le calcul pour Llama 3.1 8B. Le modèle comporte 32 couches, 8 têtes clé/valeur et une dimension de tête de 128. Chaque token stocke une clé et une valeur, à raison de 2 octets chacune en f16, donc 2 x 8 x 128 x 2 = 4096 octets par couche. Sur 32 couches, cela représente 128 KiB par token. Un contexte de 4096 tokens coûte donc 512 MiB, et un contexte de 32,768 tokens coûte 4 GiB.

Un modèle Q4_K_M 8B avec un contexte de 4k nécessite donc environ 4.58 GiB pour les poids, plus environ 0.5 GiB pour le cache, plus le runtime lui-même. Il ne tient pas dans 4 GiB de RAM. Il tient dans 8 GiB, avec de la marge pour fonctionner. Si vous augmentez le contexte à 32k sur cette même machine de 8 GiB, le cache consomme à lui seul toute la marge. Surveillez-le en temps réel avec free -h pendant que le modèle est chargé, et ne faites pas confiance à une estimation que vous n’avez pas mesurée. Si vous dimensionnez une machine pour un modèle nettement supérieur à 8B, le même calcul appliqué à un modèle de 27B sur un VPS CPU-only montre ce que chaque palier de 8 à 64 GB peut réellement contenir.

Ollama amplifie ce phénomène. OLLAMA_NUM_PARALLEL vaut 1 par défaut, et la mémoire nécessaire à un modèle évolue selon le produit de cette valeur par la longueur du contexte. Si vous augmentez les deux en même temps, le daemon demande discrètement plusieurs fois la quantité de RAM prévue. Le même calcul définit aussi votre plafond d’utilisateurs simultanés, car chaque requête concurrente a besoin de sa propre part du cache KV, ce qui explique pourquoi un serveur qui fonctionne bien pour une personne ralentit fortement à cinq.

Axe 2 : le démon à exploiter

Le script d’installation d’Ollama écrit une unité systemd, crée un utilisateur système ollama et active le service. Vous bénéficiez ainsi de la gestion du cycle de vie sans avoir à l’implémenter. La configuration passe par systemd :

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE est encore plus important sur un VPS avec CPU que partout ailleurs. Par défaut, les modèles restent en mémoire pendant 5 minutes, puis sont déchargés. La requête suivante doit recharger tout le fichier avant de pouvoir répondre. Si le noyau conserve encore le fichier dans son page cache, l’opération est rapide. Mais seule la RAM disponible permet de l’y conserver. Lorsque d’autres tâches l’en ont expulsé, le fichier est relu depuis le disque. Ainsi, le rechargement de 4.58 Gio transforme une réponse de deux secondes en une réponse de trente secondes sur un stockage lent. Une durée de keep-alive élevée supprime cette latence, mais consomme durablement la RAM. Ces deux solutions ont un coût réel. Choisissez celle qui vous gêne le moins. Si le modèle doit simplement rester résident, définir keep_alive pour le conserver pendant les périodes d’inactivité et après les redémarrages ne demande que quelques lignes et vous évite de précharger manuellement le modèle à chaque redémarrage du serveur.

llama.cpp ne fournit ni démon ni utilisateur de service. Vous devez donc configurer les deux vous-même. Depuis le répertoire llama.cpp dans lequel vous avez effectué la compilation, installez le binaire et ses bibliothèques dans /usr/local, créez un utilisateur llama et donnez-lui une copie du modèle :

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

Si vous avez utilisé l’archive de release au lieu de compiler le logiciel, faites pointer ExecStart vers llama-server à l’intérieur de cette archive, car celle-ci conserve ses bibliothèques à côté du binaire. Écrivez ensuite l’unité comme suit, dans /etc/systemd/system/llama-server.service :

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

Activez-la avec sudo systemctl enable --now llama-server. Le processus conserve alors le modèle pendant toute sa durée de vie. Par défaut, rien n’est déchargé pendant les périodes d’inactivité. Cependant, l’ajout de --sleep-idle-seconds active le déchargement et le rechargement automatiques sans arrêter le service. Si l’écriture d’unités est nouvelle pour vous, il s’agit du même modèle que l’exécution de vos propres services sous systemd sur un VPS.

Axe 3 : l’API utilisée par votre application

Cet axe s’est beaucoup réduit. Les deux projets utilisent désormais le format de chat OpenAI, si bien que la plupart des bibliothèques clientes fonctionnent avec l’un ou l’autre après une simple modification de l’URL de base. Une API identique ne garantit pas pour autant que le modèle tourne sur votre machine : Ollama 0.40.0 servait EmbeddingGemma 2 avec MLX, absent d’un VPS Linux sans GPU, et le guide RAG d’EmbeddingGemma 2 sur un VPS sans GPU montre comment produire vos embeddings avec Ollama ou avec llama-server, puis ce qu’implique la réindexation.

Ollama écoute sur 127.0.0.1:11434. Sa route compatible avec OpenAI est http://localhost:11434/v1/chat/completions, et il conserve également une API native sur /api/chat. Une route compatible avec Anthropic est aussi documentée. Aucune de ces routes ne permet au modèle d’effectuer des recherches de lui-même. Si votre application doit fournir des réponses plus récentes que les données d’entraînement du modèle, prévoyez d’intégrer la recherche web via l’API d’Ollama, Open WebUI ou une courte boucle d’outils.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

Avec les flags ci-dessus, llama-server écoute sur 127.0.0.1:8080. Laissé sans configuration, il utilise désormais par défaut le port 9931 (vérifié le 27 octobre 2026). Conservez donc --port dans la ligne de commande si votre application attend le port 8080. Il fournit /v1/chat/completions, /v1/completions et /v1/embeddings, ainsi que son propre endpoint /completion et une web UI intégrée. Il expose également des routes opérationnelles qu’Ollama ne fournit pas : /health pour une readiness probe, /props pour les paramètres du modèle chargé, /slots pour indiquer ce que fait chaque slot de requête, et /metrics au format Prometheus après l’ajout de --metrics, car cet endpoint est désactivé par défaut. Si vous prévoyez de monitorer ce service, cette différence sera probablement déterminante.

Aucun des deux serveurs n’active l’authentification pour vous. Par défaut, les deux utilisent loopback, pour de bonnes raisons. Accédez-y via un tunnel SSH ou derrière un reverse proxy, et n’exposez jamais 11434 ou 8080 sur Internet.

Ce qu’un VPS uniquement équipé d’un CPU peut réellement faire

Un VPS uniquement équipé d’un CPU exécute lentement les petits modèles. C’est le résumé honnête. L’important est de savoir où se situe la limite. Mesurez avant de concevoir quoi que ce soit autour de cette contrainte :

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

La colonne pp indique la vitesse de traitement du prompt et la colonne tg la vitesse de génération des tokens, toutes deux en tokens par seconde. Avec une offre vCPU partagée, un modèle 8B en Q4_K_M atteint généralement quelques unités par seconde pour tg. Le traitement du prompt est la partie la plus pénalisante : le prompt complet est traité avant l’apparition du premier token de sortie. Un long prompt système ajoute donc un temps d’attente à chaque requête. La longueur de la réponse est la moitié de la facture que vous pouvez réellement contrôler : à trois tokens par seconde, un modèle qui génère 600 tokens vous fait attendre 200 secondes, soit plus de trois minutes uniquement pour la génération. Limiter la sortie avec num_predict est donc le moyen le moins coûteux d’éviter qu’une réponse trop longue ne provoque un timeout.

Utilisable sur CPU : un modèle de 1B à 4B pour la classification, l’extraction, les résumés courts ou le routage. Les réponses arrivent en quelques secondes et la mémoire nécessaire tient dans une offre standard. Pour un exemple concret de cette taille, plutôt qu’une plage de tailles, Nemotron 3.5 Lightning téléchargé et mesuré sur un VPS fournit le tag exact, la quantité de RAM réellement demandée et la vitesse obtenue sans GPU. Non utilisable sur CPU : le chat interactif à vitesse de lecture, les assistants de programmation, le traitement de documents longs ou toute tâche avec une boucle d’agent effectuant de nombreux appels successifs. Une boucle qui effectue douze appels de quatre secondes prend une minute avant de produire quoi que ce soit. Si vous aviez prévu d’utiliser un assistant de programmation, orienter un agent vers un modèle que vous hébergez vous-même précise quels travaux un petit modèle local réalise réellement avec efficacité et lesquels doivent rester sur une API hébergée.

Deux solutions existent lorsque les chiffres ne conviennent pas. Si le problème vient de la concurrence, avec plusieurs utilisateurs qui sollicitent simultanément un même modèle, le choix du moteur change. La comparaison entre Ollama et vLLM pour le serving concurrent traite ce sujet. Si le problème vient de la vitesse brute, la réponse est un VPS auquel un GPU est attaché, sur lequel -ngl commence à devenir significatif. Dans les deux cas, mesurez d’abord les performances propres au matériel, car la bande passante du disque et de la mémoire influence le temps de chargement autant que le CPU. Un benchmark reproductible sur VPS mérite l’heure que vous y consacrerez.

Installer llama.cpp sur une build précise

Les deux projets évoluent chaque semaine. Notez donc la version déployée. La commande en une ligne fournie par le projet installe la build actuelle :

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Pour utiliser une build précise, téléchargez plutôt le tarball précompilé depuis la page des releases. Le projet publie désormais aussi des releases avec version sémantique : v0.7.0 était la dernière version le 27 octobre 2026, et sa page de release renvoie vers la nightly b11669 pour les binaires. La version v0.8.0 a suivi le 28 octobre 2026, et sa page de release renvoie vers la nightly b11960 pour les binaires. Les commandes ci-dessous utilisent b10224, le tag actuel au 2 août 2026. Remplacez-le par le tag que vous avez testé :

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

Vous pouvez aussi compiler ce même tag depuis les sources :

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev est la dépendance documentée pour les fonctionnalités HTTPS. La compilation prend plusieurs minutes et nécessite plus de RAM que les offres les plus petites. Compilez donc sur une machine plus grande, puis copiez les binaires si la petite machine manque de ressources.

Installer Ollama en épinglant une version

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

Le script lit OLLAMA_VERSION, ce qui vous permet de conserver une release connue comme fiable au lieu d’installer celle publiée ce matin. La version v0.32.5 a été publiée le 27 juillet 2026. Une procédure manuelle est également disponible si vous préférez ne pas transmettre un script à un shell via un pipe :

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

La procédure manuelle ne crée ni l’unité systemd ni le compte de service. Vous devez donc les créer vous-même. La procédure complète pour installer Ollama sur un VPS décrit cette configuration du service étape par étape.

Modes d’échec et messages affichés

Ollama refuse de charger le modèle. Les anciennes releases d’Ollama vérifiaient la taille avant le chargement, et ollama run renvoyait une ligne de cette forme :

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Le code source actuel d’Ollama ne contient plus ce message (vérifié le 27 octobre 2026). Ollama délègue désormais le chargement à llama-server. Un modèle trop volumineux apparaît donc comme un échec du runner, avec des erreurs qui commencent comme ceci :

llama-server reported out-of-memory during startup
llama-server process has terminated

Dans les deux cas, le correctif est identique. Descendez d’une ligne de quantification, réduisez la longueur du contexte ou choisissez un modèle plus petit.

llama.cpp n’échoue pas, mais devient extrêmement lent. Par défaut, llama.cpp mappe le fichier GGUF en mémoire. Un fichier plus volumineux que la RAM peut donc quand même démarrer. Le kernel charge alors les poids depuis le disque et les y renvoie pour chaque token. La génération passe à plusieurs secondes par token et l’utilisation du disque atteint 100 %. Passez --load-mode none pour désactiver le memory mapping. Cette option a remplacé --no-mmap, qui est documentée comme obsolète dans la build b10224 épinglée et n’apparaît plus dans les builds actuelles (vérifié le 29 octobre 2026). Lorsque le kernel intervient, dmesg affiche la raison :

Out of memory: Killed process 1234 (llama-server)

Le fichier du modèle ne se charge pas du tout. Un fichier GGUF construit pour une famille de modèles plus récente que votre moteur provoque une erreur qui indique l’architecture inconnue ; <arch> correspond au nom stocké dans les métadonnées du fichier :

llama_model_load: error loading model: unknown model architecture: '<arch>'

Le correctif consiste à mettre à niveau le moteur, pas à utiliser un autre fichier. C’est le prix du versionnement fixe, et c’est pourquoi vous devez noter le numéro de build. Vous devez savoir depuis quelle version vous effectuez la mise à niveau.

L’API répond localement, mais pas depuis votre application. Ollama écoute sur 127.0.0.1:11434. Un autre hôte reçoit donc un refus de connexion. Définissez OLLAMA_HOST=0.0.0.0:11434 via systemctl edit ollama uniquement si le port se trouve derrière un pare-feu ou sur un réseau privé, car l’API n’a aucune authentification en amont.

La première réponse après une pause est très lente. Le déchargement après 5 minutes d’inactivité a eu lieu, et le modèle est rechargé depuis le disque si le page cache ne l’a pas conservé. ollama ps exécuté juste avant la requête n’affiche aucun modèle chargé, ce qui le confirme. Augmentez OLLAMA_KEEP_ALIVE.

Alors, lequel devez-vous utiliser ?

Utilisez Ollama si vous voulez que les modèles soient gérés automatiquement et disposer immédiatement d’un endpoint compatible avec OpenAI. C’est le choix par défaut pour un premier déploiement et pour les cas où le modèle utilisé changera régulièrement.

Utilisez directement llama.cpp si la mémoire est suffisamment limitée pour vous obliger à choisir vous-même la ligne de quantification, si vous voulez /health, /slots et /metrics pour la supervision, ou si vous avez besoin d’un flag qu’Ollama n’expose pas. C’est le choix le plus adapté sur un VPS où le modèle tient tout juste, car les paramètres qui lui permettent de tenir sont précisément ceux qu’Ollama choisit à votre place.

Utiliser les deux est parfaitement normal. Ollama pour les tests, llama.cpp pour le modèle que vous mettez en production et que vous ne voulez plus voir changer.

FAQ

Ollama est-il simplement un wrapper autour de llama.cpp ?

Presque, mais le wrapper effectue un vrai travail. Le README d’Ollama indique que llama.cpp est son backend d’inférence (vérifié le 27 October 2026). Ollama ajoute au-dessus un registre de modèles, le prompt template qui transforme les messages de chat en prompt, un ensemble de paramètres d’échantillonnage par défaut, un daemon qui décharge les modèles inactifs et une API HTTP. Lorsque vous comparez le nombre de tokens par seconde avec des paramètres identiques, vous comparez le même moteur à lui-même. En réalité, vous choisissez entre les couches de gestion.

Lequel est le plus rapide sur un VPS avec CPU uniquement ?

Ils utilisent le même moteur. Avec le même fichier de modèle, la même quantisation, la même taille de contexte et le même nombre de threads, leurs performances sont donc proches. Les différences généralement rapportées viennent plutôt de paramètres par défaut différents, le plus souvent la longueur du contexte et le nombre de threads, que du moteur lui-même. Mesurez les performances avec llama-bench -m <file> -p 512 -n 128 et comparez la colonne tg sur votre propre machine avant de vous fier à une valeur publiée.

Puis-je utiliser mon propre fichier GGUF avec Ollama ?

Oui. Placez le fichier sur le serveur, écrivez un Modelfile dont la première ligne est FROM ./your-model.gguf, ajoutez les lignes PARAMETER nécessaires, comme num_ctx, puis exécutez ollama create your-name -f ./Modelfile. ollama ls le répertoriera à côté des modèles récupérés depuis le registre. C’est ainsi que vous utilisez une quantisation qui n’est pas proposée dans le registre.

De combien de RAM ai-je besoin pour un modèle 8B ?

Prévoyez la taille du fichier, le KV cache et le runtime. Une version Q4_K_M de Llama 3.1 8B occupe environ 4.58 GiB sur disque, et un contexte de 4096 tokens ajoute environ 512 MiB de cache. 8 GiB de RAM offrent donc une marge confortable, tandis que 4 GiB ne suffisent pas. Le cache évolue avec la taille du contexte : le même modèle avec un contexte de 32,768 tokens nécessite à lui seul environ 4 GiB de cache. Avec Ollama, n’oubliez pas que les besoins évoluent également avec OLLAMA_NUM_PARALLEL.