Faire tourner un LLM sur CPU avec llama.cpp sur un serveur dédié Xeon

Inférence LLM sur CPU avec un serveur dédié

Les modèles de langage (LLM) comme Llama, Mistral ou Qwen génèrent du texte, résument des documents, répondent à des questions et alimentent des chatbots. Leur exécution, appelée inférence, nécessite traditionnellement un GPU avec plusieurs dizaines de gigaoctets de VRAM. Mais un processeur serveur Intel Xeon avec suffisamment de RAM et les bonnes instructions vectorielles peut aussi faire tourner ces modèles, sans carte graphique.

llama.cpp est le moteur d'inférence LLM de référence pour le CPU. Écrit en C/C++, il charge des modèles au format GGUF (quantifiés de 2 à 8 bits) et exploite les instructions AVX-512 et VNNI des processeurs Xeon pour accélérer les calculs matriciels. Ce guide explique comment déployer llama.cpp sur un serveur dédié Intel Xeon Gold dans l'offre d'hébergement dédié ElypseCloud (2 x Xeon Gold 6230, 40 coeurs / 80 threads, DDR4 ECC de 32 à 512 Go) pour faire tourner un LLM en inférence CPU : choix du modèle et de la quantification, dimensionnement de la RAM et de l'espace disque, configuration des threads et de la topologie NUMA, mise en service du serveur HTTP llama-server et sécurisation avec un firewall et un reverse proxy.

Pourquoi faire de l'inférence LLM sur CPU

L'inférence sur GPU (NVIDIA CUDA, AMD ROCm) reste plus rapide pour les gros volumes de requêtes. Mais le CPU présente des avantages concrets pour de nombreux cas d'usage :

• Pas de carte graphique à acheter ni à héberger. Un serveur dédié standard suffit. Pas de contrainte d'alimentation ou de refroidissement supplémentaire liée au GPU.
• RAM extensible. Un serveur bi-processeur Xeon Gold 6230 dispose de 12 canaux mémoire DDR4 (6 par socket) et supporte de 32 à 512 Go de RAM DDR4 ECC dans les configurations ElypseCloud. La VRAM d'un GPU est fixe et limitée (24 Go sur un RTX 4090, 80 Go sur un A100). La RAM du serveur dédié permet de charger des modèles qui ne tiendraient pas en VRAM.
• Données sur votre propre machine. L'inférence locale évite d'envoyer vos données à une API tierce. Pour des documents internes, des données personnelles ou du code source, c'est un avantage en matière de confidentialité et de conformité.
• Simplicité de déploiement. llama.cpp se compile avec cmake, sans pilote GPU, sans CUDA toolkit, sans dépendance Python. Le binaire tourne sur n'importe quelle distribution Linux serveur. Vous disposez d'un accès root complet pour installer, compiler et configurer le service d'inférence comme vous le souhaitez.
• Pas de couche de virtualisation. Sur un serveur dédié bare metal, le processeur exécute vos calculs sans hyperviseur intermédiaire. Les instructions AVX-512 et VNNI sont exploitées directement, sans le surcoût d'un serveur virtuel.

Cas d'usage typiques sur un serveur dédié : chatbot interne, résumé de documents, extraction d'information, génération de code assistée, traitement de tickets support, prototypage avant un déploiement GPU.

AVX-512 et VNNI : les instructions du Xeon Gold 6230 pour l'inférence

La vitesse d'inférence sur CPU dépend directement des instructions vectorielles que le processeur peut exécuter. Le Xeon Gold 6230 (architecture Cascade Lake, 14 nm, 20 coeurs par socket) supporte le jeu d'instructions AVX-512 avec deux unités FMA (Fused Multiply-Add) par coeur. Chaque unité traite 512 bits de données par cycle, soit 16 opérations flottantes 32 bits ou 64 opérations entières 8 bits en un seul cycle d'horloge.

