Ollama sans GPU : jetons par seconde du Nano au Scale

De qwen3:0.6b à qwen3:14b, huit modèles mesurés sur chacune de nos formules, même question et mêmes réglages. Ce qui tient en mémoire, la vitesse réelle, pourquoi 8 vCPU ne vont pas deux fois plus vite que 4, et quel modèle pour quelle formule.

Par l'équipe FFxF Publié le 27 octobre 2026 6 min de lecture

Une puce de processeur d'où sort un flux de jetons, sans carte graphique

Un VPS sans carte graphique peut-il faire tourner un modèle de langage assez vite pour servir à quelque chose ? Plutôt que de deviner, nous avons mesuré : huit modèles avec Ollama, sur chacune de nos quatre formules, même question, mêmes réglages. Voici les chiffres, ce qu'ils donnent en pratique, et quelle formule prendre pour quel modèle.

1. Comment nous avons mesuré

Une VM commandée comme la vôtre, Ubuntu 24.04 depuis notre image, redimensionnée tour à tour à chaque formule : Nano (1 vCPU, 2 Go), Starter (2 vCPU, 4 Go), Pro (4 vCPU, 8 Go) et Scale (8 vCPU, 16 Go). La VM voit un processeur Intel Xeon Gold 6252 avec AVX-512, dont se sert llama.cpp, le moteur d'Ollama. Ollama 0.40.3, quantification par défaut de chaque modèle (Q4), aucune carte graphique nulle part.

Pour chaque modèle : une question d'un paragraphe, 128 jetons de réponse, température 0. Une première requête charge le modèle, puis deux requêtes mesurées ; les chiffres ci-dessous sont leur moyenne. Les deux passages n'ont jamais différé de plus de 12 %. Chaque requête commence différemment, pour qu'Ollama ne puisse pas réutiliser le prompt précédent depuis son cache.

2. Vitesse de génération, en jetons par seconde

Modèle	En mémoire	Nano	Starter	Pro	Scale
`qwen3:0.6b`	0,8 Go	14,1	21,4	38,7	43,6
`gemma3:1b`	0,9 Go	8,3	14,8	23,9	27,2
`llama3.2:3b`	2,3 Go	ne tient pas	6,6	9,8	13,4
`hermes3:3b`	2,3 Go	ne tient pas	6,7	9,8	13,9
`qwen3:4b`	2,9 Go	ne tient pas	5,1	8,9	11,9
`hermes3:8b`	5,0 Go	ne tient pas	ne tient pas	5,2	8,0
`qwen3:8b`	5,6 Go	ne tient pas	ne tient pas	4,3	6,9
`qwen3:14b`	9,8 Go	ne tient pas	ne tient pas	ne tient pas	4,2

« En mémoire », c'est ce qu'affiche ollama ps une fois le modèle chargé avec un contexte de 2 048 jetons. « Ne tient pas » se prend au pied de la lettre : le modèle et le système ne rentraient pas dans la mémoire de la formule. Ollama ne ralentit pas dans ce cas. Soit il s'en aperçoit à temps et refuse, soit le noyau l'arrête et la requête échoue :

log

llama-server process has terminated: exit status 1: ggml_aligned_malloc: insufficient memory
Remote end closed connection without response

Comptez environ 1 Go pour le système et Ollama en plus du modèle, davantage si vous allongez le contexte.

3. Plus de cœurs, moins de gain qu'on ne croit

Passer de 2 à 4 vCPU accélère la génération de 1,5 à 1,8 fois. Passer de 4 à 8 n'ajoute que 13 % sur les plus petits modèles, et de 34 à 60 % sur ceux de 3 à 8 milliards de paramètres. Écrire chaque jeton demande de relire tout le modèle en mémoire : au-delà de quelques cœurs, c'est la bande passante de la mémoire qui donne le rythme, pas le processeur.

La lecture de votre prompt, elle, se comporte autrement : le modèle traite tous ses jetons d'un coup, et ce travail profite des cœurs. Sur les modèles 8B, le Scale lit le prompt 1,8 fois plus vite que le Pro :

Lecture du prompt, jetons/s	Starter	Pro	Scale
`qwen3:0.6b`	151	291	428
`llama3.2:3b`	39	76	122
`qwen3:4b`	24	46	74
`hermes3:8b`	ne tient pas	23	43
`qwen3:14b`	ne tient pas	ne tient pas	26

Ça compte dès que l'entrée est longue. Faire résumer un document de 2 000 jetons à un modèle 8B sur le Pro, c'est environ 85 secondes avant le premier mot de la réponse ; sur le Scale, environ 45.

4. Ce que ces vitesses donnent à l'usage

On lit en moyenne autour de 240 mots par minute, soit à peu près 5 jetons par seconde. D'où une échelle simple :

Au-dessus de 10 jetons/s : la réponse s'affiche plus vite que vous ne la lisez. Une conversation paraît instantanée.
De 5 à 10 jetons/s : vous lisez au fil de l'écriture. Très bien pour un assistant consulté de temps en temps.
Sous 5 jetons/s : vous attendez. Gardez-le pour les tâches que personne ne regarde : trier des courriels la nuit, extraire des champs de documents, un robot qui répond dans la minute.

La première requête après une pause paie aussi le chargement du modèle depuis le disque : 7 secondes pour qwen3:0.6b, 33 pour hermes3:8b, 98 pour qwen3:14b sur le Scale. Par défaut, Ollama décharge un modèle après cinq minutes d'inactivité ; OLLAMA_KEEP_ALIVE le garde plus longtemps en mémoire, comme l'explique notre guide Hermes et Ollama.

5. Quelle formule pour quel modèle

Formule	Plus gros modèle qui tient	Pour
Nano, 8,50 CAD/mois	1B	des petites tâches avec un modèle de 0,6B à 1B : étiqueter, répondre court, un robot qui trie des messages
Starter, 16 CAD/mois	3B à 4B	un assistant privé à vitesse de lecture, des extractions simples
Pro, 30 CAD/mois	8B	le meilleur rapport : les modèles 3B à 4B à vitesse de conversation, un 8B pour le travail de fond
Scale, 56 CAD/mois	14B	un 8B à vitesse de lecture, les longs documents, un 14B quand la qualité compte plus que la vitesse

Facturé à l'heure, un Scale coûte 0,116 CAD de l'heure : de quoi essayer un modèle tout un après-midi avant de choisir. Au-delà de 14B, ou pour beaucoup d'utilisateurs à la fois, un processeur n'est plus le bon outil.

6. Le mesurer sur votre machine

Ollama renvoie ses propres temps. La vitesse de génération, c'est eval_count divisé par eval_duration, exprimé en nanosecondes :

bash

curl -s http://127.0.0.1:11434/api/generate \
  -d '{"model": "qwen3:4b", "prompt": "Explique ce qu'"'"'est un VPS.", "stream": false, "think": false,
       "options": {"num_predict": 128, "temperature": 0}}' |
  jq '{jetons: .eval_count, jetons_par_s: (.eval_count / (.eval_duration / 1e9)),
       prompt_jetons_par_s: (.prompt_eval_count / (.prompt_eval_duration / 1e9))}'

Lancez-la deux fois et gardez le second résultat : le premier comprend le chargement du modèle.