Modèle sans GPU : quand le CPU suffit vraiment

La plupart des guides sur l'IA locale commencent par une question : « Combien de VRAM me faut-il ? » C'est la bonne question si vous voulez de la vitesse. Mais ce n'est pas la seule. Il existe une seconde façon de pratiquer l'inférence locale qui est devenue pleinement légitime en 2026 : faire tourner le modèle uniquement sur le CPU, sans carte graphique dédiée. Ce n'est plus un pis-aller pour ceux qui n'ont pas de GPU, mais un choix raisonné qui fonctionne très bien pour une catégorie précise d'usages.

Dans cet article, nous vous disons quand le CPU suffit vraiment, à quelle vitesse vous pouvez raisonnablement vous attendre, comment mesurer votre matériel en cinq minutes et quelles manettes utiliser pour en tirer le meilleur. Nous ne répétons pas la théorie GPU contre CPU (il y a déjà un article dédié) : ici, nous parlons de pratique.

Pourquoi l'inférence sur CPU n'est plus un pis-aller

La raison est simple et mesurable. Décoder un jeton sur un CPU est un problème de bande passante mémoire, pas de calcul pur : pour chaque jeton, le processeur doit lire les poids du modèle depuis la RAM. Si votre RAM est assez rapide et que le modèle (quantisé) tient entièrement en mémoire, le CPU produit des jetons à un rythme constant et prévisible.

Faisons le compte. Une workstation moderne avec du DDR5 en double canal offre environ 60–70 Go/s de bande passante. Un GPU de milieu de gamme, la RTX 3060 12 Go, a 360 Go/s sur la VRAM. Prenez un modèle de 8B paramètres quantisé en 4 bits, soit environ 5 Go de poids :

• Sur CPU à 64 Go/s, la décodification tourne autour de 10–12 jetons par seconde.
• Sur la RTX 3060, à égalité de modèle, vous êtes entre 60 et 90 jetons par seconde.

Le rapport est grosso modo la bande passante : 64 contre 360. Le CPU ne perd pas parce qu'il est lent, mais parce qu'il lit les poids depuis un bus plus étroit. La différence est énorme, mais elle est structurelle et prévisible, pas aléatoire. Et pour un certain type d'usage, cette différence ne change rien.

Il y a aussi une seconde phase, le prefill, où le modèle lit votre prompt d'un coup. Là, le CPU perd beaucoup plus, car le prefill est un problème de calcul parallèle et le GPU gagne nettement. Si votre prompt est long, l'attente avant la première réponse est le point faible du CPU. En la gardant sous contrôle (prompts courts, contexte réduit), la limite devient gérable.

Quand le CPU suffit vraiment

Voici les cas où, à égalité de résultat, le CPU ne vous coûte rien.

1. Petits modèles, sous 4B. Un modèle de 0,5B à 4B quantisé en 4 bits pèse entre 0,4 et 2,5 Go. Sur CPU, vous le faites tourner à la vitesse d'une discussion : 20–40 jetons par seconde pour les plus petits. Pour les résumés, la classification, la réorganisation de texte, l'extraction de champs, les complétions courtes, c'est plus que suffisant. C'est là que le CPU ne fait pas que « suffire » : il gagne sur tout le reste — zéro coût, zéro installation, fonctionne sur n'importe quelle machine récente.

2. Conversation à basse fréquence. Si vous utilisez le modèle pour un certain nombre de questions par jour, avec des réponses moyennes à courtes, et que vous vous fichez que la première réponse arrive en une seconde ou en trois, le CPU est l'option la plus économique et la plus fiable. Ce n'est pas pour ceux qui veulent une expérience en temps réel, mais c'est tout à fait adapté à ceux qui utilisent l'IA locale comme outil de travail, pas comme chatbot réactif.

3. Travaux en lot et de nuit. Traduire un corpus, générer des métadonnées, faire des classifications de masse, produire des résumés de centaines de documents : ici, la vitesse n'est pas un problème, c'est le coût que vous acceptez de payer une nuit. Le CPU travaille à 8–15 jetons par seconde, et si le travail porte sur mille documents, vous le lancez le soir et le matin c'est fait. Pas d'abonnement, pas de pic de coût.

4. Edge et appareils toujours allumés. Raspberry Pi 5, mini-PC à 40–80 euros, vieil ordinateur portable avec 16 Go de RAM : ce sont les endroits où le CPU n'est pas la seule option, c'est l'unique option. Un modèle de 1–3B quantisé y tourne, lentement mais y tourne, et vous permet d'avoir un assistant toujours disponible sans envoyer de données à aucun serveur.

