Journal Auto-héberger ses IA : Matériel et optimisation de l'inférence

33
5
juil.
2026

Sommaire

Introduction

Camarades, prolétaires numériques, pingouins, unissez-vous ! Contre la rente des IA propriétaires, armons nos GPU ! Approprions-nous les moyens de production de l'intelligence !

Hem, bref, je pose mon mégaphone, et je rentre dans le vif du sujet.

Ce journal est essentiellement un approfondissement de mon mon précédent journal sur le sujet de l'autohébergement d'IA.

En prérequis, il faut avoir une familiarité avec :

Dans mon précédent journal, j'avais suggéré quelques solutions matérielles. Depuis, j'ai obtenu plus d'informations, j'ai beaucoup plus joué avec mes beaux joujous, et, comme un peu tout dans le monde de l'IA actuellement, les choses ont avancé étonnamment vite. Je vais aussi détailler plus les deux solutions matérielles que j'ai testées. Chacune a ses pièges qu'il me semble important de mentionner.

Mais avant tout, je vais vous parler de ce dont je ne vais pas vous parler.

Ce dont je ne vais pas parler

Les IA de génération d'images et autres

Je vais me concentrer sur les LLM.

Globalement, presque aucune des optimisations mentionnées ici ne s'applique aux IA de génération d'images.

De plus, les moteurs d'inférence pour la génération d'images que je connais (ComfyUI et stable-diffusion.cpp essentiellement) ne supportent qu'un seul GPU et le débordement sur le CPU. Ils ne sont pas en mesure d'utiliser plusieurs GPU.

Je mentionnerai tout juste rapidement stable-diffusion.cpp dans la configuration llama-swap pour la Intel Arc Pro B60.

Les moteurs d'inférence

Je ne parlerai que de llama.cpp, llama-server (qui utilise la librairie llama.cpp), et llama-swap (qui peut utiliser llama-server).

Je ne parlerai pas du mode routeur de llama-server, parce que llama-swap est et restera toujours plus flexible.

Je ne parlerai pas de Ollama. Techniquement, ils semblent avoir de plus en plus de retard sur llama-server. Politiquement et commercialement, ils semblent pencher de plus en plus vers une approche cloud, ce qui me rend nauséeux.

Je ne parlerai pas de vLLM, tout simplement parce que vLLM est un enfer à configurer, et que j'estime que ma santé mentale est préférable à quelques tokens/s en plus.

Je ne parlerai pas d'autres moteurs d'inférence, tout simplement parce que je ne les connais pas, et que llama-server et llama-swap me satisfont pleinement.

Comparatifs de performances

Évaluer les performances d'un LLM est remarquablement difficile :

  • La vitesse des LLM dépend de votre matériel, de la taille du contexte, de la variante exacte du modèle (dense, MoE, MTP, QAT, q4_k_m, q4_k_xl, q8_0, et j'en passe).
  • L'intelligence, la précision et le taux d'hallucinations dépendent de la variante exacte du modèle ... et de ce que vous lui demandez exactement.

Les comparatifs "reconnus" qu'on peut trouver sur Internet sont aussi de plus en plus critiqués. Il y a notamment de plus en plus de soupçons que certains créateurs d'IA les optimiseraient pour passer certains comparatifs spécifiquement.

Pour rajouter à ce bruit, on a aussi des gens qui, avec une carte graphique qui date de la guerre, une VRAM ridiculement petite et un débordement CPU+RAM dingue, disent avoir de bonnes vitesses de génération (plus de 15 tokens/s). Et ils vont tout de suite sur LinkedIn s'exclamer qu'ils vont pouvoir remplacer Claude Opus gratuitement. Sauf que je suis prêt à parier qu'ils n'ont testé qu'avec un modèle MoE, des contextes tout petits, presque vides, ou très simples. Je sais déjà qu'ils vont pleurer quand ils vont vouloir vraiment s'en servir en programmation agentique, mais qu'ils ne retireront pas leur publication. (sérieusement, j'en vois des comme ça tous les 2 à 3 jours sur LinkedIn, c'est épuisant ...)

Donc je vais tout de suite écarter l'idée de fournir des résultats de comparatifs. Tel que je vois ça, le mieux, c'est que vous essayiez quelques modèles en situation réelle, et que vous jugiez par vous-même.

Les modèles du moment

Pour l'heure, ma recommandation n'a pas vraiment changé par rapport à mon journal précédent.

Les champions du moment :

  • Qwen-3.6 27b : le pro du code
  • Gemma-4 31b : le pro du reste (recherche sur Internet, assistant, role-play, etc)

Et il y a aussi leurs petits frères MoE (Mixture-of-Experts):

  • Qwen-3.6 35b
  • Gemma-4 26b

Les MoE sont plus rapides, mais potentiellement plus neuneu.

À noter qu'il y a aussi un nouvel arrivant très récent :
Ornith 35b. C'est une reprise de Qwen-3.5 35b qui se veut un peu meilleure en programmation. Personnellement, je n'ai pas encore assez de recul dessus pour me prononcer.

Pour rappel, il y a plein de variantes affinées de ces modèles.

Par exemple, TheDrummer en publie plein orientés plus créativité que intelligence et exactitude. Le groupe ReadyForArt, lui, publie des LLM affinés pour les jeux de rôle et la continuité narrative (et euh ... plus si affinités disons ^^).

Introduction éclair aux réseaux de neurones

Pour comprendre les optimisations, il faut avoir une idée grossière de ce qu'est un réseau de neurones.

Du coup, accrochez-vous bien. Je vais sur-simplifier à mort, mais chez certains d'entre vous, ça risque quand même de réveiller des neurones qui étaient dans le coma depuis la fin de vos études 🧠🔥. (réveiller des neurones pour parler de neurones, ahah, que je suis drôle 🫠)

Un neurone artificiel

Un neurone artificiel simplifié

Un neurone artificiel prend en entrée plusieurs valeurs réelles, et en crache une en sortie.

À l'intérieur, un neurone, c'est essentiellement 2 fonctions mathématiques :

Tout d'abord, une bête fonction du type f(x) = a.x + b, mais avec autant de a et de x que le neurone a d'entrées. Donc, dans mon super diagramme de neurones à 3 entrées, c'est en fait f(x, y, z) = a.x + b.y + c.z + C. Pendant l'inférence, a, b, c, et C, c'est des constantes. Ce sont les fameux "poids" dont tout le monde parle.

On passe ensuite la sortie de cette première fonction à une deuxième fonction, la fonction d'activation. Mais dans le cadre de ce journal, comme je sur-simplifie à mort, on se fiche complètement de cette deuxième fonction (et désolé pour les matheux qui viennent de faire une rupture d'anévrisme en lisant ça 🫣).

Un réseau de neurones artificiel

Je vais sur-simplifier de nouveau à mort. Merci à ceux qui connaissent déjà en détails les réseaux de neurones de ne pas venir m'étouffer dans mon sommeil avec un oreiller à cause de ça !

Un réseau de neurones simplifié

Comme vous l'avez sûrement deviné, un neurone tout seul, ça sert à rien. Sinon votre calculatrice Casio du collège aurait déjà développé une conscience.

On commence à rigoler à partir de quelques millions de neurones. Et à partir de quelques milliards, en les architecturant bien, on arrive à des réseaux nettement plus intelligents qu'un fasciste moyen, voire même plus intelligents qu'un cafard ou un rat !

Mais des millions de neurones, c'est un quelque peu difficile à représenter sur un diagramme. Donc on va se limiter à ce diagramme d'un réseau de 36 neurones.

En entrée du réseau, on a des mots, mais des mots transformés en nombres (c'est la vectorisation, et c'est complètement hors-sujet pour ce journal). En sortie, on a des nombres, qui seront retransformés en mots (aussi hors-sujet).

Maintenant, le point important : Vous remarquerez que les neurones sont organisés en lignes. Chacune de ces lignes correspond à une "couche" de neurones (simplification !).

Les backends

Il y a actuellement 4 fabricants de cartes graphiques dont les GPU sont (plus ou moins bien) supportés par la plupart des projets opensources : Nvidia, Apple, AMD, et Intel.

