Mode routeur de Llama-Server – Basculement dynamique de modèle sans redémarrage

Pendant longtemps, llama.cpp présentait une limite flagrante : vous ne pouviez servir qu’un modèle par processus, et le changement impliquait un redémarrage.

Cette époque est révolue.

Les mises à jour récentes ont introduit le mode routeur dans llama-server, apportant quelque chose de beaucoup plus proche de ce que les gens attendent des temps d’exécution modernes de LLM locaux :

• chargement dynamique des modèles
• déchargement à la demande
• changement par requête
• aucun redémarrage du processus

En d’autres termes : un comportement semblable à Ollama, mais sans les roues de secours.

Si vous hésitez encore entre les temps d’exécution locaux, les API cloud et l’infrastructure auto-hébergée, la vision d’ensemble de l’hébergement de LLM est un bon point de départ.

Prérequis

Le mode routeur nécessite une version récente de llama-server — environ postérieure à la mi-2024. Les versions plus anciennes ne disposent pas des drapeaux --models-preset ou --models-dir.

Pour les options d’installation (gestionnaire de paquets, binaires pré-construits, ou compilation complète depuis le code source avec CUDA), consultez le démarrage rapide de llama.cpp.

Une fois que vous avez llama-server, confirmez que votre version prend en charge le mode routeur :

llama-server --help | grep -i models

Si --models-preset ou --models-dir apparaît, vous êtes paré. S’ils sont absents, mettez à jour vers une version plus récente.

Ma sortie actuelle de l’aide relative aux modèles :

-cl,   --cache-list                     show list of models in cache
                                        Prefix/Suffix/Middle) as some models prefer this. (default: disabled)
                                        models with dynamic resolution (default: read from model)
                                        models with dynamic resolution (default: read from model)
                                        embedding models (default: disabled)
--models-dir PATH                       directory containing models for the router server (default: disabled)
                                        (env: LLAMA_ARG_MODELS_DIR)
--models-preset PATH                    path to INI file containing model presets for the router server
                                        (env: LLAMA_ARG_MODELS_PRESET)
--models-max N                          for router server, maximum number of models to load simultaneously
                                        (env: LLAMA_ARG_MODELS_MAX)
--models-autoload, --no-models-autoload
                                        for router server, whether to automatically load models (default:
                                        (env: LLAMA_ARG_MODELS_AUTOLOAD)

Ce que fait réellement le mode routeur

Le mode routeur transforme llama-server en dispatcheur de modèles.

Au lieu de se lier à un modèle unique via -m, le serveur :

• démarre sans modèle chargé
• reçoit une requête nommant un modèle
• charge ce modèle s’il n’est pas déjà en mémoire
• exécute l’inférence
• décharge le modèle après la réponse, ou le garde chaud pour la requête suivante, le cas échéant

L’idée clé

Vous n’exécutez plus :

./llama-server -m model.gguf

Vous exécutez :

./llama-server --models-preset models.ini --port 8080

Et vous laissez le serveur décider quoi charger et quand, en se basant sur ce que le client demande réellement.

C’est important car cela signifie qu’un processus persistant unique peut servir une flotte entière de modèles, avec des clients sélectionnant le bon modèle pour chaque tâche — un modèle de codage, un modèle de discussion, un modèle de résumé — sans aucun surcoût de coordination de votre côté.

Configuration : définir vos modèles

C’est là que les choses sont encore un peu rugueuses.

Il n’existe pas encore de format officiel entièrement stable, mais les versions actuelles prennent en charge les définitions de modèles de style INI via un fichier de configuration.

Exemple de models.ini

[llama3]
model = /opt/models/llama-3-8b-instruct.Q5_K_M.gguf
ctx-size = 8192
ngl = 35
threads = 8

[mistral]
model = /opt/models/mistral-7b-instruct-v0.3.Q4_K_M.gguf
ctx-size = 4096
ngl = 20
threads = 8

[qwen]
model = /opt/models/qwen2.5-coder-7b-instruct.Q5_K_M.gguf
ctx-size = 16384
ngl = 35
threads = 8

Chaque nom de section devient l’identifiant de modèle que les clients utilisent dans le champ "model" de leurs requêtes API.

Paramètres de configuration clés

Le choix de la valeur ngl correcte dépend de la VRAM disponible sur votre GPU — pour la sélection du GPU et l’économie matérielle, le guide du matériel de calcul est une référence utile. Pour surveiller la consommation de VRAM en direct pendant le réglage, consultez les outils de surveillance GPU pour Linux.

Démarrer le serveur avec la configuration

./llama-server --models-preset /opt/llama.cpp/models.ini --port 8080

Confirmez que le serveur a démarré correctement :

curl http://localhost:8080/v1/models | jq '.data[].id'

Vous devriez voir chaque nom de section de votre models.ini listé comme identifiant de modèle.

Une note sur la stabilité

L’interface de configuration INI est toujours en évolution :

• les drapeaux peuvent changer entre les commits
• certains paramètres ne sont reconnus que par des configurations de build spécifiques
• la documentation accuse un retard par rapport à l’implémentation

Épinglez à un commit spécifique de llama.cpp si vous avez besoin de reproductibilité entre les redémarrages.

Utilisation de l’API : changer de modèle par requête

Une fois le serveur en marche, le changement de modèle se fait via l’API compatible OpenAI standard. Vous réglez simplement le champ "model".

Lister les modèles enregistrés

curl http://localhost:8080/v1/models

Requête de complétion — premier modèle

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Explain router mode in one paragraph"}
    ]
  }'

