Cela signifie-t-il qu’on peut utiliser un modèle qui nécessite davantage que 16GB de RAM, mais n’est pas dense et donc se contenterait quand même de mes 16GB ?
Attention à la confusion entre VRAM (la RAM de la carte graphique) et la RAM (la RAM du CPU) !
Si tu veux effectivement dire que tu n'as que 16 Go de RAM (et, je suppose, encore moins de VRAM), tu vas avoir du mal à faire tourner quoique ce soit de correct (dense ou non). Tu vas être restreint aux très petits LLM (denses) qui sont bêtes comme des caillous.
Si tu voulais dire que tu as 16 Go de VRAM (et, je suppose, assez de RAM), alors oui : les modèles "pas denses", ce sont les MoE (Mixture-of-Experts). Et ils permettent justement ça.
Avec l'option --cpu-moe, les éléments du MoE qui sont systématiquement sollicités à chaque token sont gérés par la carte graphique et sont mis en VRAM. Les autres (les experts) sont gérés par le CPU et sont en RAM classique. Et en terme d'occupation mémoire, les experts représentent la plus grosse partie d'un modèle MoE. Mais comme un seul expert est sollicité à chaque token (simplification), ils sont plus rapides à traiter, et le CPU seul peut s'en occuper.
Grâce à ça, avec tes 16 Go de VRAM, si tu as assez de RAM, tu peux faire tourner un MoE comme qwen 3.6 35b par exemple sans problème, même si il occupe plus de 20 Go de RAM/VRAM.
(Initialement, avec les MoE, je pensais que la vitesse de génération était OK, mais que la vitesse de preremplissage allait pêcher quand même ; d'où mon corrigendum : en fait, le préremplissage peut être optimisé et arriver à un niveau tout à fait satisfaisant).
Concernant le piège que tu évoques sur les documents et le RAG, est ce que tu as essayé l'option "Full Context" ?
Raahhh, mais évidemment qu'il y avait une option planquée pour ça … 😭
Pour ceux qui, comme moi, galère ou ont galéré, il faut :
joindre le fichier à la conversation
cliquer sur le fichier (avant d'envoyer un message au LLM !)
en haut à droite, basculer l'interrupteur "Utilisation de la récupération ciblée", qui doit alors devenir "Utilisation du document entier" (et oui, le texte décris l'état actuel, et non pas ce qui va être activé quand vous activez l'interrupteur …).
Pour le coup, merci du tuyau ! Tu viens de m'enlever une belle épine du pied 🙂.
Chers gentils modérateurs, serait-il possible de retirer ce malheureux bout de phrase de mon journal s'il vous plaît : « et que vous ne pouvez pas changer ce comportement » ? 🥺
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.
[^] # Re: Dense ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Interfaces utilisateur. Évalué à 2 (+0/-0).
Perso, j'utilise
nvtop(sudo nécessaire avec les cartes Intel et AMD pour voir la VRAM consommée).[^] # Re: Dense ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Interfaces utilisateur. Évalué à 3 (+1/-0). Dernière modification le 20 septembre 2026 à 16:51.
Attention à la confusion entre VRAM (la RAM de la carte graphique) et la RAM (la RAM du CPU) !
Si tu veux effectivement dire que tu n'as que 16 Go de RAM (et, je suppose, encore moins de VRAM), tu vas avoir du mal à faire tourner quoique ce soit de correct (dense ou non). Tu vas être restreint aux très petits LLM (denses) qui sont bêtes comme des caillous.
Si tu voulais dire que tu as 16 Go de VRAM (et, je suppose, assez de RAM), alors oui : les modèles "pas denses", ce sont les MoE (Mixture-of-Experts). Et ils permettent justement ça.
Avec l'option
--cpu-moe, les éléments du MoE qui sont systématiquement sollicités à chaque token sont gérés par la carte graphique et sont mis en VRAM. Les autres (les experts) sont gérés par le CPU et sont en RAM classique. Et en terme d'occupation mémoire, les experts représentent la plus grosse partie d'un modèle MoE. Mais comme un seul expert est sollicité à chaque token (simplification), ils sont plus rapides à traiter, et le CPU seul peut s'en occuper.Grâce à ça, avec tes 16 Go de VRAM, si tu as assez de RAM, tu peux faire tourner un MoE comme qwen 3.6 35b par exemple sans problème, même si il occupe plus de 20 Go de RAM/VRAM.
Voir:
(Initialement, avec les MoE, je pensais que la vitesse de génération était OK, mais que la vitesse de preremplissage allait pêcher quand même ; d'où mon corrigendum : en fait, le préremplissage peut être optimisé et arriver à un niveau tout à fait satisfaisant).
[^] # Re: Frustration
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Interfaces utilisateur. Évalué à 2 (+0/-0). Dernière modification le 06 septembre 2026 à 10:35.
En fait, je pense que c'est une frustration assez courante.
Sauf erreur de ma part, ceux qui veulent utiliser sérieusement l'IA générative passent généralement rapidement d'un simple chat à ComfyUI.
# Coquilles
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Corrigendum : Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. Évalué à 5 (+3/-0). Dernière modification le 28 août 2026 à 18:20.
Je voulais préciser « peut aider avec la vitesse de prédicition » …
Et ici, le « nombre de cœurs de votre CPU ».
Gentils modos, s'il vous plaît ? 🥺🙏
(en plus, je vous jure que je me relis encore et encore avant de poster …)
# Corrigendum !
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).
Petit journal supplémentaire pour corriger une belle boulette que j'ai fait ici : https://linuxfr.org/users/jflesch/journaux/corrigendum-auto-heberger-ses-llm-ia-debordement-cpu-ram-mixture-of-experts-et-benchmarks
[^] # Re: Option "Full Context" pour les documents ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Interfaces utilisateur. Évalué à 4 (+2/-0). Dernière modification le 18 août 2026 à 18:31.
Raahhh, mais évidemment qu'il y avait une option planquée pour ça … 😭
Pour ceux qui, comme moi, galère ou ont galéré, il faut :
Pour le coup, merci du tuyau ! Tu viens de m'enlever une belle épine du pied 🙂.
Chers gentils modérateurs, serait-il possible de retirer ce malheureux bout de phrase de mon journal s'il vous plaît : « et que vous ne pouvez pas changer ce comportement » ? 🥺
[^] # 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 (+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é.
# 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 (+12/-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.