Par ordre du généralement mieux supporté au moins bien supporté, les backends les plus courants sont :

  • cuda : Nvidia uniquement
  • vulkan : universel, mais généralement plus lent
  • rocm : AMD uniquement
  • sycl : Intel uniquement
  • metal : Apple uniquement

Fait amusant : Vulkan permet d'utiliser des GPU de différents fabricants ensemble (Nvidia, AMD, Intel, etc) ! Mais pour l'heure, c'est tellement lent que c'est pas vraiment utile ... 🙃

Les optimisations

Maintenant qu'on a les bases théoriques, passons au vif du sujet !

Quantification du KV cache

Option llama-server: --cache-type-k et --cache-type-v

Il n'y a pas que le modèle qui peut être quantifié pour gagner en VRAM. Le KV cache peut aussi l'être.

Je n'ai pas de statistiques précises, mais il me semble qu'il peut être quantifié en q8_0 sans dégradation notable. Quand je suis vraiment limité en VRAM, je quantifie le cache V en q4_0.

Le multi-GPU

Les LLM se distribuent assez gentiment sur plusieurs cartes graphiques. Ça permet d'avoir plus de VRAM pour faire rentrer de plus gros modèles, mais ça permet aussi d'accélérer l'inférence.

llama.cpp (et par extension llama-server) supporte plusieurs modes de distribution.

C'est une option spécifique à Nvidia pour interconnecter leurs GPU.

Si vous êtes riches ou que vous avez un datacenter IA, il parait que c'est une option viable. Mais bon, vous êtes sur Linuxfr, donc on va être réalistes et supposer que, comme moi, vous opérez dans votre grotte avec votre seul salaire de péon. Donc je ne vais même pas parler de cette option.

Découpage en couches

Option llama-server: --split-mode layer

découpage horizontal du gateau

Chaque GPU s'occupe d'un ensemble de couches. Pour chaque token à générer, le 1er GPU prend les valeurs en entrée, les fait passer dans ses couches, et envoie la sortie au GPU suivant. Le GPU suivant fait de même, etc.

Non représenté sur le diagramme : le bus PCIe et le CPU de votre machine qui se tournent les pouces.

Les avantages :

  • implémentation simple
  • si votre bus PCIe ou votre CPU est du genre mou du slip, ça ne ralentira pas trop votre LLM.
  • lors de la lecture du prompt, les tokens sont pipelinés. Donc ça, c'est super rapide.

L'inconvénient :

Lors de la génération des tokens, pendant qu'un GPU travaille, les autres attendent. Donc vous avez en sortie autant de tokens/s qu'une seule de vos cartes est capable de produire.

Découpage en lignes

Option llama-server: Anciennement --split-mode row, désormais --split-mode tensor.

découpage vertical du gateau

Chaque GPU s'occupe d'une partie de chaque couche. Et ils s'échangent donc constamment les valeurs, comme des enfants qui s'échangeraient des cartes pokémons en cour de récré, mais en beaucoup plus rapide. Toute ces communications se font par votre bus PCIe.

Non représenté sur le diagramme :

  • le bus PCIe de votre machine qui mange ses morts ;
  • possiblement votre CPU qui s'est fait aplatir comme une crêpe s'il était sur le chemin.

L'avantage :

Si votre bus PCIe et votre CPU survivent, ça donne une bien meilleure utilisation de vos GPU, et donc nettement plus de tokens/s.

Avec --split-mode row, le KV cache n'était pas distribué sur les GPU. Autrement dit, un GPU gérait tout le KV cache, et les autres allaient constamment le consulter. Évidemment, c'était pas glop.

Donc les merveilleux petits lutins qui font llama.cpp nous ont fait un --split-mode tensor. Similaire à row, mais il distribue intelligemment le KV cache. Et ce mode patatore !

Et c'est là qu'on voit que les choses vont très vite du côté des IA auto-hébergées actuellement : Le mode tensor est encore documenté comme expérimental, mais le mode row est déjà marqué comme déprécié 😁. Jusqu'à très récemment, le mode tensor ne supportait pas les KV caches quantifiés. Ils sont encore documentés comme non-supportés. Mais je suis bien placé pour vous affirmer qu'ils sont désormais supportés 😎 ! Une limitation toutefois : le cache k et le cache v doivent être quantifiés de la même façon (pas de mix q8_0 et q4_0 par exemple).

La documentation n'indique pas clairement s'il faut activer l'IOMMU dans le BIOS de votre machine ou non.

À noter que --split-mode tensor peut exploiter la communication P2P (pair-à-pair) sur votre bus PCIe si elle est disponible.

P2P sur le bus PCIe

Malheureusement pour moi, mon matériel ne le supporte pas. Je n'ai donc pas pu le tester. En plus, la documentation est extrêmement sommaire sur ce sujet actuellement. Ceci dit, mes GPU tournent déjà à 100% sans ça, donc perso, je ne pense pas qu'il m'apporterait quelque-chose.

Quoiqu'il en soit, pour ceux qui ont clairement trop d'argent et qui devraient donc envisager de me faire des dons de GPU Nvidia, voici quelques infos en vrac que j'ai noté en essayant de le faire marcher :

Il faut lancer llama-server avec la variable d'environnement GGML_CUDA_P2P=1.

Peut-être qu'il faut activer l'IOMMU dans le BIOS, peut-être pas.

Concernant les options du noyau (/etc/default/grub sur Debian), peut-être qu'il booter avec amd_iommu=on iommu=pt (IOMMU en mode "passthrough" --> moins de sécurité, mais plus de performance), ou pas.

Peut-être qu'il faut appliquer un patch, peut-être pas.

Vous pouvez vérifier l'interconnexion de vos GPU avec nvidia-smi topo -m.

ReBAR

Pensez à activer l'option Resizable BAR dans votre BIOS. Ça permet à votre RAM et votre VRAM d'échanger de plus gros blocs de données (256 Mo sans ReBAR, potentiellement jusqu'à la taille de votre VRAM avec ReBAR).

C'est particulièrement important pour les cartes Intel (et peut-être AMD). Si vous ne l'activez pas, le pilote Intel va vous sermonner activement dans le dmesg, et les performances seront clairement dégradées.

ASPM

Active State Power Management. C'est surtout pour les cartes Intel (et peut-être AMD). Quand votre GPU ne fait rien mais que votre VRAM est chargée, cette option vous ramène d'un GPU qui mange 30W et chauffe à un GPU qui mange quelques watts et ne chauffe pas.

Il faut activer l'option dans votre BIOS. Je vous invite aussi à rajouter pcie_aspm.policy=powersave à vos options noyau (/etc/default/grub + sudo update-grub sur Debian).

Flash Attention

À l'heure actuelle, la question ne se pose plus : Quelle que soit votre configuration et votre modèle, il faut activer flash attention. D'ailleurs, c'est même un prérequis pour --split-mode tensor.

Les variantes de quantification XL

Dans mon précédent journal, je vous parlais des quantifications. En bonne feignasse, je n'avais pas fait l'effort de détailler les variantes de quantifications. Je m'étais contenté de mentionner que pour l'utilisation d'outils (programmation agentique, domotique, etc), les modèles quantifiés en q4 (généralement q4_0 et q4_k_m) sont souvent trop imprécis.

Mais depuis, il y a eu une évolution : Le projet Unsloth propose de plus en plus de modèles quantifiés en q4_k_xl. Et ça, ça change un peu la donne.

Du coup, il va quand même falloir que j'explique cette histoire de variantes.

Pour la suite, je donne toujours de la quantification q4 en exemple, mais bien entendu, les mêmes principes s'appliquent à q5, q6, q7, q8, etc.

Il y a des temps immémoriaux, il n'y avait que q4_0. q4_0 est une quantification très simple : Après l'entrainement d'un modèle, les poids sont généralement des float 32 bits, soit ~4 milliards de valeur possibles. En q4, on veut les faire rentrer sur 4 bits, soit 16 valeurs possibles (et le pire, c'est que ça marche !).

