Mode routeur Llama-Server : basculement dynamique des modèles sans redémarrage

Pendant longtemps, llama.cpp avait une limitation flagrante :
vous ne pouviez servir qu’un seul modèle par processus, et changer de modèle nécessitait un redémarrage.

Cette ère est révolue.

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

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

En d’autres termes : un comportement similaire à Ollama, mais sans les roulettes.

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

Prérequis

Le mode routeur nécessite une version récente de llama-server — approximativement post-mi-2024. Les anciennes versions ne possèdent pas le drapeau --models.

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

Une fois llama-server installé, confirmez que votre build prend en charge le mode routeur :

llama-server --help | grep -i models

Si le drapeau --models apparaît, c’est bon. S’il est absent, mettez à jour vers une version plus récente.

Voici la 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 un dispatcheur de modèles.

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

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

L’idée clé

Vous ne lancez plus :

./llama-server -m model.gguf

Vous lancez :

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

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

Cela a de l’importance car cela signifie qu’un processus persistant peut servir une flotte entière de modèles, avec les clients sélectionnant le bon modèle par tâche — un modèle de codage, un modèle de chat, un modèle de résumés — sans aucun surcoût de coordination de votre côté.

Configuration : définition de vos modèles

C’est ici que les choses sont encore un peu brutes.

Il n’existe pas encore de format officiel totalement stable, mais les builds actuels 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 du 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 bonne valeur ngl dépend de la VRAM disponible de votre GPU — pour la sélection de GPU et l’économie matérielle, le guide du matériel de calcul est une référence utile. Pour surveiller la consommation VRAM en direct pendant le réglage, consultez les outils de surveillance GPU pour Linux.

Démarrage du serveur avec la configuration

./llama-server --models /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 répertorié comme un ID de modèle.

Une note sur la stabilité

L’interface de configuration INI évolue encore :

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

Ancrez-vous sur un commit spécifique de llama.cpp si vous avez besoin de reproductibilité entre les redémarrages.

Utilisation de l’API : basculement de modèles sur requête

Une fois le serveur en cours d’exécution, le basculement de modèles se fait via l’API standard compatible OpenAI. Il vous suffit de définir 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"}
    ]
  }'

Basculer vers un modèle différent — même endpoint, 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. Votre code client ne change pas — seul le champ model varie.

Exemple Python

Si vous utilisez le client Python openai :

from openai import OpenAI

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

# Utiliser le modèle de codage
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# Basculer vers le modèle de chat — même client, nom de modèle différent
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

Lorsqu’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 qwen doit rester chargé ou être remplacé

Cela répond directement à une question courante :

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

En chargeant dynamiquement les modèles par requête, et non en se liant au démarrage.

Service Systemd : configuration prête pour la production

Créer un utilisateur dédié et les 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 des modèles en place :

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 /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

Lors d’un démarrage réussi, vous verrez des lignes indiquant que le serveur écoute et que le registre des modèles a été chargé. Un rapide test de santé :

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

Vous avez maintenant un service persistant avec redémarrage automatique et basculement de modèles centralisé — sans gestion de processus manuelle requise. Si vous souhaitez appliquer le même modèle à d’autres binaires, héberger n’importe quel exécutable en tant que service Linux détaille l’approche générale.

Le drapeau --metrics de llama-server expose un endpoint 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 d’inférence LLM. Pour la configuration d’observabilité plus large, le guide d’observabilité couvre la pile complète.

Limitations à comprendre

Le mode routeur est véritablement utile, mais il vient avec des compromis dont vous devez être conscient avant de vous y fier en production.

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

Même si plusieurs modèles sont définis dans models.ini, un seul est résident en VRAM par travailleur à un moment donné. Le basculement implique un cycle complet de déchargement et de rechargement.

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

Cela répond à une autre question clé :

Est-ce que llama.cpp supporte le service de plusieurs modèles en même temps

Pas vraiment. Il supporte plusieurs définitions, pas une 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 séparés.

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

Pas de cache intelligent

Contrairement à Ollama, qui maintient un pool chaud et éviction les modèles en fonction de leur ancienneté :

• il n’y a pas de stratégie d’éviction automatique de modèle
• pas de pré-chauffage 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 déclenche un rechargement. C’est le coût fondamental de la proximité avec le matériel.

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 cohérente 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 autant que possible.

La configuration n’est pas stable

Le support INI existe et fonctionne dans la plupart des builds récents, mais il n’est pas totalement standardisé. Les drapeaux et les noms de paramètres ont changé entre les versions. Si vous mettez à jour llama-server, testez votre models.ini contre le nouveau build avant de déployer.

Llama.cpp vs Ollama : comparaison honnête

Point de vue personnel

Choisissez le mode routeur de llama.cpp lorsque vous voulez :

• un contrôle maximal sur les paramètres d’exécution par modèle
• un surcoût de processus minimal
• un accès direct aux drapeaux llama.cpp sans couches d’abstraction
• une base modifiable pour des outils personnalisés

Choisissez Ollama lorsque vous voulez :

• une expérience stable et soignée
• le téléchargement et la versionnement automatiques des modèles
• un maintien en vie intelligent et une éviction sans configuration
• une solution complète dès le premier jour

L’un n’est pas faux. Le choix dépend de combien vous voulez gérer vous-même.

Si vous optez pour Ollama, la feuille de triche CLI Ollama couvre les commandes quotidiennes. Pour une comparaison plus large incluant é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 de temporisation configurable
• il proxy la requête une fois que le modèle est prêt

Pour une configuration pratique, consultez le guide de 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 d’une instance de modèle n’affecte pas les autres. Il permet également à chaque modèle de s’exécuter avec des drapeaux llama-server totalement indépendants.

Utilisez-le si vous avez besoin :

• de meilleur contrôle du cycle de vie et d’isolation
• d’une logique de basculement plus intelligente avec des délais d’inactivité configurables
• d’une latence plus prévisible (chaque modèle a un processus chaud après le premier chargement)
• de stabilité de production aujourd’hui, pas é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 mono-utilisateur

Pensées finales

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

Il répond à une 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 seul processus qui peut traiter des requêtes pour tout un catalogue de modèles.

Mais ce n’est pas fini.

Aujourd’hui, c’est :

• assez puissant pour des charges de travail réelles
• prometteur comme fondation 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 grouper les requêtes par modèle, le mode routeur fonctionne bien aujourd’hui. Si vous avez besoin de fiabilité de niveau production et d’isolation par modèle, tournez-vous vers llama-swap pendant que l’implémentation native mûrit.

Dans les deux cas, vous obtenez un comportement similaire à Ollama, sans cacher la mécanique.