Vibe coding Open Source en local sur un ordinateur portable.

Vu que mon expérience de la semaine dernière a épuisé mon quota de tokens sur Mammouth.ai, je voulais voir si je pouvais vibe coder en local sur de tous petits modèles avec un ordinateur portable doté d'une carte graphique AMD intégrée au CPU (un 7430U pour les curieux). J'ai eu plusieurs soucis mais aussi de bonnes surprises.

D'abord pour remplacer CUDA, j'installe l'équivalent de chez AMD : ROCm, qui a en plus le bon goût d'être Open Source. Ensuite j'installe Ollama, je cherche un petit modèle et je découvre Granite 4.1 avec 3 milliards de paramètres.

Je n'ai jamais entendu parler de ce modèle d'IBM. Il peut appeler des tools donc on peut s'en servir avec un agent. Par contre il ne raisonne pas, ça risque de donner des problèmes de pertinence, on verra ce que ça donne.

Je lance Open Code avec ollama code --model granite4.1:3b. Et là je vois que le contexte est limité à 4k, c'est bien trop peu pour un agent : 128K c'est confortable mais ça fera trop de calculs pour mon petit portable, je vais essayer 32K qui est le minimum recommandé.

Les logs de Ollama confirment que le modèle utilise 4096 tokens de contexte :

level=INFO source=routes.go:1848 msg="vram-based default context" total_vram="0 B" default_num_ctx=4096

Il y a 3 façons d'augmenter la taille du contexte dans ollama :

• l'application cliente peut le forcer lors de la requête en passant l'option num_ctx,
• on peut créer son propre modèle (en définissant un Modelfile, un peu comme Docker et ses Dockerfile). qui reprend le modèle de base et surcharge num_ctx,
• on peut rajouter la variable d'environnement OLLAMA_CONTEXT_LENGTH=32768 quand on lance ollama serve,

J'aurais préféré le configurer depuis Open Code mais il ne gère pas ce paramètre donc je me rabats sur la dernière solution.

Je relance Open Code et là tout est très lent. Puisque le contexte consommé dès le départ est d'environ 10k, je diminue la taille du contexte à 16384 tokens pour alléger un peu la RAM et les calculs.

C'est mieux mais j'ai l'impression que c'est le CPU qui fait tout le calcul. Je vois ces lignes dans les logs :

msg="failure during GPU discovery" OLLAMA_LIBRARY_PATH="[/usr/local/lib/ollama /usr/local/lib/ollama/rocm]" extra_envs="map[GGML_CUDA_INIT:1 ROCR_VISIBLE_DEVICES:0]" error="runner crashed"
msg="inference compute" id=cpu library=cpu compute="" name=cpu description=cpu libdirs=ollama driver="" pci_id="" type="" total="30.7 GiB" available="21.0 GiB"

Le GPU n'est pas trouvé. Ollama le confirme :

$ ollama ps
NAME             ID              SIZE      PROCESSOR    CONTEXT    UNTIL
granite4.1:3b    6fd349357287    3.4 GB    100% CPU     16384      4 minutes from now

De ce que j'ai vu sur Internet ROCm ne supporte que les cartes graphiques récentes, c'est à dire séparées du CPU. Par contre llama.cpp, la bibliothèque utilisée par Ollama pour l'inférence, gère aussi l'accélération en utilisant Vulkan, mais c'est encore expérimental donc pour l'activer, il suffit d'ajouter la variable d'environnement OLLAMA_VULKAN=1

Un redémarrage du serveur plus tard, le modèle se charge bien dans le GPU.

$ ollama ps
NAME             ID              SIZE      PROCESSOR    CONTEXT    UNTIL
granite4.1:3b    6fd349357287    4.6 GB    100% GPU     16384      4 minutes from now

Là je vois bien dans htop que le CPU n'est pas utilisé. Par contre nvtop ne marche pas aussi bien que dans l'environnement Nvidia : il déclare que la RAM allouée est de 512Mo et il détecte une utilisation de 100% du GPU mais pas le process ollama. En utilisant le paquet snap de nvtop à la place du paquet Debian 13, la RAM est correctement affichée, mais toujours pas d'affichage du process ollama.

Finalement si on discute avec le modèle en utilisant ollama run granite4.1:3b, l'utilisation est fluide, donc on peut utiliser un petit modèle de langue en local pour chatter. Par contre pour l'utilisation de Open Code, le système est beaucoup trop lent (11 minutes pour lire un fichier de 4Ko, 4 minutes pour une question sur ce même texte) et le modèle est loin d'être pertinent. J'ai testé aussi le modèle Gemma4:e2b de Google, le système est devenu encore plus lent, c'était là aussi inutilisable.