5. La fiabilité avant la vitesse. Dans un contexte de production modeste (un bot interne, un flux de tri, un résumateur sur des fichiers reçus par courriel), la variable la plus coûteuse n'est pas le temps de réponse, mais le fait que le système soit toujours là, sans dépendance externe. Le CPU, sur un mini-PC au ventilateur silencieux et à 8 W de consommation, est l'infrastructure locale la plus simple qui soit.

Quand le CPU ne suffit pas : pour la conversation réactive, les modèles au-dessus de 14–20B, la génération d'images, le haut débit. Dans ces cas, il faut un GPU, ou au moins une hybridation CPU+GPU qui couvre une partie du goulot.

À quelle vitesse pouvez-vous raisonnablement vous attendre

Voici des repères sur une workstation CPU typique (8 cœurs / 16 threads, DDR5 en double canal, RAM suffisante). Le vôtre sera différent : le facteur qui compte, c'est la bande passante de la RAM.

Modèle (4 bits)	Décodification	Prefill	Usage
0,5B – 1B	25–45 jet/s	100–300 jet/s	discussion, classification, complétion
3B – 4B	12–25 jet/s	50–150 jet/s	conversation légère, réorganisation de texte
8B (dense)	8–15 jet/s	20–60 jet/s	conversation acceptable, résumés
8B – 14B (MoE)	15–35 jet/s	30–80 jet/s	MoE : moins de poids actifs → plus rapide
14B – 30B	3–8 jet/s	10–30 jet/s	lot, usage non interactif
30B+	sous 5 jet/s	très lent	impossible pour usage interactif

Trois notes importantes. Premier point : les chiffres de décodification sont limités par la bande passante, donc ils dépendent presque linéairement de la bande passante de votre RAM. Passer du DDR4 en double canal (40 Go/s) au DDR5 en double canal (64 Go/s), c'est 50–60 % de jetons par seconde en plus. Deuxième point : les modèles MoE (mélange d'experts) sont une bonne surprise sur CPU, car pour chaque jeton ils n'activent qu'une fraction des poids totaux et lisent donc moins de mémoire : un MoE de 30B avec 3B actifs peut dépasser un dense de 8B. Troisième point : le prefill est là où le CPU souffre le plus ; si vos prompts sont longs, c'est là que vous perdez.

Comment mesurer votre matériel en 5 minutes

Ne vous fiez pas aux chiffres des autres : mesurez les vôtres. La procédure standard est celle-ci.

Téléchargez llama.cpp (compilez-le ou prenez un binaire), téléchargez un modèle GGUF de référence (Qwen3 8B Q4_K_M est la référence de fait), et lancez le benchmark intégré :

./llama-bench -m modele.gguf -p 512 -n 128 -t <thread>

Le benchmark vous donne trois nombres : pp512 (prefill de 512 jetons) et tg128 (décodification de 128 jetons). Ce sont vos repères. Refaites avec -t 4, -t 8, -t 16 pour trouver le point de décodification maximal : il coïncide généralement avec le nombre de cœurs physiques, pas logiques.

Puis vérifiez le goulot réel pendant l'usage :

perf stat -e cache-misses,cycles ./llama-cli -m modele.gguf

Si cache-misses est élevé et que les cœurs sont saturés mais pas la RAM, le goulot est la bande passante mémoire et il n'y a pas grand-chose à faire : soit un modèle plus petit, soit une RAM plus rapide. Si les cœurs n'atteignent pas 100 %, vous avez trop peu de threads ou une limitation SMT (hyperthreading) : essayez de réduire les threads. Si la RAM physique est épuisée (échange sur disque), le modèle ne tient pas : descendez la quantisation ou la taille.

La règle d'or : mesurez toujours votre matériel avec votre modèle et votre quantisation. Un 8B Q4_K_M sur une machine à 64 Go/s fait 11 jet/s ; le même modèle sur une machine à 40 Go/s en fait 7. La différence est de 33 %, et on ne la trouve sur aucun blog.

Les manettes pour presser le CPU

C'est ici qu'on récupère l'essentiel des performances. Quatre manettes, par ordre d'impact.

1. Threads et cœurs. Le nombre de threads optimal pour la décodification est presque toujours le nombre de cœurs physiques, pas logiques. Sur un CPU à 8 cœurs / 16 threads, -t 8 bat -t 16 dans la plupart des cas : le SMT double le comptage mais pas la bande passante. Testez et vérifiez avec llama-bench.

2. Quantisation. La quantisation en 4 bits (Q4_K_M) est le point d'équilibre : qualité encore élevée, taille divisée par deux par rapport au 8 bits, vitesse doublée. Descendre en Q3 ou Q2 gagne en vitesse mais perd en qualité de façon perceptible ; monter en Q5 ou Q8 n'a pas de sens sur CPU car le goulot est la bande passante. Le format GGUF est pensé précisément pour cela : un seul fichier, poids déjà quantisés, aucune dépendance.

