Runtimes d'inférence locale
artefact/quantification → moteur/backend → serveur/API/scheduler → client/template/parser/harness
Chaque couche peut changer qualité, mémoire, latence et outils. HTTP 200 ne prouve qu'une réponse.
| Runtime | Point de départ | Risque opérateur |
|---|---|---|
| llama.cpp | GGUF, CPU/GPU, offload, contrôle | paramètres, templates, conversion, tuning |
| Ollama | packages et API rapides | choix cachés et dérive des packages |
| LM Studio | découverte desktop et comparaison | valeurs GUI et variantes à enregistrer |
| vLLM | CUDA/Python, batching, débit | environnement, formats, mémoire/scheduler |
SGLang, MLX, Transformers, TensorRT-LLM et backends spécialisés peuvent gagner ; ce n'est pas un classement exhaustif.
Compatibilité et exemple
Fixer dépôt/revision/fichier, tokenizer/template/parser/stop, outils, contexte/KV/batch/offload, runtime et drivers. « Compatible OpenAI » ne garantit pas raisonnement, comptage, IDs d'outils, streaming, annulation ou erreurs.
Sur un GPU 16 Go et un utilisateur, commencer avec quantification supportée et contexte natif ; llama.cpp pour contrôle GGUF, Ollama/LM Studio pour comparaison rapide ; mesurer à concurrence 1 ; valider format avant intelligence ; choisir vLLM seulement si son batching/service résout une charge réelle. Un service 24 Go multi-client privilégie files, annulation, métriques et isolation.
Changer un facteur à la fois et rapporter médiane/queue, prompt/decode, pic mémoire, offload, acceptation et OOM. Des tokens/s sur prompts ou poids différents ne comparent pas les runtimes.
Écouter sur loopback, authentifier avant réseau, isoler secrets, limiter tailles, tester annulation et traiter modèles/templates comme supply chain.
Cette note favorise Linux et écosystèmes ouverts ; Apple, AMD, Windows, NPU, énergie, accessibilité et flotte exigent d'autres mesures. La documentation prouve le support, pas la performance réelle.