Un auteur de Habr fait tourner Qwen 2.5 14B sur son PC et en fait la maîtresse du site INFERNUM

Un modèle de langage local de 14,7 milliards de paramètres, qui tient dans environ 9–10 Go de VRAM en quantification 4 bits, sert désormais de « maîtresse » à tout un site. L'auteur d'une publication sur Habr a fait tourner Qwen 2.5 14B sur son PC personnel et l'a connecté au projet interactif INFERNUM. Le réseau de neurones y a reçu un caractère, un rôle et un ensemble de pouvoirs au sein de la page. L'auteur lui-même parle d'un aquarium numérique dans lequel est enfermé un personnage, propriétaire du projet.

Ce que l'on sait du projet

L'annonce sur Habr est courte, et les détails techniques sont repliés sous le cut. La partie visible donne l'essentiel. L'auteur ne voulait pas se contenter de faire tourner un modèle et d'obtenir un énième bot de réponses. Il voulait quelque chose de tangible : un réseau de neurones qui vit sur le site, reste dans son personnage et peut agir dans les limites de la plateforme. L'esthétique renvoie à une Demeure infernale, d'où le nom INFERNUM.

L'auteur formule sa motivation sans emphase : « parce que je peux ». Pour un projet de loisir, cela suffit. La configuration matérielle, la méthode de lancement, la taille du contexte et la vitesse de génération ne sont pas indiquées dans l'annonce ; il est donc impossible, pour l'instant, d'évaluer les performances de cette installation précise.

Pourquoi Qwen 2.5 14B

Le modèle a été publié par Alibaba en septembre 2024 et, à l'automne 2026, n'est plus une nouveauté. Pour une expérience à domicile, il reste pratique par son rapport entre taille et qualité. La version 14B est distribuée sous licence Apache 2.0 : elle peut donc être utilisée dans des projets sans accord préalable. Elle suit nettement mieux les instructions et les prompts de jeu de rôle que les modèles de classe 7B.

Caractéristiques générales du modèle :

• environ 14,7 milliards de paramètres, 48 couches ;
• fenêtre de contexte jusqu'à 128 k tokens, génération jusqu'à 8 k tokens à la fois ;
• entraînement sur un corpus d'environ 18 billions de tokens ;
• multilingue, russe compris ;
• en FP16, il faut environ 28–30 Go de mémoire ; en quantification 4 bits, environ 9–10 Go, plus une marge pour le KV-cache.

Les deux dernières lignes comptent plus que les autres. La version quantifiée tient sur une seule carte graphique de 12–16 Go, soit le niveau d'un PC de jeu ordinaire. C'est ce qui a fait de ces « aquariums » un loisir répandu.

À quoi ressemble cette architecture

Le schéma type d'un site avec un modèle local est simple. La page web envoie la réplique du visiteur au backend. Le backend assemble un prompt à partir d'une instruction système décrivant le personnage, de l'historique du dialogue et, éventuellement, de l'état du site. Il interroge ensuite un serveur d'inférence local, par exemple Ollama, llama.cpp ou vLLM, puis renvoie la réponse à la page. Le mot « pouvoirs » dans la description de l'auteur désigne très probablement de l'appel de fonctions : le modèle renvoie une commande structurée, que le backend exécute. Nous ne connaissons pas l'implémentation concrète de l'auteur ; il s'agit d'un schéma générique.

Ce montage offre un contrôle total sur les données et n'impose aucun paiement au token. En contrepartie, il apporte les problèmes habituels de l'auto-hébergement domestique : un seul GPU ne peut servir qu'un nombre limité de dialogues simultanés, et c'est l'auteur qui paie la connexion et l'électricité.

Ce qu'il faut prévoir pour reproduire le projet

Il vaut mieux commencer par un modèle quantifié au format GGUF et un serveur local doté d'une API compatible OpenAI. Cela facilite le changement de modèle sans réécrire le site. Il faut ensuite plusieurs garde-fous.

• Limitez les actions du modèle à une liste blanche de commandes et vérifiez chacune côté backend. Il ne faut pas exécuter directement le texte généré par le modèle.
• Considérez chaque message d'un visiteur comme une injection de prompt potentielle. Un personnage « doté de pouvoirs » se laisse facilement convaincre de sortir de son rôle.
• Fixez des limites sur la longueur des réponses et sur la fréquence des requêtes par adresse, et faites passer les requêtes vers le GPU par une file d'attente.
• N'exposez pas le serveur d'inférence sur un réseau ouvert. Seul un proxy doit être visible de l'extérieur.
• Surveillez la taille du contexte : un long historique de dialogue fait grossir le KV-cache et peut chasser le modèle de la VRAM.

Pour les détails d'implémentation, mieux vaut se reporter à l'article original sur Habr. L'annonce présente l'idée ; reste à savoir si elle fonctionne, ce qui dépend du matériel choisi et de la rigueur avec laquelle l'auteur a séparé le modèle des actions exécutables.