Runtimes d’inférence locale

Un code HTTP 200 prouve seulement qu’une requête a abouti, pas que la réponse est juste. Un modèle local passe par au moins quatre couches distinctes, et modifier n’importe laquelle peut altérer la qualité, la mémoire, la latence ou le comportement des outils :

Avant de comparer des runtimes, il faut donc figer ce que chaque couche utilise ; c’est le rôle de la liste de compatibilité ci-dessous.

Carte des runtimes

Runtime/produit	Point de départ solide	Risque principal porté par l’opérateur
llama.cpp	GGUF, portabilité CPU/GPU, délestage hybride, contrôle bas niveau	options de ligne de commande, templates, provenance des conversions et réglages du backend
Ollama	gestion de paquets de modèles locaux et API	dérive des artefacts/templates ; les modèles cloud ne tournent pas sur la machine locale (voir la section Sécurité)
LM Studio	découverte sur poste de travail, comparaison interactive, API locale compatible ; GGUF via llama.cpp sur les trois systèmes, plus les modèles MLX sur Apple Silicon	les paramètres par défaut de l’interface graphique et les variantes téléchargées doivent être consignés
MLX / mlx-lm	sur Apple Silicon, le CPU et le GPU partagent un même réservoir de mémoire, les poids ne sont donc pas copiés ; Ollama et LM Studio peuvent tous deux l’utiliser comme backend	Apple Silicon uniquement ; les fichiers MLX et GGUF sont deux quantifications distinctes, non interchangeables
vLLM	service CUDA/Python, traitement par lots continu (continuous batching), débit, API compatible	environnement plus lourd, prise en charge des artefacts, réglage du planificateur et de la mémoire

SGLang, Transformers, TensorRT-LLM, les runtimes spécifiques à ROCm et ceux des constructeurs peuvent être plus adaptés à un besoin mesuré. Ce tableau n’est pas un classement exhaustif.

Changements récents qui affectent le contrôle de compatibilité

Vérifié le 29 octobre 2026 d’après les notes de version de chaque projet. Seulement les trois changements qui modifient la façon d’installer ou d’appeler un runtime :

• Ollama 0.40.0 (25 septembre) exécute automatiquement sur MLX, sur Apple Silicon, les architectures de modèle que MLX prend en charge. Les notes de version citent qwen3.8, gemma4 et qwen3.6 en exemple. La dernière version au 28 octobre est la 0.40.13. Un même nom de modèle peut passer par des backends différents sur un Mac et sur une machine NVIDIA : notez donc quel backend a servi chaque exécution.
• vLLM 0.32.0 (18 octobre) abandonne Python 3.10 et ne réserve plus max_tokens sur la fenêtre de contexte. La 0.31.0 (5 octobre) a remplacé la quantification en ligne via quantization="fp8" par le raccourci fp8_per_tensor : les anciens scripts de lancement sont à modifier.
• SGLang 0.5.22 (19 octobre) exige Python 3.11 ou plus récent.

Contrôle de compatibilité

Avant toute évaluation, figez :

• le dépôt exact du modèle, la révision, le nom de fichier et la quantification ;
• le tokenizer, le template de discussion, le format/parseur de raisonnement et les jetons d’arrêt ;
• le format d’appel d’outil et le comportement de sortie structurée ;
• le contexte natif/étendu, la longueur de contexte réellement réglée, le type de cache KV, les paramètres de lot/concurrence et le délestage GPU ;
• les versions du runtime et du pilote, vérifiées selon les exigences matérielles officielles d’Ollama, de LM Studio ou de vLLM.

« La longueur de contexte réellement réglée » est l’élément le plus souvent oublié. Ollama utilise par défaut une fenêtre de contexte de 4096 tokens ; le prompt système d’un agent de code plus quelques fichiers la dépassent, et ce qui ne tient pas n’atteint jamais le modèle. Augmentez-la avec la variable d’environnement OLLAMA_CONTEXT_LENGTH ou num_ctx dans la requête, puis vérifiez avec le budget mono-appareil que le cache tient. Dans llama.cpp, -c vaut 0 par défaut, ce qui signifie la longueur enregistrée dans le modèle (documentation du serveur).

