llama-server : une API OpenAI locale avec llama.cpp (sans Ollama)

#Pourquoi llama-server ?

Ollama, LM Studio ou Jan reposent tous sur le même moteur en dessous : llama.cpp. Ce moteur embarque son propre serveur HTTP, llama-server, qui n'a besoin d'aucune de ces couches. Vous pointez un fichier GGUF, vous obtenez une API et une interface web. Rien de plus.

L'intérêt n'est pas cosmétique. Là où Ollama décide pour vous du nombre de layers envoyés au GPU, de la taille du contexte et de la façon de découper le modèle, llama-server expose chaque paramètre en ligne de commande. Vous voyez et vous réglez ce qui se passe. C'est le mode « manuel » de l'IA locale — plus verbeux, mais sans boîte noire.

API OpenAI-compatible

Endpoints /v1/chat/completions, /v1/completions, /v1/models, /v1/embeddings. N'importe quel client OpenAI s'y branche sans modification.

Contrôle de l'offloading

--n-gpu-layers fixe précisément combien de couches partent en VRAM. Indispensable quand le modèle dépasse votre carte.

Interface web intégrée

Un chat servi directement à la racine du serveur, sans installer Open WebUI ni Docker.

Zéro dépendance lourde

Un seul binaire (quelques dizaines de Mo). Ni Python, ni conteneur, ni service système obligatoire.

Batching et parallélisme

Continuous batching activé par défaut, plusieurs requêtes simultanées via des slots.

#Prérequis

Un fichier GGUF

Le format de llama.cpp. Récupérable sur Hugging Face, ou téléchargé directement par llama-server via -hf (voir plus bas).

De la VRAM ou de la RAM

En Q4_K_M, comptez ≈2 Go pour un 3B, ≈5 Go pour un 7B, ≈9 Go pour un 14B, ≈19 Go pour un 32B, ≈40 Go pour un 70B.

Un GPU (fortement conseillé)

RTX 3060 12 Go pour démarrer, RTX 4070/4080 en milieu de gamme, RTX 4090 24 Go ou Mac M4 Pro pour les gros modèles. Le CPU seul fonctionne, mais lentement.

Un terminal

llama-server se pilote en ligne de commande. Rien d'insurmontable, mais ce n'est pas une appli à double-clic comme LM Studio.

#1. Obtenir llama-server

Trois voies, de la plus rapide à la plus performante. Sur macOS, Homebrew installe le binaire en une commande :

brew install llama.cpp

# le binaire s'appelle llama-server
llama-server --version

Sur Windows et Linux, le plus simple est de récupérer un binaire précompilé depuis les releases GitHub officielles de llama.cpp (choisissez la variante correspondant à votre matériel : CUDA pour NVIDIA, Vulkan pour un GPU générique, ou CPU).

https://github.com/ggml-org/llama.cpp/releases

Pour le maximum de tokens/seconde, compilez depuis les sources avec le backend de votre GPU. Exemple pour NVIDIA avec CUDA :

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# le binaire se trouve dans build/bin/
./build/bin/llama-server --version

#2. Lancer sur un GGUF en une commande

La commande minimale pointe un modèle et démarre le serveur. Ici, un Qwen2.5 7B en Q4_K_M avec toutes les couches envoyées au GPU :

llama-server -m ./qwen2.5-7b-instruct-q4_k_m.gguf -ngl 99 -c 8192

-m

Chemin vers le fichier GGUF à servir.

-ngl 99

Nombre de couches offloadées sur le GPU. 99 = « toutes » (le modèle en a moins, le surplus est ignoré sans erreur).

-c 8192

Taille du contexte en tokens. Par défaut c'est souvent 4096 ; adaptez selon vos besoins et votre VRAM.

Vous n'avez pas le fichier sous la main ? llama-server peut le télécharger directement depuis Hugging Face et le mettre en cache, façon ollama pull mais intégré :

llama-server -hf bartowski/Qwen2.5-7B-Instruct-GGUF:Q4_K_M -ngl 99 -c 8192

Une fois lancé, le serveur écoute par défaut sur http://127.0.0.1:8080. Vérifiez qu'il est vivant :

curl http://localhost:8080/health
# {"status":"ok"}

#3. L'API OpenAI-compatible : brancher n'importe quelle app

C'est l'argument massue de llama-server. Il parle le protocole d'OpenAI, donc tout outil conçu pour l'API OpenAI fonctionne en changeant simplement l'URL de base. Un appel chat direct en curl :

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local",
    "messages": [
      {"role": "system", "content": "Tu réponds en français, de façon concise."},
      {"role": "user", "content": "Explique le format GGUF en une phrase."}
    ],
    "temperature": 0.7
  }'

Le champ model est libre : llama-server ne sert qu'un modèle à la fois et ignore largement cette valeur. Côté SDK Python d'OpenAI, il suffit de rediriger base_url vers votre serveur. La clé API peut être n'importe quelle chaîne si vous n'avez pas fixé --api-key :

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="sk-no-key-required",
)