En plus d'AVX-512, le Xeon Gold 6230 intègre AVX-512 VNNI (Vector Neural Network Instructions), commercialisé sous le nom Intel DL Boost. VNNI ajoute des instructions spécialisées comme VPDPBUSD et VPDPWSSD, qui combinent une multiplication et une accumulation entière en une seule instruction. Ces opérations correspondent exactement à ce que llama.cpp exécute pour la multiplication matricielle sur des poids quantifiés en INT8 ou INT4.

llama.cpp détecte automatiquement les extensions AVX-512 et VNNI à la compilation et active des kernels optimisés quand le processeur les supporte. Le gain par rapport à AVX2 seul est significatif sur les calculs de produit scalaire quantifié, qui représentent l'essentiel du temps de calcul lors de l'inférence. Pour le détail complet des caractéristiques du processeur, consultez la fiche technique du Xeon Gold 6230.

Format GGUF et quantification des modèles

Les modèles de langage sont entraînés en précision flottante (FP16 ou BF16), ce qui les rend volumineux : un modèle de 70 milliards de paramètres pèse environ 140 Go en FP16. La quantification réduit la précision des poids (de 16 bits à 2-8 bits par paramètre), ce qui diminue la taille en mémoire et accélère l'inférence, au prix d'une légère perte de qualité dans les réponses générées.

GGUF (GPT-Generated Unified Format) est le format de fichier de llama.cpp. Il contient les poids quantifiés, le tokenizer et les métadonnées du modèle dans un seul fichier binaire. Les modèles GGUF pré-quantifiés sont disponibles sur Hugging Face pour la plupart des LLM open source (Llama, Mistral, Qwen, Phi, Gemma).

Les niveaux de quantification les plus utilisés :

Pour un usage serveur en production, Q4_K_M offre le meilleur compromis entre taille du fichier, qualité des réponses et vitesse d'inférence. Q5_K_M et Q8_0 sont préférables quand la RAM installée sur le serveur dédié le permet.

RAM nécessaire selon la taille du modèle

La RAM requise dépend de la taille du modèle (nombre de paramètres), du niveau de quantification et de la taille du contexte (nombre de tokens traités simultanément). Le tableau ci-dessous donne des estimations pour un contexte standard de 4 096 tokens, incluant les poids du modèle et le cache KV (Key-Value) nécessaire à l'inférence :

Ces estimations sont approximatives et augmentent avec la taille du contexte. Un contexte de 8 192 tokens double la taille du cache KV par rapport à 4 096 tokens. Prévoyez une marge de 10 à 20 % au-dessus de la taille brute du modèle pour le système d'exploitation Linux, les tampons d'inférence et le cache KV étendu.

Avec un serveur dédié Xeon Gold en configuration 128 Go de RAM DDR4 ECC, vous pouvez charger un modèle 70B en Q4_K_M avec une marge confortable pour le contexte et le système. La configuration 256 Go permet de travailler en Q5_K_M ou Q8_0 sur des modèles 70B, ou de faire tourner plusieurs modèles en parallèle sur le même serveur.

Installer llama.cpp sur un serveur dédié Linux

llama.cpp se compile depuis les sources avec cmake. Sur un serveur dédié sous Debian 12 ou Ubuntu 24.04 LTS, connectez-vous en SSH avec un accès root et installez les dépendances de compilation :

sudo apt update
sudo apt install -y build-essential cmake git

Clonez le dépôt officiel et compilez (la documentation complète est sur le dépôt GitHub du projet llama.cpp) :

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j $(nproc)

La compilation détecte automatiquement les instructions AVX-512 et VNNI du Xeon Gold 6230 et active les kernels optimisés correspondants. Vérifiez la détection dans la sortie de cmake : les lignes AVX512 et AVX512_VNNI doivent apparaître.

Les binaires compilés se trouvent dans le répertoire build/bin/ :

