FAQ

Des réponses directes aux questions qu'un sceptique pose vraiment. Version courte d'abord : VRAMPilot est un wrapper autour de llama.cpp. Ce qu'il fait que les outils populaires ne font pas : récupérer d'un out-of-memory à l'exécution au lieu de planter, se souvenir de la configuration qui a réellement marché, et survivre à un OOM en pleine génération.

C'est juste une interface pour llama.cpp ?

En grande partie, oui — et nous le disons avant vous. VRAMPilot est une couche d'automatisation et d'UX au-dessus de llama.cpp. C'est llama.cpp qui fait le vrai travail : chargement du modèle, offload GPU, tensor split, service. VRAMPilot n'exécute aucune opération d'inférence lui-même — il lance llama-server et gère les flags. Ce n'est ni un nouveau moteur d'inférence, ni un résultat de recherche. Ce qu'il ajoute : la boucle de récupération OOM à l'exécution, la persistance de ce qui a réellement démarré, le watchdog pendant l'inférence, et le rapport honnête de ce qui a été sacrifié. Ce sont les seules parties qui méritent votre attention.

En quoi est-ce différent de LM Studio, Ollama ou Jan ? Ils ajustent déjà les modèles automatiquement.

C'est vrai, et VRAMPilot ne prétend pas le contraire. Les estimateurs de VRAM et le dimensionnement automatique du contexte existent déjà — le « Fit to Hardware » de Jan, les contextes par paliers de VRAM d'Ollama, l'estimateur de pré-chargement de LM Studio. C'est la norme. La différence, c'est le moment où l'ajustement a lieu : ces outils préviennent l'OOM au chargement. Aucun ne récupère à l'exécution. Quand une configuration déborde malgré tout — un contexte explicite imposé, un prompt long qui fait déborder le KV-cache, une VRAM moins libre qu'estimé — ils plantent, ou débordent silencieusement vers la RAM système et ralentissent sans vous le dire. Aucun d'eux n'a de boucle détecter → se replier → réessayer (vérifié outil par outil en 2026, voir la page de comparaison). Ce manque est la raison d'être de VRAMPilot.

C'est quoi exactement la « récupération OOM » ?

Quand le serveur ne démarre pas — ou démarre mais ne peut pas générer de token — le lanceur lit le log d'erreur, le classifie comme out-of-memory, se replie d'un cran, et réessaie. L'ordre préserve le plus de capacité : la précision du KV-cache d'abord (garde votre contexte complet, lossy sur le raisonnement long), puis la réduction du contexte, puis plus de déchargement vers le CPU. Si rien ne tient, il dit qu'il a atteint le plancher au lieu de faire semblant. Dans le run validé, une configuration volontairement impossible à 262144 de contexte a récupéré à 131072 — 4x plus de contexte qu'un repli sur le seul contexte n'en aurait gardé — et a servi une vraie réponse.

Qu'est-ce qu'il retient sur ma machine ?

