VRAMPilot

Fait tourner vos modèles GGUF en local et récupère d'un out-of-memory à l'exécution au lieu de planter.

VRAMPilot est un outil local gratuit qui fait tourner des modèles GGUF avec llama.cpp et récupère d'un out-of-memory à l'exécution au lieu de planter. Vous lui donnez un fichier .gguf ; il lit votre GPU, choisit une configuration qui tient, lance un llama-server, et si le modèle déborde quand même — au démarrage ou en pleine génération — il se replie, réessaie jusqu'à servir, et vous dit ce qu'il a sacrifié pour que ça tienne.

Le problème : les crashs OOM

Le premier mur quand on lance un modèle local, c'est l'out-of-memory. Un outil estime que le modèle tient, le lance, et l'estimation se révèle fausse — fragmentation, une autre application qui occupe la VRAM, un contexte plus long que prévu par le calcul. Les outils populaires préviennent l'OOM au chargement ; quand l'estimation est fausse malgré tout, le serveur plante, ou déborde silencieusement vers la RAM système et devient très lent sans vous dire pourquoi.

Un estimateur est une supposition faite avant le lancement. La boucle de récupération est ce qui s'exécute une fois que la supposition s'est déjà trompée.

Ce qu'il fait

Cinq choses, chacune validée sur du vrai matériel — chaque chiffre de ce site lie le fichier de validation dont il provient, et ces fichiers sont publiés tels quels sous /proofs/ — cliquez n'importe quel chiffre pour lire sa source brute.

Plan d'ajustement automatique. Il lit le modèle depuis les octets réels de l'en-tête GGUF (couches, experts MoE, quantisation, taille) et la VRAM libre de votre GPU (mesurée sur NVIDIA, estimée sur AMD/Intel/Apple — le rapport dit toujours lequel des deux), puis choisit les couches GPU, le contexte, la précision du KV-cache et l'expert-offload MoE pour que le modèle tienne. Validé jusqu'à un fichier de 9,5 Go sur un GPU de 8 Go.
Récupération OOM à l'exécution. Si le lancement rencontre quand même une erreur out-of-memory, il la détecte, se replie sur plusieurs axes — d'abord la précision du KV-cache (pour garder votre contexte), puis le contexte, puis plus de déchargement vers le CPU — et réessaie jusqu'à ce que le serveur démarre et serve réellement un token. Puis il vous montre la trace du repli.
Persistance de ce qui a démarré. Chaque configuration qui a réellement démarré est stockée dans une base SQLite locale, en append-only. Le lancement suivant part de la configuration connue-bonne ; un changement de driver ou de GPU l'invalide et déclenche un nouveau plan. Rien ne quitte votre machine, et une commande configs list montre tout ce qu'il retient.
Watchdog pendant l'inférence. Il couvre le crash que les outils de chargement ne couvrent pas : l'épuisement de la VRAM au milieu d'une longue génération. Dans un run validé sous vraie pression VRAM externe, le plancher a été franchi à 102 MiB libres et le serveur a récupéré en 223,9 s sur une configuration dégradée — pendant que la pression était toujours là. Le coût honnête, annoncé par l'outil lui-même : la génération en cours est perdue. La récupération est réelle, pas invisible.
Installation sans prérequis. Aucune installation de llama.cpp nécessaire : le premier lancement télécharge un build llama.cpp épinglé pour votre OS et votre GPU avec vérification SHA256 obligatoire (un mismatch supprime le fichier et arrête net). Mesuré sur la machine du gate : 7,6 s d'un départ à froid jusqu'à une vraie complétion servie — avec un modèle de test de 1 Go déjà sur disque (le temps inclut le téléchargement du binaire épinglé, pas celui du modèle).

Périmètre honnête

VRAMPilot est une couche d'automatisation et d'UX au-dessus de llama.cpp, qui fait l'inférence réelle (chargement, offload, service). Ce n'est ni un nouveau moteur d'exécution, ni une percée de recherche. Si llama.cpp ne peut pas faire tourner votre modèle, VRAMPilot non plus.
L'ajustement automatique au chargement existe désormais en amont : les builds récents de llama.cpp embarquent une option -fit, et LM Studio, Ollama et Jan estiment tous avant le lancement. La prévention au chargement est la norme. Ce qui reste non couvert — et ce que VRAMPilot ajoute — c'est la récupération à l'exécution, la persistance de ce qui a réellement démarré, et le rapport honnête de ce qui a été perdu.
Le moat est un moat d'ingénierie, pas une barrière infranchissable. N'importe quel acteur établi pourrait ajouter une boucle de récupération dans une version mineure. Le pari : être correct et complet sur quelque chose de réellement non couvert aujourd'hui.
Aucun logiciel ne bat la physique. Un modèle qui ne tient pas même à la configuration plancher ne peut pas tourner ; VRAMPilot vous dit qu'il a atteint le plancher au lieu de faire semblant.

Pas de cookies

Ce site ne dépose aucun cookie et ne charge rien depuis des tiers. Comme l'outil lui-même : local, rien n'est transmis.