• llama-cli : interface en ligne de commande pour l'inférence interactive ;
• llama-server : serveur HTTP avec API compatible OpenAI ;
• llama-quantize : outil pour convertir un modèle vers un autre niveau de quantification.

Pour télécharger un modèle GGUF, rendez-vous sur Hugging Face et filtrez par format GGUF. Les fichiers portent des noms explicites : Meta-Llama-3-8B-Instruct-Q4_K_M.gguf indique un Llama 3 8B Instruct quantifié en Q4_K_M. Téléchargez le fichier directement avec wget ou curl depuis le terminal SSH de votre serveur dédié.

Configurer les threads et la topologie NUMA

Le paramètre --threads détermine combien de coeurs CPU llama.cpp utilise pour l'inférence. Sur un serveur bi-processeur Xeon Gold 6230 (40 coeurs physiques, 80 threads logiques avec Hyper-Threading), le réglage optimal dépend de la taille du modèle et de la topologie NUMA du serveur.

Chaque processeur (socket) constitue un noeud NUMA avec ses 20 coeurs physiques et sa mémoire DDR4 locale. Les accès mémoire entre deux noeuds NUMA (cross-socket) ajoutent une latence significative. Pour l'inférence LLM, où chaque token généré nécessite un balayage complet des poids du modèle en mémoire, cette latence pénalise directement la vitesse de génération. Notre guide NUMA sur serveur dédié bi-processeur détaille cette architecture.

Si le modèle tient dans la RAM d'un seul socket

Épinglez le processus sur un seul noeud NUMA avec numactl. C'est la configuration la plus performante car tous les accès mémoire restent locaux :

numactl --cpunodebind=0 --membind=0 ./build/bin/llama-cli \
  -m /chemin/vers/modele.gguf \
  --threads 20 \
  --interactive

Ici, --cpunodebind=0 --membind=0 restreint l'exécution et la mémoire au noeud NUMA 0 (premier processeur), et --threads 20 utilise les 20 coeurs physiques de ce socket. Un modèle 7B à 13B en Q4_K_M tient confortablement dans la RAM d'un seul noeud.

Si le modèle a besoin de la RAM des deux sockets

Pour un modèle volumineux (70B+), utilisez l'option NUMA intégrée de llama.cpp :

./build/bin/llama-cli \
  -m /chemin/vers/modele-70b.gguf \
  --threads 40 \
  --numa distribute \
  --interactive

L'option --numa distribute répartit les allocations mémoire sur les deux noeuds NUMA. Les options alternatives sont --numa isolate (restreindre au noeud de démarrage) et --numa numactl (utiliser la topologie définie par numactl). Avec --threads 40, les 40 coeurs physiques des deux processeurs participent à l'inférence.

Évitez de dépasser le nombre de coeurs physiques (40) avec --threads. L'Hyper-Threading (80 threads logiques) n'apporte pas de gain significatif pour l'inférence LLM : les calculs matriciels quantifiés saturent déjà les unités d'exécution AVX-512 de chaque coeur.

llama-server : exposer un LLM via HTTP

llama-server expose le modèle chargé via une API HTTP compatible avec le format de l'API OpenAI. N'importe quelle application capable d'appeler l'API OpenAI (chatbots, outils de résumé, pipelines de traitement de texte, assistants de code) peut interroger votre modèle local en changeant simplement l'URL du endpoint.

Lancez le serveur HTTP sur votre serveur dédié :

numactl --cpunodebind=0 --membind=0 ./build/bin/llama-server \
  --model /chemin/vers/modele.gguf \
  --threads 20 \
  --host 0.0.0.0 \
  --port 8080 \
  --ctx-size 4096

Le serveur écoute sur le port 8080 et accepte les requêtes sur les endpoints /v1/chat/completions et /v1/completions. Depuis la version 0.7.0 de llama.cpp, le port par défaut est 9931 si --port n'est pas spécifié. Test avec curl :

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "local", "messages": [{"role": "user", "content": "Bonjour"}]}'