resp = client.chat.completions.create(
    model="local",
    messages=[
        {"role": "user", "content": "Donne-moi trois idées de noms pour un projet open source."}
    ],
)
print(resp.choices[0].message.content)

/v1/chat/completions

Le mode conversation, avec application automatique du template de chat du modèle.

/v1/completions

Complétion brute de texte, sans mise en forme de rôles.

/v1/models

Liste le modèle chargé — utile pour les clients qui interrogent d'abord les modèles disponibles.

/v1/embeddings

Génère des embeddings si le serveur est lancé avec --embedding (pratique pour un RAG maison).

#4. n-gpu-layers : l'offloading fin qu'Ollama cache

Un modèle est une pile de couches (layers). Chaque couche envoyée en VRAM est calculée par le GPU, très vite ; celles qui restent en RAM sont calculées par le CPU, lentement. --n-gpu-layers (ou -ngl) décide combien de couches partent sur le GPU. C'est le réglage le plus important pour la vitesse.

-ngl 99

Tout sur le GPU. À viser si le modèle tient entièrement dans la VRAM. Vitesse maximale.

-ngl 20

Offloading partiel : 20 couches sur le GPU, le reste sur le CPU. Le compromis quand le modèle dépasse la VRAM.

-ngl 0

Tout sur le CPU. Lent, mais permet de faire tourner un modèle bien plus gros que votre carte.

La stratégie : monter -ngl le plus haut possible sans saturer la VRAM. Un 14B en Q4 (≈9 Go) tient entièrement sur une RTX 3060 12 Go avec -ngl 99. Un 32B (≈19 Go) ne rentre pas ; sur cette même carte, on offloade partiellement — par exemple -ngl 40 — et on accepte un ralentissement.

# 32B Q4 sur un GPU 12 Go : une partie sur GPU, le reste sur CPU
llama-server -m ./qwen2.5-32b-instruct-q4_k_m.gguf -ngl 40 -c 4096

Pour surveiller ce qui tient réellement en VRAM pendant le chargement, gardez un œil sur nvidia-smi dans une autre fenêtre :

nvidia-smi -l 1

#5. L'interface web incluse

Pas besoin d'Open WebUI ni de Docker pour discuter : llama-server sert une interface de chat directement à sa racine. Ouvrez simplement l'adresse du serveur dans un navigateur.

http://localhost:8080

Vous y trouverez un chat complet : historique de conversation, réglage de la température et des paramètres d'échantillonnage, système de prompt système, et rendu markdown. C'est suffisant pour un usage personnel quotidien, sans installer la moindre couche supplémentaire.

#Quand préférer llama-server à Ollama (et quand rester)

llama-server et Ollama font tourner le même moteur. Le choix est une question de contrôle contre confort.

Choisissez llama-server

Quand vous voulez régler finement l'offloading, tester un GGUF précis d'un quantizeur donné, éviter un daemon permanent, ou déployer un binaire unique sans dépendances sur un serveur.

Choisissez llama-server

Quand un modèle dépasse votre VRAM : le contrôle direct de -ngl et des options mémoire fait la différence entre « injouable » et « lent mais fonctionnel ».

Restez sur Ollama

Quand vous voulez jongler entre plusieurs modèles à la volée sans relancer de processus, gérer une bibliothèque avec ollama pull/list, ou charger/décharger automatiquement selon la demande.

Restez sur Ollama

Quand plusieurs applications ciblent des modèles différents sur le même port 11434 : Ollama route et swappe pour vous, là où llama-server est mono-modèle par processus.

#Dépannage

« CUDA out of memory » au chargement

Votre -ngl est trop élevé pour la VRAM. Baissez-le (offloading partiel), réduisez -c, ou passez à une quantization plus légère (Q4_K_M au lieu de Q5/Q8).

Le GPU n'est pas utilisé

Le binaire est peut-être la variante CPU. Vérifiez que vous utilisez un build CUDA/Metal/Vulkan et que -ngl est supérieur à 0. nvidia-smi doit montrer de la VRAM occupée.

Réponses incohérentes ou balises visibles

Le template de chat n'est pas appliqué. Relancez avec --jinja pour utiliser le template embarqué dans le GGUF.

L'app cliente ne trouve pas le modèle

Certains clients interrogent /v1/models d'abord. Donnez un alias avec -a et renseignez ce nom exact dans le champ model de votre application.

Contexte tronqué / réponses coupées

-c est trop petit. Augmentez la taille du contexte, en gardant à l'esprit qu'un grand contexte consomme davantage de VRAM.

#Pour aller plus loin

llama-server tire tout son intérêt d'un llama.cpp bien compilé et d'un GGUF bien choisi. Ces guides du site complètent la mise en place :

Compiler llama.cpp avec CUDA

Pour un binaire optimisé NVIDIA et le maximum de tokens/seconde sur votre carte.

Q4, Q5, Q8 : quelle quantification choisir

Pour arbitrer entre qualité, vitesse et VRAM avant de télécharger un GGUF.

llama.cpp vs vLLM vs Exllama

Pour situer llama-server face aux autres moteurs d'inférence selon vos besoins de débit.