Runtimes d’inférence locale
Un déploiement local comprend au moins quatre couches distinctes :
Modifier n’importe quelle couche peut altérer la qualité, la mémoire, la latence ou le comportement des outils. Un code HTTP 200 prouve seulement qu’une requête a abouti.
Carte des runtimes
SGLang, Transformers, MLX, 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.
Seuil 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, 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.
Les API compatibles OpenAI standardisent un sous-ensemble utile de la forme des requêtes. Elles ne garantissent pas des champs de raisonnement identiques, 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 et un utilisateur interactif :
- commencez avec un artefact quantifié pris en charge et le contexte natif ;
- 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 ;
- mesurez le temps jusqu’au premier jeton et la vitesse de décodage à une concurrence de 1 ;
- vérifiez le formatage des discussions et des outils avant de juger de l’intelligence ;
- 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.
Pour un service multi-clients actif en continu sur 24 Go, le débit, la mise en file d’attente, l’annulation, les métriques et l’isolation peuvent l’emporter sur la commodité bureautique. Il s’agit d’une distinction liée à la charge de travail, et non d’une affirmation selon laquelle un moteur produirait toujours de meilleurs jetons.
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 peuvent être appelés via localhost:11434. Pour une exécution exclusivement locale, utilisez un modèle local téléchargé et désactivez les fonctions cloud avec OLLAMA_NO_CLOUD=1, puis redémarrez Ollama. 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.
Liez par défaut au bouclage local (loopback), ajoutez une authentification avant toute exposition réseau, isolez les identifiants de service de modèles, examinez la télémétrie, plafonnez la taille des requêtes/du contexte/des sorties et testez l’annulation. Traitez 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é.
Registre de biais
Cette note privilégie les workflows de développement de type Linux et les écosystèmes ouverts populaires. Apple Silicon, AMD, Windows, les NPU mobiles, la consommation d’énergie, l’accessibilité et les opérations de parcs en production nécessitent des mesures distinctes. La documentation officielle des runtimes établit les fonctionnalités prises en charge ; les affirmations de performance nécessitent le matériel et la charge réels.