Les API compatibles OpenAI standardisent un sous-ensemble utile de la forme des requêtes. Elles ne garantissent pas un comportement identique pour les champs de raisonnement, le décompte des jetons, les identifiants d’outils, les fragments de flux (streaming chunks), les probabilités logarithmiques (logprobs), l’annulation ou les erreurs.

Choix guidé

Pour un GPU grand public de 16 Go ou un Mac Apple Silicon et un utilisateur interactif :

1. commencez avec un artefact quantifié pris en charge et le contexte natif ;
2. utilisez llama.cpp lorsque le contrôle exact du format GGUF et du délestage est essentiel, ou Ollama/LM Studio pour la comparaison manuelle la plus rapide. Sur un Mac, essayez d’abord la version MLX du modèle, puis comparez le GGUF de même taille ;
3. mesurez le temps jusqu’au premier jeton et la vitesse de décodage à une concurrence de 1 ;
4. vérifiez le formatage des discussions et des outils avant de juger de l’intelligence ;
5. ne passez à vLLM que si son artefact pris en charge et ses avantages en matière de traitement par lots/service résolvent une véritable charge de travail.

Un service multi-clients actif en continu sur 24 Go relève d’une petite équipe : le débit, la file d’attente, l’annulation et l’isolation l’emportent sur la commodité bureautique. Choisissez un serveur à traitement continu par lots comme vLLM ou SGLang, et mesurez le p95 du temps jusqu’au premier jeton et de l’intervalle entre jetons à concurrence fixe. Vérifiez que la génération s’arrête vraiment quand un client se déconnecte, et configurez l’authentification et les limites de taille des requêtes avant d’ouvrir le port.

Pour le décodage spéculatif, vérifier la compatibilité entre modèle de proposition et modèle cible avant de comparer latence, débit et mémoire à charge et qualité équivalentes.

Passage au protocole d’évaluation

Cette page traite la compatibilité des runtimes, les choix de service et les risques opérationnels. Le protocole commun d’évaluation des modèles locaux contient les fiches d’exécution, les changements contrôlés, les mesures de latence, de débit et de mémoire, le taux de résultats acceptés et les tâches répétées.

Sécurité et opérations

Lorsque la localisation des données compte, distinguez le serveur local du lieu d’exécution du modèle choisi. Les modèles cloud d’Ollama s’appellent dans la CLI et l’application de bureau par des noms comme gemma4:cloud ; ils ne demandent aucun téléchargement et l’inférence s’exécute dans le cloud d’Ollama. La documentation indique qu’Ollama traite les prompts et réponses cloud, mais ne s’en sert pas pour entraîner des modèles. Pour une exécution exclusivement locale, utilisez seulement des modèles locaux téléchargés et désactivez les fonctions cloud. Définissez OLLAMA_NO_CLOUD=1, ou mettez "disable_ollama_cloud": true dans ~/.ollama/server.json. Après le redémarrage d’Ollama, le journal doit afficher Ollama cloud disabled: true. Cela désactive les modèles cloud et la recherche web d’Ollama, pas les outils externes d’un autre harness ; ce n’est pas un bac à sable réseau.

• Liaison réseau : Ollama écoute par défaut sur 127.0.0.1:11434 ; ajoutez une authentification avant de changer l’adresse avec OLLAMA_HOST ;
• Identifiants : donnez au serveur de modèles sa propre clé, partagée avec aucun autre service et absente de tout dépôt ou journal lisible par le harness ;
• Télémétrie : identifiez les données d’usage que le runtime et le client envoient à l’extérieur, et désactivez ce dont vous n’avez pas besoin ;
• Limites de ressources : plafonnez la taille de chaque requête, de son contexte et de sa sortie ;
• Annulation : après la déconnexion d’un client, vérifiez que le serveur arrête vraiment de générer et n’occupe plus le GPU ;
• Chaîne logistique : auditez les fichiers de modèles et les templates comme des entrées de chaîne logistique logicielle.

Ne laissez pas un point de terminaison compatible devenir un proxy réseau interne non audité.

Mes lectures