Sommaire
- Introduction
- Vocabulaire
- La problématique des vitesses d'inférence
- Les modèles Mixture-of-Experts
- Élément de comparaison : les IA cloud
- Attention, benchmarks droit devant !
- Méthodologie
- 5 cartes graphiques Nvidia RTX 3060 12Go
- CPU et RAM uniquement
- Sur une Nvidia RTX 3060 12Go, avec débordement
-
Sur une Nvidia RTX 3060 12Go, avec débordement, avec
--cpu-moe - Modèles plus gros que la RAM
mmap()et--no-mmap- Sur une seule Nvidia RTX 3060 12Go, sans débordement, avec des petits modèles
- AMD RX 9070 XT 16Go
- Intel Arc Pro B60
- Conclusion globale
- Hors-sujet : mmproj en RAM
- Hors-sujet : Quantification chez openrouter.ai
- Hors-sujet : Versions anglaises
Introduction
Ce journal est dans le prolongement de mes précédents journaux :
- Auto-héberger ses IA : Principes généraux
- Auto-héberger ses IA : Matériel et optimisation de l'inférence
Dans ce journal, on va parler de faire de l'inférence avec des LLM, avec pas ou peu de VRAM. Autrement dit, on va essayer de faire rentrer une grosse pièce carrée dans un petit trou rond.
Comme moi, vous avez peut-être observé quelque chose d'étrange : Il y a plein de vidéos Youtube, de publications LinkedIn, etc. qui vous disent que c'est super simple de faire tourner des LLM sur une pièce de musée (genre Nvidia GTX 1060 6 Go avec de la DDR4). Ils vous expliquent que ça tournera super vite, super bien, etc. Apparemment, il faut juste trouver les paramètres magiques qui vont bien, et pouf ! Plus jamais besoin de Claude Fable 5 ! 🎉
Mais alors, pourquoi tous les développeurs ne font pas juste ça ? En plus, il y a un mec qui l'a bien expliqué : Tous les fadas de LLM courent désespérément après les plus grosses cartes graphiques, tant qu'ils peuvent les acheter sans devoir vendre leurs enfants.
Du coup, c'est suspect, et votre bon sens doit vous picoter pas mal.
Vocabulaire
Quelques gros mots qui vont être pas mal utilisés dans ce journal :
- LLM : une IA qui génère du texte ;
- token : un bout de mot (typiquement une syllabe par exemple) ;
- le contexte : votre discussion avec votre LLM préféré ;
- le préremplissage (prefill) : la (re)lecture du contexte par le LLM ;
- la prédiction de tokens : la génération de mots par le LLM.
La problématique des vitesses d'inférence
Mesurer la vitesse de la prédiction des tokens, avec un contexte presque vide, c'est trivial. N'importe quel Youtuber, influenceur LinkedIn ou autre amibe mononeuronale sait le faire, et … ne fait souvent que ça. Donc en bonne amibe bineuronale, je vais le faire aussi 😁. On va généralement considérer qu'un modèle est utilisable à partir de 10 tokens/s (c'est en fait assez optimiste, mais soyons généreux).
Et poussons les choses plus loin : Pour ce journal, mon objectif est de voir aussi, en fonction de la taille du contexte, s'il y a une dégradation des performances. Plus important encore, ce n'est pas juste la prédiction des tokens qui m'intéresse, mais aussi le préremplissage avec un contexte existant. Pour certaines utilisations, on se tape du préremplissage (simple conversation, etc.), mais pour d'autres, la vitesse de préremplissage est très importante. Quelques exemples :
- Domotique : Avec Home Assistant, si vous exposez beaucoup d'appareils au LLM, ça fait beaucoup de tokens d'outils en plus à lire au début de chaque conversation. Chez moi, 13 entités exposées impliquent un contexte initial de 2500 tokens. Or un assistant vocal doit être très réactif (passé 5 mississippis, je considère que la personne moyenne s'impatiente).
- Programmation agentique : Le début d'une session, c'est tout de suite ~8k tokens d'outils dans mon cas.
- Toujours en programmation agentique : À chaque fois que l'agent va appeler un outil, il va potentiellement se prendre une grosse sortie d'une commande ou un bout de fichier conséquent. À chaque fois, il va se prendre facilement 1000 à 10000 tokens à relire (si pas plus).
- Discussion Open-WebUI avec quelques outils activés : Le début d'une conversation, dans mon cas, c'est ~20k tokens d'entrée de jeu (oui, je l'ai chargé comme une mule ^^).
- Résumé de document : Pour vous résumer un PDF de 100 pages (genre d'une boite de consulting, que votre entreprise aurait embauchée pour la conseiller de faire ce que vous aviez déjà prévu de faire), le LLM doit se taper environ 45k tokens.
Et il y a pire : Si vous avez interrompu votre conversation ou votre session de programmation agentique la veille, alors que le contexte était presque plein. Quand vous voudrez la reprendre, votre LLM va devoir se refarcir tout le contexte existant. Pour la suite, on va partir sur 64k tokens, mais gardez à l'esprit que ça peut être nettement plus.
Est-ce que vous commencez à deviner le piège dans lequel beaucoup de gens tombent ? 🧐
Les modèles Mixture-of-Experts
Le premier truc qu'on peut remarquer, c'est que ces fameuses vidéos Youtube et autres vous invitent toujours à utiliser des LLM Mixture-of-Experts, et non pas des LLM denses.
Dans mon premier journal, je disais qu'un MoE (Mixture-of-Experts), c'est en fait un ensemble de sous-LLM spécialisés ("experts"), et c'est un 1er réseau de neurones qui décide vers quel autre LLM envoyer la requête. En fait, cette description est hyper-simplifiée. Il y a notamment une alternance entre les couches des experts et les couches d'attention. Mais dans le cadre de ce journal, on va rester sur cette vision simplifiée des modèles MoE.
Il faut savoir surtout une chose : Pour chaque LLM MoE, son développeur indique le nombre maximum de paramètres actifs simultanément (par exemple, A3B pour Qwen-3.6 35B, A10B pour Qwen-3.5 122B, A4B pour Gemma-4 26B, etc). Mais attention, on parle du nombre de paramètres actifs pour traiter un seul token ! D'un token à l'autre, c'est d'autres jeux d'experts/paramètres qui seront sollicités. Donc, pour traiter|générer chaque token individuellement, on gagne clairement en vitesse de calcul. Mais pour traiter un prompt ou générer toute une sortie, on doit quand même avoir l'intégralité du modèle chargé en VRAM/RAM.
Sur l'exemple beaucoup trop sursimplifié ci-dessus, on parlerait d'un modèle MoE avec 36 paramètres, dont 20 actifs simultanément.
Clairement, à taille égale, les MoE sont donc bien plus rapides que les modèles denses, qui eux sollicitent l'essentiel de leurs paramètres à chaque token. Ils sollicitent aussi nettement moins la bande passante de la VRAM/RAM. Ils sont en fait si rapides que l'idée de déborder de la VRAM et d'utiliser aussi le CPU et la RAM pour en faire tourner de plus gros n'est pas forcément absurde.
Leur gros inconvénient, c'est qu'à nombre de paramètres égaux, ils sont plus bêtes que des modèles denses. Par exemple, Qwen 3.6 35B A3B est notablement plus bête que Qwen 3.6 27B.
Toutefois, on peut noter que les gros LLM (>1T) sont souvent des MoE. Cette architecture rend leur inférence nettement moins couteuse. Or, ils sont loin d'être bêtes. Ils compensent leur bêtise proportionnelle en étant énormes et en ayant un grand nombre de paramètres actifs simultanément (A40B pour GLM-5.2 par exemple). Autrement dit, un petit dense bat un plus gros MoE, mais un beaucoup plus gros MoE 💪 prend le petit dense 🖐️, le retourne 🔄, et le fume 🚬.
En plus, un très gros modèle tolère mieux la quantification qu'un petit. On peut théoriquement taper sur du très gros modèle en q2 et toujours avoir quelque chose de correct.
Et c'est là que le commentaire de Andréas Livet sur mon précédent journal m'a fait beaucoup trop réfléchir. Et si, pour l'auto-hébergement, j'avais sous-estimé l'utilité des MoE ? Et si ces vidéos Youtube disaient vrai ? Et si on pouvait faire tourner de façon fiable un gros MoE comme Qwen-3.5 122B sur du matériel consommateur ? Peut-être même plus gros encore ? Et où se trouve la limite ? GLM-5.2 pourrait-il fonctionner sur ma machine ? Bref, comme cette idée m'a fait bizarrement saliver 🤤, il fallait que je la teste.
Élément de comparaison : les IA cloud
On va prendre pour référence les vitesses d'LLM cloud bien connus. Sauf que … zut, aucun ne publie de chiffres officiels (ahah, poules mouillées ! 🐤💧).
Ceci dit, la vitesse estimée de Claude Opus 4.5 en prédiction est d'environ 40 à 50 tokens/s. Je n'ai trouvé qu'une seule estimation pour le préremplissage : ~400 tokens/s, mais ça me semble plutôt bas.
Attention, benchmarks droit devant !
Soyons clairs : je déteste les benchmarks. Pourtant, dans ce journal, je vais sortir des résultats de benchmarks que j'ai faits moi-même comme un grand. Ces résultats sont juste là pour vous donner des ordres d'idée et illustrer, et n'ont absolument pas vocation à être exacts. En plus, comme vous le verrez, ils sont très dépendants de la configuration matérielle et logicielle.
De plus, les conclusions issues de ces benchmarks sont totalement subjectives. J'ai essayé d'être le plus factuel possible, mais les conclusions dépendent entièrement de vos besoins et de vos valeurs. Ce que je juge inacceptable ne l'est peut-être pas pour vous, et vice versa.
Sur ce, allons maintenant prestement casser notre CPU+RAM sur des LLM, tel le Titanic et son légendaire Iceberg.
Méthodologie
Matériel
Tous mes tests ont été faits sur des machines avec de la DDR4 3200 MHz.
Je n'ai jamais pu passer à la DDR5 à cause de la Ramapocalypse … (pour ceux qui vivent dans une caverne et qui n'ont pas vu le jour depuis le Covid : les prix de la DDR5 sont complètement lunaires, et ça va probablement empirer). Si vous voulez comparer au doigt mouillé avec la meilleure DDR5 disponible actuellement, vous pouvez multiplier les valeurs limitées par le CPU+RAM par des facteurs de 1,5 jusqu'à 2,5. Sur un malentendu, ça tombera peut-être à peu près juste.
Modèles
J'ai tapé dans la famille Qwen 3.5. Pour cette famille, Alibaba a développé une large variété de taille de LLM, et a fait aussi bien des denses que des MoE. Elle m'a donc semblé idéale pour illustrer ce journal.
- Les Qwen 3.5 ≤ 27B sont denses.
- Les Qwen 3.5 ≥ 35B sont MoE.
Tous ces modèles ont un contexte maximum de 256K tokens.
En plus, Qwen 3.5 27B a exactement la même architecture que mon chouchou Qwen 3.6 27B ^^.
MTP
Je n'ai pas MTP activé pour ces benchmarks.
D'après mon expérience personnelle, totalement subjective, et mesurée avec mes fesses, MTP aide uniquement quand le modèle est entièrement en GPU. Il n'aide pas (voir il dégrade) les performances dès que le CPU est impliqué. Donc par cohérence, je l'ai désactivé dans tous mes benchmarks.
Mesures
J'ai préparé essentiellement des courbes de vitesses en fonction de la taille du contexte. J'ai utilisé llama-bench. Initialement, j'avais utilisé une boucle for, mais avant que j'aie eu le temps de comprendre ce qu'il se passe, cette boucle est devenue un script Python cracra.
Pour chaque taille de contexte/prompt, je demande à llama-bench de faire lire la-dite taille de contexte au LLM, puis de faire générer 512 tokens au LLM. À noter que llama-bench génère les tokens aléatoirement. Il ne cherche pas à faire des phrases qui ont du sens. Donc je suspecte que ça doit activer les MoE comme des sapins de Noël.
Le temps d'exécution de llama-bench pour chaque point a été limité à 2h. Cette limite explique l'absence de certains points sur certaines courbes.
Certains modèles manquent parfois entièrement sur certains graphiques. C'est parce que leurs tests ont échoué pour une raison ou une autre, et que j'ai décidé que j'avais mieux à faire que de me battre avec. Au passage, j'ai un gros soupçon qu'il y a une fuite de VRAM dans le pilote Nvidia : j'ai dû redémarrer ma machine plusieurs fois et passer certains scénarios indépendamment des autres, mais avec les mêmes réglages à chaque fois.
Pour des questions de lisibilité, les valeurs dans les tableaux sont des valeurs arrondies (généralement vers le pire). J'ai mis en gras les temps estimés qui, selon moi, ne sont pas utilisables.
5 cartes graphiques Nvidia RTX 3060 12Go
Avant toute chose, on va s'intéresser rapidement aux performances quand tout tourne sur des cartes graphiques optimisées aux petits oignons (ou pas encore).
La prédiction
La vitesse de prédiction (génération de tokens) est stable (divulgâchage : elle est toujours stable sur toutes les configurations ou presque). Sans surprise, les vitesses de prédiction des MoE sont particulièrement bonnes, et les vitesses de prédiction des denses sont nettement plus basses. Dans les deux, c'est tout à fait utilisable.
Pour référence, quand MTP est activé, Qwen 3.6 27B me donne plutôt environ 40 tokens/s. Autrement dit, très confortable.
Le préremplissage
Clairement, c'est rapide.
Au début, on constate une augmentation de la vitesse avec la taille du contexte. Mais c'est très probablement juste des artéfacts : Je suppose que ces contextes sont trop petits pour mesurer correctement la vitesse sur un système si rapide 💪.
Ensuite, on a une petite surprise : on voit que la vitesse de préremplissage diminue de façon importante avec la taille du contexte. Mais même avec cette diminution importante, on reste à des vitesses tout à fait respectables.
En utilisation pratique, avec Qwen 3.5 27B et 35B, ça donne ça:
| Tokens | Vitesse moyenne | Temps estimé | ||
|---|---|---|---|---|
| Home Assistant | 2500 | |||
| MoE | 2750 | 1s | ||
| Dense | 1000 | 2,5s | ||
| Opencode | 8000 | |||
| MoE | 3650 | 2,5s | ||
| Dense | 1450 | 5,5s | ||
| Open-WebUI outillé | 20000 | |||
| MoE | 3650 | 5,5s | ||
| Dense | 1500 | 13s | ||
| PDF de 100 pages | 45000 | |||
| MoE | 3350 | 13,5s | ||
| Dense | 1350 | 33s | ||
| Reprise de session | 64000 | |||
| MoE | 3150 | 20s | ||
| Dense | 1250 | 50s |
Conclusion subjective
Bref, c'est globalement confortable pour les modèles ≤35b. Qwen 122b est utilisable, mais en q2, et sans être confortable.
CPU et RAM uniquement
On va tout de suite attaquer le cas le plus absurde. Là, clairement, on prend un éléphant, et on essaye de le faire rentrer dans un tutu taille S pour le faire danser.
La prédiction
Sans surprise, avec de la DDR4, c'est lent. Même le modèle 4B est à peine utilisable.
Avec de la DDR5, le 4B et 9B seraient probablement utilisables, et, chose amusante, un modèle 122B MoE en q2 pourrait être utilisable aussi.
Tous les autres (≥27B et ≥q4) sont juste inutilisables.
Le préremplissage
Premier constat, c'est beaucoup plus lent qu'en GPU (et l'eau, ça mouille).
Deuxième constat, la vitesse descend aussi avec la taille du contexte. Sauf qu'on part de très bas dès le départ. Cette descente fait d'autant plus mal.
Vous noterez que je n'ai pas testé plus que des contextes de 32K. C'est parce que c'était horriblement long, et que j'ai une vie (sisi, j'vous jure).
En utilisation pratique, avec Qwen 3.5 4B, 27B et 35B A3B, ça donnerait ça :
| Tokens | Vitesse moyenne | Temps estimé | ||
|---|---|---|---|---|
| Home Assistant | 2500 | |||
| MoE A3B | 25,5 | 1m 40s | ||
| Dense 4B | 43 | 1m | ||
| Dense 27B | 7 | 5m 20s | ||
| Opencode | 8000 | |||
| MoE A3B | 22 | 6m | ||
| Dense 4B | 34 | 4m | ||
| Dense 27B | 6 | 20m 30s | ||
| Open-WebUI outillé | 20000 | |||
| MoE A3B | 17 | 20m | ||
| Dense 4B | 20 | 16m | ||
| Dense | 5 | 1h 10m | ||
| PDF de 100 pages | 45000 | |||
| MoE A3B | 16 | 45m | ||
| Dense 4B | 7 | 1h 40m | ||
| Dense 27B | 3 | 4h | ||
| Reprise de session | 64000 | |||
| MoE A3B | 16 | 1h | ||
| Dense 4B | 6 | 3h | ||
| Dense 27B | 3 | 6h 30m |
Et là, on se rend compte que même les petits modèles sont inutilisables.
Conclusion objective
À moins d'avoir la patience d'un moine bouddhiste, il est évident que c'est juste inutilisable. Et sur ce coup-là, même la meilleure DDR5 ne va pas vous sauver.
Le seul cas d'utilisation que je pourrais imaginer serait dans des batchs. Et encore, il ne faut pas être trop pressé.
Sur une Nvidia RTX 3060 12Go, avec débordement
Sur une carte RTX 3060 12Go, la plupart des bons modèles ne rentrent pas en VRAM. Mais on peut les faire déborder sur la RAM : J'ai demandé à llama-bench de mettre certaines couches du modèle sur la VRAM (-ngl), et le reste en RAM.
Et là, on commence à se rapprocher de ce qui est vendu sur les réseaux sociaux.
La prédiction
Exclusivement en MoE 35B, on arrive sur quelque-chose d'utilisable, mais pas vraiment confortable.
Les denses et le 122B sont juste inutilisables.
Le préremplissage
La vitesse chute aussi, mais nettement moins. En fait, elle est presque stable. Ce qui tombe bien, parce qu'elle commence assez bas.
En utilisation pratique, avec Qwen 3.5 27B et 35B, ça donne ça :
| Tokens | Vitesse moyenne | Temps estimé | ||
|---|---|---|---|---|
| Home Assistant | 2500 | |||
| MoE | 270 | 9s | ||
| Dense | 190 | 13s | ||
| Opencode | 8000 | |||
| MoE | 265 | 30s | ||
| Dense | 190 | 40s | ||
| Open-WebUI outillé | 20000 | |||
| MoE | 255 | 1m 15s | ||
| Dense | 180 | 1m 50s | ||
| PDF de 100 pages | 45000 | |||
| MoE | 245 | 3m | ||
| Dense | 165 | 4m 30s | ||
| Reprise de session | 64000 | |||
| MoE | 240 | 4m 30s | ||
| Dense | 160 | 6m 30s |
Conclusion subjective
On arrive sur quelque chose d'utilisable parfois, mais vraiment pas confortable.
Avec de la DDR5, on peut espérer arriver sur des résultats plus sympas, utilisables, et nettement plus proches d'être confortables.
Sur une Nvidia RTX 3060 12Go, avec débordement, avec --cpu-moe
llama-server a une option bien pratique : --cpu-moe. Comme son nom l'indique, cette option est réservée aux modèles MoE. Avec cette option, on ne charge en VRAM que la partie routeur, les couches d'attention, etc. Les experts, eux, restent en RAM. L'idée est que les experts tous ensemble sont la partie la plus gourmande en VRAM/RAM du modèle. Mais individuellement, ils sont chacun relativement petits, et le CPU peut potentiellement se charger d'eux. Bref, à première vue, un excellent compromis.
À noter qu'il y a aussi l'option --n-cpu-moe X qui permet de charger des couches supplémentaires en VRAM. Mais il faut optimiser ça à la main pour chaque modèle et chaque matériel. Autant dire que ça aurait été trop pénible à faire pour ce journal.
La prédiction
On est entre 2 et 3 fois plus rapide. En MoE, c'est enfin confortable à utiliser.
Autrement dit, le gain est net 🎉 ! Ayé, on y est ! On est sauvés ! La terre promise par les réseaux sociaux ! On va enfin pouvoir résilier notre abonnement Claude Opus, et bruler les datacenters des sociétés qui font du LLM cloud, avant qu'ils ne détruisent notre planète ! Et le tout sans investir plusieurs milliers d'euros dans du matériel !
Cerise sur le gâteau, le 122B a l'air utilisable 🎉 !
Le préremplissage
Ah mais zut, il reste cette histoire de préremplissage. Bah, comme pour la prédiction, ×2~×3 aussi, tranquillou, non ?
Et ben non 😭.
Le 35B est même un peu plus lent ! Et le 122B n'est en fait toujours pas utilisable 😭.
En utilisation pratique, avec Qwen 3.5 35B, ça donne ça:
| Tokens | Vitesse moyenne | Temps estimé | ||
|---|---|---|---|---|
| Home Assistant | 2500 | 216 | 11s | |
| Opencode | 8000 | 210 | 38s | |
| Open-WebUI outillé | 20000 | 205 | 1m 30s | |
| PDF de 100 pages | 45000 | 200 | 3m 40s | |
| Reprise de session | 64000 | 200 | 5m 10s |
Comme on le voit, pour le préremplissage, on a sensiblement les mêmes résultats qu'en débordement simple … voire de moins bons résultats.
Conclusion subjective
On est limité aux modèles MoE.
C'est nettement mieux en prédiction, mais le préremplissage fait qu'on reste fondamentalement coincé sur quelque-chose d'utilisable parfois, et pas vraiment confortable.
Avec de la DDR5, on peut espérer quelque chose d'utilisable en général, voire presque confortable.
Si vous avez assez de VRAM, vous pouvez aussi jouer avec --n-cpu-moe et nvtop pour optimiser ces résultats. Basé sur mon expérience personnelle, vous pouvez les améliorer sensiblement. Mais tant que vous avez une part non-négligeable des couches en RAM plutôt qu'en VRAM, vous n'arrivez pas à des résultats fondamentalement différents.
Modèles plus gros que la RAM
Llama.cpp utilise par défaut la fonction mmap() pour charger les modèles en RAM. Le gros avantage de mmap(), c'est que ça laisse le noyau charger les données en mémoire (cache), ou pas, à la demande. En conséquence, on pourrait imaginer charger des MoE plus gros que notre RAM, et laisser le noyau swapper les morceaux de modèles entre notre NVMe et la RAM automatiquement, en fonction des besoins. En théorie, ça fonctionne. Mais en pratique, les performances sont tellement dégradées que c'est complètement inutilisable. C'est tellement dégradé que je ne vais pas m'embêter à sortir des chiffres (eh, mine de rien, c'est super long à faire ces fichus benchmarks ! ).
mmap() et --no-mmap
En fait, cette utilisation de mmap() est surtout pertinente si le modèle tient entièrement en VRAM. Elle permet de ne pas garder inutilement une copie complète du modèle en RAM. Si vous avez plus de VRAM que de RAM, elle permet aussi de quand même charger un modèle plus gros que votre RAM en VRAM.
Si vous faites du débordement sur le CPU+RAM, je vous recommande de désactiver l'utilisation de mmap() (--no-mmap). Dans ce cas, comme les logs de llama-server l'indiquent, les performances sont nettement meilleures sans mmap().
Sur une seule Nvidia RTX 3060 12Go, sans débordement, avec des petits modèles
Les petits modèles sont plus bêtes, mais selon votre utilisation, ils peuvent être suffisants.
À noter qu'aucun des petits modèles Qwen 3.5 n'est un MoE. De toute façon, je ne pense pas que cette architecture soit pertinente à ces tailles là.
La prédiction
Sans surprise, plus le modèle est petit, plus ça va vite 🏎️.
Sur ce graph, la vitesse décroche après 64K : à ces tailles de contexte, mon script de benchmark a déclenché un débordement sur la RAM. Mon script est probablement assez pessimiste. Il y a peut-être moyen de faire rentrer plus de couches en VRAM pour éviter cette chute.
Chose amusante, si on active MTP, le modèle 2B devient nettement plus lent : 110 tokens/s au lieu de 160 tokens/s.
Le préremplissage
Pareillement, plus c'est petit, plus ça va vite. Ça va même ridiculement vite pour le 2B ⚡️⚡️⚡️.
| Tokens | Vitesse moyenne | Temps estimé | ||
|---|---|---|---|---|
| Home Assistant | 2500 | |||
| 2B | 5915 | 0,5s | ||
| 4B | 2570 | 1s | ||
| 9B | 1690 | 1,5s | ||
| Opencode | 8000 | |||
| 2B | 5750 | 1,5s | ||
| 4B | 2480 | 3,2s | ||
| 9B | 1650 | 5s | ||
| Open-WebUI outillé | 20000 | |||
| 2B | 5340 | 3,7s | ||
| 4B | 2280 | 9s | ||
| 9B | 1550 | 13s | ||
| PDF de 100 pages | 45000 | |||
| 2B | 4650 | 10s | ||
| 4B | 1960 | 23s | ||
| 9B | 1390 | 32s | ||
| Reprise de session | 64000 | |||
| 2B | 4280 | 15s | ||
| 4B | 1786 | 35s | ||
| 9B | 1306 | 49s |
Bref, pour vitesse de préremplissage, on est large.
Intelligence
Sans commentaire 🤦♂️🤦🤦♀️.
Conclusion objective
Si vous êtes prêt à échanger de l'intelligence contre de la vitesse, prendre un modèle plus petit 🤏🧠 est un compromis très efficace. Par contre, il ne faudra pas venir vous plaindre si votre LLM est teubé 📉.
Aussi, si vous décidez d'utiliser ces petits modèles, je vous recommande fortement d'utiliser les variantes q8. Les petits sont déjà assez bêtes de base, on va éviter de trop les lobotomiser en plus. En q8 au lieu de q4, vous pouvez grosso-modo diviser par 2 les vitesses indiquées ici.
AMD RX 9070 XT 16Go
Cette carte graphique est intéressante car c'est une carte grand public récente, assez typique, moyen de gamme, un peu chère mais pas trop (environ 750€ au moment où j'écris ces lignes). Elle a une bande passante mémoire de 645 Go/s, soit presque deux fois plus que la Nvidia RTX 3060 12Go.
Dans le cas des cartes AMD, comme on me l'avait mentionné sur mon précédent journal, le backend Vulkan est effectivement plus rapide que le backend Rocm. Ces tests ont donc été faits avec le backend Vulkan.
La carte AMD utilisée ici n'a que 16 Go de VRAM, donc Qwen 3.5 27B et 35B q4 n'ont pu être testés qu'avec du débordement CPU+RAM. Pour aller droit au but, je ne présente ici que les résultats avec --cpu-moe.
Parce que je suis un pauvre entouré de pauvres, on reste sur de la RAM DDR4 à 3200 MHz partout.
Merci à Quarby de m'avoir autorisé à monopoliser sa machine pendant 2 jours pour ces benchmarks 😁.
La prédiction
Elle est matériellement nettement plus rapide que la Nvidia, pourtant la vitesse de prédiction est un peu en dessous de la Nvidia RTX 3060 12Go. C'est en fait plus ou moins normal : L'utilisation de --cpu-moe fait que le goulot d'étranglement devient le CPU et la RAM plus que le GPU. Je n'ai malheureusement pas pu monitorer la carte pendant le benchmark, mais je suis prêt à parier qu'elle se tournait les pouces. Du coup, à RAM identique, avoir des performances similaires n'est pas une surprise. Le fait qu'on soit un peu en dessous de la Nvidia vient possiblement d'une moins bonne optimisation de la stack logicielle.
Le préremplissage
Là, elle est un poil plus rapide que la Nvidia RTX 3060.
En utilisation pratique, avec Qwen 3.5 35B, ça donne ça:
| Tokens | Vitesse moyenne | Temps estimé | ||
|---|---|---|---|---|
| Home Assistant | 2500 | 270 | 9s | |
| Opencode | 8000 | 265 | 30s | |
| Open-WebUI outillé | 20000 | 255 | 1m 20s | |
| PDF de 100 pages | 45000 | 245 | 3m 5s | |
| Reprise de session | 64000 | 235 | 4m 30s |
Conclusion subjective
Comme mentionné précédemment, la façon dont j'ai benchmarké rendait très difficile l'utilisation de --n-cpu-moe au lieu de juste --cpu-moe, et je ne l'ai donc pas fait. Ici, cette carte ayant plus de VRAM que la Nvidia, il faudrait jouer avec --n-cpu-moe pour charger plus de couches en VRAM. En jouant sur ce paramètre, il est probablement possible d'obtenir des résultats un peu meilleurs que sur la Nvidia RTX 3060 12Go. Ceci dit, d'expérience avec cette option, il ne faut pas non plus espérer des résultats extraordinairement meilleurs. Tant qu'il y a débordement, le goulot d'étranglement restera le CPU et la RAM.
Intel Arc Pro B60
La Intel B60 (ainsi que sa grande sœur la B70) est une carte récente, avec un ratio prix/VRAM imbattable (750€ pour 24Go), mais qui est plus lente que ces concurrentes AMD ou Nvidia.
Cette carte affiche une bande passante mémoire de 450 Go/s, soit plus qu'une Nvidia RTX 3060 (360 Go/s), mais nettement moins que l'AMD RX 9070 XT. Avec ses 24Go de VRAM, les modèles Qwen 3.5 27B et 35B en q4 rentrent intégralement dessus. On pourrait donc s'attendre à des performances tout à fait honorables.
Basé sur mon expérience, si vous optez pour cette carte, il faut impérativement savoir qu'elle a une spécificité : Les cartes Intel utilisent une mémoire virtuelle unifiée (Unified Shared Memory). Autrement dit, les données sur la RAM et la VRAM sont swappés automatiquement et de façon transparente. Donc vous pouvez préciser à llama-server les options -ngl 999 -fit off, et il vous dira que tout est rentré en VRAM, mais en fait, ça déborde. Ce débordement va se ressentir tout autant sur les performances que du débordement CPU+RAM llama.cpp classique. Ça peut même être pire.
Le backend utilisé ici est Sycl. J'ai testé brièvement le backend Vulkan avec cette carte, et les performances étaient 2 à 3 fois plus mauvaises.
On est toujours sur de la DDR4 3200 MHz.
La prédiction
La vitesse de prédiction sur la B60 n'est pas dingue. Utilisable, mais pas super.
À noter que MTP peut améliorer cette vitesse (environ 20 tokens/s pour Qwen 3.6 27B q4).
Avec l'option --cpu-moe, elle est un peu plus lente que la AMD testée précédemment (un peu moins de 25 tokens/s VS un peu plus de 25 tokens/s). Mais comme elle peut faire rentrer les modèles entièrement dans sa VRAM, elle prend l'avantage.
Le préremplissage
Meh. La B60 commence pas trop mal, mais les performances tombent avec la taille du contexte.
En pratique, ça donne ça :
| Tokens | Vitesse moyenne | Temps estimé | ||
|---|---|---|---|---|
| Home Assistant | 2500 | |||
| MoE | 820 | 3s | ||
| Dense | 450 | 5,6s | ||
| Opencode | 8000 | |||
| MoE | 740 | 11s | ||
| Dense | 380 | 21s | ||
| Open-WebUI outillé | 20000 | |||
| MoE | 550 | 35s | ||
| Dense | 280 | 71s | ||
| PDF de 100 pages | 45000 | |||
| MoE | 400 | 1m 50s | ||
| Dense | 200 | 3m 45s | ||
| Reprise de session | 64000 | |||
| MoE | 360 | 3m | ||
| Dense | 180 | 6m |
Pour info, quand elle est testée avec l'option --cpu-moe, ces performances restent similaires à celle de la carte AMD testée précédemment.
Conclusion subjective
Vu qu'on ne déborde pas, sans surprise, on gagne plusieurs avantages :
- Les performances sont nettement meilleures qu'avec une Nvidia RTX 3060 12Go avec débordement.
- Il est appréciable de ne pas être limité qu'aux MoE.
- On n'est pas dépendant de la vitesse de la RAM. Couplée à cette carte, une pomme de terre mal cuite avec de la DDR3 peut suffire.
- Les pilotes Intel et une grande partie de la stack sont libres. Il manque toutefois le firmware de la carte et des bouts de l'API oneAPI.
Mais il faut admettre, ce n'est pas non plus extraordinaire. On reste entre utilisable et confortable.
J'ai le sentiment qu'on pourrait attendre plus de ce matériel. Du coup, plusieurs questions se posent :
- Est-ce que le backend logiciel Sycl pourrait être mieux optimisé ?
- Est-ce que la B70, plus performante, fait significativement mieux ?
Conclusion globale
Il faut avoir à l'esprit que la vitesse de préremplissage chute avec la taille du contexte. Cette chute dépend entièrement de votre configuration matériel.
Le débordement CPU+RAM est utilisable … pour certaines utilisations spécifiques et/ou sur certains matériels spécifiques (💸…DDR5…💸). À coté de ça, les MoE peuvent effectivement être une option intéressante pour être plus confortable. Dans tous les cas, la vitesse de préremplissage ne peut pas être ignorée. En l'omettant, énormément de publications vous vendent du rêve et vous induisent potentiellement en erreur.
On remarque aussi qu'un assistant Home Assistant nécessite de la réactivité, et cela en fait un des problèmes les plus difficiles à résoudre avec un LLM auto-hébergé.
Hors-sujet : mmproj en RAM
Une optimisation oubliée dans le précédent journal : si, comme moi, vous soumettez rarement des images à votre IA, vous pouvez garder le mmproj en RAM plutôt qu'en VRAM avec l'option --no-mmproj-offload.
Hors-sujet : Quantification chez openrouter.ai
Chose intéressante :
J'avais vu passer des rumeurs disant que les modèles sur openrouter.ai seraient souvent quantifiés, sans que ce soit clairement indiqué.
À côté de ça, quand j'ai écrit cet article, ma machine IA était généralement monopolisée par les benchmarks. J'ai donc utilisé temporairement openrouter.ai + Qwen 3.6 27B. Et à ma surprise, je me suis retrouvé plusieurs fois avec des boucles infinies (doom loops). De mémoire, il me semble avoir surtout eu ce problème en auto-hébergeant ce modèle en q4, mais que très rarement en q8.
Curieux, non ? 🧐
Hors-sujet : Versions anglaises
Si besoin, vous pouvez trouver mes journaux en versions anglaises ici :
# Fournisseurs qui quantifient
Posté par Ph Husson (site web personnel) . Évalué à 5 (+3/-0).
On sait pas trop si les fournisseurs (sur openrouter.ai ou eurouter.ai ou autre) quantifient. Ils commencent à déclarer un peu ce qu'ils font sur openrouter, mais ça reste flou.
En tout les cas, il a clairement été observé que un même modèle chez des fournisseurs différents ont des comportements significativement différents. Au delà des questions de quantifications, de nombreux bugs et ""optimisations"" peuvent apparaître (p.ex. pour un MoE, on peut trivialement réduire le nombre d'experts utilisés, mais forcément c'est moins bien) [1]
Kimi (actuellement connus comme étant le meilleur modèle weight-available avec Kimi K3) a trouvé de nombreux problèmes chez de nombreux fournisseurs, et en ont décidé:
1. de changer leur licence spécialement pour les hébergeurs de modèles: Si t'es trop gros tu passes nous voir pour qu'on approuve (et peut-être faire payer, on sait pas trop, en tout cas il est observé qu'il n'y a pas de concurrence tarifaire sur Kimi K3)
2. De faire des outils avancés de validation d'implémentation (https://www.kimi.com/blog/kimi-vendor-verifier )
# Merci, je comprends ce qui m'arrive!
Posté par piratebab2 . Évalué à 2 (+1/-0).
Merci pour ce nouvel Opus.
Je comprends mieux pourquoi j'avais des timeout avec Home assistant. Le LLM tournait sur un serveur HP proliant gen 7 de course, mais sans GPU.
Je retarde pour le moment l'achat d'un GPU à cause des finances, et vu tes tests, il va me falloir investir beaucoup pour avoir un HA qui répond en 3s.
[^] # Re: Merci, je comprends ce qui m'arrive!
Posté par BAud (site web personnel) . Évalué à 5 (+3/-0).
c'est ballot pour la haute disponibilité :/
# Ça vous sert à quoi au quotidien ?
Posté par Thomas J. (site web personnel) . Évalué à 7 (+7/-1).
Depuis bientôt 4 ans, on nous prédit une vraie révolution qui va entre autre apporter des réponses aux grands défis de l'humanité ; certains promettent même un futur hédonique.
Pour l'instant, à part générer du code pas toujours très propre, un prix des composants qui explose et du contenu dégénératif de plus en plus envahissant sur Internet, le compte n'y est pas selon moi.
Quand je pense aux milliards engloutis, niveau retour sur investissement, j'espère que vous planchez sur un truc de maboul !
Et ne me ressortez pas la rengaine du gars qui est contre le progrès… C'est un vraie question !
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Jérôme Flesch (site web personnel) . Évalué à 10 (+13/-0). Dernière modification le 03 août 2026 à 18:27.
Perso, jusqu'à présent, ça me sert surtout à faire les vieux nettoyages de code que j'ai longtemps laissés traîner. Je les ai laissés traîner parce-qu'il s'agit en général de faire des changements sur des éléments utilisés un peu partout dans le code.
Un exemple que je peux donner (hors boulot donc) : Sur mon projet perso Paperwork, j'ai environ 300 plugins. Ces plugins dérivent tous d'une même classe abstraite. Je voulais, de longue date, faire une modification dans un des contrats de cette classe abstraite, impactant donc les 300 plugins. Malheureusement, ça impliquait plus qu'un simple rechercher&remplacer. Comme il s'agissait de rendre les choses plus strictes, il fallait même corriger des erreurs qui étaient passées inaperçues jusque là. À l'époque, j'ai fini par le faire … à la main. Ça m'a pris plus de 2 semaines en temps libre. Et bien sûr, j'ai réalisé à la toute fin que j'aurais pu jeter un LLM sur le problème. J'ai fait le test pour savoir : en moins de 2h, un LLM (devstrall-small 2 de mémoire) m'avait réglé 95% du problème.
Pareillement, au boulot, je m'en sers aussi pour éliminer de la vieille dette technique bien pénible.
À coté de ça, je m'en sers aussi pour relire mes changements (soit pour du code perso, soit en pro, avant de l'envoyer en pull request aux collègues). Une sorte d'analyse statique++ avec laquelle je peux discuter en somme.
Alors moi, je ne planche sur rien du tout. Mais les chat bots sont une vieille fascination que je me traîne depuis mon adolescence. Autant te dire que je m'amuse beaucoup trop là ^^.
Toujours me concernant, on est d'ailleurs bien d'accord que les investissements sont complètement délirants par rapport à ce que l'outil à offrir. Ma conviction est qu'on nage dans un délire mondial complet : L'outil a fait un énorme effet "wow" en arrivant. Les investisseurs n'y comprennent visiblement. Et les boys de la Silicon Valley vendent continuellement un rêve sans avoir aucune certitude de pouvoir le réaliser : celle d'une IA qui n'hallucine jamais et qui ne fait jamais d'erreur, ou tellement rarement que ça devient négligeable.
De plus, je suis prêt à parier qu'il y a maintenant tellement d'argent sur la table qu'ils jouent tous au même jeu de cons : le premier qui crache ouvertement la pilule concernant les limitations des LLMs va faire s'effondrer ce château de cartes à plusieurs billions de dollars/euros et va foutre tout le monde dans la merde. Donc tout le monde continue comme si c'était la solution à tous les problèmes de l'Humanité.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par gUI (Mastodon) . Évalué à 7 (+4/-0).
la révolution elle est déjà là. pas pour les défis de l'humanité (j'y crois pas une seule seconde), mais pour énormément de métiers. pas forcément une bonne révolution (seul le temps nous le dira), mais dès aujourd'hui, passer 3h à chercher ce qu'une IA peux te pointer du doigt en 5mn, c'est très mal vu en général.
perso moi ce que je vois c'est que Claude génère du code meilleur que 90% que ce que je vois autour (et je suis gentil). d'ailleurs sa première utilisation c'est en général la relecture ou le bugfix.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par piratebab2 . Évalué à 4 (+4/-1).
Pour moi, c'est la commande vocale de ma domotique. La conversion voix vers texte, et réciproquement, fonctionne mieux avec de l'IA qu'avec les anciens algo sans IA.
Je pourrais certes m'en passer et appuyer sur un bouton pour allumer ou éteindre la lumière. Mais lorsque je m'aperçois au moment de me coucher que j'ai oublié d'allumer la lumière extérieure, j'ai actuellement 3 possibilités:
- me balader à poil dans la maison, descendre au garage, longer la voiture, et atteindre l'interrupteur
- me demander ou j'ai mis mon tel pour l'éteindre avec l'appli domotique (généralement dans la voiture, qui est dans le garage ….)
- allumer un ordi, attendre tranquillement que ça boute, ouvrir l'onglet HA, attendre qu'il se rafraîchisse, et l'éteindre
Je n'ai pas parlé de la 4 eme solution, inenvisageable en cas d'oubli fréquent (demander à ma femme qu'elle me prête son tel et lui demander d'ouvrir l'appli HA).
J'aimerai juste dire "Hey Jarvis, éteint la lumière extérieure" sans passer par un cloud.
Et cela sans avoir à débourser plus de 1000€ dans une carte graphique.
Oui, on peux s'en passer, mais c'est tellement plus pratique avec une IA en local.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par mmarc67 . Évalué à 3 (+3/-0).
Je pense que ton objectif est atteignable avec une simple 3060 12Gb d'occas à 200€ sur lbc si tu fais un bon achat.
Tu peux faire tourner qwen3.6 35B/A3B Q4_k en mode thinking avec une fenêtre de contexte de 65k sans problème, avec un petit modèle chargé en même temps pour le speech-to-text
En séparant le chat vocal de l'exécution, au prix d'une latence de quelques secondes entre les 2, tu peux fortement économiser le contexte du chatteur par rapport aux outils et à leur utilisation, vu que tu ne lui en présentes qu'un seul : son agent, qui est stateless.
Si tu peux (je ne connais pas le domaine), utilise l'agent pour passer des commandes CLI, avec une documentation bien structurée sous forme de fichier markdown à sa disposition pour connaître l'architecture et les commandes de ton installation domotique.
Le CLI il connaît par coeur, les outils pour lire ou filtrer un fichier aussi.
Même s'il ne connaît pas les commandes domotiques spécifiques, ce sera la seule partie "difficile" de son travail, et si la doc est bien faite (de son point de vue), il y arrivera sans peine au coup par coup (stateless).
Si tu veux échanger sur le sujet avec un débutant qui essaye de progresser, ce serait avec plaisir.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par piratebab2 . Évalué à 2 (+1/-0).
Perso je suis plutot AMD. NVidia, sous linux ce n'est pas terrible. Tu me conseillerais quoi en occaze chez AMD (jusqu'a 400 €)?
Il faudra ensuite que je trouve comment faire le passthroug, mes instances VM sont en containers (Incus et podman), mais c'est une autre histoire.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par gUI (Mastodon) . Évalué à 4 (+1/-0).
C'est ce que je fais sous proxmox. C'est pas très dur, il n'y a pas grand chose à faire, et c'est écrit à peu près partout donc pas de piège à priori.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par mmarc67 . Évalué à -3 (+1/-1).
Les informations sont de Fable.
RX6700 12Gb ou RX6800 16Gb, mais tu vas perdre en vitesse de prefill par rapport à une 3060 sous Cuda. Seule une RX 7800 XT 16 Go fait jeu égal en prefill avec Rocm.
Si le contexte de tes cas d'usage reste modéré, ça ne sera pas trop pénalisant. D'autant qu'AMD met le paquet sur Rocm pour ne pas complètement rater le train de l'IA, et se retrouver coincé sur le marché misérable des Gamers, alors l'espoir est permis s'il y arrivent avant que ta carte passe en legacy.
Si tu est rebuté par la complexité de la configuration du setup, économise 100€ sur la carte et offre toi un mois de Claude Max. Il peut le faire à ta place sous ta supervision ou t'expliquer ce qu'il faut faire et te laisser mettre les mains dans le cambouis, et te faire une doc et un runbook pour l'exploitation et les mises à jour.
Tuteur ou Assistant.
En mettant opus4.8 au travail, opus4.6 à la doc et la sélection auto pour claude code, tu économises les tokens pour rester dans le forfait et il a un niveau époustouflant sur le sujet de l'inférence locale.
Je n'ai pas d'actions chez Anthropic.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Meku (site web personnel) . Évalué à 5 (+4/-1).
Ah oui une IA carrément pour tout ça.
Sinon, tant qu'à faire de la domotique, tu dois avoir moyen de t'installer un interrupteur ou une télécommande en permanence sur ta table de chevet (dans son tiroir, ou à proximité) qui permette de faire ça pour quelques W à peine.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 7 (+5/-1).
J'ai demandé à Sarabot< (mon IA personnelle imaginaire), elle me suggère deux autres solutions :
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2 (+2/-2).
Alors, entre :
et
il y a un petit souci opérationnel.
Pour résoudre un tel dilemme sur la réelle action à entreprendre, il est évident qu'il faut faire appel à une grosse usinagaz basée sur des heuristiques approximatives, et sans même se demander si ça sert à quelque chose d'éclairer l'extérieur alors qu'on est au lit.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par steph1978 . Évalué à 3 (+1/-0).
La conversion voix vers texte (et réciproquement) a toujours utilisé de l'AI (et même du ML). Je pense que tu as noté une différence lorsque ces outils sont passés à la technologies des transformers (comme Wisper).
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
Pourquoi veux-tu allumer un lumière extérieure si tu n'y es pas et que tu vas dormir?
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3 (+0/-0).
Pour ajouter de la pollution visuelle et nuire aux animaux nocturnes ?
Je n’ai aucun avis sur systemd
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Misc (site web personnel) . Évalué à 4 (+2/-1).
Le souci, c'est que toutes les recherches ne sont pas égales (premier souci), et que les réponses ne sont pas toujours exhaustives (second souci), et que ça dérive (troisieme souci). Quand il s'agit d'un fait facile à vérifier, je pense que ça va. Par exemple, quelle est la capitale de la Mongolie, ça devrait aller.
Quand c'est sur un sujet moins présent dans le corpus (soit parce que c'est trop neuf, soit parce que c'est un sujet peu exploré), les risques d'halluciner augmentent. Par exemple, je suis sur que demander un résumé sur les lois autour du droit d'auteur en Afrique du Sud va donner un truc qui semble correct, mais qui va pas rentrer trop dans les détails, car les autres pays dominent sans doute le corpus, et les lois se ressemblent beaucoup. Mais peut être qu'il y a des documents et je suis pas tombé dessus.
Pour la dérive et les hallucinations, c'est facile à voir.
Par exemple, j'ai demandé une liste de films en abusant de Gemini de mon employeur (littéralement "j'ai besoin d'un liste de 10 films parlant de la GPA en vue d'organiser une rétrospective pour un club ciné."). Au début, je me suis planté, j'ai mis "PMA" au lieu de "GPA" et "Pro" au lieu de "Flash", et ça tourne encore.
J'ai pris ça parce que j'ai une idée assez précise des films sur le sujet sorti en France. J'avais en tête La Petite, il est pas dans la liste (ou La Fête des pères. Par contre, la réponse contient Gestación qui ne parle pas de GPA.
Donc hop, 10% d'hallucination.
J'ai refait une demande de ciné club sur un autre sujet (la bisexualité masculine au cinéma), la réponse est un chouia plus correct car il y a moins de films dans ma demande (6 au lieu de 10) et il y a plus de listes sur le web.
Par contre, j'ai aussi demandé des films en français, et dans la liste, il y a Cabaret (1972) qui est non dispo en streaming d'après allociné, et dont le dvd n'a pas de doublage français (vu que c'est une comédie musicale, c'est sans doute trop cher à doubler).
Encore une fois, j'ai du vérifier pour trouver ce qui va pas.
Et ça, c'est sans parler des autres soucis. Par exemple, la recherche est partie sans demander plus de détails (contrairement à un humain). J'ai eu plus qu'une liste à chaque fois (avec des explications, le titre du ciné club, les sujets à aborder, etc). J'ai eu des refs sans rapport avec les affirmations auquel elles sont attachés (vu que j'ai eu 6 fois le même article sur medium, qui ne parle que de la moitié des films de la liste…). Et à la fin, le système m'incite à continuer à utiliser Gemini en proposant d'autres requêtes, comme "faire les fiches du ciné club" ou "trouver des trucs plus expérimentaux ou plus anciens" (comprendre, avant les années 80…).
Pour le fun, j'ai cliqué sur le second, et la, le modèle s'éloigne en proposant Un chant d'amour, de Genet, qui est en effet ancien et plus expérimental, mais qui dérive du sujet de la bisexualité masculine.
Et même si j'ai pas les chiffres pour le vérifier, j'ai le sentiment que les résultats du modèle soit "culturellement aplatis". Vu que le LLM stocke tout sans trop de considération de langue (eg les tokens pour "chien" sont grosso modo au même endroit dans la matrice du LLM que "dog" ou "hund"), il me semble logique (et visiblement, d'autres personnes aussi, vu que quelqu'un a écrit sur le concept avant que je me pose la question) que si tu as peu de textes dans une langue sur un sujet (genre le français), mais beaucoup dans une autre (anglais), le modèle va tout prendre la ou un moteur de recherche ne va pas traverser la barrière de la langue. Et je me suis poser la question car sur les films sur la GPA de mon exemple, il y en avait 5 des USA, et 2 venant de l'Inde, 2 pays anglophones. Une fois que j'ai demandé spécifiquement en français, ça a pris plus de films français (et pas juste traduit).
Donc ouais, ça prends 5 minutes et pas 3h, mais le résultat est parfois subtilement faux, parfois à coté de la plaque, et sans doute subtilement biaisé
sans doute parce que le code qui a servi pour claude est du code libre (vu que c'est le code publique) qui est sans doute moins moche que les trucs horribles en internes fait par l'industrie au sens large. Ça me semble être un cas assez particulier car je ne suis pas sur qu'on retrouve une tel dichotomie dans d'autres secteurs de la société/partie du corpus (cad ou la majorité des données publiques sont de meilleurs qualités que les données privés).
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par mmarc67 . Évalué à 2 (+4/-2).
Ce qu'il serait intéressant de savoir, c'est comment as-tu prompté Gemini ?
Je me suis rapidement rendu compte des défauts de Claude par exemple, et j'ai placé un prompt général avec des consignes pour y remédier, et maintenant les recherches internet sont fiables, mais elles consomment un max de tokens.
C'est pareil pour les analyses multi sources.
Au boulot j'ai mis Claude au service des RHs, pour déterminer quelle serait la meilleure offre de mutuelle.
On lui a fourni tous les documents dont la personne en charge se servait, en ayant pris soin d'en supprimer toute référence aux personnes, fichiers excels, pdf des différentes offres, du contrat actuel, etc.
Il a eu droit à un prompt projet, qui lui donnait les infos sur la boîte : droit local Alsacien, filiale d'un groupe, CA, masse salariale, convention collective, etc.
Il a sorti une analyse complète et motivée en 20 minutes, tenant compte du droit local, de toutes les infos comptables pertinentes, de la pyramide des âges du personnel, de la convention collective et de toutes les contraintes et consignes qu'on lui a imposées, en allant même au delà.
2 semaines d'un boulot déplaisant et fastidieux (du point de vue de celle qui devait se le coltiner). Le forfait mensuel est largement amorti pour ce mois-çi.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Thomas J. (site web personnel) . Évalué à 3 (+3/-1).
Tu pars du postulat que son analyse est la plus pertinente (et elle l’est peut-être !), mais s’agissant d’une boîte noire comment le savoir sans avoir réalisé une analyse contradictoire ?
Et c’est bien là le problème : jusqu’à quel point tu es prêt à lui faire confiance dans tes prises de décisions ? Je ne doute pas qu’il n’endossera aucune responsabilité en cas de problème
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par mmarc67 . Évalué à 0 (+3/-3). Dernière modification le 04 août 2026 à 00:37.
De problème de quoi ?
De choix de la mauvaise mutuelle ?
Il a présenté une analyse argumentée, avec des sources pour les textes légaux, des références aux documents qu'on lui a donné, des explications détaillées de ses préconisations.
Un rapport complet et circonstancié.
Vérifier ? Tout est dans les sources. Les documents sont ceux qu'on lui a fourni et les liens sont cliquables.
Une question, une précision ?
Il n'y a qu'à demander.
Je ne sais pas ce qu'il te faut de plus à part quelqu'un à qui reprocher quelque chose.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Thomas J. (site web personnel) . Évalué à 2 (+3/-2).
Personnellement, je trouve la question de la responsabilité essentielle : c'est René Girard qui théorisait que la stabilité d'un groupe social venait de l'identification d'un bouc émissaire lorsqu'il y en avait besoin d'un. Le cas échéant, après une crise, on pourra bien essayer de blâmer l'IA, elle ne ressentira jamais rien. Mais de notre côté du clavier, le groupe social n'aura plus rien pour se reconstruire collectivement, notamment par le biais du "sacrifice" (anthropologiquement parlant).
Vraiment, je me demande ce qu'un philosophe de haut rang comme lui penserait de la situation actuelle…
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par gUI (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 04 août 2026 à 10:32.
La responsabilité c'est vraiment un sujet que je ne comprends pas. Quand je fais faire du code par Claude pour moi la question ne se pose pas, c'est ma responsabilité. De la même manière (et ça va avec) que le code m'appartient et pas à Claude (c'est explicitement dit dans les conditions, et je soupçonne que c'est justement pour ne surtout pas être responsable).
Il faut vraiment comprendre, mais vraiment, qu'un LLM ne fait que parler. C'est tout et c'est vraiment tout. Il ne fait rien dans le monde réel. Toutes les actions qu'il a (par exemple allumer une lumière ou modifier un fichier) c'est pas lui qui le fait, c'est un agent, à savoir un code tout ce qu'il y a d'algorithmique.
Je l'ai fait d'écrire un petit agent qui obéit à tout, c'est évidemment le plus facile, mais bon, si il fait de la merde dictée par le LLM, la faute à qui ?
À moi, point.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par BAud (site web personnel) . Évalué à 2 (+1/-1).
c'est plutôt que l'IA — par nature — n'a pas de droit d'auteur en propre
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par gUI (Mastodon) . Évalué à 3 (+0/-0).
Oui, j'ai dis Claude mais je voulais dire Anthropic bien sûr (qui, eux, existent bien, et affûtent déjà leurs armées d'avocats pour pas qu'on vienne les emmerder avec les milliards de ligne de code qu'ils pondent chaque jour).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 04 août 2026 à 14:41.
Anthropic n'a de droit d'auteur que sur le code de Claude, et n'a pas de droit d'auteur sur celui qui est généré non plus (d'ailleurs, pas par eux… vu que c'est au minimum issu de prompt).
Pour les poids utilisés par Claude, je ne sais pas et je crois ne pas être le seul à ne pas savoir (même si j'ai un avis).
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par thoasm . Évalué à 4 (+1/-0).
Le problème c'est pas d'allumer la lumière, c'est de prendre la décision d'allumer la lumière au pire moment et que ça cause un accident … le même problème que la voiture autonome.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Thomas J. (site web personnel) . Évalué à 2 (+1/-0).
Je ne suis pas forcement d'accord : c'est le LLM qui contrôle l'agent, donc si le LLM hallucine l'agent engagera un comportement non désiré (dans la limite de ce qu'il peut faire bien sûr).
On peut espérer que dans une situation de crise tout le monde aura ce courage, mais j'en doute. J'imagine plutôt une responsabilité bien diluée (c'est la faute d'Anthropic/OpenAI, le manque de régulation, la demande a été mal formulée, etc.).
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par gUI (Mastodon) . Évalué à 3 (+0/-0).
oui et non. l'agent limite le LLM. quand tu lances Claude code, l'agent te demande toutes les permissions par défaut. c'est toi qui dit bismillah au bout d'un moment parce que ça te gave.
je compare un peu l'agent qui laisserai tout faire au site web qui prend la réponse de l'utilisateur qui ne fait pas de sanitize dessus. l'injection SQL est triviale.
là c'est pareil, dis à ton LLM "voici comment exécuter du Bash" il va l'utiliser bien sûr. alors que si par exemple tu passes pas un shell contraint, dans un environnement limité par SELinux, ton LLM il est bien gentil mais il ne touchera que ce qu'on veut bien lui laisser faire.
faut vraiment être vigilent là-dessus si justement on veut pas d'emmerdes. je commence à cogiter à des agents qui vont avoir du hardware-in-the-loop, le casse-tête est grand, mais si au final on grille une board, ce sera pas la faute à Anthropic non. trop facile.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Dring . Évalué à 7 (+5/-0).
Il arrive que les liens pointent vers rien, ou un truc qui n’a rien à voir
Il arrive que les liens donnent une info contradictoire à celle fournie dans la réponse
Impossible de le savoir sans tout vérifier, ou sans avoir une connaissance du sujet qui permette de facilement identifier le ou les points à contrôler.
Il me semble que tu tombes dans le piège de « la réponse semble cohérente et argumentée donc elle doit être juste ». C’est tout le problème des LLMs ; ils se trompent avec panache, avec tout ce qu’il faut pour que l’humain soit convaincu que « là, pas de doute, c’est carré ».
Le web regorge d’anecdotes sur des erreurs de ce type.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par gUI (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 04 août 2026 à 07:24.
Alors si il y a une mauvaise utilisation de l'IA c'est bien ça. Wikipedia te le dis de manière certaine et surtout à jour (ça bouge les capitales !).
Tu demandes un contenu éditorialisé, il y a nécessairement un biais. Celui des IA est bien connu (USA, homme, blanc…) mais c'est de toutes façons ce qui t'attend. Si tu poses cette question à 20 personnes dans la rue tu auras 20 réponses différentes, donc c'est difficile de reprocher à chacune de pas être celle que tu attendais.
Mais de manière générale utiliser une IA comme savoir encyclopédique est une très mauvaise idée. Il faut partir du principe que son entraînement c'est pas des informations, son entraînement c'est une mécanique du langage : l'IA sait parler. Point. Pour le savoir, faut le faire beaucoup plus formellement via le RAG, le MCP etc.
Pour le code (la question c'était "au quotidien", moi c'est le code) les hallucinations il n'y en a quasiment pas dès lors que tu utilises un agent (et pas 3 copier/coller sur le web). Tu donnes accès à tout le code, et surtout à la boucle "code/compile/test". Et là c'est impressionnant à voir, concrètement, au quotidien, ça marche.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Misc (site web personnel) . Évalué à 4 (+1/-0).
Bien sur, mais si je tape la demande sur Google ou DDG, et qu'une vignette s'affiche avec le résultat, et est ce que j'ai demandé à une IA si je ne vais pas sur Wikipedia ?
Et je suis d'accord que pour mon exemple qui marche parfaitement, c'est aussi un cas trivial ou ça marche sans LLM (et quand je déploie des modéles, j'envoie toujours 2/3 questions qui semblent trivial mais qui ne le sont pas, comme la durée de train Paris vers New York…). Mais je pense qu'il y a sans doute des demandes plus complexes qui ne vont pas sur WP directement pour illustrer le pouvoir du pattern matching.
Certes, mais quand je demande ça sur un moteur de recherche, j'ai plus de choix, par fonctionnement d'un moteur de recherche. Et ce point sur le contenu éditorialisé est en fait important.
Nan, c'est pas difficile du tout, je viens de le faire :P
Mais mon point, c'était surtout qu'on peut pas faire confiance assez rapidement, donc prendre 3h pour un truc qui semble prendre 5 minutes me semble une simplification.
Mais ça pose la question des biais. Un agent, c'est juste l'automatisation de la vérification des résultats. On va battre les hallucinations par le pouvoir des stats et une boucle (boucle qui au passage devrait être en logiciel libre, mais curieusement un point absent des discussions en général), en gros, ça bruteforce (une approche valable, je précise).
Mais si il y a des biais dans une demande que tu qualifie d'éditorial comment ça se manifeste dans le code ?
Je précise que je dit "qualifie d'éditorial" parce je suis d'accord avec toi, mais je ne trouve pas de meilleur mot, et j'ai le sentiment qu'il y en a un.
On force la forme que prends le code via l'usage des linters, on force le code à être correct via des tests et un compilo (quand c'est possible), et ça n'est pas un processus créatif ou éditorial, mais est ce qu'il y a plus que ça qui rentrerait dans la catégorie "editorial", et est ce que c'est important ?
Pour répondre à la seconde question, je pense que c'est important.
Vu que la protection via les droits d'auteurs du code dépend du fait qu'il y a un élément créatif (cf cette article), si on estime que le code produit n'est pas comparable au résultat d'une demande "éditorial", alors même si un humain sélectionne le code, on peut argumenter qu'il n'y rien de créatif, donc rien de protégeable (avec tout ce que ça implique).
Si au contraire, on estime que l'humain qui va examiner ce que produit le LLM est capable de faire un choix éditorial, alors ça veut dire que le code produit par les LLMs souffre de biais comme le programme des cinés clubs produit par un LLM.
Et donc, si on estime qu'il y a des biais, comment ça se manifeste dans le code en pratique ?
(question ouverte, j'ai pas assez réfléchi pour avoir un avis, et on m'a filé un angine ce weekend)
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par rewind (Mastodon) . Évalué à 6 (+5/-2).
Ça sert à accélérer la chute du capitalisme moderne via une grosse bulle prête à éclater et qui va en entraîner d'autres dans la foulée. Ha, tu voulais dire si on l'utilise ?
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par ff9097 . Évalué à 3 (+2/-1).
ça fait tout beaucoup plus vite (analyser, coder, débugger, tester, ….).
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Thomas J. (site web personnel) . Évalué à 2 (+1/-0).
Ok la vitesse ça peut impressionner mais encore faut-il savoir poser la bonne question et espérer que l’IA ne réponde pas à côté de la plaque (même si le taux d’hallucinations semble avoir bien diminué depuis 4 ans).
Mon boulot actuel est justement d’essayer de comprendre ce que mon client veut versus ce qu’il pense vouloir. Dans mon cas, je n’ai pas trouvé comment l’IA actuelle pouvait aider en cela.
Malgré le temps qui passe, cet outil dispose toujours d’un très fort taux de tolérance (de fantasme aussi ?) alors que son cadre d’utilisation est toujours aussi mal définit. J’ai le sentiment qu’on ne serait pas aussi compréhensif avec un employé qui promet des lendemains toujours meilleurs.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par ff9097 . Évalué à 2 (+0/-0).
A chaque fois je le trouve particulièrement pertinent et avec des prompts assez minimalistes. Je ne m'en sert pas pour mieux comprendre ce qu'on souhaite de moi. Je l'utilise pour évidemment coder (sur plusieurs dépôts en parallèle), configurer des services, analyser des logs pour comprendre des bugs, optimiser, m'expliquer des concepts, ….
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par gUI (Mastodon) . Évalué à 6 (+3/-0).
Mmmm… faut pas que ton client teste le mode "plan" de Claude code alors :) Perso je trouve ça génial, il me tire les vers du nez ! De plus il sait tenter une implémentation, me laisser jouer avec, puis finalement on repart sur autre chose…
Les LLM peuvent aussi être pertinents si on leur fais des requêtes comme "je voudrais tel type de truc, mais je sais pas trop ce qu'il me faudrait, aide-moi à concevoir et dimensionner".
Selon le domaine dans lequel tu gravites, ça peut être intéressant d'essayer en tous cas.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Zatalyz (site web personnel) . Évalué à 4 (+2/-0).
Tiens, c'est proche d'un usage que j'ai parfois. Que l'IA m'aide à clarifier ce que je veux histoire que ça devienne explicable/cherchable. Pour le coup je trouve ça parfois assez impressionnant, quand mon prompt ressemble à "j'ai une vague idée d'un truc qui ferait ce genre de chose" et qu'assez rapidement elle me sort les bons mots de vocabulaire. Parce qu'avec les bons mots/concepts, le reste devient plus facile.
Ceci dit, je ne pense pas que ça remplacera facilement ton job, parce que ça n'est pas non plus au niveau de permettre des plans d'actions complètement pertinents. Des trucs génériques un peu bâteau oui, parfois quelques pistes intéressantes à explorer, mais beaucoup trop de choses très "scolaires" qui manquent du petit truc réellement pertinent. Peut-être qu'en les nourrissant de beaucoup plus d'infos, on finit par arriver à de bonnes choses, mais je n'ai pas poussé mes tests aussi loin et jusque là, après un premier débroussaillage, il me reste soit à trouver un humain qualifié avec qui discuter, soit à réfléchir beaucoup en me nourrissant de plein de littérature.
J'ai aussi eu l'usage "j'ai une idée à la con, et je ne vais pas dormir tant que je ne l'aurais pas exploré à fond", une discussion avec un LLM me permettant justement d'explorer un peu plus toutes les conneries liées et de finir par me dire "ouais, c'était vraiment ça : une idée à la con. Je peux la mettre dans /dev/null et dormir".
Ceci dit, ni l'un ni l'autre de ces usages ne justifie l'outil, je le reconnais…
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par gUI (Mastodon) . Évalué à 4 (+1/-0).
Le Youtubeur "Benjamin Code" a écris un agent sympa à peu près pour ça. Au lieu de te
sucerflatter dans ton ego et démarrer le code dans la foulée, il te challenge. Mais vraiment, il va chercher la particularité, le truc à mettre en avant etc.À customiser avant utilisation (perso j'ai viré pas mal de trucs), mais c'est vraiment sympa, une bonne base.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Zatalyz (site web personnel) . Évalué à 2 (+0/-0).
Ho, si l'IA arrive à suivre ces consignes, ça doit donner des discussions sacrément plus drôles ! Merci pour la découverte. Sauf que maintenant faut que je résiste à aller tester, c'est malin. Je n'avais pas prévu d'aller taquiner une IA aujourd'hui…
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par zurvan . Évalué à 6 (+4/-0).
pour mon usage, pas plus tard qu'hier j'ai utilisé mon IA locale (Gemma-4-12B) pour traduire en français des passages d'un livre en espagnol scanné en pdf. Pas besoin de se connecter au web, pas besoin d'utiliser des services type google traduction ou chatgtp, rien ne sort de chez moi.
On peut également l'utiliser comme dictionnaire des synonymes, correcteur orthographique local, conjugueur etc…
"Ce n'est pas à l'état de tout savoir sur ses citoyens, mais au citoyen de tout savoir sur l'état."
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par LaurentClaessens (site web personnel) . Évalué à 6 (+4/-0).
Moi ça me sert à trouver des démonstration mathématique que je ne trouve pas sur internet pour écrire le frido.
Voir AI-DECLARATION.md pour plus de détails.
p.ex:
Il n'y a presque aucun texte sur internet concernant les fonctions analytiques sur les espaces de Banach.
Presque tout le théorème de Cauchy-Lipschitz analytique et tous ses résultats préliminaires (c'est assez épais) dans le Frido ont été fait avec l'aide de l'IA.
Pour donner une idée de l'aide fournie par des humains :
https://math.stackexchange.com/questions/5113042/analytic-picard-lindel%c3%b6f-theorem
Bref. C'est très loin de me servir tous les jours, mais ça dépanne parfois de façon cruciale.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par par . Évalué à 1 (+0/-0).
Qui à prédit une "vraie révolution qui apporter des réponses au grandes questions de l'humanité" ? Comme dirait wikipédia : "citations needed". Parce qu'entre ce que promettent certains et ce qu’interprète les autres, il y a un monde. Là, j'ai impression que tu force le trait sur les promesses, jusqu'à la caricature, puis que tu te plaint que ton interprétation n'est pas réalisée…
Qui ? Le patron ou le porte-parole d'une boite IA ? Un éditorialiste expert IA auto-proclamé ? Monique, de la compta chez OpenIA ? Ou Dédé du café du commerce ? Et ils sont combien ? Juste un CEO un peu original, après un repas arrosé avec les investisseurs, ou c'est un consensus réfléchi des experts du domaine ?
# très éclairant
Posté par mmarc67 . Évalué à 3 (+4/-1).
j'ai lu tout le journal, et maintenant je suis obligé de lire les précédents…
Tes chiffres confirment ce que Claude avait fini par conclure quand j'ai envisagé d'acheter une RTX 3060 d'occasion.
Pour faire court : Ma config est limitée par la quantité de VRAM et la bande passante de la RAM. Une 3060 n'y changera presque rien, à part peut être une occupation VRAM légèrement inférieure à cause de certaines instructions inexistantes sur les GPU de génération Pascal.
J'ai un i7-7700k 32Go/2400 et une Titan Xp Pascal 12GB ~540GB/s
J'ai fait faire des tests à mon Qwen3.6 35B A3B_Q4K en mode agent, avec les même valeurs de contexte (hors scaffolding ~2450tk), et j'obtiens les résultats suivants :
Palier visé │ Tok utiles │ Prefill tok/s │ Prédiction tok/s │ Tok générés
1 000 │ 1 084 │ 352.6 │ 22.3 │ 227
2 000 │ 2 161 │ 367.9 │ 23.1 │ 256
4 000 │ 4 334 │ 383.7 │ 23.0 │ 161
8 000 │ 8 659 │ 373.3 │ 21.9 │ 204
16 000 │ 17 375 │ 358.8 │ 21.7 │ 256
32 000 │ 34 810 │ 320.2 │ 21.2 │ 171
Je me permet de faire une suggestion.
J'ai découvert récemment que la vitesse de prefill pouvait être améliorée en jouant sur un paramètre. J'ai obtenu ces résultats avec la valeur modifiée, qui a tout changé au prix d'une légère augmentation de l'occupation VRAM :
--ubatch-size, passé de 512 (défaut) à 1536. Gain mesuré : +91% sur le prefill de Qwen3.6, un peu moins pour Gemma 4 26B A4B.
Tu l'as sûrement déjà fait au vu de tes résultats, mais comme tu n'en fais pas mention j'ai jugé utile de le mentionner.
[^] # Re: très éclairant
Posté par Jérôme Flesch (site web personnel) . Évalué à 2 (+0/-0).
Ça dépend. Seule, effectivement, elle ne t'apportera rien. Si tu peux la mettre en plus de ta Titan XP, tu arrives à 24Go de VRAM. Et 24Go de VRAM, ça t'ouvres par exemple la porte de Qwen 3.6 27b (dense) en q4_k_xl avec une taille de contexte décente (128K de mémoire).
De mon coté, l'expérience montre que ça joue en effet beaucoup pour la Intel B60. Les Nvidia, nettement moins. La AMD, je n'ai pas pu tester.
[^] # Re: très éclairant
Posté par mmarc67 . Évalué à 2 (+2/-0).
Mon setup ne supporterait pas une 3060 de plus. 750W 80+ silver et la titanXp consomme déjà 250W.
En plus je serai obligé de la brider avec Cuda 12 si j'ai bien compris, parce que la titanXp est dépréciée et ne supporte pas Cuda 13.
Je pourrai toujours brider les tdp, mais je suis plutôt satisfait de la version de Qwen/Ornith que j'utilise.
La profondeur de raisonnement et les compétences en codage et sysadmin me permettent de faire des choses inespérées.
Pour l'instant je l'ai scaffoldé pour du python, pour le tester il a résolu AoC 2025, m'a fait un démo level type super mario fonctionnel et un tetris à partir d'un layout PNG (mmproj).
Une fois au point, je l'ai mis au travail sur le frontend d'inférence pour qu'il refactore une copie de lui-même dont le code est validé pydantic et vérifié ruff avec des conventions de nommage et placement strictes.
Ca me semblait ambitieux pour un A3B scaffoldé par un newbie, alors je me suis morigéné pour ne rien espérer, mais il a réussi.
Pour moi sa principale limite est dans le contexte réellement utile. Au delà de 40k il se perd en temps qu'orchestrateur, même si en tant qu'agent il semble pouvoir en gérer plus ; mais le prefill devient le problème de toutes façons.
C'est en partie pour ça que les sessions de mon agent sont limitées à 20min, s'il les atteint c'est le fallback avec synthèse par llm (toujours le même pour éviter le swap) qui est renvoyé en retour d'outil au modèle du chat et qui remplace son rapport.
J'ai lu ton précédent journal, et j'y ai appris l'existence de Qwen 3.6 MTP… C'est le prochain que je teste.
S'il est aussi bon que celui que j'ai tout en étant plus rapide, c'est vraiment super !
[^] # Re: très éclairant
Posté par Jérôme Flesch (site web personnel) . Évalué à 2 (+0/-0).
Alors, ça vaut le coup de l'essayer. Mais je ne veux pas non plus te donner de faux espoirs.
MTP, c'est vraiment quitte ou double. Sur certaines configurations (logiciel, matériel, en fonction du LLM, etc.), ça détériore salement les performances, et sur d'autres, ça double la vitesse de génération des tokens ¯\_(ツ)_/¯. Dans tous les cas, ça n'améliore pas la vitesse de préremplissage.
# Typo dans le lien "poules mouillées"
Posté par Jérôme Flesch (site web personnel) . Évalué à 2 (+0/-0).
Si un gentil modo passe par là, serait-il possible de corriger le lien "poules mouillées" ? Le bon lien est https://www.youtube.com/watch?v=tM4044bh4FU (j'ai visiblement réussi à faire une typo: le B est en majuscule au lieu d'être en minuscule).
Merci d'avance :-)
[^] # Re: Typo dans le lien "poules mouillées"
Posté par gUI (Mastodon) . Évalué à 4 (+1/-0).
Corrigé, merci.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Passer de 16 à 32 Go : un vrai gain, mais jusqu’où ?
Posté par wouf (site web personnel) . Évalué à 0 (+0/-0).
Merci pour ce journal, qui distingue bien le fait de réussir à charger un modèle de celui de pouvoir réellement l’utiliser confortablement.
Je travaille principalement sous Ubuntu, notamment pour du développement web, du Python et du LaTeX. Je suis récemment passé de 16 à 32 Go de RAM et j’ai clairement vu la différence, aussi bien dans le confort général que lors de mes essais avec des outils d’IA en local.
Cela dit, votre article me fait me demander si cette augmentation de RAM change réellement le choix du modèle ou si elle ne fait que repousser le moment où les ralentissements deviennent gênants.
Pour un usage assez modeste — aide ponctuelle sur du code, relecture, LaTeX ou analyse de documents — vaut-il mieux privilégier un petit modèle entièrement contenu dans la VRAM, ou les 32 Go de RAM rendent-ils raisonnable l’utilisation d’un modèle plus ambitieux débordant sur le CPU ?
Autrement dit, le passage à 32 Go améliore indéniablement les choses, mais à partir de quel moment la bande passante mémoire et le temps de préremplissage deviennent-ils plus importants que la quantité de RAM disponible ?
[^] # Re: Passer de 16 à 32 Go : un vrai gain, mais jusqu’où ?
Posté par Jérôme Flesch (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 06 août 2026 à 00:33.
Tout d'abord, les vitesses des LLM dépendent bien plus de la quantité de VRAM que de la quantité de RAM : Si 99% du modèle est en VRAM, ça tournera bien. Si 99% du modèle est en RAM, ça sera très lent. Par exemple, vous pouvez avoir 1 To de la meilleure RAM DDR5 possible, si vous n'avez pas de VRAM du tout, vous ne ferez jamais tourner raisonnablement de LLM plus gros que du 10b (un peu plus de 10Go de RAM en q8).
Ensuite, il n'y a vraiment pas de réponse binaire à cette question :
La taille du modèle définit grosso-modo son niveau d'intelligence (j'hyper-simplifie ici ; l'architecture du modèle et ses données d’entraînement jouent aussi pas mal). Pour les taches indiquées, tous les modèles ont leur limite. Même Fable 5 a ses limites et va échouer parfois sur ces tâches. Mais plus le modèle est petit, plus il échouera. C'est à chacun de déterminer ce qu'il considère acceptable. Pour ma part, je suis à l'aise avec Qwen 3.6 27b. D'autres se contenteront peut-être d'un modèle un peu plus petit et plus bête. D'autres voudront absolument un modèle plus grand et plus intelligent.
Il en va de même avec la vitesse. Certaines personnes seront OK avec le fait d'attendre 5 min que le préremplissage se fasse pour reprendre leur session, et d'autres non. Certaines personnes seront OK avec un LLM qui mâche ses mots à 15 tokens/s, et d'autres s’impatienteront.
Il n'y a malheureusement pas de règle magique pour savoir à l'avance quoi utiliser. C'est vraiment à chacun d'essayer, voir ce qu'il peut faire tourner, et voir si ça lui convient.
[^] # Re: Passer de 16 à 32 Go : un vrai gain, mais jusqu’où ?
Posté par wouf (site web personnel) . Évalué à 2 (+2/-0).
Merci pour cette réponse très claire.
J’en retiens finalement une règle moins technique que philosophique : faire avec ce que l’on a, avec ce que l’on peut raisonnablement acquérir… et apprendre à s’en contenter.
Ce n’est d’ailleurs pas forcément une résignation. Pour mes usages, le meilleur modèle n’est sans doute pas le plus gros, mais celui qui répond suffisamment bien, sur la machine dont je dispose, sans transformer chaque requête en exercice de méditation.
Le passage de 16 à 32 Go m’a apporté un vrai confort, mais je comprends mieux qu’il ne remplace pas la VRAM et qu’il ne dispense surtout pas d’essayer. Il reste donc à trouver son propre compromis entre intelligence, vitesse, coût et patience — cette dernière ressource étant parfois la plus difficile à augmenter.
[^] # Re: Passer de 16 à 32 Go : un vrai gain, mais jusqu’où ?
Posté par mmarc67 . Évalué à 0 (+0/-0).
Je suis moi même en train d'essayer de me monter une machine me permettant de faire tourner des plus gros modèles, et mes modèles actuels plus vite.
Si on laisse de côté la carte graphique, qui est devenue plus rare et chère qu'une licorne, le levier côté RAM se situe au niveau de la bande passante.
Pour ma part, je remplace mon i7-7700k sur chipset h270 (dual channel DDR4 2133MHz) par un threadripper 1950x sur chipset x399.
J'y perds de la consommation électrique en idle (les remarques assassines vont fuser), mais j'y gagne un quasi doublement de la bande passante, (DDR4 2666MHz dual rank quad channel), la possibilité d'installer 3 cartes graphiques sur 16 lignes PCIE3 chacune, au lieu d'un 16+4 sur ma carte mère actuelle, et des performances brutes en multi thread bien meilleures.
Grosso modo un petit cran en dessous de la bande passante d'une plateforme DDR5 entrée de gamme en dual channel, pour une fraction du prix.
Il est encore possible de trouver de bonnes affaires sur des composants un peu exotiques et anciens de ce type, qui ont des specs adaptées à l'inférence tout en restant accessibles sur le marché de l'occasion.
Et si j'ai tout bien compris, en simplifiant et toutes choses étant égales par ailleurs, 2x plus de bande passante mémoire = 2x plus de tokens/s si le calcul suit, en RAM comme en VRAM ; et si ton modèle est en RAM, la vitesse de prefill augmentera aussi.
[^] # Re: Passer de 16 à 32 Go : un vrai gain, mais jusqu’où ?
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 08 août 2026 à 21:04.
ah, t'aime bien les CPU qui datent de 2017 :D sans indiscrétion, c'est de la récup' ou parce que tu préfères l'occasion ?
une estimation du gain peut être faite avec :
https://cpu-benchmark.org/compare/amd-ryzen-threadripper-1950x/intel-core-i7-7700k/
si tu connais mieux comme benchmark, ça m'intéresse, généralement je m'appuie plutôt sur Passmark https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+Threadripper+1950X mais il a une ergonomie pas trop pratique pour comparer :/
https://www.cpubenchmark.net/singleCompare.php ajout des CPU puis résultat :
https://www.cpubenchmark.net/compare/3058vs2874/AMD-Ryzen-Threadripper-1950X-vs-Intel-i7-7700K
qui t'indique une différence de coût par an de quasi x2 :
mais bon, c'est du prévisionnel, à décliner par rapport à ton utilisation effective plutôt que générique comme ici…
[^] # Re: Passer de 16 à 32 Go : un vrai gain, mais jusqu’où ?
Posté par mmarc67 . Évalué à 0 (+1/-1).
Parce que c'est bien moins cher ! Je ne suis pas un fétichiste du vieux matos.
J'imaginais un plus gros delta de consommation, ça me conforte.
J'ai décroché sur le prix du hardware il y a un bail, mais quand j'ai voulu explorer les IAs et que j'ai vu les tarifs tant en neuf qu'en occasion du matériel adapté, je suis tombé de ma chaise, et ça ne s'est pas arrangé depuis.
Donc si je vise un setup directement performant mais upgradable par ajout, il ne restait pas beaucoup d'options.
Je m'en suis tiré pour 240 (MB+proc) + 180 (RAM) + 45 (ventirad) + 100 (alim 1200W).
Avec ça je double ma vitesse de génération avec mes modèles et ma carte graphique actuelle (Titan Xp), et je peux y placer 3x 3060 12Go en PCIE3 16x as-is, ou autre chose.
Je reste en veille pour voir ce qui se présente avec un bon rapport qualité/prix.
Je dois bien avouer que j'ai utilisé Claude pour les évaluations de gains potentiels. Il connait mon setup, ses performances qui sont documentées dans ses fichiers de projet, les modèles et les apps que j'utilise, et il est idéal pour estimer assez précisément l'avant/après, et trouver les plateformes exotiques quivontbien en évitant les pièges liées à des limitations de chipset, de bios, de gestion mémoire, de mémoire supportée, de connectique, etc…
Il faut souvent lui tirer les vers du nez, mais c'est incomparablement plus rapide que de tout rassembler soi-même, et comme les prix augmentent sans arrêt, y compris en occasion ; le temps c'est vraiment de l'argent.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.