Le paramètre --ctx-size contrôle la taille maximale du contexte et impacte directement la consommation de RAM (plus le contexte est long, plus le cache KV est volumineux).

Reverse proxy et nom de domaine

En production, ne laissez jamais llama-server exposé directement sur Internet sans protection. Placez-le derrière un serveur web qui fait office de reverse proxy : Nginx ou Apache gèrent le TLS (HTTPS), l'authentification et la limitation de débit, tandis que llama-server écoute uniquement sur 127.0.0.1. Notre guide publier un service en HTTPS sur Linux détaille la mise en place d'un reverse proxy avec certificat TLS Let's Encrypt.

Attribuez un nom de domaine à votre service d'inférence (par exemple llm.votre-domaine.fr) et configurez l'enregistrement DNS de type A (ou AAAA pour IPv6) pointant vers l'adresse IP publique de votre serveur dédié. ElypseCloud fournit une adresse IPv4 et un bloc IPv6 avec chaque serveur. Le serveur web reverse proxy (Nginx, Apache) route ensuite les requêtes HTTPS entrantes vers le port local de llama-server.

Firewall et accès réseau

Configurez le firewall de votre serveur dédié pour restreindre l'accès au service. Avec UFW, ouvrez uniquement les ports nécessaires (SSH, HTTP, HTTPS) et gardez le port de llama-server fermé au trafic extérieur puisque le reverse proxy communique en local :

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Notre guide ouvrir les ports avec UFW sur Linux détaille la configuration du firewall. Pour un service en production, créez une unité systemd afin que llama-server redémarre automatiquement au boot du serveur.

Espace disque et sauvegardes des modèles GGUF

Les fichiers GGUF occupent un espace disque significatif. Un modèle 7B en Q4_K_M pèse environ 4 Go, un 13B environ 8 Go et un 70B environ 40 Go. Si vous travaillez avec plusieurs modèles ou plusieurs niveaux de quantification, prévoyez 100 à 200 Go d'espace disque pour votre bibliothèque de modèles. Les serveurs dédiés Xeon Gold ElypseCloud incluent un SSD de 1 To, ce qui laisse une marge confortable pour le système d'exploitation, les modèles GGUF et les logs du serveur d'inférence.

Mettez en place une stratégie de sauvegardes pour vos fichiers de configuration, vos modèles personnalisés et vos données d'inférence. Un modèle téléchargé depuis Hugging Face peut être re-téléchargé, mais un modèle fine-tuné ou des configurations NUMA optimisées méritent un backup régulier vers un emplacement distant. Notre guide sauvegardes et haute-disponibilité sur serveur dédié couvre les stratégies de backup adaptées à un hébergement dédié.

Serveur dédié bare metal ou serveur VPS pour l'inférence LLM

L'inférence LLM sur CPU est un cas d'usage où le choix entre un serveur dédié bare metal et un serveur VPS a un impact direct sur les performances.

Sur un serveur virtuel, la couche de virtualisation (hyperviseur KVM, VMware, Hyper-V) introduit un surcoût. Selon la configuration de l'hébergeur, les instructions AVX-512 peuvent ne pas être exposées à la machine virtuelle, ce qui force llama.cpp à se replier sur AVX2 ou SSE et réduit significativement la vitesse d'inférence. La RAM allouée à un VPS est aussi généralement plafonnée à 32 ou 64 Go, insuffisant pour les modèles 70B+.

Un serveur dédié bare metal supprime ces limitations :

• Accès direct aux instructions AVX-512 et VNNI, sans filtrage par l'hyperviseur ;
• Accès root complet pour configurer la topologie NUMA, les huge pages et les paramètres du noyau Linux ;
• Jusqu'à 512 Go de RAM DDR4 ECC dédiée intégralement à l'inférence ;
• 40 coeurs physiques exploitables sans partage avec d'autres locataires.

