MARKETIA

Ollama 0.40.6 testé pour de vrai : modèle qwen2.5:0.5b, mesures et limites (2026-10-18)

Test exécuté le 18 octobre 2026 (page rédigée le 18 octobre 2026).

Test d'usage réel mais limité : une machine, un jeu de test synthétique, aucune note ni classement. Les résultats ne se généralisent pas à d'autres données. Notre méthode.

Demander l'installation de Ollama sur devisRéponse sous 5 jours ouvrés, sans engagement. Aucun paiement à cette étape.

En résumé

Le 2026-10-18, nous avons téléchargé Ollama v0.40.6 (publiée le 2026-10-16), vérifié l'empreinte de l'archive, téléchargé le modèle qwen2.5:0.5b, puis mesuré trois questions en français, trois fois chacune, dans deux modes : avec la carte graphique et sur le processeur seul. Ce test porte sur une machine, une version, un modèle de 0,5 milliard de paramètres et neuf requêtes par mode : il décrit ce que nous avons observé et ne dit rien de la qualité d'Ollama avec des modèles plus gros. L'avis MagicMate sur Ollama donne le contexte de l'outil.

Précision de version : le comparatif « Exécuter un modèle de langage en local » cite la v0.40.7 (sortie le 2026-10-18), alors que ce test a été fait avec la v0.40.6 du 2026-10-16.

Ce que nous avons observé, dans l'ordre :

  • Chargement à froid du modèle : 32 194 ms avec la carte graphique (89 301 ms de temps mur pour la première requête), 1 065 ms sur le processeur seul (2 021 ms de temps mur). La cause de la lenteur côté carte graphique n'est pas établie.
  • Vitesse de génération, modèle chargé : environ 190 à 210 jetons par seconde avec la carte graphique (GeForce GTX 1650), environ 46 à 55 jetons par seconde sur le processeur seul.
  • Qualité des réponses : correcte sur deux questions sur trois sur le processeur ; la reformulation polie a changé le sens de la phrase. Avec la carte graphique, la réponse à la question sur la capitale de l'Australie commence bien puis devient fausse et incohérente.
  • À graine et température identiques, les textes obtenus avec la carte graphique ne sont pas ceux obtenus sur le processeur. La cause n'est pas vérifiée.
  • Réseau : le serveur écoute uniquement sur 127.0.0.1 et ne demande aucune authentification en local. Il a ouvert une connexion sortante vers une destination que nous n'avons pas identifiée dès le démarrage.

Protocole et commandes

Machine : Windows 11, Intel Core i5-10400F (6 cœurs, 12 threads), 31,9 Go de mémoire vive, carte graphique dédiée NVIDIA GeForce GTX 1650 (4 Go). Ollama l'a détectée et utilisée par défaut (CUDA). Nous avons donc mesuré deux modes : « gpu » (par défaut) et « cpu » (variables CUDA_VISIBLE_DEVICES=-1 et OLLAMA_VULKAN=0). Commandes en PowerShell. Aucun déplacement dans les dossiers téléchargés, aucune installation, aucun service : tout reste dans un dossier de travail $b (sous-dossiers dl, bin, models, out).

  1. Version et archive. Ollama v0.40.6 est publiée le 2026-10-16 (API GitHub, release la plus récente). Archive utilisée : ollama-windows-amd64.zip, 1 471 164 488 octets (1,47 Go). Il existe aussi un installateur OllamaSetup.exe (1,58 Go), que nous n'avons pas utilisé : aucun installateur exécuté.
  2. Vérification. SHA-256 calculé par nous : E359637575302F288D76C0007C408A4BE9C7376D59C4F28684D63B232A44B427, identique au champ digest de l'API GitHub. La release contient aussi un fichier sha256sum.txt, que nous n'avons pas comparé.
  3. Téléchargement et extraction : Invoke-WebRequest https://github.com/ollama/ollama/releases/download/v0.40.6/ollama-windows-amd64.zip -OutFile $b\dl\..., puis Get-FileHash ... -Algorithm SHA256, puis Expand-Archive vers $b\bin. Contenu extrait : ollama.exe (27,9 Mo) et un dossier lib (moteurs processeur, CUDA v13, llama-server). Cette archive embarque aussi le support des cartes NVIDIA ; les variantes -rocm et -mlx sont des archives distinctes.
  4. Serveur : $env:OLLAMA_MODELS="$b\models"; $env:OLLAMA_HOST='127.0.0.1:11500' puis Start-Process $b\bin\ollama.exe -ArgumentList serve -WorkingDirectory $b\out -WindowStyle Hidden, avec journaux redirigés dans out.
  5. Modèle : ollama.exe pull qwen2.5:0.5b (mêmes variables), puis GET /api/tags. Taille sur disque 397 821 319 octets (398 Mo), 494 millions de paramètres, quantification Q4_K_M. Digest du modèle (manifeste Ollama) : a8b0c51577010a279d933d14c2a8ab4b268079d44c5c8830c0a93900f1827c67. Le téléchargement affiche « verifying sha256 digest » puis « success ». Taille en mémoire rapportée par /api/ps : environ 484 Mo.
  6. Mesure : serveur redémarré à neuf pour chaque mode, 3 questions en français, 3 répétitions chacune, via POST /api/generate (stream=false, temperature=0, seed=1, num_predict=200). Questions : (1) « Quelle est la capitale de l'Australie ? » ; (2) « Reformule cette phrase de façon plus polie : Donne-moi le dossier tout de suite. » ; (3) « Combien font 17 multiplié par 23 ? ». Chargement = load_duration ; vitesse = eval_count / eval_duration ; temps mur au chronomètre. La toute première requête de chaque mode est le chargement à froid (modèle absent de la mémoire).
  7. Mémoire : somme, par sondage toutes les 50 ms, du WorkingSet64 des processus lancés depuis $b\bin. Écoute réseau : netstat -ano -p tcp filtré sur les identifiants de processus d'Ollama.
  8. Arrêt : processus arrêtés par chemin ; contrôle final : aucun processus ollama* ni llama* restant.

