GPU ou CPU : quand la CPU suffit

Quand on parle d'IA locale, le réflexe est toujours le même : « combien de VRAM me faut-il ? » Dans beaucoup de cas, cependant, la question est la mauvaise. La réponse dépend de ce que vous voulez faire, et pour un nombre croissant de scénarios, la CPU est largement suffisante — même sur du matériel que vous n'auriez jamais pensé utiliser.

Dans cet article, on clarifie le trade-off : ce qui fait vraiment la différence entre CPU et GPU, quand vous pouvez passer sans GPU, et comment mesurer vous-même les chiffres sur votre matériel.

Comment fonctionne l'inférence : deux phases, un goulot d'étranglement

Chaque requête à un LLM passe par deux phases :

1. Prefill : le modèle lit le prompt (les tokens d'entrée) d'un coup. C'est la phase qui détermine la latence du premier token — la fameuse latence du premier token.
2. Decode : le modèle génère la réponse, un token à la fois. C'est la phase qui détermine la vitesse d'affichage du texte (les fameux tokens par seconde).

Les deux phases ont des exigences différentes, et c'est là que se joue toute la question CPU contre GPU.

Prefill : celui qui calcule gagne

Le prefill est un problème de puissance de calcul pure : d'énormes multiplications de matrices qu'un GPU exécute en parallèle sur des milliers de cœurs. Un GPU dédié fait le prefill jusqu'à un ordre de grandeur plus vite qu'une CPU : sur un prompt long, le premier token arrive en un éclair avec un GPU, mais peut mettre quelques secondes avec une CPU.

Decode : celui qui lit la mémoire gagne

La génération token par token est un problème différent : pour chaque token, le modèle doit relire tous les poids (et le KV cache) depuis la mémoire. La vitesse de génération dépend presque uniquement de la bande passante mémoire — combien d'octets par seconde vous pouvez lire.

Et c'est ici que la CPU tient sa partie :

• les mémoires DDR5 dual ou quad channel atteignent 50–100 Go/s ;
• la VRAM d'un GPU grand public monte à 300–1000 Go/s ;
• la mémoire unifiée d'un Apple Silicon dépasse les 800 Go/s.

Concrètement, pour les petits et moyens modèles (de 1 à environ 8 milliards de paramètres en quantisation Q4), une CPU moderne multi-canaux génère des tokens à des vitesses parfaitement utilisables : 5 à 20 tokens par seconde selon le modèle. C'est le rythme d'une personne qui lit à voix haute : largement suffisant pour des conversations, des résumés et des tâches courtes.

Quand la CPU suffit

1. Petits modèles (0,5 à 4 milliards de paramètres)

En dessous de 4 milliards de paramètres quantisés, les poids occupent 0,5 à 3 Go de RAM : ils entrent dans le cache de niveau 3 du processeur et la bande passante mémoire n'est même pas une limite. Sur un portable de 5–6 ans avec 12 Go de RAM, un modèle de 1 milliard génère plus de 20 tokens par seconde.

2. Usage interactif avec des réponses courtes

Chat du quotidien, reformulations, classification, extraction de données : les réponses courtes ne souffrent pas de la lenteur du prefill, et la génération sur CPU est fluide.

3. Charges par lots et nocturnes

Si le modèle doit traiter des documents, étiqueter des données ou générer des rapports pendant que vous dormez, la vitesse n'est pas l'objectif : c'est le coût. Une CPU consomme 50–150 W contre 300–600 W pour un GPU de gaming, et ne produit ni chaleur ni bruit.

4. Le matériel est déjà à la maison

Si votre portable n'a pas de GPU dédié (et la grande majorité des portables grand public n'en ont pas), l'IA locale reste accessible. Pas besoin d'acheter quoi que ce soit : il faut de la RAM.

5. Raspberry Pi et edge

Sur un Raspberry Pi 5, un modèle de 0,5 à 1 milliard génère 5 à 10 tokens par seconde : peu pour une chat, parfait pour l'automatisation, les déclencheurs vocaux et les assistants hors ligne qui répondent aux commandes.

6. La fiabilité d'abord

En environnement de production (un serveur à la maison, une automatisation), la CPU est la solution la plus stable : aucun driver à mettre à jour, aucune erreur « out of memory » de la VRAM, une consommation prévisible.

Quand il vous faut un GPU

