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.

Une boucle agentique

Un poil avares de documentation, chez Mistral ! Il a fallu se battre, mais j'ai finalement quelque chose d'un peu intégré. Mon idée : avoir Mistral Vibe qui tente de corriger les issues Github associées à mon projet.

Première étape, avoir Vibe qui cause à Github. C'est possible via le serveur MCP de Github, dont la configuration est simple, ou du moins le serait si la doc aidait un petit peu. Ce qui a fonctionné chez moi, c'est de créer un token sur Github, de lui donner accès à tous mes dépôts, et de lui donner accès en lecture et écriture aux pull requests. Ensuite, avec le token généré, j'enlève la ligne mcp_servers = [] si elle existe et j'ajoute ceci à mon ~/.vibe/config.toml:

[[mcp_servers]]
name = "github"
transport = "http"
url = "https://api.githubcopilot.com/mcp/"

[mcp_servers.headers]
Authorization = "Bearer letokendegithubquilestbô"

Ensuite, dans github, je fais /mcps et je vois qu'il détecte mon mcp github, et m'indique toute une liste d'outils. Super - On peut passer à la suite. Je peux lui demander de regarder la liste des issues du projet, prendre la première, la corriger, et faire une PR. Magie ! Il se lance et fait tout de manière autonome !

Ensuite, j'utilise la commande /loop pour faire tourner cela automatiquement. Un prompt qui semble marcher pas mal:

Look at list of issues for the current project. Take the first one that doesn't have an open PR, attempt to fix it. Do a fetch, then a reset on master, create a new branch from master, correct the issue, push the branch, and create a pull request, do not merge into master. If no such issue exists, stop.

Je peux m'en aller et le laisser tourner, et depuis n'importe quel appareil, vérifier l'avancée des correctifs, lever les issues, et fusionner les PRs!

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).

Nouveau mini-jeu

Parce que c'est l'occasion d'intégrer les dessins de la petite, je me suis lancé dans un nouveau mini-jeu. Et j'ai bataillé beaucoup trop longtemps avec Godot avant de finalement repasser à mon bon vieux sfml. Pour un jeu complexe, avec beaucoup d'animations ou même en 3D, il n'y a pas photo. Mais pour un bête truc qui affiche 3 images, revenir aux fondamentaux, c'est plutôt plaisant.

pySpice retrospective

J'ai (presque) complété l'implémentation Unity3D, j'ai pu aider à la game jam, tout va bien. Au final, avec les outils modernes, tout cela va quand même rudement vite - Un jeu presque complet en 200 lignes de Python, et encore moins en Godot ou Unity? C'est impressionnant.

La même en Godot!

En une petite journée, j'ai pu porter pySpace vers gdSpace. Très intéressant - Certaines choses sont nettement plus élégantes, d'autres moins, mais ça reste un bon système (peut-être un poil plantogène?). Hâte de passer à Unity3D!

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!