Un modèle peut charger correctement, répondre sans erreur et quand même produire un benchmark faux.
Model Serving Minefield essaie de documenter précisément cette catégorie de problème. Le dépôt recense actuellement 116 pièges rencontrés dans des chemins de serving LLM : templates de chat, champs de raisonnement, parsers d’outils, quantification, images de conteneurs, mémoire, harness d’évaluation ou version exacte des poids.
Le point commun est pénible : tout a l’air normal jusqu’au chiffre final.
Le registre part du symptôme
Au lieu de classer uniquement par bibliothèque, chaque entrée commence par ce que l’utilisateur voit. Par exemple : un taux de raisonnement à 0 % alors que le modèle raisonne visiblement, un </think> orphelin, un modèle « FP4 » beaucoup plus lent que prévu, ou un serveur qui charge puis meurt au premier token.
Chaque cas indique ensuite un mécanisme probable, les stacks concernées, un test de confirmation et un statut de preuve. Le projet distingue ce qu’il a reproduit lui-même, ce qu’un contributeur a mesuré, ce qui est seulement rapporté ailleurs et ce qui reste en cours de test.
Cette séparation est probablement plus importante que le nombre 116. Un bug observé sur une machine n’a pas automatiquement la même valeur qu’un cas reproductible avec données publiées.
Le projet fournit aussi des pages par stack, notamment vLLM, llama.cpp/GGUF, Ollama, SGLang ou MLX, ainsi qu’un petit doctor en lecture seule et une interface MCP pour aider un agent à diagnostiquer un endpoint.
Pour l’IA locale, la leçon est assez brutale : mesurer le modèle ne suffit pas. On mesure aussi le template, le serveur, le kernel choisi, la mémoire réservée, le parser et parfois une version de conteneur oubliée.
Un benchmark propre commence donc moins par « quel modèle est le plus rapide ? » que par une question beaucoup moins glamour : est-ce que je sais exactement ce que j’ai réellement exécuté ?