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 GPUcache-type-k=q8_0 ; KV cache K en q8cache-type-v=q5_1 ; KV cache V en q5fit-ctx=102400 ; contexte ajusté automatiquementspec-type=draft-mtp ; MTP activéspec-draft-n-max=4 ; jusqu'à 4 tokens draftspec-draft-p-min=0.85 ; seuil d'acceptationspec-draft-type-k=q8_0 ; cache MTP K en q8spec-draft-type-v=q5_1 ; cache MTP V en q5mmproj=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. 🐧🦙
# Je me permets de partager mon approche
Posté par i M@N (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. É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-serverplutô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-wakeC'est en cherchant à faire fonctionner cette approche que j'ai découvert un bug upstream : avec
--sleep-idle-secondset--fit on, le serveur plantait en boucle de réveil surtensor_buft_overrides already set by user, abort. Le-fitrecalculait le contexte réduit au premier chargement (262K → 102K pour tenir en VRAM), mais au réveil il tentait de réappliquer lestensor_buft_overridesdéjà fixés.J'ai ouvert ggml-org/llama.cpp#24684 et proposé un fix qui sauvegarde le
fitted_n_ctxau 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 :
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 :
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!