La commande llama.cpp qui fonctionne pour moi

HIP_VISIBLE_DEVICES=0 ./llama-server -a Devstral-Small-2507 -m ~/Devstral-Small-2-24B-Instruct-2512-Q4_K_M.gguf -c 64000 -fa on -ngl 99 --jinja --host 0.0.0.0 -nkvo

Rapidement, parce qu'il est tard, et que je dois aller me coucher. Ce qui marche: HIP_VISIBLE_DEVICES=0 pour viser le GPU discret, le modèle Devstral-Small-2-24B-Instruct-2512-Q4_K_M.gguf qui fonctionne bien en agentique et tient tout juste dans mes 16 GB de VRAM, -c 64000 pour le contexte (que l'on peut augmenter à volonté, grace au -nkvo), le --jinja pour s'assurer que la couche agentique fonctionne, et le -nkvo qui pousse le contexte en RAM, ce qui ralentit un peu (mais pas tant que ça!), mais surtout permet d'augmenter grandement le contexte et de permettre des tâches nettement plus avancées.

Un setup de vibe coding en local qui fonctionne avec 16GB de VRAM (si on est patient)

J'étais arrivé à la conclusion qu'il n'est pas possible de vibe coder avec seulement 16GB de VRAM, et que je devais donc considérer mon AMD 7800XT comme suffisante pour du conversationel, mais pas pour de l'agentique.

Le problème principal est un problème de taille. Les gros modèles ne tiennent pas en mémoire, et les petits fonctionnent mal : soit ils partent en mode poisson rouge et racontent d'importe quoi, soit ils perdent la compréhension du protocole pour communiquer avec la GUI agentique.

Sauf qu'à force d'insister, j'ai compris plusieurs choses : d'une part, ollama, lorsqu'il détecte que la VRAM est basse, configure par défaut un tout petit contexte. D'autre part, ollama est capable de décharger une partie de la VRAM en RAM, ce qui est lent, mais doit continuer de fonctionner. Et c'est seulement lorsque l'on tente de changer de modèle qu'il s'emmelle les pinceaux et peut planter en ne trouvant plus de mémoire pour y charger le modèle.

Un setup qui marche chez moi, c'est donc devstral-small-2 avec 32K de contexte, en utilisant Mistral Vibe du côté client. Alors, c'est très lent - Compter plusieurs minutes entre chaque action de la boucle agentique, et plusieurs dizaines de minutes pour arriver au bout d'une requête ou feature, surtout si on lui demande de compiler (il se trompe beaucoup). Mais ça marche !

J'ai plein d'idées, principalement orientées vers l'idée de le laisser tourner en tâche de fond pendant que je fais autre chose (comme écrire des billets de blog).

On se remet à écrire des jeux

La game jam de l'école approche, et, soucieux de mener à bien mon rôle de mentor, je me suis lancé dans l'écriture d'un mini shooter spatial en vue de dessus, en utilisant Python, langage avec lequel je suis très peu familier.

Une fois compris qu'il fallait mettre des self partout, et avec l'assistance d'une IA locale (il faudra que je vous parle de mon petit lab IA dont je suis très content), j'ai réussi à coder quelque chose de sympathique étant donné le peu de temps que je m'étais donné. Il est vrai qu'avec Python, tout va assez vite, même si je perds parfois pas mal de temps avec les petites erreurs de syntaxe. Il faudra que j'améliore mon setup.

Voici la bête, les graphismes sont de l'IA (locale à nouveau, mais de l'IA quand même), mon but étant purement de me dépatouiller du code, qui lui est écrit à la main, même si je me suis permis de poser des questions à Mistral.

Prochaine étape : faire exactement la même chose avec Godot, et avec Unity!

Un NAS maison qui dépote

Je me suis lancé tête baissée dans la configuration de mon Raspberry Pi pour le transformer en NAS. Aprés une première soirée pas très productive à me battre avec le SSH, j'ai fini par réussir à installer les services suivants : OpenSSH pour l'accès à distance, Avahi pour la résolution de nom, et enfin Samba pour le partage de répertoires.

Et ça marche du tonnerre ! Je peux même y accéder depuis mon IPhone, moyennant l'ajout de support pour une vieille version du protocole. Après tout, Apple n'est qu'une petite PME sans grande ambition, on ne peut pas leur demander de supporter SMB 3!

Je m'en vais maintenant mettre tout ceci en production pour de bon, et le tester un bon moment. Si en effet cela s'avère utile, je pense en particulier pour le partage de fichiers entre les différentes machines de la maison, ainsi que pour centraliser les photos de famille, alors j'investirai dans un Raspberry Pi 5 et une paire de M2 pour avoir du RAID.

Bazzite

Je vous avais parlé dans l'article précédent de Bazzite, la distribution orientée gaming. Je continue à en être pleinement satisfait - On a vraiment besoin de toucher à rien, tout se gère via le client steam en mode plein écran, les jeux tournent et le matériel aussi.

Le XBox wireless adapter marche très bien, ainsi que le dongle de ma manette Razer. Parfois, il faut aller débrancher et rebrancher un dongle pour que tout le monde s'y retrouve, mais cela reste l'exception.

Finalement, la vraie limitation de Bazzite, c'est justement de sortir du petit pré carré du gaming Steam - En particulier, la multiplication des gestionnaires de paquet de type Flatpack et autres qui se contrôlent via des scripts ujust me semble juste ajouter au désordre ambiant - J'ai ainsi essayé d'installer openrgb pour calmer un peu les ardeurs des diodes du PC, j'ai suivi les instructions, et, déçu par la complexité de l'installation, j'ai voulu revenir en arrière, et ce n'est pas vraiment possible. Il faudrait sans doute retrouver chaque paquet Flatpack et le supprimer, en espérant ne pas se tromper. Les utilisateurs venant de Windows ne seront sans doute pas dépaysés, mais j'ai l'habitude de pouvoir garder mon système propre avec des desinstallations parfaitement configurées, et cela m'a chagriné. Je vais donc surtout ne pas tenter de bidouiller.