• Grands modèles (13, 30, 70 milliards et plus) : la mémoire système ne tient pas la cadence — 70 milliards en Q4 demandent environ 40 Go et descendent à 1–2 tokens par seconde sur CPU. Avec 24 Go de VRAM (RTX 3090/4090), les tokens arrivent à 20–30 par seconde.
• Prompts longs ou contexte étendu : le prefill sur CPU pour 100 000 tokens peut prendre des dizaines de secondes.
• Beaucoup d'utilisateurs en parallèle : le débit par utilisateur s'effondre sur CPU dès que deux ou trois requêtes se chevauchent.
• Latence du premier token critique : assistants en temps réel, outils qui attendent la première réponse.

Chiffres réels : à quoi vous attendre

Test de référence sur un portable Intel i5 de milieu de gamme (12 Go de RAM, sans GPU utile), avec Ollama et des modèles quantisés Q4_K_M :

Modèle	Taille du fichier	Vitesse de génération
Qwen3 0.6B	~0,5 Go	34–36 tok/s
TinyLlama 1.1B	~0,6 Go	25–28 tok/s
Gemma 3 1B	~0,8 Go	~18 tok/s
Gemma 4 E2B	~7 Go	~10 tok/s
Granite 4 3B	~2 Go	8–9 tok/s
Phi-4 Mini 3.8B	~2,5 Go	~7 tok/s
OpenHermes 7B	~4 Go	4 tok/s
Ministral 3 8B	~6 Go	3 tok/s

La règle est simple : en dessous de ~10 tokens par seconde, la conversation commence à peser ; au-dessus de 20, elle est fluide. Et les chiffres évoluent avec la bande passante mémoire : une station de travail dual-socket avec 12 canaux DDR5 (ou un Mac à mémoire unifiée) génère 5 à 10 fois plus de tokens par seconde sur le même modèle qu'un portable.

Mesurez votre matériel en 5 minutes

Avec Ollama :

ollama run qwen3:4b --verbose

Le flag --verbose affiche eval rate (tokens/s de génération) et prompt eval rate (tokens/s du prefill).

Avec llama.cpp, pour forcer la CPU (aucune couche sur le GPU) :

llama-server -m qwen3-4b-q4_k_m.gguf -ngl 0 -t 8 --port 8080

Puis interrogez l'API :

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen3","messages":[{"role":"user","content":"Raconte une blague"}]}'

Les deux chiffres à noter : eval rate (vitesse de réponse) et time to first token (vitesse du prefill). Si l'eval rate dépasse 10 tokens par seconde et que votre cas d'usage n'a pas d'énormes prompts, la CPU vous suffit.

Règles pratiques pour exprimer la CPU

1. La RAM avant tout : les poids + le contexte doivent tenir en RAM. Comme estimation, 1 Go par milliard de paramètres en Q4, plus 0,5–1 Go de marge.
2. Threads = cœurs physiques, pas cœurs totaux. Une CPU de 8 cœurs/16 threads tourne mieux avec -t 8 qu'avec -t 16.
3. La quantisation Q4_K_M est le meilleur compromis : quasi la qualité de Q8, deux fois la vitesse.
4. Contexte modéré : le KV cache grandit avec le contexte. Si vous n'avez pas besoin de 32 000 tokens, n'en allouez pas.
5. Le dual channel vaut de l'or : deux barrettes de RAM au lieu d'une double la bande passante, et avec elle les tokens par seconde.
6. Sur les systèmes multi-socket, épinglez les threads sur un seul nœud NUMA : lire la RAM de l'autre socket coûte jusqu'à 30 % de vitesse.

Le cas Apple Silicon

Un Mac moderne est le contre-exemple parfait : le GPU intégré est rapide, mais la mémoire est unifiée — CPU et GPU lisent les mêmes octets. Un modèle qui « ne tient pas en VRAM » tient très bien en RAM sur un Mac avec 32–64 Go, et tourne à des vitesses de GPU. Si vous avez un Mac, la question « CPU ou GPU ? » devient sans objet : en mesurant, vous découvrez que le modèle est plus rapide que vous ne l'attendiez.

En synthèse

Scénario	Le bon choix
Chat avec des modèles de 0,5 à 4 milliards	CPU, sans y penser
Automatisation par lots	CPU (coût + silence)
Portable sans GPU	CPU (l'unique option — et elle fonctionne)
Raspberry Pi / edge	CPU
Modèles de 13 milliards et plus en qualité	GPU (ou Mac à mémoire unifiée)
Prompts longs, beaucoup d'utilisateurs	GPU

Le GPU n'est pas le ticket d'entrée pour l'IA locale : c'est une option qui compte quand la qualité ou la vitesse l'exigent. Votre matériel actuel, avec les bons modèles, est probablement déjà suffisant. Testez les chiffres sur votre machine, puis décidez.

Article généré par IA