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 ?
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.
Plus sérieusement, les LLM me ramènent au temps où une compilation complète d'un projet durait souvent longtemps. Ce temps où j'allais parfois discuter à la machine à café "le temps que la machine finisse" 🙂
j'y ai appris l'existence de Qwen 3.6 MTP… C'est le prochain que je teste.
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.
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).
Ç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).
--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.
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.
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.
Quand je pense aux milliards engloutis, niveau retour sur investissement, j'espère que vous planchez sur un truc de maboul !
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é.
D'autant que malgré mes recherches assistées par IA, je n'ai pas trouvé de homelabeur qui pousse de petits agents jusqu'au vibe-sysadmin, ou vibe-coding.
Même si je méfis du vibe-coding comme de la peste, je crois que je vais prendre cepassagepersonnellement … 🙂
Connais tu une communauté qui travaille sur le sujet ??
Sur le sujet de l'utilisation des LLMs sur les configurations à faible VRAM (≤16gb) ? Ou sur les très petits modèles (≤10b) ?
En fait, dans les deux cas, pas vraiment. Les petits modèles sont très limités, et ont donc peu d'utilisations possibles. Et faire tourner sérieusement des LLM plus gros sur des configurations à faible VRAM implique de faire du débordement CPU+RAM. Et le débordement, c'est vicieux : Au premier abord, ça semble donner des résultats utilisables. Mais ce que beaucoup ratent, c'est que ces résultats s'effondrent vite en utilisation réelle avec l'augmentation du contexte. Je pense détailler cette dernière problématique dans un prochain journal.
Tout ce que j'ai mis dans le journal (ReBAR, amd_iommu=on, iommu=pt, le patch Nvidia, etc), je les ai configurés et/ou installés. Par contre, je n'ai pas essayé simpleP2P ni p2pBandwidthLatencyTest. À la place, j'avais regardé l'état d'interconnexion avec nvidia-smi topo -m.
Eh, nextgens ! Ça fait super longtemps ! Comment tu vas ? :-)
Alors c'est vrai que mon matériel le supporte peut-être, j'ai du mal à être 100% sûr sur ce point. Mais ce n'est pas faute d'avoir essayé de le faire marcher … Je vais retenter à l'occasion. Qui sait, j'arriverai peut-être à lui arracher un miracle. Si tu as une idée de trucs à essayer que j'aurais peut-être raté, je suis preneur.
Personne ne sait de quoi le futur est fait, et cette vidéo ne fait pas exception à la règle.
Personnellement, je suis d'avis qu'il vaut mieux baser ses choix sur ce qui existe maintenant que ce qui pourrait exister dans 6 mois. Si tu veux voir si une IA locale d'aujourd'hui pourrait convenir à tes besoins d'aujourd'hui, tu peux tester la plupart des modèles en passant par openrouter.ai (attention par contre, leur quantifications ne sont jamais spécifiées).
Mon cas est un peu entre les deux : une seule RTX 3090 qui doit servir à la fois pour l'inférence LLM (Qwen3.6-27B) et la génération d'images.
Je ne l'ai pas mentionné explicitement, mais, par défaut, llama-swap ne garde qu'un seul modèle actif (il faut définir une matrice pour en charger plusieurs simultanément). Et en fait, si tu regardes l'exemple de configuration llama-swap que j'ai mis pour la Intel Arc Pro B60, tu constateras que je suis exactement dans le même cas que toi : Avec cette configuration, llama-swap bascule automatiquement entre stable-diffusion.cpp et différentes configurations de llama-server. (bon par contre, la Intel Arc Pro B60, la bascule, c'est plutôt 1 à 2 min … :/)
Est-ce que les ~31 Go du q8 valent vraiment le coup quand on peut avoir presque la même qualité en 16 Go ?
Mon expérience personnelle est que oui, le q8 est meilleur pour moi. Mais honnêtement, je pense que ça dépend vraiment des besoins de chacun, d'où ma suggestion d'utiliser la B60 avec qwen 3.6 q4_k_xl.
Personnellement, je suis activement le subreddit /r/locallama. Quand un nom de modèle revient plusieurs fois avec des avis positifs, je me dis que ça vaut le coup que je le teste :-)
Comme mentionné, actuellement, les deux à tester en premier, c'est qwen3.6 27b (code) et gemma-4 31b (généraliste) … si pouvez les faire passer sur votre machine. Sinon ça peut valoir le coup d'essayer leurs petits frères MoE.
Les versions quantifiées par le projet Unsloth sont généralement les plus fiables. Ce sont les versions officielles, quantifiées proprement, avec tout au plus quelques corrections de bugs dans leur manifeste.
Après, des fois, j'en essaye d'autres au petit bonheur la chance ¯\_(ツ)_/¯
J'ai fait un test sur mon portable AMD de 2021 qui a de la DDR4. Avec un qwen3.6 35b a3b, j'arrive à tirer 10 tokens/s. J'ai utilisé en partie le GPU, mais la VRAM est la RAM sur cette machine. Autant dire que ça ne semble pas faire une grosse différence avec du CPU+RAM purs.
Donc après réflexion, concernant le cas d'origine que tu exposes, je me dis qu'avec un processeur moderne et de la DDR5, avec un MoE a10b, même en CPU+RAM purs ou presque, la personne peut peut-être bien arriver à 30 tokens/s, de façon fiable.
C'est très intéressant, parce-qu'autant les a3b sont plutôt bêtes, autant je suppose que les a10b doivent être plus malins.
En effet, c'est vrai … pour un token individuellement :-). Sur un contexte, c'est une autre histoire.
Et 10B c'est pas forcément la taille de l'expert, parfois les experts sont bien plus petits et plusieurs s'active en même temps, juste y en a toujours autant qui s'activent en même temps, mais je me trompe peut-être.
Et sur ce point, en fait, tu as parfaitement raison. Désolé, mes explications étaient franchement confuses voir inexactes.
Ceci dit, le principe tient : lors du traitement du contexte, le passage d'un token à l'autre peut déclencher différents experts. Si ces experts ne sont pas en VRAM, les perfs vont prendre une claque.
Effectivement, je ne connaissais pas. Le benchmark de la Intel B70 a attiré mon œil. Elle patatore effectivement nettement plus que la B60 :-)
Pour l'anecdote, j'ai testé très rapidement qwen-3.6 122b sur une Intel B60 avec débordement CPU+RAM DDR4 :
Sans MTP, je vois quelque-chose d'assez intriguant : La vitesse de génération commence très très basse (quelques tokens/s ; GPU utilisé à 10~20%), et elle monte lentement mais sûrement vers un peu plus de 10 tokens/s (GPU à 100%). Je suis agréablement surpris : c'est lent, mais ce n'est pas si loin d'être utilisable.
Avec MTP, curieusement, les performances sont catastrophiques. Ça reste en dessous de 1 token/s.
J'ai aussi testé vite fait sur mes Nvidia RTX 3060, sans MTP : en --split-mode layer, j'arrive à 15 tokens/s (pas confortable, mais utilisable). En --split-mode row, sans trop de surprise, c'est à pleurer tellement c'est lent.
Reste surtout cette question de la bascule d'un jeu d'experts à un autre. Ça promet de ne pas être simple du tout à tester.
Je vais creuser ça un peu plus dans les prochains temps.
En fait, Ollama, pour commencer, pourquoi pas. Il reste plus simple à installer que llama-swap + llama-server. Mais une fois une première phase d'essais passée, si on veut aller plus loin, je recommande de ne pas rester sur Ollama (plus le changement sera tardif, plus il sera pénible).
Pour HA, je vais jouer le suspense :-). J'ai pour projet de faire un futur journal dédié aux frontends, dont HA.
Je vais un peu modérer mes propos et ma position aussi :
De façon générale, le débordement CPU+RAM est utilisable … à petite dose. llama.cpp ne l'a pas implémenté juste pour le fun.
Les fameux posts LinkedIn dont je me plaignais, ce n'est pas sur du matériel récent. C'est du style "j'ai sorti ma vieille GTX 1060 6Go d'un carton, j'ai mis Qwen 3.6 35b dessus, je lui ai balancé 2 phrases, et clairement je n'ai plus besoin de Claude Opus !" (un des posts que j'ai en mémoire était presque littéralement ça !).
Alors, ce qu'il dit n'est pas impossible mais il y a beaucoup de variables à prendre en compte. Ce qui va jouer :
122b. C'est gros.
en q4, sa carte graphique peut contenir 4 experts à la fois.
la taille du contexte max qu'il a choisi
le ou les prompt exacts / les contextes exacts
Sur un petit prompt, il va peut-être activer un ou deux réseaux de neurones experts, et vu la config, ça passera largement. Sur un contexte large, avec des tokens variés, il risque de solliciter plus que 4 experts, et là, ses performances vont s'effondrer brutalement. À chaque bascule d'un expert à l'autre, son système va devoir les échanger entre RAM et VRAM.
Ce qui le sauve peut-être aussi, c'est qu'un modèle 122b, c'est gros. Je n'ai pas encore testé aussi gros. C'est plus de connaissances entassées dans un modèle que les 26b et 35b dont j'ai l'habitude, et ses experts de 10b doivent être plus autonomes que les 3b dont j'ai l'habitude. Donc en solliciter plus que 4 à la fois n'arrive peut-être pas si souvent.
S'il a de la DDR5, ça peut aussi atténuer la dégradation en permettant des bascules d'experts plus rapides. Mais perso, n'étant qu'un pauvre péon, je suis actuellement coincé en DDR4 :-)
Je pense qu'un bon test pour un MoE serait d'utiliser le LLM en tant qu'agent, et lui faire chercher quelque-chose sur Internet. Les pages Internet remplissent généralement vite le contexte, avec du texte assez varié.
Pour les MoE ≤35b, honnêtement, je n'ai jamais été pleinement satisfait de ceux que j'ai testés. Par exemple, Gemma4-26b (MoE a4b) fonctionne, et est très bien pour des choses simples, mais dès que ça se complique, il est un peu con (et répétitif). Qwen-3.6 35b a3b est très rapide, mais dès que ça se complique, il est du genre à se manger les mûrs. Qwen-3.6-27b (dense) par contre, j'en suis globalement content. C'est pas parfait, mais il est clairement plus futé.
Je vais essayer des gros MoE avec du débordement à l'occasion. Mes NVMe vont pleurer, mais je suis curieux de voir ce que je peux en tirer. Peut-être qu'un aussi gros MoE me fera changer d'avis ? :-)
Et pour le projet ds4 … comme d'hab, les oubliés, c'est les cartes Intel. Snif.
Je ne parle pas de TCO, parce que c'est très difficile à évaluer, et surtout, pour moi, c'est totalement hors-sujet.
C'est difficile à évaluer :
J'ai une utilisation modeste de l'IA. Contrairement à ce que certains semblent supposer, ma machine ne tourne pas 24/24. Elle est allumée quand j'en ai besoin (soit quelque-part entre 4h et 10h par jour), et elle est idle une grosse partie du temps à ~100W. J'ai une prise intelligente branchée dessus, donc si ça intéresse des curieux, je pourrais vous faire un retour sur le coût de l'électricité dans quelques mois.
Et c'est tout aussi difficile à comparer au cloud : Pour quelqu'un comme moi qui a une utilisation modeste de l'IA, ça peut remplacer complètement un abonnement Claude. Pour des gens qui vibe-sloppent, il leur faudrait sûrement garder leur abonnement, mais ils pourraient peut-être s'en servir pour passer du max (90€/mois) au pro (18€/mois) ?
Et est-ce qu'une Intel Arc Pro B60/B70 ne pourrait pas suffire à ces gens ? Auquel cas, le TCO devient probablement beaucoup plus raisonnable. Mais ça dépend toujours des gens et de leur façon de travailler, donc c'est tout aussi difficile à dire.
Et c'est totalement hors-sujet pour moi :
Je ne fais pas ce montage pour faire des économies. Je fais ce montage parce-que j'ai une sainte horreur de tout ce qui est cloud, et parce-que le sujet m’intéresse particulièrement.
Concernant le futur des modèles openweight :
Anthropic n'a jamais distribué aucun modèle openweight à ma connaissance.
En terme de modèles récents, le seul d'OpenAI est gpt-oss, mais il n'a pas beaucoup marqué les mémoires.
De plus, Gemma est fait par Google, pas par une boite chinoise. Je suspecte qu'ils font ces modèles en anticipation du jour où les téléphones Android seront capables de les faire tourner.
À noter que les premiers modèles open-weight furent quasiment tous américains (GPT-1, GPT-2, llama2, etc). Ce ne sont pas les chinois qui ont lancé cette tendance. Il est aussi intéressant de noter que Mistral, notre (seul) champion français, ouvre aussi généralement les poids de ses modèles.
Alors, je viens de regarder: pour une deuxième alimentation, il faut un petit module "add2psu".
D'ailleurs, je viens de refaire mes calculs, et si je veux monter à 6 GPU sans risquer de faire cramer mon alimentation, il va me falloir une deuxième alimentation. Donc je vais devoir tester les add2psu.
J'espère bien que tout le monde ne va pas faire pareil ! On est bien d'accord que ça serait une catastrophe. Déjà rien que les IA en datacenter promettent d'être un cauchemar écologique.
Pour le coup, c'est un montage somme toute très compliqué à faire, matériellement et logiciellement. C'est clairement un projet de passionné. Je ne me suis pas imaginé à un seul moment que quelqu'un de non-passionné puisse vouloir faire ça.
Je le partage ici surtout pour éviter à d'autres passionnés des erreurs que j'ai pu faire ou que j'aurai pu faire (d'autant plus important qu'il y a un risque incendie non-négligeable sur ce genre de montage). Je suppose aussi que pour les non-passionnés, c'est juste intéressant de voir ce l'auto-hébergement d'IA peut nécessiter.
Pour le futur, mon espoir est que les prix du matériel reviennent à une certaine normalité, et que la capacité du matériel permette de faire tourner les IA auto-hébergeables d'aujourd'hui sur une seule carte graphique de demain. Ceci dit, vu la tournure des évènements, je n'y crois pas trop.
Les alimentations 1200W et 1500W viennent normalement avec suffisamment de connecteurs.
Je déconseille les splitters sur les câbles d'alimentation. Le risque de dépasser le maximum accepté par le connecteur initial est non-négligeable.
À défaut, je recommande plutôt de mettre en place une deuxième alimentation. Je sais que c'est faisable parce-que les mineurs de cryptomonnaie l'ont souvent fait. Mais comme j'ai eut la chance de trouver une bonne alimentation de 1500W, je n'ai pas creusé plus le sujet. Si on part sur cette option, il faut surtout faire très attention à ne pas dépasser la capacité du réseau électrique domestique (fusible, prise, multi-prise), et à toujours garder en tête que les puissances maximum indiquées sont des maximum en pic, pas en consommation continue.
[^] # Re: Passer de 16 à 32 Go : un vrai gain, mais jusqu’où ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. É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: Tant de mots
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Ma découverte de l'IA, et de sa mise en exploitation personnelle.. Évalué à 4 (+2/-0). Dernière modification le 04 août 2026 à 16:36.
Pschut, caftes pas nos secrets ! 😁
Plus sérieusement, les LLM me ramènent au temps où une compilation complète d'un projet durait souvent longtemps. Ce temps où j'allais parfois discuter à la machine à café "le temps que la machine finisse" 🙂
[^] # Re: très éclairant
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. É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) . En réponse au journal Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. É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: très éclairant
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. É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: Ça vous sert à quoi au quotidien ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. Évalué à 10 (+11/-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é.
# Vexant
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Ma découverte de l'IA, et de sa mise en exploitation personnelle.. Évalué à 10 (+11/-0). Dernière modification le 03 août 2026 à 13:25.
Même si je méfis du vibe-coding comme de la peste, je crois que je vais prendre ce passage personnellement … 🙂
[^] # Re: Petite config
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 2 (+0/-0).
Je ne connais pas de communauté dédiée à ces sujets. La plus proche que je connaisse est le sub-reddit /r/localllama.
[^] # Re: Petite config
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 3 (+1/-0). Dernière modification le 14 juillet 2026 à 09:33.
Sur le sujet de l'utilisation des LLMs sur les configurations à faible VRAM (≤16gb) ? Ou sur les très petits modèles (≤10b) ?
En fait, dans les deux cas, pas vraiment. Les petits modèles sont très limités, et ont donc peu d'utilisations possibles. Et faire tourner sérieusement des LLM plus gros sur des configurations à faible VRAM implique de faire du débordement CPU+RAM. Et le débordement, c'est vicieux : Au premier abord, ça semble donner des résultats utilisables. Mais ce que beaucoup ratent, c'est que ces résultats s'effondrent vite en utilisation réelle avec l'augmentation du contexte. Je pense détailler cette dernière problématique dans un prochain journal.
[^] # Re: P2P / RDMA
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 3 (+1/-0).
Tout ce que j'ai mis dans le journal (ReBAR, amd_iommu=on, iommu=pt, le patch Nvidia, etc), je les ai configurés et/ou installés. Par contre, je n'ai pas essayé
simpleP2Pnip2pBandwidthLatencyTest. À la place, j'avais regardé l'état d'interconnexion avecnvidia-smi topo -m.Je vais réessayer tout ça à l'occasion.
[^] # Re: P2P / RDMA
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 3 (+1/-0).
Eh, nextgens ! Ça fait super longtemps ! Comment tu vas ? :-)
Alors c'est vrai que mon matériel le supporte peut-être, j'ai du mal à être 100% sûr sur ce point. Mais ce n'est pas faute d'avoir essayé de le faire marcher … Je vais retenter à l'occasion. Qui sait, j'arriverai peut-être à lui arracher un miracle. Si tu as une idée de trucs à essayer que j'aurais peut-être raté, je suis preneur.
[^] # Re: Je me permets de partager mon approche
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 2 (+0/-0). Dernière modification le 10 juillet 2026 à 22:00.
Personne ne sait de quoi le futur est fait, et cette vidéo ne fait pas exception à la règle.
Personnellement, je suis d'avis qu'il vaut mieux baser ses choix sur ce qui existe maintenant que ce qui pourrait exister dans 6 mois. Si tu veux voir si une IA locale d'aujourd'hui pourrait convenir à tes besoins d'aujourd'hui, tu peux tester la plupart des modèles en passant par openrouter.ai (attention par contre, leur quantifications ne sont jamais spécifiées).
[^] # Re: Je me permets de partager mon approche
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 2 (+0/-0). Dernière modification le 08 juillet 2026 à 21:09.
Je ne l'ai pas mentionné explicitement, mais, par défaut, llama-swap ne garde qu'un seul modèle actif (il faut définir une matrice pour en charger plusieurs simultanément). Et en fait, si tu regardes l'exemple de configuration llama-swap que j'ai mis pour la Intel Arc Pro B60, tu constateras que je suis exactement dans le même cas que toi : Avec cette configuration, llama-swap bascule automatiquement entre stable-diffusion.cpp et différentes configurations de llama-server. (bon par contre, la Intel Arc Pro B60, la bascule, c'est plutôt 1 à 2 min … :/)
Mon expérience personnelle est que oui, le q8 est meilleur pour moi. Mais honnêtement, je pense que ça dépend vraiment des besoins de chacun, d'où ma suggestion d'utiliser la B60 avec qwen 3.6 q4_k_xl.
[^] # Re: Je me permets de partager mon approche
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 3 (+1/-0).
Personnellement, je suis activement le subreddit /r/locallama. Quand un nom de modèle revient plusieurs fois avec des avis positifs, je me dis que ça vaut le coup que je le teste :-)
Comme mentionné, actuellement, les deux à tester en premier, c'est qwen3.6 27b (code) et gemma-4 31b (généraliste) … si pouvez les faire passer sur votre machine. Sinon ça peut valoir le coup d'essayer leurs petits frères MoE.
Les versions quantifiées par le projet Unsloth sont généralement les plus fiables. Ce sont les versions officielles, quantifiées proprement, avec tout au plus quelques corrections de bugs dans leur manifeste.
Après, des fois, j'en essaye d'autres au petit bonheur la chance ¯\_(ツ)_/¯
[^] # Re: T'as testé une conf hybride CPU/GPU
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 2 (+0/-0). Dernière modification le 08 juillet 2026 à 10:12.
J'ai fait un test sur mon portable AMD de 2021 qui a de la DDR4. Avec un qwen3.6 35b a3b, j'arrive à tirer 10 tokens/s. J'ai utilisé en partie le GPU, mais la VRAM est la RAM sur cette machine. Autant dire que ça ne semble pas faire une grosse différence avec du CPU+RAM purs.
Donc après réflexion, concernant le cas d'origine que tu exposes, je me dis qu'avec un processeur moderne et de la DDR5, avec un MoE a10b, même en CPU+RAM purs ou presque, la personne peut peut-être bien arriver à 30 tokens/s, de façon fiable.
C'est très intéressant, parce-qu'autant les a3b sont plutôt bêtes, autant je suppose que les a10b doivent être plus malins.
Reste le problème de la ramapocalypse … :/
[^] # Re: auto hebergement et HA
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 2 (+0/-0).
HA = Home Assistant :-)
MDM, Mobile Device Management ? oO
[^] # Re: T'as testé une conf hybride CPU/GPU
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 2 (+0/-0). Dernière modification le 07 juillet 2026 à 15:50.
En effet, c'est vrai … pour un token individuellement :-). Sur un contexte, c'est une autre histoire.
Et sur ce point, en fait, tu as parfaitement raison. Désolé, mes explications étaient franchement confuses voir inexactes.
Ceci dit, le principe tient : lors du traitement du contexte, le passage d'un token à l'autre peut déclencher différents experts. Si ces experts ne sont pas en VRAM, les perfs vont prendre une claque.
Effectivement, je ne connaissais pas. Le benchmark de la Intel B70 a attiré mon œil. Elle patatore effectivement nettement plus que la B60 :-)
Pour l'anecdote, j'ai testé très rapidement qwen-3.6 122b sur une Intel B60 avec débordement CPU+RAM DDR4 :
Sans MTP, je vois quelque-chose d'assez intriguant : La vitesse de génération commence très très basse (quelques tokens/s ; GPU utilisé à 10~20%), et elle monte lentement mais sûrement vers un peu plus de 10 tokens/s (GPU à 100%). Je suis agréablement surpris : c'est lent, mais ce n'est pas si loin d'être utilisable.
Avec MTP, curieusement, les performances sont catastrophiques. Ça reste en dessous de 1 token/s.
J'ai aussi testé vite fait sur mes Nvidia RTX 3060, sans MTP : en
--split-mode layer, j'arrive à 15 tokens/s (pas confortable, mais utilisable). En--split-mode row, sans trop de surprise, c'est à pleurer tellement c'est lent.Reste surtout cette question de la bascule d'un jeu d'experts à un autre. Ça promet de ne pas être simple du tout à tester.
Je vais creuser ça un peu plus dans les prochains temps.
# Autres montages
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 3 (+1/-0).
Apparemment, j'ai de la compétition en matière de montages façon "Dédé la bricole" : https://www.reddit.com/r/LocalLLaMA/comments/1uoa1t3/who_has_the_jankiest_local_llm_setup_nonofficial/ :-)
[^] # Re: auto hebergement et HA
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 3 (+1/-0). Dernière modification le 06 juillet 2026 à 17:03.
En fait, Ollama, pour commencer, pourquoi pas. Il reste plus simple à installer que llama-swap + llama-server. Mais une fois une première phase d'essais passée, si on veut aller plus loin, je recommande de ne pas rester sur Ollama (plus le changement sera tardif, plus il sera pénible).
Pour HA, je vais jouer le suspense :-). J'ai pour projet de faire un futur journal dédié aux frontends, dont HA.
[^] # Re: vulkan me semblait plus rapide que rocm
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 2 (+0/-0). Dernière modification le 06 juillet 2026 à 16:29.
Merci pour ce retour, je dormirai moins bête :-)
En plus, ça me fait plaisir de lire ça. De mon point de vue, Vulkan est clairement le bon chemin pour le futur.
[^] # Re: T'as testé une conf hybride CPU/GPU
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 3 (+1/-0). Dernière modification le 06 juillet 2026 à 16:26.
Je vais un peu modérer mes propos et ma position aussi :
De façon générale, le débordement CPU+RAM est utilisable … à petite dose.
llama.cppne l'a pas implémenté juste pour le fun.Les fameux posts LinkedIn dont je me plaignais, ce n'est pas sur du matériel récent. C'est du style "j'ai sorti ma vieille GTX 1060 6Go d'un carton, j'ai mis Qwen 3.6 35b dessus, je lui ai balancé 2 phrases, et clairement je n'ai plus besoin de Claude Opus !" (un des posts que j'ai en mémoire était presque littéralement ça !).
Alors, ce qu'il dit n'est pas impossible mais il y a beaucoup de variables à prendre en compte. Ce qui va jouer :
Sur un petit prompt, il va peut-être activer un ou deux réseaux de neurones experts, et vu la config, ça passera largement. Sur un contexte large, avec des tokens variés, il risque de solliciter plus que 4 experts, et là, ses performances vont s'effondrer brutalement. À chaque bascule d'un expert à l'autre, son système va devoir les échanger entre RAM et VRAM.
Ce qui le sauve peut-être aussi, c'est qu'un modèle 122b, c'est gros. Je n'ai pas encore testé aussi gros. C'est plus de connaissances entassées dans un modèle que les 26b et 35b dont j'ai l'habitude, et ses experts de 10b doivent être plus autonomes que les 3b dont j'ai l'habitude. Donc en solliciter plus que 4 à la fois n'arrive peut-être pas si souvent.
S'il a de la DDR5, ça peut aussi atténuer la dégradation en permettant des bascules d'experts plus rapides. Mais perso, n'étant qu'un pauvre péon, je suis actuellement coincé en DDR4 :-)
Je pense qu'un bon test pour un MoE serait d'utiliser le LLM en tant qu'agent, et lui faire chercher quelque-chose sur Internet. Les pages Internet remplissent généralement vite le contexte, avec du texte assez varié.
Pour les MoE ≤35b, honnêtement, je n'ai jamais été pleinement satisfait de ceux que j'ai testés. Par exemple, Gemma4-26b (MoE a4b) fonctionne, et est très bien pour des choses simples, mais dès que ça se complique, il est un peu con (et répétitif). Qwen-3.6 35b a3b est très rapide, mais dès que ça se complique, il est du genre à se manger les mûrs. Qwen-3.6-27b (dense) par contre, j'en suis globalement content. C'est pas parfait, mais il est clairement plus futé.
Je vais essayer des gros MoE avec du débordement à l'occasion. Mes NVMe vont pleurer, mais je suis curieux de voir ce que je peux en tirer. Peut-être qu'un aussi gros MoE me fera changer d'avis ? :-)
Et pour le projet ds4 … comme d'hab, les oubliés, c'est les cartes Intel. Snif.
[^] # Re: Coût
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 5 (+3/-0). Dernière modification le 06 juillet 2026 à 13:45.
Je ne parle pas de TCO, parce que c'est très difficile à évaluer, et surtout, pour moi, c'est totalement hors-sujet.
C'est difficile à évaluer :
J'ai une utilisation modeste de l'IA. Contrairement à ce que certains semblent supposer, ma machine ne tourne pas 24/24. Elle est allumée quand j'en ai besoin (soit quelque-part entre 4h et 10h par jour), et elle est idle une grosse partie du temps à ~100W. J'ai une prise intelligente branchée dessus, donc si ça intéresse des curieux, je pourrais vous faire un retour sur le coût de l'électricité dans quelques mois.
Et c'est tout aussi difficile à comparer au cloud : Pour quelqu'un comme moi qui a une utilisation modeste de l'IA, ça peut remplacer complètement un abonnement Claude. Pour des gens qui vibe-sloppent, il leur faudrait sûrement garder leur abonnement, mais ils pourraient peut-être s'en servir pour passer du max (90€/mois) au pro (18€/mois) ?
Et est-ce qu'une Intel Arc Pro B60/B70 ne pourrait pas suffire à ces gens ? Auquel cas, le TCO devient probablement beaucoup plus raisonnable. Mais ça dépend toujours des gens et de leur façon de travailler, donc c'est tout aussi difficile à dire.
Et c'est totalement hors-sujet pour moi :
Je ne fais pas ce montage pour faire des économies. Je fais ce montage parce-que j'ai une sainte horreur de tout ce qui est cloud, et parce-que le sujet m’intéresse particulièrement.
Concernant le futur des modèles openweight :
Anthropic n'a jamais distribué aucun modèle openweight à ma connaissance.
En terme de modèles récents, le seul d'OpenAI est gpt-oss, mais il n'a pas beaucoup marqué les mémoires.
De plus, Gemma est fait par Google, pas par une boite chinoise. Je suspecte qu'ils font ces modèles en anticipation du jour où les téléphones Android seront capables de les faire tourner.
À noter que les premiers modèles open-weight furent quasiment tous américains (GPT-1, GPT-2, llama2, etc). Ce ne sont pas les chinois qui ont lancé cette tendance. Il est aussi intéressant de noter que Mistral, notre (seul) champion français, ouvre aussi généralement les poids de ses modèles.
Ce n'est donc pas une tendance nouvelle, et je doute qu'elle soit temporaire. Sinon le patron d'Anthropic ne s'embêterait pas à activement de lutter contre.
[^] # Re: Alimentation
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 4 (+2/-0).
Alors, je viens de regarder: pour une deuxième alimentation, il faut un petit module "add2psu".
D'ailleurs, je viens de refaire mes calculs, et si je veux monter à 6 GPU sans risquer de faire cramer mon alimentation, il va me falloir une deuxième alimentation. Donc je vais devoir tester les add2psu.
[^] # Re: PUE ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 3 (+1/-0).
J'espère bien que tout le monde ne va pas faire pareil ! On est bien d'accord que ça serait une catastrophe. Déjà rien que les IA en datacenter promettent d'être un cauchemar écologique.
Pour le coup, c'est un montage somme toute très compliqué à faire, matériellement et logiciellement. C'est clairement un projet de passionné. Je ne me suis pas imaginé à un seul moment que quelqu'un de non-passionné puisse vouloir faire ça.
Je le partage ici surtout pour éviter à d'autres passionnés des erreurs que j'ai pu faire ou que j'aurai pu faire (d'autant plus important qu'il y a un risque incendie non-négligeable sur ce genre de montage). Je suppose aussi que pour les non-passionnés, c'est juste intéressant de voir ce l'auto-hébergement d'IA peut nécessiter.
Pour le futur, mon espoir est que les prix du matériel reviennent à une certaine normalité, et que la capacité du matériel permette de faire tourner les IA auto-hébergeables d'aujourd'hui sur une seule carte graphique de demain. Ceci dit, vu la tournure des évènements, je n'y crois pas trop.
[^] # Re: Alimentation
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 3 (+1/-0).
Les alimentations 1200W et 1500W viennent normalement avec suffisamment de connecteurs.
Je déconseille les splitters sur les câbles d'alimentation. Le risque de dépasser le maximum accepté par le connecteur initial est non-négligeable.
À défaut, je recommande plutôt de mettre en place une deuxième alimentation. Je sais que c'est faisable parce-que les mineurs de cryptomonnaie l'ont souvent fait. Mais comme j'ai eut la chance de trouver une bonne alimentation de 1500W, je n'ai pas creusé plus le sujet. Si on part sur cette option, il faut surtout faire très attention à ne pas dépasser la capacité du réseau électrique domestique (fusible, prise, multi-prise), et à toujours garder en tête que les puissances maximum indiquées sont des maximum en pic, pas en consommation continue.