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

Sommaire

• Introduction
• Ce dont je ne vais pas parler
  • Les IA de génération d'images et autres
  • Les moteurs d'inférence
  • Comparatifs de performances
• Les modèles du moment
• Introduction éclair aux réseaux de neurones
  • Un neurone artificiel
  • Un réseau de neurones artificiel
• Les backends
• Les optimisations
  • Quantification du KV cache
  • Le multi-GPU
    • Nvidia: NVLink
    • Découpage en couches
    • Découpage en lignes
    • P2P sur le bus PCIe
  • ReBAR
  • ASPM
  • Flash Attention
  • Les variantes de quantification XL
  • Les modèles QAT
  • MTP (Multi-Token Prediction)
  • Les tailles des lots
  • Intel : le cache persistent Sycl
  • Le mmproj
• Comparer avant et après
  • Éviter le débordement sur le CPU+RAM
  • nvtop
  • llama-swap
  • llama-bench
• Le matériel
  • La solution Apple
  • La solution du pauvre : Intel Arc Pro B60
    • Le bon
    • Le mauvais
    • Cas d'utilisation
    • La grande sœur
    • Optimisations spécifiques
    • Exemple de configuration llama-swap
  • La solution de Dédé la bricole
    • Le matériel
      • La configuration
      • Le châssis
      • Les risers PCIe
      • Les bifurcations PCIe
    • Le bon
    • Le mauvais
    • Optimisation
    • Exemple de configuration llama-swap
• Conclusion

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 :

• Linux en général ;
• Docker ;
• le bus PCIe ;
• quelques notions de base concernant les LLM auto-hébergés (sinon ça va piquer fort).

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 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 !

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.

Nvidia: NVLink

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

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.

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.

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 🦆 :

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

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.

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 :

• CUDA
• Nvidia Container Toolkit

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/