{"id":558,"date":"2026-08-23T22:05:13","date_gmt":"2026-08-23T21:05:13","guid":{"rendered":"https:\/\/elcep.legtux.org\/?p=558"},"modified":"2026-08-23T22:05:13","modified_gmt":"2026-08-23T21:05:13","slug":"mon-royaume-pour-4-go-de-vram-faire-entrer-ollama-dans-le-gpu","status":"publish","type":"post","link":"https:\/\/elcep.legtux.org\/?p=558","title":{"rendered":"Mon royaume pour 4 Go de VRAM : faire entrer Ollama dans le GPU"},"content":{"rendered":"
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

Dans un pr\u00e9c\u00e9dent billet, \u00ab Mon royaume pour une IA en localhost \u00bb<\/a>, je racontais mes premiers pas avec Ollama. L\u2019enjeu \u00e9tait assez simple : si je dois confier des articles, des rapports ou des archives de recherche \u00e0 une intelligence artificielle, je pr\u00e9f\u00e8re que tout cela reste dans ma machine. Garder l\u2019IA dans sa bo\u00eete, donc, avec l\u2019espoir de conserver un peu de prise sur ce que je lui donne et sur ce qu\u2019elle en fait.<\/p>\n\n\n\n

\u00c0 ce stade, faire r\u00e9pondre un mod\u00e8le dans un terminal avait quelque chose de presque magique. Mais entre demander un r\u00e9sum\u00e9 de trois pages et faire analyser un v\u00e9ritable corpus de recherche, il y a un petit gouffre. C\u2019est dans ce gouffre que mon ordinateur et moi sommes tomb\u00e9s.<\/p>\n\n\n\n

L\u2019histoire qui suit est donc un retour d\u2019exp\u00e9rience sur la mani\u00e8re dont j\u2019ai essay\u00e9 de faire travailler Ollama avec une petite carte graphique de portable. Ce n\u2019est pas un tutoriel universel : les r\u00e9glages d\u00e9pendent du mod\u00e8le, du GPU, de sa m\u00e9moire et de la taille des textes. C\u2019est plut\u00f4t un pense-b\u00eate document\u00e9 pour \u00e9viter de refaire, dans six mois, le m\u00eame chemin \u00e0 travers les journaux d\u2019erreurs.<\/p>\n\n\n\n

Le contexte : 839 documents et une semaine de patience<\/h2>\n\n\n\n

Je travaille sur les archives du projet Sant\u00e9 & Territoires<\/a> au S\u00e9n\u00e9gal. Le corpus rassemble des comptes rendus, pr\u00e9sentations, termes de r\u00e9f\u00e9rence, tableaux, documents de travail et rapports produits autour des Living Labs de Mbane et de Keur Momar Sarr, pr\u00e8s du lac de Guiers.<\/p>\n\n\n\n

L\u2019objectif n\u2019\u00e9tait pas seulement de faire r\u00e9sumer les documents. Je voulais reconstruire une chronologie, retrouver les groupes impliqu\u00e9s, rep\u00e9rer les formes de participation, distinguer ce qui avait \u00e9t\u00e9 propos\u00e9 de ce qui avait r\u00e9ellement \u00e9t\u00e9 fait et suivre la mani\u00e8re dont la perspective \u00ab Une seule sant\u00e9 \u00bb avait \u00e9t\u00e9 progressivement prise en compte. Le tout en conservant, pour chaque codage, un extrait et un chemin vers le document source.<\/p>\n\n\n\n

Apr\u00e8s extraction des textes, agr\u00e9gation des doublons et exclusion des images, vid\u00e9os et fichiers audio, il restait tout de m\u00eame 839 unit\u00e9s documentaires susceptibles de passer devant le LLM.<\/p>\n\n\n\n

J\u2019ai donc lanc\u00e9 mon script R, assez fier de moi, avec plusieurs workers<\/em> pour les op\u00e9rations locales et Ollama pour le codage. Quelques heures plus tard, la barre de progression affichait quelque chose comme :<\/p>\n\n\n\n

Codage LLM documents   16\/839 | \u00e9coul\u00e9 4h29m | ETA \u2248 231h22m<\/code><\/pre>\n\n\n\n
Le script annon\u00e7ait ensuite, avec un calme que je trouvais presque provocateur :<\/p>\n\n\n\n
Timeout ou \u00e9chec pour D00010 chunk 4 (4000 caract\u00e8res) ;\nrepli en 2 sous-chunk(s) de 2500 caract\u00e8res au maximum.<\/code><\/pre>\n\n\n\n
Le premier bloc attendait le timeout. Puis le script le d\u00e9coupait en deux et recommen\u00e7ait. Quand plusieurs requ\u00eates partaient en m\u00eame temps, elles se disputaient la m\u00e9moire disponible. \u00c0 ce rythme, l\u2019analyse ne ressemblait plus vraiment \u00e0 un gain de temps. Elle ressemblait plut\u00f4t \u00e0 une mani\u00e8re sophistiqu\u00e9e de transformer un ordinateur portable en radiateur et par ces temps de canicules, pas la meilleur id\u00e9e que j’ai eu!<\/p>\n\n\n\n
Pas qu’un probl\u00e8me de mod\u00e8le<\/h2>\n\n\n\n
Ma premi\u00e8re r\u00e9action a \u00e9t\u00e9 de chercher un mod\u00e8le plus petit. C\u2019est assez logique : un mod\u00e8le de 8 milliards de param\u00e8tres sera plus lourd qu\u2019un mod\u00e8le de 3 ou 4 milliards. Mais cela n\u2019expliquait pas compl\u00e8tement pourquoi des passages de quelques milliers de caract\u00e8res pouvaient immobiliser Ollama pendant plusieurs minutes.<\/p>\n\n\n\n
La machine poss\u00e8de deux processeurs graphiques :<\/p>\n\n\n\n
Intel Corporation Meteor Lake-P [Intel Arc Graphics]\nNVIDIA RTX 500 Ada Generation Laptop GPU<\/code><\/pre>\n\n\n\n
La carte NVIDIA ne dispose que de 4 Go de VRAM. Ce n\u2019est pas \u00e9norme, mais un llama3.2:latest<\/code> quantifi\u00e9 p\u00e8se environ 2 Go. Il devait donc \u00eatre possible d\u2019en faire quelque chose.<\/p>\n\n\n\n
La commande suivante confirmait d\u2019ailleurs qu\u2019Ollama voyait bien la carte :<\/p>\n\n\n\n
nvidia-smi<\/code><\/pre>\n\n\n\n
Dans la liste des processus, \/usr\/local\/bin\/ollama<\/code> occupait environ 666 Mio de m\u00e9moire vid\u00e9o. Mais cette information ne disait pas quelle part du mod\u00e8le \u00e9tait r\u00e9ellement ex\u00e9cut\u00e9e sur le GPU. Pour cela, il fallait demander directement \u00e0 Ollama :<\/p>\n\n\n\n
ollama run llama3.2:latest \"R\u00e9ponds uniquement par OK\"\nollama ps<\/code><\/pre>\n\n\n\n
Et l\u00e0, surprise :<\/p>\n\n\n\n
NAME               SIZE     PROCESSOR          CONTEXT\nllama3.2:latest    18 GB    71%\/29% CPU\/GPU    16384<\/code><\/pre>\n\n\n\n
Le mod\u00e8le t\u00e9l\u00e9charg\u00e9 faisait environ 2 Go, mais Ollama annon\u00e7ait une empreinte de 18 Go et ne pla\u00e7ait que 29 % du calcul sur le GPU. Le m\u00eame test avec qwen3:4b-instruct<\/code> donnait encore moins :<\/p>\n\n\n\n
qwen3:4b-instruct    18 GB    83%\/17% CPU\/GPU    16384<\/code><\/pre>\n\n\n\n
Le GPU \u00e9tait donc bien utilis\u00e9, mais comme une petite annexe du CPU. La majeure partie de l\u2019inf\u00e9rence se faisait toujours dans la m\u00e9moire centrale. Hors, j’ai toujour entendu Th\u00e9o me parler de GPU dans sa th\u00e8se.<\/a><\/p>\n\n\n\n
Quatre contextes pour une seule petite carte<\/h2>\n\n\n\n
L\u2019indice principal \u00e9tait la valeur CONTEXT 16384<\/code>. Ollama avait r\u00e9serv\u00e9 beaucoup plus de m\u00e9moire que n\u00e9cessaire. Le parall\u00e9lisme \u00e9tait ici particuli\u00e8rement co\u00fbteux : plusieurs requ\u00eates simultan\u00e9es signifient plusieurs contextes \u00e0 conserver en m\u00e9moire. Quatre contextes de 4 096 tokens donnent justement 16 384 tokens \u00e0 allouer.<\/p>\n\n\n\n
La documentation d\u2019Ollama<\/a> pr\u00e9cise que la m\u00e9moire n\u00e9cessaire augmente avec le produit :<\/p>\n\n\n\n
OLLAMA_NUM_PARALLEL \u00d7 OLLAMA_CONTEXT_LENGTH<\/code><\/pre>\n\n\n\n
Sur une grosse carte, plusieurs requ\u00eates parall\u00e8les peuvent augmenter le d\u00e9bit. Sur 4 Go de VRAM, elles font surtout sortir le mod\u00e8le du GPU. Le paradoxe est assez joli : j\u2019avais demand\u00e9 plus de parall\u00e9lisme pour aller plus vite, et ce parall\u00e9lisme \u00e9tait pr\u00e9cis\u00e9ment ce qui ralentissait le calcul.<\/p>\n\n\n\n
Il fallait donc distinguer deux choses dans mon script :<\/p>\n\n\n\n