Module 7 — Accélération matérielle

Le module précédent nous a appris combien de RAM chaque modèle réclame. Ce module répond à la question complémentaire : à quelle vitesse ce modèle répond, et pourquoi la même étiquette est fluide sur le MacBook de la directrice et pénible sur la tour de bureau du secrétariat. La différence tient à peu de choses : la présence ou non d'une accélération matérielle, la mémoire disponible sur cette accélération, et le nombre de couches du modèle qu'Ollama parvient à y placer.

Trois familles matérielles

Ollama exploite trois familles d'accélération, avec une même logique sous-jacente.

NVIDIA CUDA couvre l'immense majorité des cartes graphiques dédiées Windows et Linux. Ollama détecte automatiquement la présence d'une carte compatible et le pilote CUDA installé. Sur une RTX 4060 8 Go, un llama3.1:8b en q4 tourne autour de 55 à 70 jetons par seconde en génération, contre 6 à 12 sur un CPU récent. Le facteur 6 à 10 change tout dans l'expérience utilisateur.

AMD ROCm couvre certaines cartes AMD sous Linux et, plus récemment, Windows. La compatibilité est plus étroite que côté NVIDIA — vérifier la carte dans la matrice officielle Ollama avant d'espérer une accélération. Quand elle fonctionne, les performances sont comparables à CUDA à segment équivalent.

Apple Metal est intégré directement à macOS sur les puces M1 à M4. C'est peut-être la voie la plus élégante : la mémoire est unifiée entre le CPU et le GPU, ce qui évite d'avoir à choisir entre les deux et permet de charger sur GPU même un modèle qui prendrait 12 Go alors que la machine n'en aurait « que » 16. Un llama3.1:8b en q4 tourne autour de 25 à 40 jetons par seconde sur un M3, un chiffre très correct pour un ordinateur portable silencieux.

Le CPU seul reste un choix parfaitement viable pour un usage occasionnel : les processeurs récents avec des instructions AVX2 ou AVX-512 délivrent 5 à 15 jetons par seconde sur un 8B en q4. Une réponse de 300 jetons prend alors 20 à 60 secondes — supportable pour le secrétariat qui reçoit 30 questions par jour, éprouvant pour un usage en flux tendu.

Le déchargement partiel des couches

Un LLM est un empilement de couches identiques (32 pour un Llama 7B/8B). Chaque couche a un poids ; on peut choisir de placer les 32 sur le GPU, ou seulement les 16 premières et laisser les 16 restantes sur le CPU. C'est ce qu'on appelle le déchargement partiel (partial offload), et c'est le paramètre num_gpu qui le contrôle.

Sur la RTX 4060 du bureau juridique équipée de 8 Go de VRAM, un llama3.1:8b en q4 (4,7 Go de poids + 1 Go de cache pour 4 K de contexte) tient largement sur GPU. Mais un llama3:13b en q4 (7,4 Go) ne tient plus une fois qu'on ajoute le cache d'attention. Sans déchargement, Ollama refuserait de charger le modèle ; avec num_gpu à 25 (sur 40 couches), les 25 premières couches vont sur GPU, les 15 restantes tournent sur CPU, et le modèle fonctionne — au prix d'une vitesse divisée par trois environ par rapport à un placement complet.

En pratique, on laisse Ollama décider : sans consigne, il calcule combien de couches tiennent en VRAM et applique le meilleur découpage. La bascule manuelle par num_gpu sert quand on veut réserver de la VRAM pour un autre usage sur la même machine, ou quand la détection automatique échoue.

Mesurer les jetons par seconde

Le seul chiffre qui importe pour l'expérience utilisateur, c'est le nombre de jetons générés par seconde. Ollama l'affiche à la fin de chaque réponse quand on lance la session avec le mode verbeux :

ollama run --verbose llama3.1:8b-instruct-q4_K_M
>>> Redige en trois paragraphes une mise en demeure pour loyers impayes.
[reponse]
total duration:       5.487s
load duration:        24ms
prompt eval count:    112 tokens
prompt eval rate:     1435.28 tokens/s
eval count:           298 tokens
eval rate:            54.83 tokens/s

Les deux mesures à retenir sont eval rate (les jetons par seconde en génération, la vitesse « perçue » par l'utilisateur) et prompt eval rate (la vitesse d'ingestion de la consigne). Cette dernière est bien plus élevée que la génération, parce qu'elle est massivement parallélisable — c'est pourquoi une consigne courte fait rarement une différence perceptible en temps total, alors qu'une réponse plus courte fait toute la différence.

Le banc d'essai du cabinet

Nous avons lancé la même question — la mise en demeure ci-dessus — sur les trois postes du cabinet, avec le même modèle et les mêmes paramètres. Les mesures qui suivent sont indicatives et dépendent des générations de matériel :

Poste	Matériel	eval rate	Temps pour 300 jetons
Directrice	MacBook Pro M3 16 Go	~30 t/s	~10 s
Secrétariat	Windows i7-12700 32 Go, sans GPU	~10 t/s	~30 s
Serveur commun	Ubuntu, RTX 4060 8 Go	~65 t/s	~5 s

La conséquence organisationnelle est immédiate : les scripts lourds (résumé de 50 courriers d'un coup, indexation du fonds documentaire) tournent la nuit sur le serveur commun, tandis que le MacBook et le poste Windows restent réservés aux questions interactives.

Quelques leviers de réglage

Deux variables d'environnement sont utiles quand on partage une machine avec d'autres logiciels gourmands. OLLAMA_NUM_PARALLEL fixe le nombre de requêtes traitées en parallèle par le service (défaut 4). OLLAMA_MAX_LOADED_MODELS limite le nombre de modèles gardés simultanément en mémoire. Pour un usage mono-utilisateur, OLLAMA_NUM_PARALLEL=1 réduit la mémoire utilisée et évite qu'un pic accidentel n'expulse le modèle chargé.

La confusion RAM et VRAM

Sur un poste PC avec GPU dédié, la RAM système et la VRAM de la carte sont deux mémoires distinctes. Un modèle qui tient dans 16 Go de RAM n'a rien à voir avec un modèle qui tient dans 8 Go de VRAM. Sur Mac Apple Silicon, cette distinction n'existe pas : la mémoire est unifiée, et un M3 16 Go a réellement 16 Go accessibles au GPU. C'est ce qui rend les Mac particulièrement bien placés pour l'inférence locale à budget contraint.

En résumé

• Ollama exploite CUDA (NVIDIA), ROCm (AMD) et Metal (Apple Silicon) automatiquement ; à défaut, il tourne en CPU, plus lent d'un facteur 6 à 10.
• Le paramètre num_gpu contrôle le déchargement partiel des couches ; Ollama choisit tout seul par défaut, on n'y touche que si un autre logiciel doit partager la VRAM.
• eval rate (jetons/s en génération) est la mesure qui gouverne l'expérience utilisateur, et se lit sur ollama run --verbose.
• La mémoire unifiée d'Apple Silicon efface la distinction RAM/VRAM et rend les Mac étonnamment compétitifs à budget matériel modeste.

Module suivant : intégrer ce moteur local à des applications existantes — script métier, LangChain, interface web.