Passer à un modèle différent — même point d’accès, même port

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen",
    "messages": [
      {"role": "user", "content": "Write a Python function that reads a CSV file"}
    ]
  }'

Le serveur gère le cycle de déchargement/chargement de manière transparente. Le code de votre client ne change pas — seul le champ model change.

Exemple en Python

Si vous utilisez le client Python openai :

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8080/v1", api_key="not-needed")

# Use the coding model
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# Switch to the chat model — same client, different model name
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "What is the capital of Australia?"}],
)
print(response.choices[0].message.content)

Ce qui se passe en interne

Quand une requête arrive pour qwen et que llama3 est actuellement chargé :

1. llama3 est déchargé de la VRAM
2. les poids de qwen sont lus depuis le disque et chargés dans la VRAM
3. l’inférence s’exécute
4. la requête suivante détermine si l’on garde qwen chargé ou si l’on effectue un autre échange

Cela répond directement à une question courante :

Comment un serveur LLM local peut-il changer de modèles sans redémarrer

En chargeant dynamiquement les modèles par requête, plutôt qu’en se liant au démarrage.

Service Systemd : configuration prête pour la production

Créer un utilisateur dédié et des répertoires

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/llama.cpp llm
sudo mkdir -p /opt/llama.cpp/models
sudo chown -R llm:llm /opt/llama.cpp

Copiez votre binaire et la configuration du modèle à l’endroit prévu :

sudo cp build/bin/llama-server /opt/llama.cpp/
sudo cp models.ini /opt/llama.cpp/

/etc/systemd/system/llama-server.service

[Unit]
Description=Llama.cpp Router Server
After=network.target

[Service]
Type=simple
User=llm
WorkingDirectory=/opt/llama.cpp
ExecStart=/opt/llama.cpp/llama-server --models-preset /opt/llama.cpp/models.ini --port 8080
Restart=always
RestartSec=5

Environment=LLAMA_LOG_LEVEL=info

[Install]
WantedBy=multi-user.target

Activer et démarrer

sudo systemctl daemon-reload
sudo systemctl enable llama-server
sudo systemctl start llama-server

Vérifier et inspecter les journaux

sudo systemctl status llama-server

journalctl -u llama-server -f

En cas de démarrage réussi, vous verrez des lignes indiquant que le serveur est à l’écoute et que le registre des modèles a été chargé. Une vérification rapide de bon sens :

curl -s http://localhost:8080/v1/models | jq '.data[].id'

Vous avez maintenant un service persistant avec redémarrage automatique et changement de modèle centralisé — aucune gestion manuelle des processus n’est requise. Si vous souhaitez appliquer le même schéma à d’autres binaires, hberger un exécutable quelconque en tant que service Linux décrit l’approche générale.

Le drapeau --metrics de llama-server expose un point d’accès compatible Prometheus. Pour les tableaux de bord spécifiques à llama.cpp, les requêtes PromQL et les règles d’alerte, consultez le guide de surveillance de l’inférence LLM. Pour la configuration de surveillance plus large, le guide de la visibilité (observability) couvre la pile complète.

Limitations que vous devez comprendre

Le mode routeur est réellement utile, mais il comporte des compromis dont il faut être conscient avant de s’y fier en production.

Un seul modèle en mémoire à la fois

Bien que plusieurs modèles soient définis dans models.ini, un seul est résident en VRAM par travailleur à un moment donné. Le changement implique un cycle complet de déchargement et de rechargement.

• le changement signifie recharger
• un pic de latence est inévitable
• pour un modèle 7B typique en Q5, un rechargement peut prendre 3 à 10 secondes selon la vitesse du disque et la bande passante de la VRAM

Cela répond à une autre question clé :

llama.cpp prend-il en charge le service de plusieurs modèles à la fois

Pas vraiment. Il prend en charge plusieurs définitions, mais pas la résidence simultanée. Si vous avez besoin de deux modèles réellement chargés en parallèle, vous avez besoin de deux processus sur deux GPU distincts.

Pour la consommation de VRAM mesurée et les tokens par seconde à travers différentes tailles de modèles, les benchmarks de performance LLM couvrent le tableau complet. Pour les chiffres spécifiques à llama.cpp sur un GPU de 16 Go — modèles denses et MoE à plusieurs tailles de contexte — consultez les benchmarks llama.cpp pour 16 Go de VRAM.

Pas de mise en cache intelligente

Contrairement à Ollama, qui maintient un pool chaud et éjecte les modèles en se basant sur la récence :

