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

Pendant longtemps, llama.cpp présentait une limitation criante : vous ne pouviez servir qu’un seul modèle par processus, et changer de modèle 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 utilisateurs attendent des runtime LLM locaux modernes :

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

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

Si vous hésitez encore entre les runtime locaux, les API cloud et l’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 les drapeaux --models-preset ou --models-dir.

Pour les options d’installation (gestionnaire de paquets, binaires pré-construits ou compilation complète depuis les sources avec CUDA), consultez le 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 --models-preset ou --models-dir apparaît, vous êtes bon. S’ils sont absents, mettez à jour vers une version plus récente.

Mon output actuel pour 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 dispenseur de modèles.

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

• démarre sans aucun 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 chaud pour la prochaine requête

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 laissez le serveur décider quoi charger et quand, en fonction de ce que le client demande réellement.

Cela est important car cela signifie qu’un processus persistant peut servir une flotte entière de modèles, avec des clients sélectionnant celui qui convient pour chaque tâche — un modèle de codage, un modèle de chat, un modèle de résumé — sans aucune surcharge de coordination de votre côté.

Configuration : définir vos modèles

C’est là que les choses restent encore un peu brutes.

Il n’existe pas encore de format officiel entièrement 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 valeur ngl appropriée dépend de la VRAM disponible de votre GPU — pour la sélection du GPU et l’économie du matériel, 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 un 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 est en retard par rapport à l’implémentation

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

Utilisation de l’API : basculer les modèles sur demande

Une fois le serveur en cours d’exécution, le basculement des modèles se fait via l’API standard compatible OpenAI. Il 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 point de terminaison, 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 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")

# 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 en VRAM
3. l’inférence s’exécute
4. la prochaine requête détermine si qwen doit rester chargé ou être échangé à nouveau

Cela répond directement à la 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, 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 des modèles à leur 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-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

Au démarrage réussi, vous verrez des lignes indiquant que le serveur é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 basculement centralisé des modèles — aucune gestion manuelle de processus 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écrit la démarche générale.

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

Limitations que vous devez comprendre

Le mode routeur est genuinely utile, mais il implique des compromis dont vous devez être conscient avant de vous 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 basculement signifie un cycle complet de déchargement et de rechargement.

• le basculement signifie rechargement
• un pic de latence est inévitable
• sur 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 simultanément

Pas vraiment. Il prend en charge plusieurs définitions, 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 séparés.

Pour la consommation mesurée de VRAM et les tokens par seconde selon les tailles de modèles, 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 pour 16 Go de VRAM.

Pas de mise en cache intelligente

Contrairement à Ollama, qui maintient un pool chaud et évacue les modèles en fonction de la récurrence :

• il n’y a pas de stratégie d’évacuation automatique des modèles
• 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 seule requête 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 entrelace plusieurs modèles sera lente. Planifiez votre logique de routage client en conséquence — regroupez les requêtes par modèle whenever possible.

La configuration n’est pas stable

Le support INI existe et fonctionne dans les builds les plus récents, mais il n’est pas entièrement 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 le déploiement.

Llama.cpp vs Ollama : comparaison honnête

Prise de position

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

• un contrôle maximum sur les paramètres runtime par modèle
• une surcharge de processus minimale
• un accès direct aux drapeaux de llama.cpp sans couches d’abstraction
• une base hackable pour des outils personnalisés

Choisissez Ollama lorsque vous voulez :

• une expérience stable et polie
• le téléchargement et la gestion de version automatiques des modèles
• un maintien en vie et une évacuation intelligents sans configuration
• tout inclus dès le premier jour

Aucun n’est faux. Le choix dépend de ce que vous voulez gérer vous-même.

Si vous optez pour Ollama, la fiche de commandes Ollama CLI couvre les commandes quotidiennes. Pour une comparaison plus large incluant également vLLM, LM Studio et LocalAI, consultez comment les différents runtime locaux se comparent en 2026.

Llama.cpp vs llama-swap

llama-swap est un orchestrateur externe qui se place devant une ou plusieurs instances 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 d’inactivité configurable
• 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 donne 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 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 basculement 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, pas à l’avenir

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 dev ou les configurations mono-utilisateur

Pensées 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 il n’est pas terminé.

Aujourd’hui, il 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 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.

Lorsque vous devez libérer de la VRAM sans redémarrer — pour une course de benchmark, une fenêtre de maintenance ou un reset de développement propre — l’approche scriptable est de lister les modèles chargés et d’appeler le point de terminaison de déchargement pour chacun. Le modèle complet curl-and-jq est couvert dans Décharger tous les modèles du routeur llama.cpp sans redémarrer.

Dans les deux cas, vous obtenez un comportement semblable à Ollama, sans cacher la machinerie.