Comparaison

Cette page compare VRAMPilot à Ollama, LM Studio et llama.cpp nu sur un seul axe : ce qui se passe autour de l'out-of-memory. Ce n'est pas une comparaison générale de produits — Ollama et LM Studio sont des produits plus aboutis, avec catalogues de modèles, interfaces de chat et de grandes communautés. La comparaison s'appuie sur un sondage outil par outil de LM Studio, Ollama et Jan réalisé en juin 2026 (sources nommées dans validation/MARKET.md).

Capacité	VRAMPilot	Ollama	LM Studio	llama.cpp `-fit` nu
Prévention OOM au chargement estimation avant lancement, auto-offload, dimensionnement du contexte	Oui	Oui — auto-offload, contextes par paliers de VRAM	Oui — estimateur de pré-chargement, limite de mémoire GPU dédiée	Oui — `-fit` dans les builds récents
Récupération OOM à l'exécution détecter → se replier → réessayer jusqu'à démarrer et servir	Oui — validée de bout en bout sur NVIDIA et AMD	Rien trouvé dans le sondage	Rien trouvé dans le sondage	Non — un lancement raté échoue
Persistance des configurations qui ont réellement démarré append-only, inspectable, le lancement suivant part de là	Oui	Pas à notre connaissance	Pas à notre connaissance	Non
Watchdog pendant l'inférence effondrement de la VRAM en pleine génération → redémarrage contrôlé sur une configuration dégradée	Oui sur NVIDIA, où la VRAM libre est mesurée ; honnêtement déclassé en surveillance processus+santé ailleurs	Rien trouvé — le sondage n'a trouvé aucun outil qui surveille la VRAM pendant l'inférence	Rien trouvé — idem	Non
Rapport honnête des pertes la trace du repli, les compromis nommés	Oui — le rapport nomme ce qui a été sacrifié	Non — un débordement peut déborder silencieusement vers la RAM système	Pas de rapport équivalent	Les flags sont explicites parce que c'est vous qui les posez ; pas de narration des compromis
Chiffres traçables vers des sources publiées chaque chiffre lie son fichier de validation, servi sous /proofs/ sur ce site	Oui — et la construction de ce site échoue si un chiffre ne correspond pas à son fichier source	Pas une promesse qu'ils font	Pas une promesse qu'ils font	Pas une promesse qu'ils font

Soyons justes sur la première ligne

La prévention au chargement est la norme, et tout le monde l'a — y compris llama.cpp lui-même depuis l'apparition de l'option -fit dans les builds récents. VRAMPilot ne revendique ni l'auto-fit, ni l'estimation de VRAM, ni le dimensionnement du contexte comme différenciateurs. La partie non couverte, d'après le sondage, c'est la boucle de récupération à l'exécution, plus la persistance et le rapport honnête qui l'entourent.

Le sondage, et sa date de péremption

Le sondage était une tentative active de tuer le différenciateur de VRAMPilot en cherchant outil par outil chez LM Studio, Ollama, Jan et des outils de niche. Le verdict : le volet récupération OOM à l'exécution est réellement non couvert ; le profilage de VRAM en direct et l'auto-contexte sont largement couverts et personne ici ne les revendique comme nouveaux.

Deux mises en garde honnêtes :

Les concurrents évoluent. Une version mineure de n'importe lequel de ces outils pourrait ajouter une boucle de récupération — c'est une fonctionnalité d'ingénierie, pas une barrière physique. Ce tableau décrit juin 2026, pas l'éternité. Si vous trouvez un outil local qui livre une boucle détecter → se replier → réessayer, le tableau ci-dessus est périmé et nous voulons le savoir.
« Pas à notre connaissance » ne veut pas dire « n'existe pas ». Les lignes persistance et watchdog reflètent notre recherche, qu'aucun outil sondé ne met en avant ; la ligne récupération à l'exécution est celle sondée fonctionnalité par fonctionnalité dans validation/MARKET.md.