Pour les modèles compacts (7-8B en Q4_K_M, environ 5 Go de RAM), un VPS Linux avec 8 à 16 Go peut suffire pour du prototypage. Pour un usage en production ou des modèles plus volumineux, l'hébergement dédié est le choix adapté. Notre guide serveur dédié bare metal vs VPS détaille les critères de choix entre les deux formules.

CPU vs GPU : les limites honnêtes de l'inférence sur processeur

L'inférence sur CPU avec llama.cpp fonctionne et produit des résultats utilisables, mais un GPU dédié (NVIDIA A100, H100, L40S) reste significativement plus rapide :

• Bande passante mémoire. L'inférence LLM est limitée par la bande passante mémoire (memory-bound) : chaque token généré nécessite de lire l'intégralité des poids du modèle en RAM. La DDR4 d'un serveur CPU ne rivalise pas avec la mémoire HBM des GPU modernes sur ce point.
• Parallélisme massif. Un GPU possède des milliers de coeurs spécialisés en calcul matriciel, contre 40 coeurs généralistes sur le bi-processeur Xeon Gold.

L'inférence CPU reste pertinente pour :

• Un usage à faible débit (quelques requêtes par minute, pas par seconde) ;
• Des modèles trop volumineux pour la VRAM d'un GPU (70B+ en haute quantification) ;
• Du prototypage et de l'expérimentation avant d'investir dans une infrastructure GPU ;
• Des contraintes de confidentialité qui imposent un traitement local sur votre propre serveur.

Si votre charge nécessite un débit d'inférence élevé ou des temps de réponse courts pour de nombreux utilisateurs simultanés, un serveur GPU est plus adapté. ElypseCloud propose du housing GPU en datacenter Equinix PA6 à Paris pour héberger vos propres cartes graphiques dans une infrastructure refroidie et alimentée.

Quelle configuration de serveur dédié choisir