• il n’y a pas de stratégie automatique d’éjection de modèles
• pas de pré-échauffement en arrière-plan
• pas de file d’attente prioritaire pour les modèles fréquemment utilisés

Si vous envoyez des requêtes alternées pour llama3 et mistral, chaque requête individuelle déclenche un rechargement. C’est le coût fondamental d’être plus proche du métal.

La latence est imprévisible pour les charges de travail mixtes

Une charge de travail bien comportée qui utilise un modèle de manière constante sera rapide. Une charge de travail qui intercale plusieurs modèles sera lente. Planifiez votre logique de routage client en conséquence — groupez les requêtes par modèle lorsque c’est possible.

La configuration n’est pas stable

La prise en charge INI existe et fonctionne dans la plupart des versions récentes, mais elle n’est pas entièrement standardisée. Les drapeaux et les noms des paramètres ont changé entre les versions. Si vous mettez à jour llama-server, testez votre models.ini contre la nouvelle version avant le déploiement.

Llama.cpp vs Ollama

Le mode routeur réduit l’ancien écart de cycle de vie avec Ollama — le chargement dynamique et le changement par requête existent désormais nativement dans llama-server — mais ne le comble pas. La gestion de la mémoire reste basique (pas de politique d’éjection, pas de pool chaud), la stabilité de la configuration est toujours expérimentale, et le changement entre deux modèles différents paie toujours un déchargement et rechargement complet, plutôt que le maintien en vie basé sur la durée de vie (TTL) d’Ollama. En résumé : le mode routeur vous offre un contrôle maximal et une base modifiable ; Ollama vous offre une expérience plus soignée et plus orientée, avec moins de configuration.

Pour la décomposition par paire complète — installation, gestion des modèles, placement GPU, contrôle du cache KV, API, performance, modes de défaillance et déclencheurs concrets pour choisir l’un ou migrer entre eux — consultez llama.cpp vs Ollama en 2026, qui est la comparaison canonique entre les deux temps d’exécution sur ce site.

Si vous optez pour Ollama, la fiche de commandes du CLI Ollama couvre les commandes au quotidien. Pour une comparaison plus large qui inclut également vLLM, LM Studio et LocalAI, consultez comment les différents temps d’exécution locaux se comparent en 2026.

Llama.cpp vs llama-swap

llama-swap est un orchestrateur externe qui se place devant une ou plusieurs instances de llama-server :

• il intercepte les requêtes et inspecte le champ model
• il démarre le processus llama-server approprié pour ce modèle
• il arrête les instances inactives après un délai configuré
• il proxy la requête une fois le modèle prêt

Pour une configuration pratique, consultez le démarrage rapide de llama-swap.

Différence clé

Quand utiliser llama-swap

llama-swap vous offre une isolation au niveau du processus par modèle, ce qui signifie qu’un plantage dans une instance de modèle n’affecte pas les autres. Il permet également à chaque modèle de fonctionner avec des drapeaux llama-server complètement indépendants.

Utilisez-le si vous avez besoin de :

• un meilleur contrôle du cycle de vie et de l’isolation
• une logique de changement plus intelligente avec des délais d’inactivité configurables
• une latence plus prévisible (chaque modèle a un processus chaud après le premier chargement)
• une stabilité de production aujourd’hui, et non éventuellement

Quand le mode routeur natif suffit

Utilisez le routeur intégré si vous voulez :

• zéro dépendance externe
• un seul processus à gérer
• un déploiement plus simple (un binaire, un fichier de configuration)
• une pile minimale pour le développement ou les configurations monousers

Réflexions finales

Le mode routeur est une avancée significative pour llama-server.

Il répond à la demande de longue date :

Qu’est-ce que le mode routeur dans le serveur llama.cpp

C’est la couche manquante qui transforme un binaire statique en un service d’inférence dynamique — un processus qui peut traiter les requêtes pour tout un catalogue de modèles.

Mais ce n’est pas terminé.

Aujourd’hui, il est :

• suffisamment puissant pour des charges de travail réelles
• prometteur comme fondement pour un routage plus sophistiqué
• légèrement rugueux sur les bords de la configuration et de la stabilité

Si votre charge de travail est prévisible et que vous pouvez regrouper les requêtes par modèle, le mode routeur fonctionne bien aujourd’hui. Si vous avez besoin d’une fiabilité de niveau production et d’une isolation par modèle, tournez-vous vers llama-swap pendant que l’implémentation native mûrit.

Quand vous avez besoin de libérer de la VRAM sans redémarrer — pour une exécution de benchmark, une fenêtre de maintenance, ou un réinitialisation propre de développement — l’approche scriptable consiste à lister les modèles chargés et à appeler le point d’accès de déchargement pour chacun d’eux. Le motif complet curl-et-jq est couvert dans Décharger tous les modèles routeur llama.cpp sans redémarrer.

Dans tous les cas, vous obtenez un comportement semblable à Ollama, sans masquer le mécanisme.