URL: https://linuxfr.org/users/jflesch/journaux/corrigendum-auto-heberger-ses-llm-ia-debordement-cpu-ram-mixture-of-experts-et-benchmarks Title: Corrigendum : Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks Authors: Jérôme Flesch Date: 2026-08-28T18:03:42+02:00 License: CC By-SA Tags: intelligence_artificielle, amd, intel, grands_modèles_de_langage, nvidia et llama-swap Score: 0 > In medio stat virtus. Non, c'est tout à fait correct, la vertu est dans le juste milieu. En revanche, ça n'a rien à voir avec la conversation. > > - Le roi Loth (François Rollin), *Kaamelott*, Livre V, *Corvus corone*, écrit par Alexandre Astier. # TL;DR Sans être exceptionnel, Qwen 3.5 35B A3B est adéquat pour de la programmation agentique. Or contrairement à ce que j'avais écrit, les modèles MoE comme Qwen 3.5 35B A3B sont en fait parfaitement utilisables avec une seule carte graphique comme la Nvidia RTX 3060 12 Go ou l'AMD RX 9070 XT 16 Go. Même en prenant en compte la vitesse de préremplissage, c'est assez confortable. Mais il faut optimiser la taille des lots correctement. # Introduction Dans un de mes précédents journaux, je parlais de [l'utilisation de matériel limité en VRAM avec des modèles MoE (*Mixture-of-Experts*)](https://linuxfr.org/users/jflesch/journaux/auto-heberger-ses-llm-ia-debordement-cpu-ram-mixture-of-experts-et-benchmarks). Et [un gentil utilisateur de Reddit m'a fait remarquer que j'y ai fait une grosse omission](https://www.reddit.com/r/LocalLLaMA/comments/1vz41ef/comment/p63bav7/). Le genre d'omission qui change partiellement la conclusion … 🫠 # Configuration matérielle et logicielle de départ On repart d'une [Nvidia RTX 3060 12 Go, avec débordement, avec --cpu-moe](https://linuxfr.org/users/jflesch/journaux/auto-heberger-ses-llm-ia-debordement-cpu-ram-mixture-of-experts-et-benchmarks#toc-sur-une-nvidia-rtx-3060-12go-avec-d%C3%A9bordement-avec---cpu-moe). La RAM est de la DDR4 3200 Mhz. Le CPU est un AMD Threadripper 1950X. Pour rappel, les Nvidia RTX 3060 12 Go sont une vieille gamme de cartes Nvidia, à mi-chemin entre l'entrée de gamme et le milieu de gamme. Elles sont actuellement trouvables d'occasion pour ≈250€ (ce qui est ironiquement très proche de son prix neuf il y a quelques années). Elle est donc franchement abordable … enfin, abordable pour du matériel IA 🤷. # Principe de la taille des lots Lors du préremplissage, [les tokens sont traités par lots (*batch*) par le GPU et/ou le CPU](https://linuxfr.org/users/jflesch/journaux/auto-heberger-ses-ia-materiel-et-optimisation-de-l-inference#toc-les-tailles-des-lots). La taille de ces lots est configurable. Llama-server a deux options pour ça : `--batch-size` et `--ubatch-size`. Par défaut, ces deux valeurs sont à 2048 et 512 respectivement. Touiller avec ces paramètres peut aider si vous avez *beaucoup* de sessions concurrentes. Par exemple, si vous générez 1 token à la fois (pas de MTP), et que vos tailles de lots sont à 256, vous pouvez avoir 256 sessions concurrentes. Mais vu qu'on parle d'auto-hébergement, je vais supposer que vous n'avez pas de datacenter, et donc que ce n'est pas votre cas. Par contre, là où ces réglages vont vous être utiles, c'est pour la vitesse de préremplissage avec certains matériels. D'après mon expérience, pour un LLM entièrement en VRAM sur mes cartes Nvidia RTX 3060, changer ces valeurs n'apporte rien, voire ça empire les performances. Sur une Intel Arc Pro B60, ça aide notablement. Et quand le modèle tourne partiellement sur CPU … ça aide **beaucoup**. Et ça, je ne le savais pas, et donc je l'avais zappé. # Optimisation de la taille des lots Comme mentionné, le bon réglage dépend de votre configuration matérielle et logicielle. Ceci dit, si vous travaillez avec un MoE et l'option `--cpu-moe` (ou sa petite sœur `--n-cpu-moe`), plus la taille de batch est grande, meilleures seront les performances. Aussi, si vous n'avez jamais plusieurs sessions de LLM en parallèle, vous pouvez juste mettre `--ubatch-size` et `--batch-size` à la même valeur. À partir de là, `llama-bench` est votre ami pour trouver la meilleure valeur pour votre situation. Par exemple : ```sh # mettez le nombre de cœur à l'option `-t` docker run --rm --entrypoint \ /app/llama-bench \ -v /data/llama.cpp:/models:ro \ --env CUDA_VISIBLE_DEVICES=0 \ --gpus all \ ghcr.io/ggml-org/llama.cpp:full-cuda \ -t 16 \ --n-gen 512 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --flash-attn on \ -r 1 \ --n-cpu-moe 999 \ --n-prompt 32768 \ --batch-size 8192 \ --ubatch-size 8192,6144,4096,2048,1024,512,256 \ -m /models/qwen3.5/Qwen3.5-35B-A3B-UD-Q4_K_XL.gguf ``` Passé un certain point, votre CPU ayant ses limites, vous arriverez probablement à un plateau. Mais le facteur qui va vous limiter bien avant sera plus probablement … votre VRAM (oui, encore et toujours 😑). Avoir des lots plus gros implique de consommer plus de VRAM. Si `llama-bench` dit qu'il ne réussit pas à charger votre modèle, ça peut être parce que vous avez dépassé la capacité de votre VRAM. En pratique, avec une Nvidia RTX 3060 12 Go, de la DDR4 3200 Mhz, et un AMD Threadripper 1950X, ça donne ça : ![Graph taille des lots / vitesse de préremplissage](https://i.imgur.com/cc933ne.png). 🎉 Ayé, ≈1000 tokens/s en préremplissage avec Qwen 3.5 35B A3B q4_k_xl et une carte à 250€ !! 🎉 [`--cpu-moe` a déjà rendu la prédiction utilisable](https://linuxfr.org/users/jflesch/journaux/auto-heberger-ses-llm-ia-debordement-cpu-ram-mixture-of-experts-et-benchmarks#toc-sur-une-nvidia-rtx-3060-12go-avec-d%C3%A9bordement-avec---cpu-moe). Maintenant, grâce aux tailles de lots, le préremplissage ne se traîne plus. Donc, comme on va le voir plus loin, c'est désormais parfaitement utilisable, voire même confortable ! ## Équilibrer taille des lots et `--n-cpu-moe` Comme [expliqué précédemment](https://linuxfr.org/users/jflesch/journaux/auto-heberger-ses-llm-ia-debordement-cpu-ram-mixture-of-experts-et-benchmarks#toc-conclusion-subjective-2), vous pouvez jouer sur `--n-cpu-moe X` plutôt que `--cpu-moe` pour essayer de gagner un peu de vitesse (en préremplissage et en prédiction). Et comme on vient de le voir, vous pouvez jouer sur la taille des lots pour maximiser de façon importante votre vitesse de préremplissage. Il y a donc un équilibre à trouver, en fonction de vos besoins. # Là où la magie s'arrête Je reboucle sur les influenceurs LinkedIn, youtubeur et autres personnages bizarres qui essayent de vous vendre du rêve. Plus spécifiquement, je vais utiliser comme référence [une vidéo Youtube de Codacus](https://www.youtube.com/watch?v=8F_5pdcD3HY). Codacus utilise comme référence une relique sacrée de l'ancien temps : la Nvidia GTX 1060 (2016). Elle a 6 Go de VRAM. ## Petits MoE uniquement C'est évident, mais en même temps, ça mérite d'être souligné. Parce que, à ces tailles, ces modèles sont plus rares. Par exemple, Qwen 3.8 27b dense est sorti depuis peu, mais on attend toujours une annonce pour Qwen 3.8 35B A3B (autrement dit, pas dit qu'il y ait un Qwen 3.8 35B A3B un jour). De plus, comme mentionné précédemment, à taille similaire et quantification identique, les [modèles MoE sont un peu plus bêtes que les denses](https://linuxfr.org/users/jflesch/journaux/auto-heberger-ses-llm-ia-debordement-cpu-ram-mixture-of-experts-et-benchmarks#toc-les-mod%C3%A8les-mixture-of-experts). ## La quantification Premier constat : sur un matériel aussi restreint, il faut utiliser des versions fortement quantifiées des modèles. Codacus utilise la quantification `q4_k_m`. Il quantifie aussi fortement le KV cache (`turbo4` / `turbo3`). Or, il y a débat sur la qualité des `q4_k_m` et des KV caches quantifiés. Personnellement, j'ai été frustré par les nombreuses hallucinations que j'ai eues avec les `q4_k_m`. Les `q4_k_xl` m'ont fait une bien meilleure impression. ## La taille des batchs Dans la vidéo de Codacus, en plus d'avoir omis la vitesse de préremplissage, on notera qu'il se garde bien d'y mentionner explicitement les options `--batch-size` ou `--ubatch-size`. Et pour cause probable : si [on regarde attentivement](https://youtu.be/8F_5pdcD3HY?t=836), pour que ça passe, on peut y voir qu'il a dû choisir une taille de lot < 1024. # En pratique Comme je n'ai pas de GTX 1060, je vous propose de poser une hypothèse : Imaginons que la seule différence entre la GTX 1060 6 Go et la RTX 3060 12 Go soit la taille de la VRAM. Autrement dit, imaginons qu'elles ont la même vitesse de calcul et la même bande passante mémoire. Cette hypothèse est bien entendu fausse, mais il s'agit ici avant tout d'isoler l'effet du manque de VRAM, et accessoirement d'être très gentils avec la GTX 1060 et Codacus. En suivant cette supposition, la seule différence notable entre les deux serait la taille des lots : la RTX 3060 peut monter à 4K~8K, tandis que la GTX 1060 reste coincée à 1024. En pratique, ça nous donnerait ça : | | | | Tokens | Avg Speed | Estimated Time | |-----------------------|-------------|-----------|--------|-----------|----------------| | Home Assistant | | | | | | | | ub = 1024 | | | | | | | | 35B-A3B | 2500 | ≥ 344 | **7s** | | | | 122B-A10B | 2500 | ≥ 100 | **25s** | | | ub = 4K/8K | | | | | | | | 35B-A3B | 2500 | ≥ 1100 | 2.3s | | | | 122B-A10B | 2500 | ≥ 270 | **9s** | | Opencode | | | | | | | | ub = 1024 | | | | | | | | 35B-A3B | 8000 | ≥ 344 | 24s | | | | 122B-A10B | 8000 | ≥ 100 | **78s** | | | ub = 4K/8K | | | | | | | | 35B-A3B | 8000 | ≥ 1100 | 7s | | | | 122B-A10B | 8000 | ≥ 270 | 30s | | Tool-enabled Open-WebUI| | | | | | | | ub = 1024 | | | | | | | | 35B-A3B | 20000 | ≥ 344 | **1m** | | | | 122B-A10B | 20000 | ≥ 100 | **3m 20s** | | | ub = 4K/8K | | | | | | | | 35B-A3B | 20000 | ≥ 1100 | 18s | | | | 122B-A10B | 20000 | ≥ 270 | **1m 10s** | # Conclusion subjective La vitesse de préremplissage reste un facteur important à prendre en compte. Mais changer la taille des lots rend certaines configurations modestes tout à fait utilisables. Nvidia RTX 3060 12 Go, AMD RX 9070 XT 16 Go, etc. peuvent très bien faire tourner des MoE de taille raisonnable.