Pour faire ça, on passe sur chaque ligne de poids, et on repère le poids min, le poids max. On calcule ensuite le facteur de réduction par lequel on doit multiplier chaque poids de la ligne pour les ramener entre [-8,8[. Puis on multiplie tous les poids de la ligne par ce facteur pour les réduire, et on les tronque à leur valeur entière. Et à coté de chaque ligne, on note le facteur de réduction qu'on a utilisé.

Les matheux auront vite repéré que ça suppose que les poids sont centrés autour de 0. q4_1 optimise donc ça en calculant et stockant aussi un offset pour chaque ligne.

En 2023, le projet llama.cpp a proposé une nouvelle quantification, plus subtile : les k-quants.

Grosso-modo, au lieu d'appliquer un facteur de réduction pour chaque ligne, on groupe les poids (par exemple par 32), et on applique un facteur et un offset pour chaque groupe.

En plus de ce groupage, il a été observé que certains poids sont plus sensibles à la quantification que d'autres. En conséquence, avec les k-quants, il est possible d'avoir une quantification plus élevée que la quantification de base pour certaines couches plus sensibles (par exemple du q6 pour certaines couches dans un q4_k_m). Les suffixes _s, _m, ou _l correspondent chacun à un jeu de poids "sur-quantifié". Sans surprise, _s est le plus petit jeu de poids. _l était à l'époque le plus grand.

Au début de l'an 2026, un nouveau suffixe est apparu : _xl.

Bien entendu, ce n'est pas parfait. Il y a toujours une perte de précision et je pense que les q8 restent largement préférables quand c'est possible. Mais mon expérience personnelle est les q4_k_xl sont sensiblement plus fiables que les q4_k_m pour les appels aux outils (et donc probablement pour d'autres choses). Ça en fait donc un compromis très intéressant quand on est limité en VRAM (et qui ne l'est pas ?).

Les modèles QAT

QAT signifie Quantization-Aware Training. Les modèles QAT sont des modèles où la problématique de la quantification a été prise en compte pendant leur entrainement. Par exemple, des problèmes de précision dû à la quantification ont pu être simulés pendant leur entrainement. Ces modèles sont donc nettement plus tolérants à la quantification.

Pour info, les modèles Gemma-4 sont disponibles en variantes QAT.

MTP (Multi-Token Prediction)

Option llama-server: --spec-type draft-mtp

Plutôt que prédire un token à la fois, les modèles MTP prédisent plusieurs tokens à chaque fois. Le gain de performance peut aller de rien du tout jusqu'au nombre de tokens simultanément générés, en fonction de votre matériel.

Il y a des variantes de Qwen-3.6 qui intègrent directement le modèle MTP. Pour Gemma-4, par contre, le modèle MTP est distribué dans un fichier à part du modèle lui-même (option llama-server: --spec-draft-model <X>).

Les tailles des lots

Options llama-server:

  • -b <X> / --batch-size <X>
  • -ub <X> / --ubatch-size <X>

Lors du "pré-remplissage" (prefill) (la lecture du prompt), les tokens sont envoyés groupés par lots (batches) aux GPU. Faites des lots trop petits, et votre carte graphique perdra beaucoup de temps à faire des aller-retour entre RAM et GPU, en passant par votre CPU et votre VRAM. Faites des lots trop grands, et votre VRAM fera paf.

En fonction de votre matériel, les réglages par défaut peuvent déjà être à peu près optimaux, ou alors, ça peut valoir le coup de jouer sur ces valeurs.

À noter que llama-server distingue lots logiques (--batch-size) et lots physiques (--ubatch-size). Un lot physique ne peut correspondre qu'à une seule conversation. Un lot logique peut regrouper plusieurs lots physiques. La notion de lot logique ne change donc rien si vous n'avez pas plusieurs conversations en parallèle. Et donc, pour optimiser votre installation, vous pouvez vous concentrer avant tout sur le le réglage des lots physiques --ubatch-size.

Intel : le cache persistent Sycl

Ça plante. ̄\_(ツ)_/ ̄

Quand ça marchera, je suppose que ça sera sûrement une optimisation très utile pour accélérer les chargements des modèles (qui auraient sérieusement besoin d'être accélérés). Mais tous mes essais avec llama-server ont donné le même résultat : un plantage.

Pour le jour où ça marche, il y a 2 variables d'environnement à définir :

  • SYCL_CACHE_PERSISTENT=1
  • SYCL_CACHE_DIR=/un/chemin/persistant

Le mmproj

Le fichier .mmproj permet aux modèles qui en ont un de "voir". Vous pouvez fournir une image à ses modèles, et ils peuvent l'examiner.

Si vous souhaitez faire de la programmation agentique, la vision n'est généralement pas utile. Vous pouvez donc juste ne pas fournir le mmproj à llama-server et économiser de la VRAM.

Comparer avant et après

Éviter le débordement sur le CPU+RAM

Dans mon précédent journal, je disais qu'on pouvait voir le débordement dans les logs. Évidemment, peu après la parution de mon journal, ils ont changé les logs 🙄.

Comme le débordement, c'est de toute façon le mal, le plus simple est de l'interdire: --n-gpu-layers 9999 et --fit off. Si vous dépassez votre VRAM, llama-server se prendra une erreur, qui se traduira par un plantage dégueulasse mais redoutablement efficace.

nvtop

nvtop est un super outil pour visualiser rapidement :

  • l'utilisation de votre VRAM ;
  • l'utilisation de votre GPU ;
  • la température de votre GPU ;
  • la consommation électrique de votre carte graphique.

Malgré son nom (historique), il est compatible avec les cartes Nvidia, Intel et AMD.

llama-swap

L'interface web de llama-swap inclut un bac à sable (playground). Vous pouvez y faire un test rapide. Ensuite vous pouvez voir dans les logs de llama-server la vitesse de votre LLM (je sens que je vais regretter cette dernière phrase d'ici mon prochain journal ... 😅).

Un test rapide classique : "écris-moi un poème".

Ce n'est bien entendu pas un benchmark complet, mais ça donne tout de suite un ordre d'idée.

llama-bench

Si vous voulez évaluer les performances agressivement, ou essayer rapidement différents réglages, les développeurs de llama.cpp ont pensé à vous !

Il faut couper votre instance de llama-swap pour pouvoir lancer llama-bench.

Exemple d'utilisation, pour chercher le meilleur --ubatch-size sur une carte Intel :

docker run --rm \
 --device /dev/dri --group-add 44 --group-add 993 \
 -v "/data/llama.cpp/models:/models:ro" \
 --entrypoint /app/llama-bench
 ghcr.io/ggml-org/llama.cpp:full-intel \
 -m /models/ornith/ornith-35b-UD-Q4_K_XL.gguf \
 -t 1 -r 3 \
 --n-prompt 32000 --n-gen 1024 \
 --cache-type-k q8_0 --cache-type-v q4_0 \
 --n-gpu-layers 999 \
 --flash-attn on \
 --ubatch-size 256,512,1024,1500,2048

Le matériel

Comme expliqué dans mon précédent journal, le nerf de la guerre, c'est l'argent ... enfin la VRAM ... enfin bon là, en ce moment, vu les prix, c'est clairement les deux.

La solution Apple

Ayant une sainte horreur du propriétaire, je n'ai pas fait l'acquisition d'un Mac pour l'IA. Mais pour être rigoureux, j'ai quand même évalué cette approche. Et j'ai oublié de préciser quelque chose d'important dans mon précédent journal : les macs mini ne sont pas bien dimensionnés pour un usage intensif en IA. Les Mac mini ont deux inconvénients majeurs pour l'IA :

Les Mac mini actuels sont vendus avec au mieux des puces M4 pro. Leur bande passante mémoire est seulement de 273 Go/s. Même mes vieilles Nvidia RTX 3060 font nettement mieux (360 Go/s). Autant dire que ça vous promet des LLM anémiques.

Un vendeur LDLC m'a aussi expliqué que les mac mini ne sont pas suffisamment ventilés pour les IA. Utilisés intensément, ils surchauffent. Il m'a mentionné avoir eu beaucoup de retours de Mac Mini à cause de ça.

Je suspecte que les MacBook air ont exactement les mêmes problèmes.

Donc, si vous voulez faire tourner sérieusement de l'IA sur des macs, il vous faudra obligatoirement un Mac Studio (ou peut-être un MacBook pro ?), de préférence avec un processeur M max.

La solution du pauvre : Intel Arc Pro B60

Le bon

En cartes graphiques neuves, le meilleur ratio VRAM / prix est actuellement détenu par la Intel Arc Pro B60. Elle a 24 Go de VRAM et ne coûte que 750€ (enfin "que", oui, bon, hein, v'là quoi).

Du coup, j'ai craqué et je m'en suis acheté deux. Eh, on fait tous des erreurs ̄\_(ツ)_/ ̄.

La B60 a de solides avantages :

  • Elle se prête bien à l'IA de génération d'images avec ComfyUI et stable-diffusion.cpp. Elle est largement suffisante pour permettre à fétichistes des pieds de se faire une bonne overdose ^^.
  • Elle a assez de VRAM pour faire de la programmation agentique à un niveau "acceptable"
  • Elle fait tourner les jeux vidéos au moins aussi bien qu'une Nvidia RTX 3060.
  • Côté pilote Linux, sous Debian, vous chopez la version trixie-backports du noyau, et c'est tout bon. Wayland qui fonctionne au poil, pas de bugs chelous venus de l'espace, pas de jeu Steam qui ne démarrent que 2 fois sur 3. Juste un GPU qui fonctionne.
  • Côté Docker, pareil : pas de nvidia-docker-container-runtime-toolkit-machin-truc à installer. Juste deux /dev à rediriger, et finito.

Pour la programmation agentique, vous pouvez faire rentrer dessus le modèle Ornith 35b q4_k_xl avec un contexte de 256K tokens. Ornith est une variante de Qwen3.6 35b. Sans être du Claude Fable 5, ils se défendent plutôt bien. Ça balancera du 30 à 40 tokens/s en sortie, ce qui est confortable. Vous pouvez aussi décider de n'avoir que des contextes de 128K, mais d'en autoriser deux (--parallel 2), ouvrant ainsi la possibilité d'utiliser des sous-agents.

Si vous voulez faire de la prose plus humaine, un Gemma-4 26b q4_k_xl donnera des résultats pas trop mal. Ça ne vaudra pas un Gemma-4 31b, mais, avec cette carte, mais le 26b vous autorisera un contexte nettement plus long (192K au lieu de juste 32K) et un meilleur débit. Typiquement, sur cette carte, vous pouvez espérer 20 à 30 tokens/s.

Attention tout de même : les chiffres que je vous donne là sont pour un serveur sans affichage. Si vous avez une interface graphique qui tourne, vous aurez moins de VRAM disponible. Donc il faudra réduire les contextes.

Le mauvais

Mais. (vous pensiez pas que ça serait si facile quand même ?)

Elle a certains défauts qui ne peuvent pas être ignorés :

  • Le backend Intel (Sycl) est généralement un des moins bien supportés par les projets. Parfois, ça plante, et la seule solution est d'utiliser un backend Vulkan à la place (environ 50% plus lent).
  • Faute de cache persistent Sycl, le temps de chargement d'un modèle est horriblement long (de l'ordre de 1 à 2 minutes)
  • Le support multi-GPU (Sycl ou Vulkan) FHPR QRF OVGRF Q'BHEF RA RASRE 🤬 ! Soit ça plante tout le temps, soit c'est incroyablement lent. Et, oui, j'ai passé beaucoup trop d'heures à essayer de le faire marcher. Bref, la peinture n'est pas encore sèche.

Cas d'utilisation

C'est définitivement une bonne carte graphique si vous ne voulez pas mettre trop d'argent sur la table pour auto-héberger vos IA. Mais pour l'heure, vous devez être absolument sûr de ne pas vouloir utiliser plus qu'une carte graphique Intel.

Typiquement, ça peut être une solution peu coûteuse pour compléter un abonnement cloud : Qwen3.6 q4_k_xl sur la Intel pour les opérations qui ne demandent pas trop d'intelligence, et Claude ou whatever pour les opérations que vous devriez probablement faire vous-même 🙄.

Dans mon cas, la première a fini dans mon serveur perso. Je l'utilise avec Gemma4-26b q4_k_xl pour les tâches qui ne demandent pas trop d'intelligence (Home Assistant, des petites questions rapides, etc). La deuxième est devenue ma carte graphique de jeu ... beaucoup trop chère pour les perfs plutôt moyennes qu'elle a ̄\_(ツ)_/ ̄ (mais je bidouille aussi un peu dessus avec ComfyUI et autres).

La grande sœur

Il existe aussi la Intel Arc Pro B70. Elle a 32Go de VRAM et plus de patate. Par contre, en Europe, elle est à ~1200€ actuellement.

Optimisations spécifiques

Il va de soit que les meilleures performances seront obtenues avec le backend Sycl.

En dehors du moteur et des optimisations pour la VRAM, il y a une optimisation utile : --ubatch-size 1024. D'après mes tests, ça augmente sensiblement la vitesse de relecture du prompt (pré-remplissage).

Exemple de configuration llama-swap

Ci-dessous, un exemple de configuration llama-swap.

Avec cette configuration, llama-swap doit être installé directement sur le système hôte, mais il démarre ensuite les IA dans Docker. L'avantage de cette approche est que vous pouvez facilement vous replier sur un backend Vulkan si besoin, et plus facilement jongler avec les images Docker jusqu'à en trouver une qui ne plante pas 🛠️😵‍💫.

(attention aux permissions dans /dev/dri : les --group-add sont à ajuster)

hooks:
 on_startup:
 preload:
 - "Ornith-35b-q4"
models:
 img-gen:
 checkEndpoint: /
 cmdStop: docker stop AI
 cmd: >
 docker run --rm
 --name AI
 --device /dev/dri --group-add 44 --group-add 993
 -v /data/llama.cpp/models:/models
 -v /data/comfyui:/comfyui
 -p ${PORT}:8080
 --entrypoint /sd-server
 ghcr.io/leejet/stable-diffusion.cpp:master-sycl
 --listen-port 8080 --listen-ip 0.0.0.0
 --diffusion-model /comfyui/models/diffusion_models/ideogram4-Q8_0.gguf
 --llm /comfyui/models/text_encoders/Qwen3VL-8B-Instruct-Q8_0.gguf
 --vae /comfyui/models/vae/flux2-vae.safetensors
 --type q8_0
 --clip-skip 2
 --diffusion-fa
 --vae-tiling
 --clip-on-cpu
 Gemma4-26b-q4:
 cmdStop: docker stop AI
 cmd: >
 docker run --rm
 --name AI
 --device /dev/dri --group-add 44 --group-add 993
 -v /data/llama.cpp/models:/models
 -p ${PORT}:8080
 --entrypoint /app/llama-server
 ghcr.io/mostlygeek/llama-swap:intel
 --port 8080 --jinja
 --ctx-size 196608 --flash-attn on
 --parallel 1
 --fit off
 --n-gpu-layers 9999
 --cache-type-k q8_0
 --cache-type-v q4_0
 --no-mmap
 --model /models/gemma4/gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf
 --mmproj /models/gemma4/mmproj-BF16-qat-mtp.gguf
 --spec-draft-model /models/gemma4/mtp-gemma-4-26B-A4B-it.gguf
 --spec-type draft-mtp
 -ub 1024
 Ornith-35b-q4:
 cmdStop: docker stop AI
 cmd: >
 docker run --rm
 --name AI
 --device /dev/dri --group-add 44 --group-add 993
 -v /data/llama.cpp/models:/models
 -p ${PORT}:8080
 --entrypoint /app/llama-server
 ghcr.io/mostlygeek/llama-swap:intel
 --port 8080 --jinja
 --ctx-size 262144 --flash-attn on
 --parallel 1
 --fit off
 --n-gpu-layers 9999
 --cache-type-k q8_0
 --cache-type-v q4_0
 --no-mmap
 --model /models/ornith/ornith-35b-UD-Q4_K_XL.gguf
 -ub 1024

Et le service Systemd qui va avec :

[Unit]
Description=Llama-Swap Service
After=network.target docker.service
[Service]
Type=simple
ExecStart=/chemin/vers/llama-swap --listen :8123 --config /chemin/vers/config.yaml
Restart=always
RestartSec=5
WorkingDirectory=/chemin/vers/ce/que/vous/voulez/on/sen/fiche/en/fait
[Install]
WantedBy=default.target

Claquez un Open-WebUI et/ou un Home Assistant et/ou un opencode devant ça, et vous aurez une solution IA auto-hébergée plutôt sympa.

La solution de Dédé la bricole

Maintenant qu'on a parlé de la tapette à mouche neuve, parlons de l'arme nucléaire façon 2018.

Le matériel

La configuration
  • Alimentation : minimum 1200W (1500W dans mon cas)
  • Carte mère : Taichi X399
  • Processeur : AMD Threadripper 1950x
  • Cartes graphiques : 4x Nvidia RTX 3060 12Go
  • RAM : minimum autant la VRAM, soit 48Go (96Go dans mon cas)

La gamme des processeurs Threadripper est très intéressante pour ce montage. Ce sont des processeurs avec beaucoup de lignes PCIe. Or comme on l'a vu, pour le split-mode tensor, les lignes PCIe sont importantes.

La Taichi X399 n'a que du PCIe gen 3. Mais j'ai pu voir que ce n'est clairement pas un problème. Mes 4 GPU tournent à 100%, donc le bus PCIe gen 3 n'est pas un goulot d'étranglement.

Dans mon cas, comme mon alimentation me le permet, plus tard, le plan est de rajouter des bifurcations PCIe et mettre 2 RTX 3060 12 Go en plus.

Je ne donne plus les prix du montage, parce que depuis mon dernier journal, ils ont déjà bougés. Et au rythme où ça va, ils auront encore bougé avant que vous ne lisiez ce journal ci ...

Le châssis

Dans mon précédent journal, j'ai fait une erreur : un boitier Cooler Master MasterFrame 600 ne peut pas bien accommoder quatre Nvidia RTX 3060. Pourquoi ? Parce qu'elles vont chauffer. C'est frustrant quand son LLM ralentit parce que la machine est en feu ... 🖥🔥🚒. Plus sérieusement, d'expérience, une des cartes monte rapidement à 90°C et se thermo-régule en ralentissant. C'est sans risque. Mais à moins de vouloir ouvrir une pizzeria et d'avoir besoin d'un très mauvais four, ce n'est juste pas pratique.

chassis fermé VS chassis ouvert

Le plus simple est finalement un châssis ouvert et des risers PCIe. Eh oui ! Les mêmes châssis utilisés par les mineurs de cryptomonnaie. Maintenant qu'ils sont passés aux ASIC, autant recycler leurs déchets pour l'IA \o/

Important : leurs châssis sont prévus pour des CPU ridiculement anémiques, avec des ventilateurs rikiki. Mais nous, on est des Hommes, des vrais, avec des poils sous les bras 💪 ! Donc quand on fait de l'IA, on se doit d'avoir du Xeon ou du Threadripper avec d'énormes ventilateurs. Et sur un châssis ouverts 6 GPU, souvent, ça ne passe pas (j'ai testé ...). Donc même si vous n'avez prévu de ne mettre que 4 cartes, je vous recommande de prendre tout de suite un châssis 12 GPU. C'est moche, mais ça fonctionne ̄\_(ツ)_/ ̄.

Laissez-moi vous montrer le problème avec l'aide de mon copain Ducky le canard 🦆 :

ventilateur trop grand

ventilateur mal placé

Bien entendu, ils auraient juste pu prévoir les trous pour pouvoir tourner la carte mère. Mais vu que nous n'étions pas le public visé à l'époque, ils s'en sont tamponné le coquillard.

Les risers PCIe

Riser PCIe

Là, par contre, il ne faut surtout pas recycler les risers des mineurs. Ce sont des risers PCIe gen1 1x, faits en carton-pâte, avec des câbles USB 3 douteux, et des câbles alimentations qui sentent bon l'incendie potentiel. Pour de l'IA, il vous faut impérativement des risers PCIe gen3/gen4 16x, correctement blindés, et pas trop longs (20cm max !).

Les bifurcations PCIe

Attention : Je n'ai pas encore essayé les bifurcations ! J'ai commandé les miennes, mais je ne les ai pas encore reçues. Je mets ici juste une information importante que je n'ai vu nulle part ailleurs.

Si vous décidez d'utiliser des bifurcations, il faut aussi faire attention. Une carte graphique branchée sur un port PCIe 16x peut légitimement tirer 75W de ce port. Votre bifurcation doit pouvoir fournir ces 75W sans faire un barbecue. Les bifurcations ont donc besoin d'un apport de courant supplémentaire. Or certaines le prennent via un connecteur d'alimentation SATA, et sont donc automatiquement suspectes : un connecteur d'alimentation SATA ne peut fournir que 54 Watts de plus. Ironiquement, les bons vieux connecteurs Molex s'y prêtent mieux, avec un maximum de 132 Watts.

Les bifurcations

Le bon

Avec 48Go de VRAM, on commence à rigoler. La VRAM accommode un qwen3.6 27b q8 sans problème. Et avec le split-mode tensor, ça patatore 🎉.

À titre purement indicatif et mesuré au doigt mouillé :

  • Ornith 35b q8 (MoE) :
    • contexte de 512K, coupé en deux (pour avoir agent et sous-agent) ;
    • lecture à ~1700 tokens/s ;
    • génération à ~100 tokens/s.
  • Qwen-3.6 27b q8 (modèle dense) :
    • contexte de 192K ;
    • lecture à ~700 tokens/s ;
    • génération à ~40 tokens/s (modèle dense).
  • Gemma-4 31b q4_k_xl (modèle dense ; le q8 me fait des misères):
    • contexte de 128K ;
    • lecture à ~630 tokens/s ;
    • génération à ~45 tokens/s.

C'est un montage à base de cartes Nvidia. Donc, en dehors de l'abomination qu'est le pilote Nvidia, le support logiciel est impeccable.

Le mauvais

Les IA génératrices d'images ne peuvent pas être distribuées sur plusieurs cartes graphiques. Or chaque carte Nvidia n'ayant que 12Go de VRAM. Ce montage est donc un peu limite pour la génération d'images. Je préfère utiliser une de mes cartes Intel pour ça.

La machine chauffe (« qui aurait pu prédire ? » 🙃).

Le risque évident avec le châssis ouvert, c'est la poussière. C'est d'autant plus évident si vous avez des animaux de compagnie. Pour ma part, j'ai la chance d'avoir une pièce débarra / chambre d'ami dans laquelle je peux enfermer cette machine. Mais ce n'est probablement pas le cas de tout le monde.

La Taichi X399 est le top-of-the-line de 2018 ... donc tout tourne en PCIe gen 3, deux de ses slots physiques PCIe 16x sont en fait câblés uniquement en PCIe 8x, et il ne faut pas compter sur une connexion P2P. Avec des Nvidia RTX 3060, ce n'est pas grave : le goulot d'étranglement reste les cartes graphiques. Le jour où je change de cartes, ça pourrait changer. Ceci dit, au prix des cartes actuelles, comme je tiens à mes reins, ce n'est pas prêt d'arriver.

Optimisation

Sur ce montage, le point clé est bien entendu le --split-mode tensor. Tant que ce mode ne marchait pas, je me demandais si j'avais bien fait d'engouffrer autant d'argent dans ce projet. Maintenant qu'il marche, je me le demande toujours, mais au moins j'ai des LLM qui patatorent 😎 !

Exemple de configuration llama-swap

Comme mentionné dans mon précédent journal, il faut installer d'abord :

Comme je n'ai pas eu de soucis notable avec le support de Cuda, sur cette machine là, j'ai llama-swap directement dans un conteneur Docker. L'image inclut llama-server.

Le docker-compose.yaml :

services:
 llama.cpp:
 image: ghcr.io/mostlygeek/llama-swap:unified-cuda
 restart: "always"
 runtime: nvidia
 privileged: true
 ipc: host
 shm_size: "16gb"
 ports:
 - "8123:8080"
 volumes:
 - /data/llama.cpp/models:/models
 - ./config.yaml:/etc/llama-swap/config/config.yaml:ro
 deploy:
 resources:
 reservations:
 devices:
 - capabilities: [gpu]

Le config.yaml de llama-swap :

models:
 gemma4-31b-q4:
 cmd: >
 llama-server --port ${PORT} --jinja
 --ctx-size 131072 --flash-attn on
 --no-warmup
 --parallel 1
 --cache-type-k q8_0
 --cache-type-v q8_0
 --model /models/gemma-4-31b-q4/gemma-4-31B-it-UD-Q4_K_XL.gguf
 --mmproj /models/gemma-4-31b-q4/mmproj-BF16.gguf
 --spec-draft-model /models/gemma-4-31b-q8/mtp-gemma-4-31B-it.gguf
 --spec-type draft-mtp
 --split-mode tensor
 --fit off
 -ngl 9999
 qwen3.6-27B-q4:
 cmd: >
 llama-server --port ${PORT} --jinja
 --ctx-size 262144 --flash-attn on
 --parallel 2
 --cache-type-k q8_0
 --cache-type-v q8_0
 --model /models/qwen3.6-27b-q4/Qwen3.6-27B-UD-Q4_K_XL.gguf
 --spec-type draft-mtp
 --split-mode tensor
 --fit off
 -ngl 9999
 qwen3.6-27B-q8:
 cmd: >
 llama-server --port ${PORT} --jinja
 --ctx-size 196608 --flash-attn on
 --no-warmup
 --parallel 1
 --cache-type-k q8_0
 --cache-type-v q8_0
 --model /models/qwen3.6-27b-q8/Qwen3.6-27B-UD-Q8_K_XL.gguf
 --spec-type draft-mtp
 --split-mode tensor
 --fit off
 -ngl 9999
 ornith-1.0-35b-q8:
 cmd: >
 llama-server --port ${PORT} --jinja
 --ctx-size 524288 --flash-attn on
 --parallel 2
 --cache-type-k q8_0
 --cache-type-v q8_0
 --model /models/ornith/ornith-1.0-35b-Q8_0.gguf
 --split-mode tensor
 --fit off
 -ngl 9999

Conclusion

L'auto-hébergement d'IA n'est pas un long fleuve tranquille. Il faut faire la chasse à la VRAM, se battre avec les pilotes capricieux et propriétaires, lutter contre les backends mal-supportés, résister aux sirènes de ces capitalistes de vendeurs de GPU, et j'en passe. Autrement dit, le chemin de la Révolution est semé d'embûches. Mais tel est le prix de notre liberté, camarade pingouin !

PS: Quand je parle à un LLM d'un article ou un journal dans le style LinuxFr, il sait de quoi je parle ! On est célèbres les gars \o/

  • # vulkan me semblait plus rapide que rocm

    Posté par (site web personnel) . Évalué à 6 (+4/-0).

    vulkan : universel, mais généralement plus lent
    rocm : AMD uniquement

    C'est marrant, mon expérience est plutôt dans l'autre sens, en tout cas pour AMD, que Vukkan est plus rapide que rocm, mais c'etait il y a 6 mois, ça a peut-être changé entre temps, et je n'ai plus mon pc de compétition pour tester.

    • [^] # Re: vulkan me semblait plus rapide que rocm

      Posté par (site web personnel) . É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: vulkan me semblait plus rapide que rocm

        Posté par . Évalué à 4 (+2/-0).

        Je confirme que sur mon AMD Ryzen AI 9 HX 370, le mode vulkan est légèrement plus rapide que ROCm/HIP et sans doute un peu moins efficace d'un point de vue énergétique.

        • [^] # Re: vulkan me semblait plus rapide que rocm

          Posté par (site web personnel) . É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: vulkan me semblait plus rapide que rocm

            Posté par . Évalué à 3 (+1/-0).

            Moi j'avoue que ça m'a étonné.
            Cuda et HIP, voir même OpenCL sont des langages et librairies spécifiques pour permettre du calculs distribué sur carte graphique, là où Vulkan est une librairie graphique. Bas niveau certes, mais a priori c'est tout de même plus difficile de faire du calcul distribué avec Vulkan que via un langage de programmation fait pour ça...

            Après, cela fait bien longtemps que je ne code plus sur carte graphique (Vulkan n'existait pas encore) et je ne connais plus les capacités actuelles...

            En tout cas, je te rejoins sur le fait que Vulkan pourrait les unifier tous... bon Cuda est tout de même omniprésent dans le monde de l'IA...

  • # Temps de "thinking" après envoie du prompt

    Posté par (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 06 juillet 2026 à 00:11.

    Merci beaucoup pour ce journal très utile.

    Je n'utilise des IA locale qu'avec un CPU, pas encore les moyens d'investir pour le moment, j'espère bien que des solutions vont émerger (ou que les Intel Arc vont finir par fonctionner...), donc ce que je constate, c'est que le modèle met un temps fou à réfléchir après avoir reçu mon prompt.

    D'où ma question :
    Tu donnes des chiffres de token/s en lecture et en output, mais est-ce que tu intègres ce temps de calcul où le modèle évalue le prompt ?

    Si non, est-ce qu'on peut calculer un taux de token/s en fonction du nombre de token en entrée, et avoir une fourchette de token/s généré qui prennent en compte ce temps de calcul ?

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Temps de "thinking" après envoie du prompt

      Posté par (site web personnel) . É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.

  • # Alimentation

    Posté par (Mastodon) . Évalué à 5 (+2/-0).

    Encore merci pour ces journaux détaillés !

    Une question toute bête, comment on fait pour alimenter 4 CG ? Au delà de la simple addition des puissances, niveau câblage ça se gère comment ? Grosse alim 1200W et des "splitters" ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Alimentation

      Posté par (site web personnel) . É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: Alimentation

        Posté par (site web personnel) . É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.

  • # PUE ?

    Posté par (site web personnel) . Évalué à 2 (+1/-0).

    Quel est le PUE de ton installation ?

    Car c'est bien beau de tout vouloir faire en local, mais un datacenter est quand même optimiser pour réduire au maximum celui-ci. Si tout le monde se met à faire pareil, ça va être catastrophique.

    • [^] # Re: PUE ?

      Posté par (site web personnel) . É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: PUE ?

      Posté par (Mastodon) . Évalué à 4 (+1/-0).

      En dehors du PUE, la gestion de la température est un sujet important en été. La température de mon appartement oscille entre 27C et 32C de juin à fin septembre.

      Dès 11h j'allume la clim dans la pièce où je travaille et 1h environ dans ma chambre à coucher avant de dormir. Je limite au maximum les appareils allumés 24x7 (rien que le routeur wifi chauffe pas mal la pièce où il est situé) et je ne me verrais pas faire tourner une machine avec 3-4CPU avec des agents travaillant toute la journée ou toute la nuit dans ces conditions.

      • [^] # Re: PUE ?

        Posté par . Évalué à 3 (+1/-0).

        Je me suis fait la même réflexion, c'est là où on se rend compte que la matérialité de toutes ces installations "clouds". Quand on veut les rapatrier chez nous, on se rend compte à quel point ça consomme et à quel point ça chauffe !

        Je trouve justement l'exercice intéressant, car comme toute démarche d' "autonomie", elle permet de conscientiser les usages et souvent de s'auto limiter.

        Quand j'utilise claude code, c'est comme quand je branche un appareil électrique sur une prise de ma maison, je ne me rends pas compte de toutes les externalités négatives (centrales électriques, data center etc.).

  • # Macbook PRO et chauffe

    Posté par (Mastodon) . Évalué à 4 (+1/-0).

    Je suspecte que les MacBook air ont exactement les mêmes problèmes.

    Donc, si vous voulez faire tourner sérieusement de l'IA sur des macs, il vous faudra obligatoirement un Mac Studio (ou peut-être un MacBook pro ?), de préférence avec un processeur M max.

    J'ai lu dans des commentaires sur hacker news qu'un macbook pro va bien pour des LLMs...mais pas en utilisation laptop. Sur les genous ça chauffe suffisemment pour atteindre le stade de la douleur et des brûlures de la peau. J'imagine que ça n'augure rien de bon sur la fiabilité sur le long terme d'un macbook pro qui serait sollicité via des agents 24/7h ou en tout cas de longues heures par jour.

    • [^] # Re: Macbook PRO et chauffe

      Posté par (site web personnel) . Évalué à 6 (+3/-0).

      J'ai envie de dire que la plupart des ordinateurs portables ne sont pas dimensionnés pour un usage intensif de longue durée.

      Si on veut une machine puissante capable d'encaisser une charge intensive H24, faut prendre du matériel conçu pour.

      • [^] # Re: Macbook PRO et chauffe

        Posté par (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 06 juillet 2026 à 10:36.

        J'ai envie de dire que la plupart des ordinateurs portables ne sont pas dimensionnés pour un usage intensif de longue durée.

        Pour avoir utilisé un Framework 13" en compilation intensive, je ne peux que confirmer. Ralentissement voire freeze c'était compliqué. Un collègue qui avait la version 16" a eu moins de soucis, on suppose que c'est directement lié à la compacité de la chose.

        Si on veut une machine puissante capable d'encaisser une charge intensive H24, faut prendre du matériel conçu pour.

        C'est ce qu'on a fait (serveur Xeon d'occase).

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Coût

    Posté par (Mastodon) . Évalué à 3 (+1/-1). Dernière modification le 06 juillet 2026 à 11:11.

    Tu ne mentionnes pas le TCO de ton affaire là.

    Par exemple on commence à avoir des boîtes (Über il me semble) qui ont annoncé qu'ils avaient explosé leur budget annuel en IA en moins d'un trimestre. D'autres études qui commencent à sortir et dire que le budget réel de l'IA est supérieur à celui des ingénieurs qu'elles sont supposées "remplacer".

    Du coup à long terme plutôt que de jouer avec llama-cpp pour tes projets hobby, ça ne vaudrait pas le coup d'embaucher un (削除) esclave indien (削除ここまで) ingénieur pour qu'il code ce que tu as besoin? J'ai du mal à croire qu'on puisse arriver à obtenir un coût plus bas en autohébergeant une IA avec son propre matos que via les économies d'échelles réalisées dans un datacenter. J'ai l'impression que ça reste viable maintenant parce que les modèls Qwen ou Gemma sont subventionnés par les chinois qui nous proposent des modèles gratuits dans le but de flinguer le marché US, mais le jour où les chinois ont rattrapé leur retard sur Anthropic et OpenAI et arrêtent de nous distribuer des modèles gratuits, tu vas les créér comment tes modèles? D'autant plus que l'optimization et paramétrisation des modèles demande beaucoup de ressources humaines.

    • [^] # Re: Coût

      Posté par (Mastodon) . Évalué à 4 (+1/-0).

      Du coup à long terme plutôt que de jouer avec llama-cpp pour tes projets hobby, ça ne vaudrait pas le coup d'embaucher un esclave indien ingénieur pour qu'il code ce que tu as besoin?

      J'en doute très fort. Partons d'une machine 1000W en pleine charge. Si elle tourne 27/7, elle va consommer 1*24*365 = 8760kWh. À 20cts le kWh, ça fait 1752€.

      Si c'est juste 4h par jour par exemple on tombe à 300€ environ.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Coût

      Posté par (site web personnel) . É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.

  • # T'as testé une conf hybride CPU/GPU

    Posté par . Évalué à 3 (+1/-0).

    Merci encore pour ce super journal, je ne l'ai pas encore lu dans le détail mais déjà bien survolé.
    Comme pour le dernier, je partage tes galères et errements et je découvre aussi pas mal de choses (notamment le split "tensor") donc très cool, merci !

    L'autre jour, j'ai vu un personne "annoncer" (comme tu le dis bien dans ton intro) qu'elle atteignait 30 t/s sur un laptop à 1500€ (donc j'imagine avec une carte graphique avec peut-être 10/12Go max si acheté à l'époque pré rampocalypse) avec le Qwen 3.5 122B A10B en 4bits, en mode hybride donc en chargeant que les poids actifs sur le GPU, le reste étant en RAM.

    J'ai été très étonné de cette affirmation, croyant que les perfs s'effondrait dans ce cas.

    Si c'est vraiment utilisable de faire de l'hybride CPU/GPU, ça ouvre la voie à l'utilisation de modèles plus gros comme celui mentionné ci-dessus, voir même DeepSeek v4-flash qui serait une sorte de "graal" pour l'usage agentique local : il est pensé pour être quantifié et gère de très long contexte sans que les perfs s'effondrent.

    Car, honnêtement, j'ai abandonné l'usage des "petits" gemma 4 et qwen que tu cites, car pour faire du code et manipuler des fichiers, c'est très très limite. Même avec des instructions claire, ils me faisaient n'importe quoi. Mais bon, j'ai testé les versions MoE, les versions denses étaient trop lentes sur ma config.

    Pour deepseek v4, il y a un projet a part qui a l'air vraiment top : https://github.com/antirez/ds4, llama.cpp étant visiblement trop "générique" pour pouvoir prendre en compte efficacement les optis implémentées dans DeepSeek v4 (notamment sur la compression du contexte).

    Donc si t'as testé ça aussi, je suis carrément preneur !

    • [^] # Re: T'as testé une conf hybride CPU/GPU

      Posté par (site web personnel) . É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.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.

      • [^] # Re: T'as testé une conf hybride CPU/GPU

        Posté par . Évalué à 3 (+1/-0).

        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.

        J'avais pas compris le fonctionnement des MoE comme ça. Pour moi, quand on LLM MoE indique 10B pour les experts c'est que, dans tous les cas, il n'y a que 10B de paramètres qui s'active, peu importe la complexité de la tâche.
        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.

        Sur les benchmark, y a un gars qui fait du bon boulot je trouve : https://github.com/kyuz0
        Il crée des sites spécifiques pour chaque carte ou config qu'il teste avec des résultats qu'il s'efforce d'être le plus normé possible.
        Exemple sur les strix halo : https://strix-halo-toolboxes.com

        • [^] # Re: T'as testé une conf hybride CPU/GPU

          Posté par (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 07 juillet 2026 à 15:50.

          il n'y a que 10B de paramètres qui s'active

          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.

          Sur les benchmark, y a un gars qui fait du bon boulot je trouve : https://github.com/kyuz0

          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.

          • [^] # Re: T'as testé une conf hybride CPU/GPU

            Posté par . Évalué à 3 (+1/-0).

            Super, merci pour les retours et les explications, je n'avais pas en tête que c'était potentiellement des experts différents pour chaque token, c'est vrai que c'est de réseau auto régressif et donc tout se rejoue à chaque fois. J'imagine que dans la pratique c'est peu ou prou les mêmes experts quand on est sur une même tâche, mais que ça peut en effet bouger.

            Bon, donc ces modèles ne sont pas encore pleinement utilisable sur du matériel "normal"... peut-être qu'un jour ça le sera ? Ou peut-être que les prix des composants vont baisser un jour et se spécialiser de plus en plus pour exécuter des modèles de ce genre ?

            Ça me fait bizarre car pendant 15 ans j'ai quelque part lutter contre cette course à la performance, au renouvellement des machines etc. Et j'en viens à souhaiter qu'on fasse de nouvelles machines plus performantes et moins chères... je crois que je suis tombé dans le piège de l'IA...

            • [^] # Re: T'as testé une conf hybride CPU/GPU

              Posté par (site web personnel) . É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 ... :/

  • # auto hebergement et HA

    Posté par . Évalué à 1 (+2/-1).

    Merci pour ces 2 articles. J'ai fait des tentatives d'auto hébergement pour monter en compétence mon HA, mais sans carte graphique à 800,ドル c'est trop lent, pas utilisable au quotidien.
    J'ai utilisé Ollama, mais tu sembles dire que ce n'est plus une solution intéressante.
    Utiliser de l'IA pour HA n'est pas aussi contraignant qu'un gros llm, et l'auto hébergement est intéressant (compatible avec l'utilisation de HA),et abordable, et pourrait intéresser pas mal de monde.
    Est ce que tu peux nous parler de ce que tu as fait pour booster ton HA ?

    • [^] # Re: auto hebergement et HA

      Posté par (site web personnel) . É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.

  • # Autres montages

    Posté par (site web personnel) . É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/ :-)

  • # Je me permets de partager mon approche

    Posté par (site web personnel) . Évalué à 5 (+5/-1). Dernière modification le 08 juillet 2026 à 12:01.

    Merci pour cet article très complet, jflesch. C'est un excellent tour d'horizon des solutions matérielles actuelles pour l'auto-hébergement d'IA, avec des benchmarks concrets qui se font rares.

    Je me permets de partager mon approche, qui diffère sur certains points — non par désaccord mais parce que mes contraintes et objectifs sont différents : une seule RTX 3090 (24 Go) partagée entre plusieurs workloads IA.

    Une carte, plusieurs usages

    Ton article présente deux solutions : la « solution du pauvre » Intel Arc Pro B60 et le montage multi-GPU Nvidia avec ×ばつ RTX 3060. 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.

    La conséquence directe, c'est que le sleep-idle n'est pas un compromis mais une nécessité. Garder le modèle chargé m'empêcherait d'utiliser la carte pour autre chose. Avec ~20 secondes de rechargement, je peux faire tourner d'autres applications IA quand le LLM dort, et inversement :

    C'est le seul moyen réaliste de partager 24 Go entre des workloads aussi gourmands.

    llama-server router vs llama-swap

    J'utilise le mode routeur natif de llama-server plutôt que llama-swap. Avec une seule carte et un nombre limité de modèles, le routeur intégré suffit largement. L'avantage supplémentaire, c'est qu'il gère nativement le sleep/wake — ce qui est au cœur de mon workflow.

    Le bug -fit / sleep-wake

    C'est en cherchant à faire fonctionner cette approche que j'ai découvert un bug upstream : avec --sleep-idle-seconds et --fit on, le serveur plantait en boucle de réveil sur tensor_buft_overrides already set by user, abort. Le -fit recalculait le contexte réduit au premier chargement (262K → 102K pour tenir en VRAM), mais au réveil il tentait de réappliquer les tensor_buft_overrides déjà fixés.

    J'ai ouvert ggml-org/llama.cpp#24684 et proposé un fix qui sauvegarde le fitted_n_ctx au premier chargement pour le réutiliser au wake-up en contournant -fit. J'ai aussi corrigé un bug de clustering pathologique des checkpoints (#25023) et un problème de template Jinja avec TranslateGemma (#20305). Tout est documenté sur mon blog.

    Performance en pratique

    Pour donner un point de comparaison avec tes benchmarks :

    Setup Modèle Quantification Génération
    Ta config ×ばつ RTX 3060 Qwen-3.6 27b (dense) q8 ~40 tok/s
    Ma RTX 3090 seule Qwen-3.6 27b (dense) q4_k_m + MTP ~45-58 tok/s

    Il y a deux facteurs à jouer ici. D'abord, le q8 consomme environ 31 Go de VRAM pour un modèle dense 27B — ce qui explique pourquoi ton montage en multi-GPU est nécessaire. En q4_k_m, le même modèle tient dans ~16 Go, laissant place au KV cache, au MTP et aux buffers compute sur une seule carte. La perte de qualité entre q8 et q4_k_m est minime sur la plupart des tâches, surtout avec un imatrix calibré (ici par Unsloth). Est-ce que les ~31 Go du q8 valent vraiment le coup quand on peut avoir presque la même qualité en 16 Go ? C'est une question de budget VRAM autant que de précision.

    Ma configuration complète pour ce modèle :

    model = Qwen3.6-27B-MTP-Q4_K_M.gguf ; ~16 Go sur GPU
cache-type-k = q8_0 ; KV cache K en q8
cache-type-v = q5_1 ; KV cache V en q5
fit-ctx = 102400 ; contexte ajusté automatiquement
spec-type = draft-mtp ; MTP activé
spec-draft-n-max = 4 ; jusqu'à 4 tokens draft
spec-draft-p-min = 0.85 ; seuil d'acceptation
spec-draft-type-k = q8_0 ; cache MTP K en q8
spec-draft-type-v = q5_1 ; cache MTP V en q5
mmproj = mmproj-BF16.gguf ; vision encoder chargé

    Ensuite, le MTP (Multi-Token Prediction) fait toute la différence : avec un taux d'acceptation moyen de ~93% et une longueur moyenne de draft de 3 à 4 tokens, la vitesse de génération effective est multipliée par deux ou trois. Sans MTP, je serais probablement autour de 15-20 tok/s sur ce modèle dense.

    Le prompt processing tourne à ~950-970 tok/s avec Flash Attention activé. La carte consomme 235W (limité volontairement à 250W contre 350W nominal) et reste à 60°C en pleine charge — ce qui s'explique par un boîtier bien ventilé et un water-cooling.

    En résumé

    Ton article cible très bien le cas « serveur dédié LLM ». Mon approche montre qu'avec une seule carte milieu/haut de gamme, un bon usage du sleep-idle et du MTP, on peut obtenir des performances tout à fait utilisables tout en partageant le matériel entre plusieurs applications IA. Le chemin est différent mais il mène au même résultat : de l'IA auto-hébergée qui fonctionne bien.

    Encore merci pour la qualité de ton article, c'est une référence utile pour quiconque s'intéresse au sujet. 🐧🦙

    wind0w$ suxX, GNU/Linux roxX!

    • [^] # Re: Je me permets de partager mon approche

      Posté par (Mastodon) . Évalué à 4 (+1/-0).

      Je commence à sortir des quelques modèles proposés par Ollama pour aller tripatouiller sur Hugging Faces et llm-server (notamment grâce aux journaux de Jérôme). Mais bon, c'est un peu la jungle, des sous-saveurs de modèles il y en a des tétra-chiées... quel critères vous utilisez pour trouver des modèles "sérieux" ?

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Je me permets de partager mon approche

        Posté par (site web personnel) . É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: Je me permets de partager mon approche

      Posté par (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 08 juillet 2026 à 21:09.

      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.

  • # P2P / RDMA

    Posté par (site web personnel) . Évalué à 1 (+1/-0).

    Plop! Ça fait un bail!

    Malheureusement pour moi, mon matériel ne le supporte pas. Je n'ai donc pas pu le tester.

    T'es sûr? Perso je pense que si.

    En plus, la documentation est extrêmement sommaire sur ce sujet actuellement. Ceci dit, mes GPU tournent déjà à 100% sans ça, donc perso, je ne pense pas qu'il m'apporterait quelque-chose.

    L’intérêt c'est de faire du RDMA pour que l'échange entre les GPUs ne passe pas par le CPU. Ça permet entre-autres d'utiliser l'intégralité de la mémoire de tous les GPUs sur tous les GPUs à une latence acceptable et de réduire la charge sur le bus.

    L'iommu c'est plus simple de le désactiver au début

    Dommages que ta config soit en PCIe3, tes cartes sont en PCIe4! Et si tu commences à utiliser le P2P tu vas voir que le bus devient un bottleneck rapidement.

    • [^] # Re: P2P / RDMA

      Posté par (site web personnel) . É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: P2P / RDMA

        Posté par (site web personnel) . Évalué à 1 (+1/-0).

        Super! Je pars en vacances demain mais à mon retour j'essaierai de te contacter.

        Essaies de procéder par étapes:

        • lspci -s $PCI_ID -v -> vérifies qu'il y a bien un "large BAR" sur les cartes, typiquement: Memory at 28800000000 (64-bit, prefetchable) [size=32G]

        • ajoutes amd_iommu=on iommu=pt comme paramètre à ton noyau; vérifies avec cat /proc/cmdline

        • patches ton driver driver (c'est pas optionnel), assures toi d'avoir bien rechargé les modules si tu ne rebootes pas et de bien avoir mis à jour l'initrd si tu rebootes. Vérifie que tu as bien la bonne version de chargée avec modinfo; si tu utilises secureboot il faudra signer le module pour qu'il s'insère.

        • compiles simpleP2P ou p2pBandwidthLatencyTest du SDK cuda ; tant que ça ne fonctionne pas il n'est pas utile d'essayer de faire plus compliqué

        Tu en étais resté bloqué où?

  • # Petite config

    Posté par (site web personnel) . Évalué à 3 (+1/-0).

    Je suis peut-être hors sujet, mais j'aime, de temps en temps, tester les nouveaux modèles sur de très petites configs (J'ai une RTX 2070 8go et une Geforce 1050 2go).
    Même si cela reste assez inutilisable, je suis assez impressionné par les progrès fait pas les petits modèles. Je ne comprends pas comment ils peuvent stocker autant d'informations dans 1Go.
    Connais tu une communauté qui travaille sur le sujet ??

    • [^] # Re: Petite config

      Posté par (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 14 juillet 2026 à 09:33.

      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.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.