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.
Le temps de calcul où le modèle évalue le prompt, c'est le temps de lecture, aussi appelé pré-remplissage (prefill). À ma connaissance, c'est exactement la même procédure, et donc la même vitesse, pour lire un contexte depuis le début, que pour lire une phrase de 10 mots écrite par l'utilisateur après coup pendant la conversation.
C'est tout à fait possible. Je n'ai pas de carte AMD, donc je ne peux pas tester de mon côté.
Quand j'ai écris "généralement plus lent", je me suis basé sur mon expérience avec la Intel B60 et sur ce que j'ai pu lire dans divers commentaires sur divers sites. J'ai peut-être fait une généralisation hâtive sur ce coup-là :/
Ça serait plutôt l'écriture de nouvelles ça.
Pour le jeu de rôle, il s'agit de demander au LLM de soit jouer le rôle du Maître du Jeu, soit le rôle d'un autre personnage, soit les deux.
Pour avoir essayé le vibe-coding, c'est exactement mon expérience. Le vibe-coding donne trop vite des résultats. C'est impossible de se motiver à relire sérieusement ce que génère l'IA. On veut juste sa dose de dopamine suivante le plus vite possible.
Et en parlant d'expérience, à force de vibe-coder, la perte de compétences va être brutal chez certains.
Moi qui en avait déjà ras-le-bol de devoir repasser régulièrement derrière les collègues pour nettoyer leur travail bâclé, v'là que ça va pas râter, je vais devoir repasser derrière leurs IAs ...
Elles sont compliquées à refroidir correctement. Elles ne sont plus supportées par les pilotes Nvidia depuis mi-2024 (pilote 470 il me semble). Et comme gUI l'a fait remarquer, comparé aux dernières générations de GPU, elles ont maintenant autant de puissance de calcul qu'une pomme de terre mal-cuite.
Et les H100 à moins 600,ドル faut me dire où ! C'est l'occasion de devenir riche ! :-)
C'est une remarque intéressante. Ceci dit, pour ma part, j'ai l'impression que c'est plutôt l'inverse. Je pense que l'entrisme est plutôt du coté des LLMs cloud.
Les LLMs cloud sont nettement plus accessibles et faciles à utiliser que les LLMs auto-hébergés. Le prix d'entrée des LLMs cloud est nettement plus bas aussi. Les LLMs auto-hébergés sont, eux, très difficiles à mettre en place de façon viable. D'ailleurs, je viens d'acheter deux cartes Intel Arc Pro B60, et j'ai encore envie d'hurler tellement elles sont ridiculement difficiles à utiliser pour faire tourner des LLMs.
Mais comme mentionné, les LLMs cloud ont des limitations tarifaires. Je pense que c'est surtout ces limitations qui vont pousser les gens qui ont une utilisation plus intense des LLMs vers les LLMs auto-hébergés. Je suppose que la plupart feront alors, comme moi, un mix des deux : LLMs auto-hebergés pour ce qu'ils savent faire, et occasionnellement LLMs cloud pour les tâches qui demandent un peu plus d'intelligence ou de fiabilité.
De ce que j'en comprends, SLI et Crossfire ont été abandonné. Les jeux n'exploitent plus qu'une seule carte vidéo.
Pour le gain de perf, d'après ce que je comprends, ça dépend de ton moteur d'inférence.
llama.cpp est bête et méchant: il met les N premières couches du réseau de neurones sur une carte graphique, les N couches suivantes sur une autre carte graphique, etc. Et pour chaque token, il interroge chaque carte graphique, les unes après les autres. Du coup, il y a un gain de perf que lorsqu'il y a plusieurs requêtes en parallèle. Mais sinon, il y a même un peu de perte de vitesse à cause du temps perdu à passer par le bus PCIe et le CPU entre chaque carte.
vLLM, lui distribue ça plus intelligemment : chaque couche est répartie entre les cartes graphiques --> toutes les cartes travaillent en parallèle et s'échangent, à chaque sortie de couche, une partie de leur résultat. Ça sollicite plus intensément le bus PCIe et le CPU, mais augmenter le nombre de GPU augmente les performances. Par contre, pour cette raison, vLLM est plus exigeant et préfère des cartes graphiques identiques. C'est pour ça que je n'ai pas pu l'utiliser efficacement sur mon montage.
La conso, ça dépend. Comme llama.cpp ne parallélise pas le calcul, tu n'as qu'une carte vraiment active à la fois. Je n'ai pas pu tester avec vLLM.
[^] # 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é à 2 (+0/-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.
[^] # Re: Temps de "thinking" après envoie du prompt
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).
Le temps de calcul où le modèle évalue le prompt, c'est le temps de lecture, aussi appelé pré-remplissage (prefill). À ma connaissance, c'est exactement la même procédure, et donc la même vitesse, pour lire un contexte depuis le début, que pour lire une phrase de 10 mots écrite par l'utilisateur après coup pendant la conversation.
[^] # 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é à 5 (+3/-0).
C'est tout à fait possible. Je n'ai pas de carte AMD, donc je ne peux pas tester de mon côté.
Quand j'ai écris "généralement plus lent", je me suis basé sur mon expérience avec la Intel B60 et sur ce que j'ai pu lire dans divers commentaires sur divers sites. J'ai peut-être fait une généralisation hâtive sur ce coup-là :/
[^] # Re: Jeu de rôle?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA. Évalué à 3 (+1/-0).
Ça serait plutôt l'écriture de nouvelles ça.
Pour le jeu de rôle, il s'agit de demander au LLM de soit jouer le rôle du Maître du Jeu, soit le rôle d'un autre personnage, soit les deux.
[^] # Re: Ben ... Oui !
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Un code généré par IA est-il obligatoirement du "AI slop" ?. Évalué à 5 (+3/-0).
Pour avoir essayé le vibe-coding, c'est exactement mon expérience. Le vibe-coding donne trop vite des résultats. C'est impossible de se motiver à relire sérieusement ce que génère l'IA. On veut juste sa dose de dopamine suivante le plus vite possible.
Et en parlant d'expérience, à force de vibe-coder, la perte de compétences va être brutal chez certains.
Moi qui en avait déjà ras-le-bol de devoir repasser régulièrement derrière les collègues pour nettoyer leur travail bâclé, v'là que ça va pas râter, je vais devoir repasser derrière leurs IAs ...
[^] # Re: 600€ pour s'inicier
Posté par Jérôme Flesch (site web personnel) . En réponse au journal IA : mon parcours initiatique. Évalué à 4 (+2/-0). Dernière modification le 21 mai 2026 à 17:27.
Elles sont compliquées à refroidir correctement. Elles ne sont plus supportées par les pilotes Nvidia depuis mi-2024 (pilote 470 il me semble). Et comme gUI l'a fait remarquer, comparé aux dernières générations de GPU, elles ont maintenant autant de puissance de calcul qu'une pomme de terre mal-cuite.
Et les H100 à moins 600,ドル faut me dire où ! C'est l'occasion de devenir riche ! :-)
[^] # Re: De l'entrisme ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA. Évalué à 3 (+1/-0).
C'est une remarque intéressante. Ceci dit, pour ma part, j'ai l'impression que c'est plutôt l'inverse. Je pense que l'entrisme est plutôt du coté des LLMs cloud.
Les LLMs cloud sont nettement plus accessibles et faciles à utiliser que les LLMs auto-hébergés. Le prix d'entrée des LLMs cloud est nettement plus bas aussi. Les LLMs auto-hébergés sont, eux, très difficiles à mettre en place de façon viable. D'ailleurs, je viens d'acheter deux cartes Intel Arc Pro B60, et j'ai encore envie d'hurler tellement elles sont ridiculement difficiles à utiliser pour faire tourner des LLMs.
Mais comme mentionné, les LLMs cloud ont des limitations tarifaires. Je pense que c'est surtout ces limitations qui vont pousser les gens qui ont une utilisation plus intense des LLMs vers les LLMs auto-hébergés. Je suppose que la plupart feront alors, comme moi, un mix des deux : LLMs auto-hebergés pour ce qu'ils savent faire, et occasionnellement LLMs cloud pour les tâches qui demandent un peu plus d'intelligence ou de fiabilité.
[^] # Re: Plusieurs cartes en SLI ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA. Évalué à 6 (+4/-0). Dernière modification le 19 mai 2026 à 16:08.
De ce que j'en comprends, SLI et Crossfire ont été abandonné. Les jeux n'exploitent plus qu'une seule carte vidéo.
Pour le gain de perf, d'après ce que je comprends, ça dépend de ton moteur d'inférence.
llama.cpp est bête et méchant: il met les N premières couches du réseau de neurones sur une carte graphique, les N couches suivantes sur une autre carte graphique, etc. Et pour chaque token, il interroge chaque carte graphique, les unes après les autres. Du coup, il y a un gain de perf que lorsqu'il y a plusieurs requêtes en parallèle. Mais sinon, il y a même un peu de perte de vitesse à cause du temps perdu à passer par le bus PCIe et le CPU entre chaque carte.
vLLM, lui distribue ça plus intelligemment : chaque couche est répartie entre les cartes graphiques --> toutes les cartes travaillent en parallèle et s'échangent, à chaque sortie de couche, une partie de leur résultat. Ça sollicite plus intensément le bus PCIe et le CPU, mais augmenter le nombre de GPU augmente les performances. Par contre, pour cette raison, vLLM est plus exigeant et préfère des cartes graphiques identiques. C'est pour ça que je n'ai pas pu l'utiliser efficacement sur mon montage.
La conso, ça dépend. Comme llama.cpp ne parallélise pas le calcul, tu n'as qu'une carte vraiment active à la fois. Je n'ai pas pu tester avec vLLM.