Chaque configuration qui a réellement démarré, persistée par (empreinte machine, hash de l'en-tête du modèle, contexte demandé) dans un fichier SQLite local — en append-only : une configuration qui ne marche plus est gardée en historique, jamais écrasée. Le lancement suivant démarre directement sur la configuration connue-bonne ; un changement de driver ou de GPU l'invalide et déclenche un nouveau plan. Pourquoi c'est utile : une tentative ratée coûte un chargement complet du modèle, mesuré à ~220 s par tentative pour un MoE de 9,5 Go sur le disque de la machine du gate. Rien ne quitte votre machine ; vrampilot configs list montre tout ce qu'il retient, et --no-cache le désactive entièrement.

Et si la VRAM lâche en pleine génération ?

C'est un crash qu'aucun des outils que nous avons sondés ne couvre (nommément, 2026 — voir la page comparaison) : vous êtes au milieu d'une longue génération, une autre application prend de la VRAM, et le serveur meurt. Sur NVIDIA, le watchdog mesure la VRAM libre avec de vraies lectures nvidia-smi, émet une alerte douce sur une mauvaise tendance, et au plancher auto-calibré fait un redémarrage contrôlé sur une configuration dégradée, puis persiste la survivante pour que le prochain lancement parte de là. Run validé sous vraie pression : plancher franchi à 102 MiB libres → récupéré en 223,9 s à un contexte 8192 → 4096 pendant que la pression était toujours là → vraie complétion servie. 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. Contre-test : 0 soft alerts, 0 interventions sur des générations normales. Sur Vulkan/Apple, la VRAM libre est une estimation, donc le watchdog se déclasse honnêtement en surveillance processus + santé — et vous le dit.

Je dois installer llama.cpp moi-même ?

Non. Le premier lancement télécharge un build llama.cpp épinglé (b9592) 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. Par défaut : Vulkan sur Windows/Linux (un seul binaire, quel que soit le fabricant du GPU), Metal sur macOS, CUDA en opt-in. Si vous préférez votre propre build de llama-server, vous pouvez toujours le pointer.

Est-ce que ça marche vraiment ? Qu'est-ce qui est validé ?

Mesuré sur du vrai matériel, pas affirmé en l'air. Il démarre et sert une vraie complétion sur 3 fabricants de GPU : une NVIDIA RTX 3070 (CUDA), une AMD Radeon 780M (iGPU, Vulkan), et une puce Apple M1 (Metal). La récupération OOM a été démontrée de bout en bout sur NVIDIA et AMD : face à une configuration volontairement impossible, il a récupéré et servi une vraie réponse. La persistance et le watchdog ont été validés de bout en bout sur une NVIDIA RTX 4070 Laptop GPU, 8 Go — y compris un MoE de 9,5 Go à 32k de contexte via expert-offload. Les logs bruts sont commités à côté de chaque affirmation.

Peut-il faire tourner un modèle plus gros que la VRAM de mon GPU ?

Dans certaines limites, oui — c'est à ça que sert le déchargement : les runs validés incluent un fichier de 9,5 Go sur un GPU de 8 Go, ajusté via expert-offload MoE. Mais il existe un plancher physique : un modèle trop gros même à la configuration plancher ne peut pas tourner, et aucun logiciel ne bat la physique. Le déchargement CPU coûte aussi de la vitesse — VRAMPilot vous dit ce qu'il a sacrifié, mais lent reste lent. Et sur une toute petite machine, une requête absurde peut démarrer et produire du charabia ; l'usage normal plafonne le contexte à la limite d'entraînement du modèle.

C'est quoi le moat ? LM Studio ou Ollama ne peuvent pas juste copier ?

Réponse inconfortable : si, ils peuvent. C'est un moat d'ingénierie, pas un brevet ni un moat de données. Ça a d'ailleurs déjà commencé côté prévention : les builds récents de llama.cpp embarquent un auto-fit au chargement (-fit), donc la prévention au chargement est désormais la norme en amont. Ce qui reste non couvert : la boucle de récupération à l'exécution, la persistance, et le rapport honnête de ce qui a été perdu. Le pari : livrer maintenant, aller en profondeur sur le repli multi-axes, et valider sur plusieurs fabricants. Si les acteurs établis l'ajoutent, c'est une victoire pour tous ceux qui font tourner des modèles en local.

Qu'est-ce que ça ne fait PAS ?

Dit simplement : ce n'est pas un nouveau moteur d'exécution — c'est llama.cpp qui infère, et si llama.cpp ne peut pas faire tourner votre modèle, ceci non plus. Ça n'agrandit pas votre GPU — un modèle qui ne tient pas même au plancher ne peut pas tourner. La récupération n'est pas gratuite — un redémarrage du watchdog perd la génération en cours, et une configuration dégradée est dégradée (le rapport nomme la perte). La récupération sur Apple n'est pas entièrement démontrée : le démarrage et le service fonctionnent sur M1 et le mécanisme est en place, mais une démonstration propre d'OOM forcé n'était pas possible sur le petit runner de CI. C'est un utilitaire modeste et utile, construit en solo, en sprint — pas une révolution.

Pourquoi faire confiance au rapport « honnête » des pertes ?

Parce que c'est le principe, et parce que c'est vérifiable. L'outil montre la trace du repli et nomme chaque compromis ; vous voyez exactement quelle configuration a démarré. Ce site s'applique la même règle à lui-même : chaque chiffre publié est enveloppé dans un marquage de claim pointant vers le fichier de validation commité qui le contient, et la construction du site échoue si un chiffre et sa source divergent.

C'est gratuit ?

Oui, l'outil est gratuit. Le dépôt de code est privé pour l'instant, avec l'intention de l'ouvrir. Il s'appuie sur llama.cpp, qui est open source.