Résultats mesurés

Chargement à froid (première requête de chaque mode) :

ModeDurée de chargementTemps mur de la 1re requête
gpu32 194 ms89 301 ms (la requête a aussi généré 105 jetons à 8,6 jetons/s)
cpu1 065 ms2 021 ms

Le chargement à froid avec la carte graphique est très long (32 s de chargement, 89 s au total). Nous n'en avons pas déterminé la cause : le journal montre l'initialisation du moteur CUDA et une initialisation ou compilation GPU au premier lancement est possible, mais cela n'est pas vérifié. Une fois le modèle résident en mémoire, les requêtes suivantes le retrouvent en 5 à 7 ms.

Vitesse de génération, en jetons par seconde (modèle déjà chargé) :

Questiongpu (3 répétitions)cpu (3 répétitions)
1 capitale8,6 (à froid) / 202,8 / 201,855,4 (après chargement) / 54,6 / 46,9
2 reformulation196,6 / 202,0 / 208,846,6 / 47,9 / 49,8
3 calcul186,6 / 198,0 / 198,945,8 / 49,1 / 48,1

Ordres de grandeur : environ 190 à 210 jetons par seconde sur la GTX 1650, environ 46 à 55 sur le processeur seul. Temps mur d'une réponse courte une fois chargé : 0,46 à 0,87 s (gpu), 0,65 à 0,97 s (cpu). Questions de 41 à 52 jetons ; réponses de 12 à 18 jetons, jusqu'à 85 à 105 pour la question 1 en mode gpu.

Mémoire (working set, approximatif) :

  • Mode cpu : environ 489 Mo pour le processus runner llama-server et 32 Mo pour ollama serve, en pic.
  • Mode gpu : environ 557 Mo pour le runner et 52 Mo pour ollama serve, en pic. D'autres processus llama-server transitoires (133 à 260 Mo) apparaissent, probablement pour la détection des cartes graphiques (non vérifié). /api/ps indique size_vram = 483 645 193 octets en gpu (modèle entièrement en mémoire de la carte), 0 en cpu.
  • Une première série de mesures ne comptait que les processus nommés ollama* (pic de 306 Mo en gpu, 33 Mo en cpu). Elle ne voyait pas le processus runner llama-server.exe : ces deux valeurs sont sous-estimées et ne sont pas à citer.

Qualité des réponses (température 0, graine fixe), telle que nous l'avons jugée à la main.

Mode cpu, identique sur les 3 répétitions :

  1. « La capitale de l'Australie est Canberra. » : correct.
  2. « Je vous suggère de me le donner immédiatement. » : la reformulation change le sens (« le » ne désigne plus le dossier) et la phrase reste un ordre peu poli. Jugée incorrecte pour la tâche.
  3. « 17 multiplié par 23 donne 391. » : correct (17 x 23 = 391).

Mode gpu, mêmes questions et mêmes réglages, résultats différents :

  1. Début correct (« Canberra ») mais suite fausse et incohérente : « située dans l'ouest de l'Australie » (faux), « 63 provinces et 10 départements », puis « l'ouest de l'Antarctique » aux répétitions 2 et 3. Réponse globalement incorrecte.
  2. « Je vous suggère de me donner le dossier immédiatement. » (répétitions 2 et 3) : même défaut que sur le processeur, un peu plus proche du sens.
  3. « 17 fois 23 est 391. » et « 17 multiplié par 23 donne 391. » : correct.