Le choix de la configuration dépend de la taille du modèle LLM que vous souhaitez faire tourner. Tous les serveurs dédiés Xeon Gold ElypseCloud embarquent les mêmes 2 x Intel Xeon Gold 6230 (40 coeurs / 80 threads, 2,1 GHz de base, 3,9 GHz en turbo), un SSD de 1 To, la protection anti-DDoS, une adresse IPv4 et un bloc IPv6, et la bande passante 1 ou 10 Gbit/s. Votre espace de gestion sur manager.elypsecloud.com (panel d'administration) permet de piloter le serveur, de suivre la consommation réseau et de gérer vos adresses IP. La différence entre les offres se fait sur la RAM DDR4 ECC :

Pour un budget plus serré ou un modèle de petite taille (7-8B), la gamme Xeon E5 offre un point d'entrée moins coûteux. Les Xeon E5 supportent AVX2 (pas AVX-512), ce qui réduit la vitesse d'inférence par rapport au Xeon Gold, mais reste fonctionnel pour des modèles légers avec llama.cpp.

Les serveurs dédiés ElypseCloud sont hébergés en datacenter Equinix PA6 à Paris, avec connectivité réseau redondante. Pour les services d'inférence critiques qui exigent une haute disponibilité, combinez le serveur dédié avec une stratégie de sauvegardes et haute-disponibilité adaptée à votre charge.

Questions fréquentes

Peut-on faire de l'inférence LLM sur un serveur sans carte graphique ?

Oui. llama.cpp est conçu pour l'inférence sur CPU. Il exploite les instructions AVX-512 et VNNI des processeurs Intel Xeon pour accélérer les calculs sur des modèles quantifiés au format GGUF. Un serveur dédié avec suffisamment de RAM DDR4 ECC peut charger et exécuter des modèles de 7 à 70+ milliards de paramètres sans aucune carte graphique.

Quelle quantification GGUF choisir pour un serveur de production ?

Q4_K_M offre le meilleur rapport entre taille du fichier, qualité des réponses et vitesse d'inférence. C'est le choix par défaut pour la plupart des déploiements serveur. Q5_K_M et Q8_0 améliorent la qualité des réponses si la RAM installée sur le serveur dédié le permet. En dessous de Q4_K_M (Q3, Q2), la dégradation de qualité est perceptible et ces niveaux ne sont pas recommandés pour la production.

Combien de RAM faut-il pour un modèle 70 milliards de paramètres ?

En quantification Q4_K_M, un modèle 70B occupe environ 40 à 42 Go de RAM pour les poids, plus le cache KV qui varie avec la taille du contexte. Avec un contexte standard de 4 096 tokens, comptez environ 45 Go au total. La configuration SD3-G-128 (128 Go de RAM DDR4 ECC) offre une marge confortable pour le modèle, le système d'exploitation et un contexte étendu. La configuration SD2-G-64 (64 Go) fonctionne avec un contexte court, mais sans marge.

llama.cpp exploite-t-il les deux processeurs d'un serveur bi-socket ?

Oui, avec l'option --numa distribute ou via numactl. Si le modèle tient dans la RAM d'un seul socket (environ 64 Go sur un noeud NUMA de la configuration bi-processeur), le confiner sur un seul processeur avec numactl --cpunodebind=0 --membind=0 donne de meilleures performances en évitant les accès mémoire cross-socket. Réservez l'utilisation des deux sockets aux modèles trop volumineux pour un seul noeud NUMA.

Faut-il un GPU pour de l'inférence LLM en production ?

Cela dépend du débit attendu. Pour quelques requêtes par minute (chatbot interne, assistant de rédaction, résumé de documents à la demande), l'inférence CPU sur un serveur dédié Xeon suffit. Pour des centaines de requêtes par minute ou des temps de réponse inférieurs à la seconde, un GPU est nécessaire. ElypseCloud propose du housing GPU en datacenter pour les charges d'inférence qui dépassent les capacités du CPU.

Combien d'espace disque les modèles GGUF occupent-ils ?

La taille d'un fichier GGUF dépend du nombre de paramètres et du niveau de quantification. En Q4_K_M, un modèle 7B pèse environ 4 Go, un 13B environ 8 Go et un 70B environ 40 Go. Les serveurs dédiés Xeon Gold ElypseCloud incluent un SSD de 1 To, suffisant pour stocker plusieurs modèles et leurs différentes variantes de quantification.

Un serveur VPS suffit-il pour faire tourner un LLM ?

Pour un petit modèle (7-8B en Q4_K_M), un VPS avec 8 à 16 Go de RAM peut convenir en phase de test. En revanche, la couche de virtualisation d'un serveur virtuel peut masquer les instructions AVX-512, et la RAM plafonnée limite la taille des modèles chargeables. Pour de l'inférence en production ou des modèles au-delà de 13B, un serveur dédié bare metal avec accès root et RAM DDR4 ECC extensible est recommandé.

Conclusion

llama.cpp rend l'inférence LLM accessible sur un serveur dédié Intel Xeon, sans carte graphique et sans dépendance GPU. Le Xeon Gold 6230 apporte AVX-512 et VNNI pour accélérer les calculs sur les modèles quantifiés au format GGUF, et ses 40 coeurs physiques répartis sur deux sockets offrent une puissance de calcul exploitable pour l'inférence locale. Le choix de la configuration dépend du modèle visé : 32 ou 64 Go suffisent pour les modèles 7 à 30B, 128 Go ouvrent la porte aux modèles 70B en quantification standard, et 256 Go ou plus permettent les contextes longs et l'inférence multi-modèle.

Pour sécuriser votre serveur dédié avant de déployer un service d'inférence en production, consultez notre guide premiers réglages de sécurité sur serveur dédié. Et si vos besoins en inférence dépassent ce que le CPU peut offrir, notre offre de housing GPU accueille vos cartes graphiques en datacenter Equinix PA6 à Paris.