LLM local sur CPU : la douche froide
Des chiffres, pas une impression : ce que donne réellement un LLM local sur un VPS CPU-only, comparé au cloud. Quatrième article de la série.
Par Nicolas Cousin — Publié le 6 octobre 2026
LLM local sur CPU : la douche froide
TL;DR
Sur le VPS de la série (8 vCores, 24 Go RAM, CPU-only), j'ai chronométré ce qu'Ollama donne réellement, du prompt minuscule à la tâche de coding complète, et comparé au même type de question posée à un modèle cloud. Résultat : une question qui prend 3 secondes dans le cloud en a pris 4 min 44 en local via Hermes, et une tâche de coding a dépassé le quart d'heure. Le VPS exécute bien des modèles de 7B à 24B, mais « ça tourne » ne veut pas dire « c'est interactif ».
Sommaire
- Ce que j'ai mesuré, et ce que je n'ai pas mesuré
- Le coût du prefill, visible dès les petits prompts
- Hermes ajoute sa propre couche de latence
- Devstral 24B : la vraie douche froide
- Ce que la mémoire raconte
- Ce que ça change
Ce que j'ai mesuré, et ce que je n'ai pas mesuré
Ce n'est pas un benchmark scientifique modèle contre modèle : le matériel, le fournisseur cloud et le pipeline diffèrent d'une ligne à l'autre du tableau ci-dessous. Ce sont des temps observés en conditions réelles d'usage, sur mon VPS CPU-only, pendant que je construisais l'environnement décrit dans les articles précédents. Comme mesure d'expérience utilisateur, c'est-à-dire ce que ça fait vraiment d'attendre une réponse, c'est parlant :
| Test réel | Modèle | Temps observé | Remarque |
|---|---|---|---|
| Prompt direct minuscule (~18 tokens d'entrée) | Mistral NeMo | ~36 s | Déjà perceptible pour une interaction triviale |
| Prompt direct, ~2 225 tokens d'entrée | Mistral NeMo | ~2 min 20 s | Le coût du prefill devient évident |
| Question .NET simple via Hermes | Mistral NeMo | ~4 min 44 s | Orchestration + contexte Hermes aggravent la latence |
| Réponse de coding conséquente | Devstral 24B | ~16 min 27 s | Première vraie douche froide |
| Tâche multi-fichiers | Devstral 24B | ~18 min 28 s | Résultat pas exploitable comme vrai agent |
| Question simple équivalente | GPT-5.6 Sol (cloud) | ~3 s | Ordre de grandeur radicalement différent |
Le coût du prefill, visible dès les petits prompts
La première ligne du tableau à elle seule ne dit pas grand-chose : 36 secondes pour ~18 tokens d'entrée, c'est lent, mais on pourrait croire que c'est juste Mistral NeMo qui génère doucement. La deuxième ligne change la lecture : passer à ~2 225 tokens d'entrée, sans rien changer d'autre, fait grimper le temps à ~2 min 20.
Ces deux mesures ne séparent pas explicitement le temps d'ingestion du prompt (le prefill) du temps de génération de la réponse : l'écart pourrait en théorie venir en partie d'une réponse plus longue sur le deuxième test. Mais l'ordre de grandeur suggère fortement que le prefill pèse lourd : avant de produire le moindre token de réponse, le modèle doit d'abord ingérer tout le prompt, et sur CPU cette étape coûte cher, une étape qui grossit avec la taille du contexte d'entrée, pas seulement avec la taille de la réponse attendue.
Hermes ajoute sa propre couche de latence
La troisième ligne va dans le même sens que l'article précédent : une question comparable posée à Mistral NeMo, mais via Hermes plutôt qu'en appelant Ollama directement, prend ~4 min 44, davantage que le prompt brut à contexte comparable de la ligne précédente (~2 min 20). Ce n'est pas une mesure contrôlée (les deux prompts ne sont pas identiques), mais l'écart va dans le sens attendu : Hermes injecte son propre system prompt, ses définitions d'outils et l'historique de conversation avant même d'arriver à la question posée, et sur CPU, chacune de ces couches se paie en secondes de prefill supplémentaires.
Pour donner une échelle à ce chiffre : la même question posée à un modèle cloud (GPT-5.6 Sol) prend environ 3 secondes. Soit environ 95 fois plus long dans ce test précis, pour un cas d'usage interactif basique.
Devstral 24B : la vraie douche froide
Les temps précédents concernaient des questions simples. Sur une vraie tâche de coding, avec Devstral 24B, le temps grimpe à ~16 min 27 s pour une réponse conséquente, et à ~18 min 28 s pour une tâche répartie sur plusieurs fichiers, sans même que le résultat soit exploitable comme travail d'agent autonome, un sujet que je reprendrai plus en détail dans un article dédié à ces benchmarks agentiques.
C'est le moment où la question change de nature. En dessous de quelques minutes, on peut encore parler d'un inconfort d'usage. Au-delà d'un quart d'heure pour une tâche qui prendrait quelques secondes à quelques minutes dans le cloud, ce n'est plus un problème d'ergonomie : c'est un mode d'usage entièrement différent qu'il faut envisager.
Ce que la mémoire raconte
Le CPU n'est pas le seul facteur à surveiller sur un VPS à 24 Go de RAM. Quelques ordres de grandeur d'empreinte mémoire pour les modèles manipulés à cette étape de la série :
- Devstral 24B : ~14 Go
- GPT-OSS 20B : ~13 Go
- Qwen3-Coder 30B : ~18 Go
- GLM-4.7-Flash : ~19 Go
Ce sont des empreintes de poids du modèle, pas le coût du KV cache (le
contexte) évoqué dans l'article précédent avec num_ctx : les deux se
cumulent sur les mêmes 24 Go. Les modèles de cette taille rentrent dans le
budget mémoire du VPS, mais laissent d'autant moins de marge pour le
contexte que leurs poids en occupent déjà une grande partie.
Ce que ça change
Un VPS CPU à moins de 30 € par mois peut réellement exécuter des LLM de 7B à 24B : ce n'est pas une promesse en l'air, les modèles chargent, tournent et répondent. Mais « ça tourne » ne veut pas dire « c'est interactif ». Une question qui prenait quelques secondes dans le cloud en a pris plusieurs minutes en local, et une tâche de coding a dépassé le quart d'heure.
Ce résultat n'invalide pas le local : il invalide surtout l'idée de départ d'un copilote interactif tournant entièrement sur ce CPU. C'est cette distinction, entre usage interactif et usage différé, qui structure la suite : ce qu'Hermes fait de son mode background, quand on arrête d'exiger une réponse immédiate.