À graine et température identiques, le mode gpu ne donne pas les mêmes textes que le mode cpu et varie entre la 1re et la 2e répétition (la question 1 passe de 105 à 85 jetons). Nous n'en connaissons pas la cause (calculs sur carte graphique non déterministes, chargement à froid ou autre : non vérifié). Le mode cpu est reproductible à l'identique sur nos 9 requêtes. Les caractères « é » vus dans « multiplié » viennent du décodage de notre propre script PowerShell 5.1 (UTF-8 lu comme du Latin-1), pas du modèle.

Réseau et authentification

Observations locales uniquement ; nous n'avons tenté aucune connexion externe.

  • netstat : ollama serve écoute sur 127.0.0.1:11500 uniquement, pas sur 0.0.0.0. Le runner llama-server écoute sur un port local aléatoire (127.0.0.1:51824, 127.0.0.1:51845), lui aussi en boucle locale.
  • Authentification : aucune. GET /api/version, /api/tags, /api/ps et POST /api/generate répondent sans jeton, clé ni en-tête particulier, depuis la machine locale. Rien dans la configuration par défaut (journal « server config ») n'indique un mécanisme d'authentification. D'après ce que nous avons observé, tout processus ou utilisateur local qui peut joindre le port peut lister et utiliser les modèles. Nous n'avons pas testé /api/pull, /api/delete ni /api/create sans authentification, ni aucune exposition réseau : la portée réelle de l'issue #12665 sur un serveur exposé n'est donc pas vérifiée ici.
  • Le journal de configuration affiche OLLAMA_ORIGINS avec des origines autorisées par défaut : localhost, 127.0.0.1, 0.0.0.0 (HTTP et HTTPS, tous ports), plus app://*, file://*, tauri://*, vscode-webview://* et vscode-file://*. Nous n'avons pas testé le comportement CORS.
  • Connexion sortante : le processus ollama serve a ouvert une connexion TCP établie vers 34.36.133.15:443 dès le démarrage, observée à trois reprises (avant tout téléchargement de modèle, puis dans chaque mode), sans que nous l'ayons demandée. Le journal mentionne un « model recommendations cache » et OLLAMA_NO_CLOUD:false (« Ollama cloud disabled: false »). Nous n'avons identifié ni le contenu des échanges ni l'hôte exact ; nous ne tirons aucune conclusion sur la nature de cette connexion. Le téléchargement du modèle a lui aussi contacté le registre d'Ollama, ce qui est attendu.

Limites du test

  • Une seule machine (i5-10400F et GTX 1650 de 4 Go), une seule version (0.40.6), un seul modèle de 0,5 milliard de paramètres. Sa qualité n'est pas représentative de modèles plus gros.
  • Trois questions, trois répétitions, une seule série par mode ; aucune statistique. Les écarts entre gpu et cpu sont des observations, pas des conclusions.
  • Le chargement à froid mesuré (32 s en gpu) concerne un premier lancement avec un dossier de modèles neuf. Une seconde mesure à froid réellement indépendante (même processus redémarré, modèle déchargé) n'a pas été faite.
  • Mémoire par sondage toutes les 50 ms du working set (approximation ; la mémoire de la carte graphique n'est pas comptée). Température 0 avec graine fixe, num_predict=200, contexte par défaut de 4096 jetons (choisi par Ollama selon la mémoire de la carte).
  • Qualité jugée à la main sur 3 questions, sans score. Une seule langue (français).
  • Version : ce test porte sur la v0.40.6 ; le comparatif LLM local cite la v0.40.7, parue le 2026-10-18, que nous n'avons pas testée.

Ce que nous n'avons pas testé

  • Les gros modèles (7 milliards de paramètres et plus), et le comportement quand la mémoire de 4 Go de la carte ne suffit pas.
  • D'autres cartes graphiques (AMD avec ROCm, MLX, Vulkan seul) et d'autres systèmes.
  • Un Modelfile personnalisé, ollama create, l'import de fichiers GGUF, des quantifications autres que Q4_K_M, l'appel d'outils (le modèle annonce cette capacité), les embeddings, la vision.
  • L'exposition réseau réelle (OLLAMA_HOST=0.0.0.0), CORS, un proxy inverse, une authentification placée devant Ollama, les opérations d'administration sans authentification (pull, delete, create) et la vérification de l'issue #12665 elle-même.
  • La fonction « cloud » d'Ollama et la nature exacte du trafic sortant vers 34.36.133.15.
  • La charge concurrente, les longs contextes, la stabilité sur la durée.
  • La comparaison du fichier sha256sum.txt de la release avec nos fichiers.

Sources

Aller plus loin

Recevoir la newsletter Marketia