3. Flash attention. La flash attention réduit la mémoire lue pendant la décodification et le prefill, avec un gain particulièrement marqué sur les contextes longs. Dans llama.cpp, on l'active avec le drapeau -fa : c'est une seule chose à ajouter à la ligne de commande et le bénéfice est mesurable. Si votre version est récente, activez-la et faites avant/après avec llama-bench : sur votre matériel, l'amélioration est plus prévisible que n'importe quel chiffre rapporté par un blog.

4. Décodification spéculative. La technique la plus élégante : un petit modèle (brouillon) produit une série de jetons rapidement, et le grand modèle les vérifie tous en une seule passe de prefill. Si le brouillon devine bien — et pour la plupart des tâches d'usage courant, c'est le cas —, le résultat est un multiplicateur de 2 à 3 fois sur la vitesse de décodification sans perte de qualité. Sur CPU, où la décodification est le goulot, c'est la manette la plus puissante.

Et une cinquième, pour les grands modèles : mmap. Mappager les poids en mémoire (--mmap) permet au système d'exploitation de charger en RAM uniquement les poids nécessaires et de laisser le reste sur disque. Cela signifie qu'un modèle qui ne tient pas en RAM peut tout de même tourner, à vitesse réduite mais pas nulle. Le compromis, c'est que chaque accès au disque est bien plus lent qu'un accès à la RAM : mmap est une porte de sortie, pas une solution.

Pour le serveur, Ollama gère déjà tout cela en arrière-plan : une seule commande ollama serve, et les modèles tournent avec la configuration adaptée à votre machine. La release v0.35.0 a aussi ajouté le support des modèles de décision de type Jev, qui produisent des sorties structurées pour la classification et l'évaluation — exactement le type de charge qui va très bien sur CPU. Pour les lots ou le serveur, vLLM supporte aussi le CPU (via OpenMP), même si son cœur est le GPU : c'est le bon choix si un jour vous voulez servir plusieurs utilisateurs en parallèle.

Le paysage en 2026

Le point, c'est ceci : l'inférence sur CPU en 2026 n'est pas un cas de niche. llama.cpp continue d'investir spécifiquement sur le côté CPU : la série de releases d'octobre (la plus récente est b11337) a élargi la matrice de backends pour CPU et edge — Snapdragon avec Adreno et Hexagon, OpenVINO, SYCL FP16, CUDA 13, Android — et les modèles deviennent toujours plus efficaces : les MoE réduisent la mémoire active, les quantisations deviennent plus agressives sans perdre en qualité.

Et le mouvement va dans la bonne direction côté modèles : Cloudflare a rendu public clef, un modèle de 27B qui transforme un état et un ensemble de questions typées en décisions structurées — une probabilité par option en une seule passe, sans génération de texte libre — avec une variante plus petite et plus rapide (clef-flash) pensée pour les charges à faible latence. Ce n'est pas un chatbot : c'est exactement la classe de modèles — sorties structurées, inférence courte, latence minimale — qui fonctionne bien sur CPU. La frontière entre « modèle pour GPU » et « modèle pour CPU » se déplace vers le haut, et les modèles compacts et MoE à poids actifs faibles deviennent la classe la plus intéressante pour l'inférence locale sur CPU.

La question n'est plus « puis-je faire tourner un modèle sans GPU ? ». La question est : « mon usage précis a-t-il besoin de plus de 15 jetons par seconde ? ». Si la réponse est non, le CPU ne fait pas que suffire : c'est le meilleur choix.

En synthèse

• Le CPU est suffisant pour les modèles sous 4B, la conversation à basse fréquence, les travaux en lot, l'edge et la fiabilité.
• La décodification sur CPU est limitée par la bande passante : la vitesse dépend de la bande passante de la RAM, pas de la fréquence du processeur.
• Les modèles MoE sont la surprise : moins de poids actifs → plus rapide à égalité de paramètres totaux.
• Mesurez toujours avec llama-bench les chiffres prefill et décodification de votre configuration.
• Les manettes par ordre d'impact : threads = cœurs physiques, quantisation Q4_K_M, flash attention, décodification spéculative.
• Pour le serveur : Ollama pour l'usage unique, vLLM pour le lot et le multi-utilisateur.
• La frontière entre « modèle pour CPU » et « modèle pour GPU » se déplace vers 20–30B : en 2027, le CPU fera tourner des modèles que vous considérez aujourd'hui comme réservés au GPU.

Article généré par IA