- Gemma 4 26B-A4B a été exécuté à une vitesse de lecture sur un serveur de 2016 avec un seul Intel Xeon E5-2620 v4, 128 Go de DDR3 et aucun GPU, grâce aux optimisations de
ik_llama.cpp
- Le passage décodeur d’un LLM est limité non par le calcul mais par la bande passante mémoire : le CPU passe beaucoup de temps à attendre que les poids suivants remontent de la RAM vers le cache
--spec-type mtp, --cpu-moe, --merge-up-gate-experts, --run-time-repack et d’autres options réduisent les goulets d’étranglement en environnement DDR3 via le décodage spéculatif MTP, le routage MoE et une disposition mémoire pensée pour le cache- D’après les logs, l’empreinte mémoire totale est de 82,355MiB ; sur le contexte complet de 262K, le cache KV à environ 56 Go dépasse les poids du modèle, à environ 25 Go
- Les outils boîte noire comme
ollama n’offrent ni le support modèle nécessaire ni assez de réglages fins ; sur du matériel ancien, il faut comprendre en profondeur le moteur d’inférence et la structure mémoire pour obtenir de bonnes performances
Environnement d’exécution et goulet d’étranglement principal
- Le serveur de test est du matériel réemployé, avec Intel Xeon E5-2620 v4 @ 2.10GHz, 8 cœurs / 16 threads, AVX2, 20MiB de cache L3, 2MiB de L2, 128 Go de DDR3 et aucun GPU
- Ce CPU ne prend pas en charge AVX-512, AVX-VNNI ni BF16, et ne dispose pas non plus de GPU intégré
- En inférence LLM, le passage décodeur qui génère les tokens un par un est surtout contraint par la bande passante mémoire plutôt que par le volume de calcul
- Pour calculer le token suivant, il faut déplacer en continu depuis la RAM vers les caches CPU et les cœurs les poids qui contiennent les connaissances apprises par le modèle ; le processeur passe donc plus de temps à attendre le déplacement des poids suivants qu’à faire les multiplications de matrices
- Ce « mur mémoire (memory wall) » est un obstacle majeur aux performances non seulement sur Xeon, mais aussi sur du matériel haut de gamme comme le H100
Les réglages d’exécution nécessaires au lieu d’outils boîte noire
- Lancer simplement
llama-cli dans un environnement DDR3 sans GPU est extrêmement lent, et laisse beaucoup de marge d’amélioration à cause d’optimisations pensées pour les cas d’usage GPU classiques
ollama peut ne pas prendre en charge le modèle requis et n’expose pas suffisamment de paramètres détaillés pour tirer réellement les performances vers le haut- En pratique, l’exécution n’est possible qu’en combinant les nombreux flags exposés par
ik_llama.cpp
- L’ensemble clé de flags est le suivant
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune
-sm graph -smgs -sas -mea 256 --split-mode-f32
-t 8 --parallel 8
--cpu-moe --merge-up-gate-experts
--flash-attn on --mla-use 3
--mlock --run-time-repack --no-kv-offload
Décodage spéculatif et optimisation MoE
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune utilise le vérificateur 26B avec un petit drafteur MTP construit en amont--draft-max 3 fixe un maximum de 3 tokens par draft, --draft-p-min 0.0 accepte toutes les probabilités, et --spec-autotune ajuste la longueur de chaîne selon la charge de travail- Lorsqu’on génère une longue chaîne de raisonnement, même si l’utilisateur ne voit au final qu’une réponse courte, chaque token de réflexion caché nécessite un passage décodeur complet
- Sur CPU, le coût du streaming des poids du vérificateur vers le cache est élevé, tandis que les couches actives du petit drafteur tiennent bien dans le cache L3 ; l’avantage du décodage spéculatif y est donc encore plus marqué
- Gemma 4 26B-A4B adopte une architecture MoE dans laquelle 8 experts sur 128 sont activés par token ; sur environ 25.2B de paramètres au total, seuls environ 3.8B sont actifs
--cpu-moe ajuste le routage à la hiérarchie de cache du CPU et réduit le cache thrashing causé par les allers-retours constants entre 128 experts, qui vident le cache et forcent de nouveaux chargements depuis la DDR3--merge-up-gate-experts fusionne l’up projection et la gate projection au sein des experts en une seule multiplication de matrices ; dans les logs, cela apparaît sous fused_up_gate = 1-t 8 correspond aux 8 cœurs physiques ; sur une charge limitée par la mémoire, utiliser les 16 threads SMT peut augmenter le coût d’ordonnancement plutôt que le débit
Verrouillage mémoire, réorganisation et découpage du graphe
--run-time-repack réorganise les matrices de poids juste avant l’inférence selon une disposition adaptée au cache CPU ; dans les logs, cela apparaît sous Repacked 265 tensors- Ce réglage paie quelques secondes au démarrage pour réarranger en RAM les tables de nombres dans un format plus lisible pour le CPU, afin d’exploiter au mieux la bande passante mémoire pendant la génération effective de texte
--mlock verrouille le modèle en RAM pour empêcher le système d’exploitation de le swapper sur disque- Si la limite memlock du noyau n’est pas assez élevée, des avertissements comme
failed to mlock 27628376064-byte buffer et Try increasing RLIMIT_MEMLOCK apparaissent ; ce n’est pas un problème propre au LLM mais au réglage ulimit par défaut
--no-kv-offload évite, dans un environnement sans GPU, toute tentative de déplacer le cache KV vers le GPU et le maintient en RAM système-sm graph tente un découpage du graphe de calcul à la verticale afin que plusieurs unités de traitement ou zones mémoire calculent en parallèle différentes parties d’une même couche- Dans cette exécution, le log
Split mode 'graph' is not supported for Gemma4 external MTP indique un repli sûr vers un découpage par couches
-sas indique une répartition de la charge entre sockets CPU physiques ou nœuds NUMA, et --split-mode-f32 force l’usage de la précision flottante 32 bits aux points intermédiaires qui sont recombinés après le découpage
Attention, usage mémoire et conclusion
- ikawrakow a écrit un kernel personnalisé pour traiter Flash Attention sur CPU, afin que la gestion de contextes lourds fonctionne sans GPU
--flash-attn on fusionne le softmax d’attention et la multiplication de matrices, ce qui évite d’écrire physiquement en RAM toute la matrice d’attention N×N et permet de calculer et consommer les données par petits blocs dans le cache--mla-use 3 active Multi-Head Latent Attention pour compresser Key et Value du cache KV en représentations latentes plus compactes- Les logs affichent
flash_attn = 1, fused_moe = 1, fused_up_gate = 1, confirmant que ces optimisations sont bien appliquées
- Selon les logs mémoire, le total sur l’ensemble des couches atteint 81,607.46MiB, et la mémoire requise pour les tenseurs du modèle et les caches est de 82,355MiB
- Sur le contexte complet de 262K, les poids représentent environ 25 Go et le cache KV environ 56 Go ; le cache KV est donc plus volumineux que le modèle
- Cette configuration charge un MoE de 25B paramètres et effectue du décodage spéculatif avec un drafteur MTP, afin de générer du texte à une vitesse de lecture sur un Xeon de 2016 avec DDR3 et sans GPU
- La conclusion est que, pour exécuter localement une IA moderne à poids ouverts, le goulet d’étranglement ne tient pas seulement au silicium, mais aussi à la compréhension du moteur d’inférence et de la structure mémoire ; avec le bon fork, une quantification bien calibrée et une bonne compréhension de l’architecture mémoire, cela reste possible même sur un vieux serveur
2 commentaires
Commentaires sur Hacker News
J’ai écrit ce billet par frustration face au manque de moyens pour faire tourner le nouveau modèle Gemma 4 Drafter et au fait que les outils grand public cachent les points de réglage des performances
Au final, j’ai réussi à faire tourner en vitesse de lecture un modèle MoE 26B récent sur un vieux serveur recyclé, sans GPU, avec seulement un Xeon E5-2620 v4 et 128GB de RAM DDR3
J’ai aussi mis en lien un modèle quantifié à la fin de l’article, mais il ne fonctionnera pas sans le fork ik_llama-cpp mentionné, et il faut voir un autre billet pour les détails
Je ne suis pas ingénieur machine learning, et le serveur est déjà bien occupé à servir de cache Nix, mais je peux répondre aux questions dans la mesure du possible
Pendant qu’un thread attend la DDR3, un autre peut s’exécuter
Je comprends aussi mal l’explication de
--cpu-moe. Si un expert contient environ 4.0GiB de paramètres et que le cache L3 ne fait que 20MiB, j’ai l’impression que même en optimisant l’ordre des experts on ne pourra pas réellement mettre ces paramètres en cacheComme d’autres l’ont dit, seuls certains Intel Xeon E5-2xxx v4 prenaient en charge la DDR3, et selon la documentation Intel, le E5-2620 v4 n’en fait pas partie
C’est une configuration double Xeon avec 128GB de DDR3, et les CPU sont 2 × Xeon E5-2697 v2 pour un total de 24 cœurs / 48 threads, donc c’est mieux en nombre de cœurs, mais l’écart réel n’est peut-être pas énorme
Le matériel prend la poussière, mais une Gemma à vitesse de lecture, c’est plutôt prometteur
Cherchez “chia farming” sur Amazon, mais ignorez les résultats sur les graines de chia
Aujourd’hui, le même matériel coûte environ 2,5 fois plus cher, mais reste bien moins cher qu’une machine DDR5 de génération actuelle
https://www.amazon.com/dp/B095TRGCSX
Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz, CPU en ligne 0-31, avec 128GB de RAMJe me demande si, avec 8 emplacements DIMM, la bande passante mémoire est vraiment meilleure. Pour l’instant, cette pauvre machine ne sert qu’à regarder YouTube
On n’y est pas encore, mais le point d’arrivée évident de la bulle actuelle, c’est que des modèles ouverts tournant sur du matériel local et des appareils deviennent “assez bons” pour la plupart des usages
Et à ce moment-là, tout ce qui se passe actuellement dans l’industrie tech pourrait s’effondrer complètement
En cas de vrai blocage, j’appellerai l’API de Claude, mais j’ai l’impression qu’un modèle local plus bête peut couvrir 80% de mes besoins
Les langages et techniques de programmation ne changent pas tant que ça, donc j’espère pouvoir l’utiliser au moins 5 ans, puis faire une mise à niveau quand on saura faire tenir des modèles plus intelligents dans la même VRAM
J’aime bien cette direction
Si ce n’est pas le cas, j’imagine que c’est parce que les labos IA vendent aujourd’hui leurs modèles à perte, donc pour Amazon, proposer du calcul à faible marge est moins intéressant que d’autres produits à forte marge
L’état actuel n’a peut-être même pas besoin d’aller jusqu’à l’exécution locale pour s’effondrer. Quand les labos IA n’auront plus leur piste de décollage financée gratuitement et devront vendre au-dessus du coût réel d’exécution, quiconque dispose de capacité de calcul aura intérêt à proposer un service de modèles ouverts moins cher à des prix de marché génériques
Tout le monde finira par avoir les modèles et la capacité de les faire tourner, et c’est pourquoi la pénurie de GPU joue en leur faveur
Leur espoir repose sur le fait que les grandes et petites entreprises déplacent tous leurs processus de travail dans le cloud, et que les employés rivalisent pour consommer le plus de tokens possible
Des modèles “assez bons”, combinés à la confidentialité et à la baisse du coût sur le long terme, c’est attractif
Paradoxalement, plus l’environnement d’exécution générique pour les agents de code s’améliore, plus le fossé protecteur de services comme Claude se réduit. Il est difficile de croire à quelle vitesse certains modèles ouverts ont rattrapé les modèles de pointe d’il y a seulement quelques mois
Le billet est bon et techniquement impressionnant. Je suis d’accord sur le fait qu’il faut comprendre la pipeline de build et pouvoir exécuter ça en local
En revanche, selon le prix de l’électricité, cela peut ne pas être rentable. Les vieux serveurs sont peu efficaces énergétiquement, et je pensais qu’un ancien serveur Xeon consommerait autour de 200W en charge, alors que le même modèle est proposé sur OpenRouter à 0.1/0.3 dollar par million de tokens, 76 tokens/s et 262k de contexte
En plus, ce genre de serveur est bruyant. Cela dit, mon estimation de 200W était sans doute trop élevée, et même si mes vieux serveurs Xeon consommaient beaucoup, je ne me souviens plus des modèles exacts
Les serveurs sont généralement bruyants, mais là aussi cela dépend de la configuration. Il existe beaucoup d’hébergement low cost basé sur ce type de puces, et c’est plus efficace énergétiquement qu’on ne le pense
Une configuration similaire dans un boîtier 4U avec de lents ventilateurs de 120mm passe très bien
Ça fait plaisir de voir que d’autres s’en rendent compte aussi. Je fais tourner Gemma 26B-A4B Q4 sur un Xeon de 2012 avec 16 à 24 Go de RAM dans un conteneur, et j’obtiens environ 8 à 12 tokens/s
Ça ne se compare pas à un grand contexte ni à une exécution sur GPU, et le décodeur d’images de
llama.cppest lui aussi bien plus lent que sur GPU, mais pour de petites tâches d’automatisation ou des questions de culture générale, ça suffit. C’est assez rapide pour suivre en lisant, donc l’attente se fait moins sentirLa config, c’est un build de
llama.cppavec OpenBLAS et OpenMP activés,OPENBLAS_NUM_THREADS=4,OMP_NUM_THREADS=4,unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL, cacheq8_0et contexte à 8192Il faut regarder les optimisations par CPU, comme AVX2, et j’ai essayé MTP rapidement sans gain de performances. On peut aussi ajuster la taille du lot du cache et du contexte, ou descendre jusqu’à Q2, et mieux vaut éviter de surallouer les threads. Je recommande de commencer par les valeurs par défaut ou par
llama-benchPendant les tests, j’ai fait tourner
gemma4:e4b-it-q4_K_M, qui tient entièrement dans 11 Go de VRAM, et j’ai dépassé les 50 tokens/s. Un modèle aussi petit n’est pas très utile pour coder, mais il peut servir à autre choseJ’aimerais créer un système de Wake-on-Use pour l’utiliser comme un ChatGPT personnel. Peut-être avec un Pi en proxy qui appelle un script Wake-on-LAN ; ça pourrait faire un projet de week-end sympa un jour
Le LLM que je laisse toujours allumé, c’est un
Gemma4:31bdense dont je n’arrive même pas à charger la moitié sur une 2060 12 Go ; c’est très lent mais la qualité est bonne, et comme c’est pour du traitement en file automatique, je ne reste pas à attendre la sortie. J’ai une autre 2060, mais si je branche les deux, le PC ne passe pas le POSTJ’ai envisagé un Mac Studio Pro pendant un moment, puis j’ai finalement pris cette voie. Une machine headless HP Z620 avec 192 Go de RAM ECC, deux Xeon E5-2680 v2, une Optane AIC, deux P102-100 de 10 Go de VRAM, un SSD de boot minimal sous Debian 12.6, et une vieille version figée de CUDA qui prend en charge les cartes Pascal
Je l’utilise à distance depuis le sous-sol via AMT/meshcommander, je lance
llama.cppet un frontend, puis j’y accède via le réseau local. Je teste Talkie, Qwen 3.6 27b et medgemma, et en choisissant la bonne quantification, les performances GGUF étaient globalement correctesLe coût total était inférieur à 500 dollars, mais j’ai acheté le serveur sur eBay l’an dernier, donc ce n’est peut-être plus le cas aujourd’hui
À l’avenir, si les LLM ternaires s’épanouissent, j’espère que ce vieux matériel pourra en fait héberger des modèles haute densité bourrés de connaissances. Même s’ils dépassent la RAM GPU et débordent sur l’Optane, ce n’est pas grave, car ce qui compte, c’est davantage la connaissance factuelle générale que la vitesse
Le plan final, c’est de tout configurer puis de le stocker dans une poubelle Faraday au sous-sol, pour en faire un oracle de « reconstruction de la civilisation » quand le monde s’effondrera. Évidemment, dans un tel scénario, l’électricité serait un problème, mais vu le prix dérisoire de ce matériel et le fait que l’IA récente est souvent vraiment exploitable, ça vaut le coup d’essayer
Le plus intéressant dans les progrès de l’IA, ce n’est ni l’AGI ni le dernier modèle d’une licorne de l’IA en particulier, mais ce qu’on peut faire tourner en local
Il y a 6 ans, on faisait tourner sur un gros PC gaming des modèles amusants mais pas très utiles ; aujourd’hui, on peut faire tourner sur un portable M5 quelque chose de 100 fois meilleur
Si le marché réagit au manque de mémoire et que les progrès de l’Apple silicon continuent au même rythme, ce qu’on pourra faire tourner en local dans 6 ans sera soit très intéressant, soit assez effrayant
Je ne sais pas non plus ce que cela implique pour les valorisations des entreprises d’IA. J’ai déjà posé une question du même genre à un employé de l’une d’elles lors d’un événement, et il a esquivé pour aller chercher un cocktail
Le secteur de l’IA est capitalistique, comme une vieille usine. Les datacenters coûtent cher, les modèles consomment énormément d’électricité, et le matériel interne doit être remplacé tous les 3 à 4 ans
Des modèles plus petits et spécialisés rognent les marges par le bas. Pour la transcription, la voix ou la détection d’images, pas besoin d’énormes modèles
Il n’y a aucune raison d’attendre des marges élevées comme dans le logiciel traditionnel, et la majeure partie des gains de l’IA ira aux consommateurs. En revanche, quelques géants comme Microsoft, Google, Amazon ou Meta peuvent peut-être viser un avantage de coût grâce aux économies d’échelle
Il ne faut pas forcément un très haut de gamme comme une 5080 : même avec un bon GPU gaming, on peut déjà faire tourner en local des modèles meilleurs que l’état de l’art du début 2025
Selon la tâche visée, il faudra peut-être changer de modèle, et les énormes modèles universels restent encore du domaine des datacenters
Mais la plupart des gens qui ont un emploi à plein temps et deux enfants n’ont ni le temps ni l’énergie de patcher et maintenir tout ça. Les systèmes deviennent toujours plus complexes et les bugs se multiplient. C’est l’éternel compromis entre liberté et commodité
La plupart des utilisateurs ne savent pas ce qu’est un LLM ni comment ça s’exécute. Beaucoup de ceux qui utilisent des LLM se contentent de ce qui leur est fourni au travail, et même les utilisateurs un peu plus avertis semblent très bien accepter de payer un abonnement à OpenAI ou Anthropic
Il y aura sans doute une petite mais fervente base d’utilisateurs de modèles à poids ouverts qui préféreront les LLM locaux, mais tous les autres continueront probablement à consommer ceux des grands fournisseurs. Ce pourrait être comparable au choix d’un système d’exploitation aujourd’hui : une minorité d’utilisateurs Linux face à la majorité sous Windows, macOS ou Chrome
Les jeux de 5 à 6 ans coûtent bien moins cher et tournent sur du matériel ordinaire. Mais l’industrie ne reste pas immobile pendant 5 ans, donc de nouveaux logiciels qui exigent un meilleur matériel continuent d’arriver
Le résultat indiqué par l’auteur du billet dans les commentaires est d’environ 12 tokens/s
C’est un effort bien plus impressionnant que ce que j’aurais cru possible sur ce matériel, mais on reste encore assez loin du niveau nécessaire pour une session interactive satisfaisante
Ils sont souvent 100 à 500 fois moins chers que les modèles de pointe, et il arrive même que le débit en tokens/s soit 2 à 5 fois plus rapide
Pour un usage en arrière-plan, ce serait tout à fait correct
Ça fonctionne, mais ce n’est pas un débit exploitable pour un travail sérieux
Le E5-2620 v4 est excellent. J’en utilise un depuis 10 ans, et j’ai renoncé à upgrader après avoir vu les prix actuels
Je l’ai associé à 64 Go de DDR4 et à une RX 9060 XT 16 Go, et les jeux tournent toujours vite. Sur DOOM The Dark Ages, le CPU est peut-être un léger goulot d’étranglement, mais à 60 fps ce n’est pas un problème
Faire tourner un petit LLM sur le GPU est évidemment le choix logique, et c’est cool de voir qu’avec un peu de tuning ça peut aussi bien tourner sur CPU
J’ai acheté un 2667 v4 pour 30 dollars il y a un mois, et il devrait apporter un gain de performance appréciable, mais je n’en ai pas encore eu besoin. Si je poussais davantage dans la direction LLM comme dans l’article, j’upgraderais probablement, car le 2667 peut gérer de la RAM un peu plus rapide
Je suis encore assez surpris par ce qu’on peut trouver sur le marché de l’occasion
Je ne m’attendais pas à ce que les prix de la RAM et des GPU explosent autant, mais j’ai eu de la chance sur le timing. J’envisage parfois de revendre la 1080 Ti pour attraper une 3080 autour de 300 dollars sur eBay, mais à part ça, ça a été une excellente mise à niveau
La machine consomme l’électricité comme du Coca Cola, mais en tant que station de travail elle fonctionne à merveille, donc je compte la pousser jusqu’à ce qu’elle rende l’âme
Avant, je pensais que les dommages liés à la chaleur tuaient les CPU au bout de 5 à 7 ans, et je me demande si cette hypothèse était fausse. Peut-être que les CPU modernes sont bien plus solides et robustes qu’avant
Il y a eu récemment un billet similaire à propos de l’optimisation des anciens Xeon
“High-Performance AI on a Budget: Optimizing llama.cpp for Qwen3.5 Inference on a Dual-GPU HP Z440”
https://news.ycombinator.com/item?id=47320244
De manière assez surprenante, Itanium semble aussi plutôt bien adapté aux LLM : https://medium.com/@tglozar/running-llama-inference-on-intel...
En y réfléchissant, ce n’est pas si étonnant
Le contenu est intéressant. J’ai un ancien système Xeon, je vais essayer moi aussi.