Sommaire
- Introduction
- Quelques définitions
- Pourquoi auto-héberger ?
- Open-source et open-weight
- Comment faire ?
- L'importance de la vitesse d’exécution
- Exemple: configuration de llama-swap
- Utilisations concrètes et limites
- Trouver le matériel
- Conclusion
Introduction
Si on en croit les décideurs pressés sur LinkedIn, l'IA, c'est la nouvelle révolution technologique, la nouvelle ruée vers l'or, et j'en passe. Bientôt, plus besoin d'ingénieurs logiciels !
Et si on en croit mes recommandations Youtube, l'IA, c'est la dernière arnaque à la mode, une bulle économique sans précédent en train de gonfler, et un désastre écologique ¯\(ツ)/¯.
Dans tous les cas, dans les métiers de l'informatique, le sujet est devenu difficile à éviter.
Pour ma part, après examen du problème, je suis arrivé à la conclusion personnelle suivante : C'est un nouvel outil, ni plus, ni moins. Reste à trouver comment s'en servir au mieux. Et en vieux pingouin barbu communiste, ça veut dire trouver les outils les plus open-source possibles et trouver comment auto-héberger la bête.
Pour la suite, je vais me concentrer spécifiquement sur les LLMs. Vers la fin, je rebouclerai rapidement sur les IA de génération d'images.
Quelques définitions
- IA : regroupe tous les algorithmes capables d'effectuer des tâches habituellement associées à l'intelligence humaine (jouer aux échecs, trouver son chemin dans un labyrinthe, parler, dessiner, etc).
- ML : Machine Learning. Algorithmes capables d'apprendre à partir de données d'exemple. Ces algorithmes sont un sous-ensemble des IA.
- Les réseaux de neurones : un sous-ensemble du machine-learning, où on a tenté d'imiter les neurones humains, où on a probablement échoué, mais où ça a quand même donné des résultats utilisables (échec réussi ! )
- LLM : Large-Language Model. En gros, une IA qui génère du texte et discute. Ce sont un sous-ensemble des réseaux de neurones
- IA générative : Techniquement, les LLMs en font partie, mais on s'en sert aussi parfois pour désigner les IA qui font spécifiquement des images, de la vidéo, etc (autrement dit, tout sauf les LLMs). C'est aussi un sous-ensemble des réseaux de neurones.
- token : un mot, ou une syllabe, ou un symbole. Pour simplifier à mort, on peut considérer que le nombre de tokens, c'est le nombre de mots.
- Contexte : la discussion en cours entre un LLM et un utilisateur.
- Programmation agentique : programmation assistée par un LLM.
- Vibe-coding : la même chose, sans les mains, à plus de 130km/h.
- Inférence : en gros, c'est l'utilisation du LLM.
- Entraînement : c'est la fabrication du LLM, à partir de (beaucoup) d'exemples.
Pourquoi auto-héberger ?
Face à cette question, spontanément, tel un William Wallace des temps modernes, je serais tenté de répondre en hurlant « pour la liberté !! ». Mais en soit, ce n'est pas hyper-constructif. Alors soyons plus constructifs :
Le respect de votre vie privée
En auto-hébergeant et en utilisant des logiciels open-source, vous avez la garantie que vos échanges resteront confidentiels.
Malheureusement, je sais que de nos jours beaucoup de gens s'en fichent, tout comme beaucoup de gens ne comprennent pas le concept d'immunité collective …
Le coût des API cloud
Pour faire court, les API cloud sont horriblement chères.
Je les utilise occasionnellement. Je passe par openrouter.ai pour avoir un vaste choix de fournisseurs et de modèles.
La facturation de ces API se fait au token (hyper-simplification: on paye au mot). Sauf qu'un token, comme on l'a vu, c'est un peu flou comme concept. Donc, niveau transparence, ça commence tout de suite mal. Pire, chaque API utilise son propre tokenizer. Donc difficile de déterminer précisément comment ils comptent les tokens.
Ensuite, pour une utilisation type programmation agentique, la facturation tokens, ça chiffre vite.
À ça, on m'a déjà répondu « mais prends donc un abonnement, c'est nettement moins cher ! »
Les abonnements cloud
Et en effet, c'est nettement moins cher. Des commentaires que j'ai pu voir sur Internet suggèrent que certains sont passés de plusieurs centaines de dollars/euros d'API chaque mois à des abonnements à 20~90€/mois. De façon générale, ça serait 2 à 5 fois moins cher. En bref, c'est tellement moins cher que ça en devient vite suspect.
1er problème : les abonnements ne vous laissent pas utiliser les API. Donc vous êtes coincé avec les frontends de votre fournisseur: leur interface web (chatgpt.com, claude.ai, etc), leur outil de programmation agentique (Claude Code, Mistral Code, etc), etc.
Le 2ième problème, c'est que les prix des APIs reflètent vraisemblablement le vrai coût des LLMs. Les abonnements LLM ne sont donc pas assez chers. Comme les FAI, ils misent potentiellement sur le fait que certains utilisateurs se servent peu de leur abonnement pour compenser ceux qui s'en servent beaucoup. Mais actuellement, l'utilisation des IA augmente fortement. Je pense qu'il y a peu de chance pour que cette idée tienne, et donc je pense qu'ils seront amenés à monter brutalement le prix des abonnements, ou à continuer à baisser les plafonds d'utilisation.
Le 3ième problème est que les plafonds d'utilisation sont déjà passablement bas. Quel bonheur, quand, en plein milieu de votre session de coding, votre frontend vous annonce joyeusement que vous avez tapé votre plafond journalier !
Accès à des modèles spécialisés
Les LLMs cloud sont le plus souvent des LLMs généralistes. Mais il existe des modèles spécialisés (fine-tuned). Certains sont spécialisés pour la programmation, pour jouer le rôle d'assistant, pour faire du role-play, pour faire de l'OCR, etc.
Et vous connaissez le principe : dès qu’une nouvelle technologie apparaît, la première question que beaucoup se posent, c’est « comment est-ce qu’on peut s’en servir pour le sexe ? ». Donc forcément, on a aussi des variantes décensurées, notamment utiliser pour du jeu de rôle érotique ^
Très peu de ces modèles spécialisés sont accessibles par API. Pratiquement aucun ne l'est via les abonnements.
La seule option, c'est les faire tourner soi-même.
L'écologie, l'économie, tout ça ?
Il est difficile de trouver des chiffres officiels quant à l'impact des LLMs cloud. Mais comme on le verra plus loin, il s'agit de modèles LLM généralistes énormes, et donc forcément gourmands, même si mutualisés. Et vu les constructions de datacenters un peu partout dans le monde, ben, c'est pas glop.
Du côté auto-hébergement, ce n'est pas mutualisé. Et comme on va le voir, il faut des cartes graphiques, et non pas juste la première carte graphique venue.
Au final, je ne me risquerai juste pas à comparer les deux.
Open-source et open-weight
Comme le mot "opensource" fait désormais partie du vocabulaire des marketoïdes, beaucoup de développeurs d'IA prétendent que leur IA est opensource. Or ils ne donnent que le modèle pré-entrainé (son architecture et ses poids), mais pas ses données d’entraînement. Donc, contrairement à logiciel opensource, ils ne fournissent pas tout le matériel nécessaire pour reconstruire le binaire final depuis "ses sources".
L'OSI a donc tranché : pour qu'un LLM soit considéré comme opensource, il faut qu'il soit fourni avec ses données d’entraînement, ou une description suffisamment détaillée pour permettre la reproduction. La quasi-entièreté des modèles disponibles sur ollama.com, huggingface.com, etc sont donc en fait open-weight, et non pas opensource.
Toutefois, ce n'est pas tout noir : même s'il n'est pas possible de reproduire leur entraînement from scratch, il est possible de les fine-tuner. Il est aussi possible de reprendre leur architecture et de les entraîner à partir d'autres jeux de données.
À noter que ça ne change rien en terme de confidentialité des données : un modèle ne peut strictement rien faire sans l'assistance de son moteur d'inférence et de son frontend. Par exemple, impossible donc d'y cacher un spyware. Si un LLM fait fuiter vos données, c'est que votre frontend lui a donné les outils pour.
Comment faire ?
La recette pour un LLM auto-hébergé, c'est:
- une grosse dose de carte graphique,
- un modèle LLM parfaitement assaisonné,
- une cuillère de moteur d'inférence LLM,
- et un soupçon de frontend
Pourquoi la carte graphique est super duper importante ?
Le CPU est une puce relativement généraliste et optimisée pour la faible latence. Le GPU (le processeur de la carte graphique) est une puce spécialisée dans le calcul parallélisé massivement.
En gros, si le calcul était du transport de matériel, le CPU est un peu l'équivalent d'une voiture de course, là où le GPU est un camion. Et l'IA a besoin de camions.
Choisir son matériel
Du coup, le point le plus important pour les LLM, et de très loin, c'est la VRAM : la RAM de la carte graphique. La taille de la VRAM va déterminer la taille du LLM que vous pouvez utiliser. Si vous tentez de charger un LLM trop gros pour votre VRAM, la plupart des moteurs d'inférence vont le faire déborder sur le CPU et la RAM. Dans un premier temps, ça va marcher, mais les performances vont s'effondrer très rapidement.
Histoire de faire gagner du temps à certaines personnes : en dessous de 12 Go de VRAM, vous n'arriverez probablement à rien de véritablement utile avec les LLMs.
À noter que la bande passante de votre VRAM est importante aussi : plus vous avez de bande passante, plus votre modèle s’exécutera rapidement. Les cœurs ont bien entendu aussi leur importance, mais l'expérience tend à montrer que la bande passante de la mémoire est un meilleur indicateur des performances potentielles d'une carte.
Vous pouvez opter pour des cartes graphiques Nvidia, AMD ou Intel:
- Nvidia: ce sont les mieux supportées en général. Peuvent nécessiter l'installation de CUDA sur votre machine.
- AMD: plutôt bien supportées, même si pas autant que les Nvidia. Peuvent nécessiter l'installation de Rocm sur votre machine.
- Intel: les moins bien supportées actuellement. La plupart des projets les gèrent désormais, mais leur configuration risque d'être plus compliquée, et les nouvelles fonctionnalités et optimisations risquent d'arriver plus tard.
Choisir le moteur d'inférence
Le moteur d'inférence, c'est le logiciel qui fait tourner votre modèle. À ma connaissance, la grande majorité des moteurs d'inférence sont opensource.
En auto-hébergement, les plus communs sont les suivants :
llama.cpp
C'est, à ma connaissance, le moteur d'inférence le plus courant. Mais c'est juste une
librairie C++, difficile donc à utiliser tel quel :-)
Ollama
Le plus simple à utiliser, mais pas le meilleur. Il est construit autour de llama.cpp. Il offre un outil ligne de commande inspiré de Docker.
Il peut utiliser tous les modèles de ollama.com, et il peut, théoriquement, utiliser ceux de huggingface.com. En pratique, pour ceux d'huggingface, ce n'est pas simple.
J'ai longtemps utilisé Ollama, mais les dernières versions se révèlent de plus en plus décevantes. Notamment, les derniers modèles mettent un temps fou à charger sur mon setup.
llama-server et llama-swap
llama-server est un serveur web qui wrappe llama.cpp. Il offre de bonne performances. Il peut utiliser n'importe quel modèle au format GGUF de huggingface.com.
Par contre, il ne peut s'occuper que d'un modèle. Si vous voulez basculer sur un autre modèle, il faut le reconfigurer.
llama-swap est un wrapper autour de llama-server. Il permet justement de basculer
de façon transparente d'une configuration de llama-server à une autre (et plus encore).
vllm
C'est un moteur d'inférence .. pas du tout lié à llama.cpp :-).
Il est connu pour être un des plus performant, si pas le plus performant. Mais comme llama-server, il ne peut gérer qu'un modèle à la fois. Il a aussi des contraintes matérielles plus fortes. Par exemple, il n'est pas du tout fan des configurations de cartes graphiques asymétriques comme la mienne (différents types de cartes mélangées).
Ma recommandation
À l'heure actuelle, je recommande llama-swap.
Docker ?
Personnellement, je fais tourner mes moteurs d'inférence dans Docker.
J'utilise du matériel Nvidia. Et dans le cas du matériel Nvidia, Docker complexifie plus qu'il ne simplifie (il faut quand même installer Cuda, et il faut installer nvidia-container-toolkit). Par contre, ça permet quand même de passer d'un moteur à un autre facilement, et de ne pas saloper le système hôte.
Dans le cas des cartes AMD (Rocm) et Intel (sycl), je ne serai pas surpris si Docker simplifie pas mal les choses. Sauf erreur de ma part, pas besoin d'installer Rocm sur le système hôte. Il suffit de passer les devices dans le conteneur, et chaque conteneur intègre la version de Rocm/Sycl dont il a besoin.
Choisir son modèle
Le modèle, c'est le cœur des réseaux de neurones. C'est un gros blob binaire, qui contient les valeurs représentant les neurones et leurs synapses.
Votre matériel peut vous permettre une certaine taille de modèle, et votre utilisation et votre matériel peuvent vous permettre certains modes de fonctionnement.
La taille du modèle
Là, on rentre dans le cœur du sujet.
Je vais sursimplifier à mort : Chaque modèle a ses propres spécificités. Mais là, il s'agit juste de donner des points de repères.
Les caractéristiques qui déterminent la taille sont surtout :
- le nombre de paramètres
- la quantification
Le nombre de paramètres est actuellement en milliards pour les modèles self-hosted (les modèles cloud tapent les milliers de milliards). Ça donne un ordre d'idée de la quantité de connaissances stockées dans le LLM, mais aussi plus ou moins de sa capacité de réflexion (<< attention, ceci est hyper approximatif !). Milliard est abrégé b en anglais. Donc des tailles classiques en LLM auto-hébergé, c'est, par exemple, 3b, 14b, 27b, 35b, etc.
La quantification, c'est la taille de chaque paramètre en mémoire. Les classiques sont :
- fp16: précision max. 2 octets par paramètre
- q8: 1 octet par paramètre
- q4: 1 octet pour 2 paramètres
Après il y a encore des variantes dans les quantifications (S, M, XL, etc), mais je ne vais pas détailler ça.
En gros, fp16, ça bouffe plein de VRAM, mais c'est la variante qui hallucinera le moins.
q8, on parle d'une précision de 99% par rapport à fp16. C'est généralement suffisant pour avoir un bon résultat. q4, on parle de ~97% par rapport à fp16. q4, ça fonctionne, mais on a parfois des surprises.
Il y a des quantifications en dessous de q4, mais je ne vais même pas en parler tellement les résultats sont médiocres.
À noter que, d'expérience, plus un modèle a de paramètres, plus il sera tolérant à la quantification. Par exemple, un 70b en q4 sera probablement aussi utilisable qu'un 14b en q8 (estimation au doigt mouillé sortie de mon chapeau magique).
Et donc là, on peut estimer au doigt mouillé la taille en VRAM du modèle :
nombre de paramètre × (quantification / 8)
La taille du contexte
Mais ce n'est pas tout ! Il faut aussi stocker en VRAM le contexte. Autrement dit, la discussion que l'utilisateur et le LLM sont en train d'avoir. Ce contexte est stocké dans le "KV cache". Pour des questions de performances, on doit déterminer dès le départ la taille maximum du contexte.
Estimer la consommation en VRAM du KV cache est très délicat et dépend du modèle. Le plus simple, à mon avis, c'est de juste essayer et voir si ça rentre.
Il est quantifié à fp16 par défaut, mais les moteurs d'inférence permettent maintenant de réduire ça. Personnellement, je le mets en q8.
Il faut aussi penser à activer "Flash Attention". C'est une optimisation qui réduit considérablement la taille du KV cache pour les modèles qui la supportent. Bientôt devrait aussi arriver une nouvelle optimisation, "TurboQuant".
Un grand contexte est particulièrement nécessaire en programmation agentique (opencode, etc): il faut au moins un contexte de 64K, voire 128K, pour que ce soit utilisable (sinon ça va recompresser le contexte constamment). Je soupçonne que c'est aussi particulièrement utile pour du jeu de rôle avec SillyTavern. La plupart des modèles modernes supportent a minima 128K, donc la limite sera clairement du côté de votre VRAM.
À noter que, par défaut, Ollama utilise un petit contexte de max 4K ou 8K si je me souviens bien. Suffisant pour une simple discussion. Insuffisant pour tout le reste. Il faut donc le régler.
Et attention aux débordements ! L'effet sur les performances est sournois : s'il y a débordement sur la RAM+CPU, une discussion courte n'utilisera qu'une petite partie du KV cache, et donc les performances ne seront que légèrement dégradées. Par contre, la dégradation va s'amplifier sévèrement avec la taille du contexte.
Pour référence, j'ai 16+16+12Go de VRAM, et je fais tout juste rentrer qwen3.6-35b-a3b en q8 avec 128K de contexte.
La vitesse du modèle
En dehors de la taille même du modèle, il y a deux caractéristiques qui jouent beaucoup sur sa vitesse d’exécution :
Modèles pensants
Vous avez sûrement déjà dû voir des LLM afficher « Thinking … » ou quelque-chose de similaire. Et vous avez pu voir qu'on peut examiner ce qu'ils « pensent ». Il s'agit des modèles dits pensants (thinking). Les études montrent que ces modèles donnent de meilleurs réponses. Par contre, ils mettent bien entendu plus de temps à répondre (et consomment plus de tokens si vous passez par une API .. ah ben oui, bien sûr que c'est facturé …).
Modèles denses ou mélanges d'experts (MoE)
Au début, il n'y avait des LLMs denses : quand on leur envoie une requête, une grande partie du réseau de neurones est utilisée. Puis sont arrivés les MoE (mélange d'experts ; Mixture-of-Expert).
Un des 1er MoE open-weight correct est mixtral, de Mistral (cocorico ! :-)
Un LLM MoE, c'est en fait un ensemble de sous-LLM spécialisés ("experts"). C'est un 1er réseau de neurones qui décide vers quel autre LLM envoyer la requête.
L’avantage: il n'y a qu'une sous-partie du LLM qui est active à la fois. Le GPU a nettement moins de calculs à faire. Ils sont donc nettement plus rapides.
L'inconvénient: les experts sont relativement petits, leurs connaissances sont moins entrecroisées, donc ils sont potentiellement plus bêtes.
Exemple:
- qwen3.6-27b est dense
- qwen3.6-35b-a3b est un MoE, avec max 3 milliards de paramètres actifs simultanément (autrement dit, des experts de 3 milliards de paramètres)
Autre caractéristiques
Les modèles instruct
Des modèles entraînés à suivre des instructions rapidement .. et donc à ne pas trop réfléchir. Vous verrez donc rarement des modèles taggués à la fois instruct et thinking.
Support des outils
Les modèles taggués "tools" ou "tooling" sont des modèles entraînés à lire et émettre du JSON bien formaté. Le frontend peut leur mettre à disposition des outils, sous forme d'une manifeste JSON. Les LLMs peuvent alors s'en servir en émettant, sous forme de JSON, des instructions qui seront interprétées par le frontend.
Les modèles modernes (autrement dit, ceux qui ont moins d'un an .. ^^) supportent quasiment tous l'utilisation d'outils.
C'est absolument nécessaire pour la programmation agentique, la domotique, etc.
La spécialisation du modèle
Les LLMs self-hosted sont très limités en taille. Il y a donc des choix à faire quant à ce qu'on leur apprend.
Exemples:
- ministral-3 est un généraliste, mais qui sait suivre des instructions et utiliser des outils (mon préféré pour Home Assistant)
- qwen3-coder est spécialisé programmation
- qwen3.6 : un généraliste, mais avec un fort accent sur le code et la programmation agentique. Il se débrouille très bien pour ça. C'est probablement le meilleur modèle auto-hébergeable pour ça à l'heure actuelle.
- gemma4 : un généraliste, mais avec un accent sur le multi-modal (image, audio, etc)
Choisir son front-end
Là, rien de bien particulier à savoir.
Une brève liste rapide de quelques frontends opensources sympas:
- open-webui ou LibreChat : des interfaces web pour juste discuter avec un LLM
- SillyTavern : une interface web pour faire du jeu de rôle avec un LLM
- opencode : un outil pour faire de la programmation agentique
Les all-in-one
Pour simplifier l'utilisation, il y a des programmes qui font tout ou presque tout d'un bloc.
Par exemple:
- gpt4all
- lm-studio (attention, closed-source !)
L'importance de la vitesse d’exécution
Il y a essentiellement deux vitesses à prendre en compte:
- la vitesse de lecture du "prompt"
- la vitesse de génération de tokens
Les deux sont exprimées en tokens par seconde.
La première nous dit combien de temps il faudra au LLM pour prendre en compte une nouvelle entrée utilisateur. Mais attention ! Si vous perdez le KV cache (par exemple si vous reprenez une ancienne discussion), cette vitesse nous dit aussi combien de temps il faudra au LLM pour le reconstituer.
La 2ième nous dit à quelle vitesse le LLM va nous répondre.
Et pour certaines utilisations, la vitesse d’exécution du LLM est très importante. Cela se voit particulièrement avec la programmation agentique.
Typiquement, en programmation agentique, on considère que le LLM est pénible à utiliser s'il n'arrive pas à répondre plus de ~10 tokens par seconde (plus si c'est un LLM thinking).
Toujours en programmation agentique, quand vous arrivez à la limite de votre contexte (on peut arriver très vite à >128000 tokens), le frontend doit demander au LLM de compacter le contexte. Autrement dit, il lui demande de résumer tout ce qui s'est dit jusque là. Du coup, le LLM doit générer un gros pavé, invisible pour vous.
Tout aussi embêtant : le matin, quand vous voulez reprendre votre session de la veille, le LLM doit reconstruire son KV cache entièrement. En imaginant que votre contexte était alors proche de 128K tokens, si votre GPU et modèle peuvent relire:
- 1000 token/s : 2 minutes pour redémarrer votre session !
- 200 token/s: 10 minutes pour redémarrer votre session !!
Exemple: configuration de llama-swap
llama-swap permet de passer d'un LLM à l'autre, mais il peut aussi jongler avec n'importe quel autre logiciel fournissant une API compatible OpenAI. Cela inclut notamment stable-diffusion.cpp (moteur d'inférence pour IA générative d'image).
Voici la configuration que j'utilise sur ma machine Debian, avec des cartes Nvidia (16Go + 16Go + 12Go de VRAM).
CUDA et Nvidia Container Toolkit
Il faut installer:
Dockerfile
L'image Docker officielle de llama-swap:cuda n'inclut pas (encore) stable-diffusion.cpp. Je l'ai donc rajouté moi-même.
FROM nvidia/cuda:12.9.1-devel-ubuntu24.04 AS builder
RUN apt-get update && apt-get install -y --no-install-recommends \
git build-essential cmake ca-certificates \
&& rm -rf /var/lib/apt/lists/*
RUN git clone --recursive https://github.com/leejet/stable-diffusion.cpp /tmp/sd
RUN cmake -S /tmp/sd -B /tmp/sd/build \
-DSD_CUDA=ON \
-DSD_BUILD_SERVER=ON \
-DCMAKE_BUILD_TYPE=Release \
&& cmake --build /tmp/sd/build --config Release -j"$(nproc)"
FROM ghcr.io/mostlygeek/llama-swap:cuda
COPY --from=builder /tmp/sd/build/bin/sd-server /usr/local/bin/sd-server
Point de vigilance : il faut utiliser exactement la même image CUDA pour construire stable-diffusion.cpp que celle utilisée par llama-swap.
docker-compose.yml
services:
llama.cpp:
build: .
restart: "always"
privileged: true
ports:
- "8080:8080"
volumes:
- /data/llama.cpp/models:/models-llm
- /data/stable-diffusion.cpp/models:/models-img
- ./config.yaml:/app/config.yaml:ro
deploy:
resources:
reservations:
devices:
- capabilities: [gpu]config.yaml
La configuration de llama-swap.
Permet d'avoir:
- simultanément actifs Gemma4 sur 2 de mes GPU, et stable-diffusion.cpp sur le 3ième GPU
- ou alors n'importe-quel autre LLM, mais un à la fois
matrix:
vars:
img: img
gm: Gemma4-31b-q4
sets:
llm-and-image: "il & gm"
models:
img:
checkEndpoint: /
env:
- "CUDA_VISIBLE_DEVICES=2"
cmd: >
/usr/local/bin/sd-server --listen-port ${PORT} --listen-ip 0.0.0.0
-m /models-img/some_model.safetensors
--vae /models-img/vae/sdxl-vae-fp16-fix.safetensors
--lora-model-dir /models-sd/lora
--diffusion-fa
--vae-tiling
Gemma4-31b-q4:
env:
- "CUDA_VISIBLE_DEVICES=0,1"
cmd: >
llama-server --port ${PORT} --jinja
--ctx-size 131072 --flash-attn auto
--cache-type-k q8_0
--cache-type-v q8_0
--model /models/gemma4/gemma-4-31B-it-UD-Q4_K_XL.gguf
--mmproj /models/gemma4/mmproj-BF16.gguf
Qwen3.6-35B-q4:
cmd: >
llama-server --port ${PORT} --jinja
--ctx-size 131072 --flash-attn auto
--model /models/qwen3.6/Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf
--mmproj /models/qwen3.6/mmproj-BF16-35b.gguf
Qwen3.6-35B-q8:
cmd: >
llama-server --port ${PORT} --jinja
--ctx-size 131072 --flash-attn auto
--cache-type-k q8_0
--cache-type-v q8_0
--model /models/qwen3.6/Qwen3.6-35B-A3B-UD-Q8_K_XL.gguf
--mmproj /models/qwen3.6/mmproj-BF16-35b.gguf
Qwen3.6-27B-q4:
cmd: >
llama-server --port ${PORT} --jinja
--ctx-size 131072 --flash-attn auto
--model /models/qwen3.6/Qwen3.6-27B-UD-Q4_K_XL.gguf
--mmproj /models/qwen3.6/mmproj-BF16.gguf
Qwen3.6-27B-q8:
cmd: >
llama-server --port ${PORT} --jinja
--ctx-size 131072 --flash-attn auto
--cache-type-k q8_0
--cache-type-v q8_0
--model /models/qwen3.6/Qwen3.6-27B-UD-Q8_0.gguf
--mmproj /models/qwen3.6/mmproj-BF16.gguf
Ministral-3-14b-q8:
cmd: >
llama-server --port ${PORT} --jinja
--ctx-size 131072 --flash-attn auto
--model /models/ministral-3/Ministral-3-14B-Instruct-2512-Q8_0.gguf
--mmproj /models/ministral-3/Ministral-3-14B-Instruct-2512-BF16-mmproj.ggufÇa rentre ?
llama-swap a une interface web. Connectez vous sur http://localhost:8080.
Dans cette interface, vous pouvez accéder aux logs de l'"upstream" (llama-server, stable-diffusion.cpp, etc). Si vous filtrez les logs sur "GPU", vous pourrez voir si votre modèle est rentré entièrement en VRAM, ou si il a débordé sur la RAM.
Utilisations concrètes et limites
Comme on l'a vu, la seule vraie limite est en fait votre matériel. En théorie, rien ne vous empêche de faire tourner Kimi K2.5. Il vous suffit d'avoir 1.5To de VRAM :-)
Mais en réalité, la plupart d'entre nous arriverons à avoir au mieux entre 24Go et 42Go de VRAM. Ce que je vais décrire ci-dessous correspond à mon expérience, avec mes 3 cartes graphiques.
Vibe-coding
TL;DR : Mouais, bof, pas vraiment.
Modèle que je recommande actuellement : qwen3.6, ou beaucoup plus gros. q8 au minimum.
Avec ma VRAM, je peux faire fonctionner le modèle qwen3.6, en version q8, 27b ou 35b-a3b, avec un contexte de 128K.
De mon point de vue (totalement subjectif et pas du tout benchmarké proprement), ce modèle donne un code à peu près aussi bon que Claude Sonnet 4.5. Autrement dit, le code fonctionne, mais c'est de la merde. Dès qu'on regarde sous le capot, on se rend compte que le code est bordélique. C'est notamment accentué si, comme moi, vous êtes du genre à changer d'avis. Le LLM est incapable de prendre du recul et de se dire « eh mais attends, du coup, on pourrait simplifier tout ça ».
Autre problème: le contexte. En auto-hébergé, vous allez travailler avec un contexte plus petit. Qui dit contexte plus petit, dit plus de recompression du contexte. Qui dit plus de recompression du contexte, dit plus de pertes d'informations. Et avant d'avoir compris ce qui se passe, le LLM aura oublié des instructions clés.
Certains me diront que ça peut être mitigé. Par exemple, avec des mécanisme de mémoire, en jetant plus de matériel sur le problème, ou alors … en utilisant un LLM cloud comme Claude Opus 4.7.
Mais de façon générale, je trouve que les LLMs (LLMs cloud inclus) codent comme des stagiaires qui auraient fraîchement fini leurs études, auraient une quantité incroyable de connaissances, mais auraient juste autant de bon sens qu'un pneu crevé.
Et même en mettant ces problèmes de côté, personnellement, je vois aussi des problèmes fondamentaux dans le vibe-coding, qui sont plus d'ordre humain :
À la fin, c'est mon nom qui sera sur ce code. C'est moi, l'être humain, qui devra en prendre la responsabilité. Donc je dois a minima le relire correctement.
J'ai expérimenté le vibe-coding pendant 2 semaines à titre personnel, avec qwen3.6 et Claude Sonnet 4.5. Ma conclusion est que le vibe-coding rend vite accroc … et paresseux. Le vibe-coding permet d'avoir des résultats visibles, beaucoup plus vite. Et donc ça permet d'avoir sa dose de dopamine, beaucoup plus vite. J'ai essayé de me forcer à relire attentivement le code généré, mais la relecture créait une friction, et se mettait entre moi et ma dose. Je me suis surpris à relire trop vite et à rater plein d'erreurs.
De plus, j'ai senti mon expérience me glisser entre les doigts. L'expérience, ça s'entretient. Autrement dit, si je ne forge plus, bientôt, je ne serai plus forgeron.
Relecture de code
TL;DR: Oui.
Modèle que je recommande actuellement : qwen3.6
Personnellement, j'ai toujours été plus adepte de l'idée d'IAs qui assistent les humains plutôt que d'IAs qui les replacent complètement. Donc plutôt que de vibe-coder, j'ai décidé d'opter pour une autre approche. J'utilise les LLMs pour me relire. Parfois, quand j'utilise une techno que je maîtrise peu, je les interroge aussi, comme j'interroge Google. Parfois, je leur demande une suggestion. Mais c'est toujours moi qui écris le code final. Ça prend plus de temps, mais je trouve ça plus satisfaisant et plus constructif.
Et ça, qwen3.6 sait très bien le faire.
Un LLM cloud arrivera probablement à identifier des problèmes plus "larges" que qwen3.6. Mais dans l'ensemble, qwen3.6 me suffit pour ça.
Traduction
TL;DR: Oui.
Modèle que je recommande actuellement : n'importe lequel
Une grosse partie du problème des traductions est résolue par la vectorisation et dévectorisation, en amont et en aval du LLM. Pour une traduction, un LLM a donc un travail relativement minimal de contextualisation à fournir. N'importe quel LLM arrive maintenant à faire ça de façon satisfaisante.
OCR
TL;DR: Oui.
Modèle que je recommande actuellement : n'importe lequel étiqueté vision.
Certains LLMs peuvent prendre en entrée des images (les LLMs flagués vision). Ces LLMs savent lire, et ils le font généralement bien ! :-)
Il y a même des LLMs de petites tailles spécialisés dans l'OCR.
Domotique
TL;DR: Oui.
Modèle que je recommande actuellement : ministral-3-14b-q8 (ou un ministral-3 plus petit). q8 au minimum.
Personnellement, j'utilise ministral-3-14b-q8 avec mon Home Assistant. Je trouve le résultat satisfaisant. Le LLM manque juste un peu de jugeotte (par exemple, ça ne le dérange pas de rajouter sur ma liste de course un objet qui y est déjà), mais ce n'est pas dérangeant.
À noter qu'il vaut mieux éviter les ministral-3 en q4 : ils ratent trop souvent leurs appels aux outils Home Assistant. q8 semble être un minimum.
Jeu de rôle
TL;DR: Oui
Modèle que je recommande actuellement : gemma4.
J'ai remarqué qu'ils ont quelques problèmes avec la réalité physique de notre monde :-). Mais ça n'a pas été trop gênant jusqu'à présent. Par contre, je n'ai pas encore fait de session longue, et donc je ne sais pas encore comment (et si) SillyTavern gère la limite de contexte.
Encyclopédie
TL;DR: Je déconseille.
Les LLMs cloud sont déjà assez enclins aux hallucinations et inventions, alors imaginez les LLMs auto-hébergés …
Relecture d'article LinuxFr
TL;DR: Oui, mais attention.
Ce journal a été relu, corrigé et validé par Gemma4-31b-q4 ;-)
Sauf qu'en fait, je me suis rendu compte après coup qu'il manquait des mots dans certaines de mes formulations. Ni moi, ni un ami, ni Gemma4 ne les avions repérés. C'est Claude Opus 4.7 qui les a vus. Apparemment, les LLMs sont sujets, comme nous, à un biais de complétion :-)
Trouver le matériel
La question que beaucoup se posent : comment s'équiper sans se ruiner ?
Les prix de la RAM et des GPUs ayant explosé, je n'ai pas de bonne réponse à ce problème. Juste de moins mauvaises réponses.
Les ordinateurs Apple M
Oui, bon, proposer ça sur linuxfr, je sais …
Mais il faut rendre justice à Apple : leur mémoire unifiée est parfaite pour l'inférence des LLMs. Attention tout de même à la bande passante de leurs mémoires. Pour avoir des résultats satisfaisants, il faut taper dans processeurs M Ultra ou M Max. C'est pas donné.
À noter aussi que, sur un Mac, vous serez généralement limité à faire de l'inférence. Pas d’entraînement, pas de fine-tuning. Peu de logiciels de fine-tuning supportent les macs.
Si vous voulez vous acheter une configuration complète juste pour de l'inférence, les Mac Studio M1 d'occasion ont un ratio VRAM/prix imbattable actuellement.
La solution de Dédé la bricole
Personnellement, j'ai opté pour une configuration à base de multiples cartes graphiques. Et à ma connaissance, actuellement, les cartes graphiques Nvidia les moins chères au gigaoctet sont les RTX 3060 12 Go. Si vous voulez faire du bourrage GPU dans un seul boîtier, l'option la moins chère est un vieux processeur AMD Threadripper et la carte mère qui va avec, pour avoir assez de lignes PCIe.
Voici donc une suggestion de configuration badass, façon top-of-the-line-de-2018 :
- Carte mère Taichi X399 avec 4 slots PCIe 16x : 200€ sur Ebay
- Processeur Threadripper 1950x : 100€ sur Leboncoin
- 2x 2x 16Go de DDR4 3200Mhz : 2x 150€ sur Ebay
- Alimentation 1200W : 200€ neuve (parce que vous ne voulez probablement pas d'une alim déjà rincée)
- 1To NVMe: 200€ neuf (même logique que l'alim ; je ne sais pas pour vous, mais je n'achète presque jamais de disque d'occasion)
- Cartes graphiques : 4x 250€ sur ebay
- Boîtier Cooler Master MasterFrame 600 : 200€ (attention: la plupart des autres boîtiers ATX ne peuvent accueillir que 3 cartes graphiques double-slot)
Ça fait un total de 2200€ pour 48 Go de VRAM, et le bruit peut être problématique. Voili voilou.
Ceci dit, cette configuration a surtout le mérite d'être améliorable progressivement plus tard (par exemple quand la bulle de l'IA aura enfin explosé).
Conclusion
Si vous espérez avoir un LLM moins cher que les options cloud, c'est pour le moins compliqué. Mais il y a d'autres raisons de vouloir héberger ses LLMs.
# And remember kids ...
Posté par Jérôme Flesch (site web personnel) . Évalué à 10 (+16/-4).
And remember kids …
[^] # Re: And remember kids ...
Posté par devnewton 🍺 (site web personnel) . Évalué à 9 (+7/-1).
Autre rappel pour les enfants :
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
# Cohérence sur cette histoire de coût
Posté par arnaudus . Évalué à 10 (+16/-0).
Merci pour cette contribution, c'est super intéressant et ça montre aussi qu'on peut utiliser des LLM sans accepter une dépendance à des géants du web.
Il y a quand même une incohérence à propos de cette histoire de coût.
En fait, c'est très, très, très probablement la deuxième option qui est vraie.
* Les gros acteurs du LLM perdent des milliards par semaine, donc ils sont loin de facturer le coût réel
* Les gros acteurs du LLM bénéficient forcément d'énormes effets de masse (méga-commandes, méga-bâtiments, etc).
* Les gros acteurs du LLM vont pouvoir mieux exploiter leur matériel, du fait de la distribution de leur clients (quand les japonais sont couchés c'est au tour des américains, etc)
C'est inévitable, faire tourner ces logiciels coûte cher, parce que les ressources impliquées sont sans commune mesure avec ce qu'on connaissait jusque là (streamer de la vidéo, centraliser des centaines de connexions sur un serveur de MMORPG, etc). Après, quand on voit ce qu'il fallait pour miner du bitcoin, openAI n'a pas du tout inventé le principe d'utiliser des fermes de calcul entières pour un output minuscule. Il faut donc payer d'une manière ou d'une autre, et je ne suis pas sûr du tout qu'un modèle à base de publicités soit suffisant.
Par contre, je ne sais pas si c'est complètement clair dans le texte, mais ce qui est possible d'héberger, c'est un modèle déja entrainé. L'entrainement du modèle lui-même demande des ressources qui sont hors de portée d'un particulier.
[^] # Re: Cohérence sur cette histoire de coût
Posté par Tarnyko (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 18 mai 2026 à 17:06.
En fait, je me suis fait la même réflexion : le setup d'exemple de Jérôme Flesch n'est pas une config très courante.
Avec ses 3 GPUs, c'est même plutôt une workstation dédiée à l'usage des LLMs ; pas si chère qu'attendu car il a assemblé lui-même (et il a raison !), mais clairement plus qu'une tour de joueur - qui est déjà le top pour beaucoup.
Mais en fait ce clivage où il faut de la moula pour exploiter à fond les nouvelles techs (comme le crypto-minage que tu cites), il existe depuis longtemps.
Du coup je ne vois que 3 options :
- petite config : pas le choix, utiliser/payer les APIs cloud, et laisse tomber la confidentialité quoiqu'il arrive ;
- grosse config : tu peux héberger ton propre modèle "OK tier" qui sera toujours inférieur au cloud ;
- config dédiée : seule solution pour plusieurs modèles simultanés ou un gros modèle solide te rendant indépendant.
[^] # Re: Cohérence sur cette histoire de coût
Posté par arnaudus . Évalué à 5 (+2/-0).
Il y a quand même des "sous-options".
Déja, pour la confidentialité, il faut distinguer les trucs gratuits et/ou sponsorisés, qui sont l'équivalent des cookie walls pour les sites d'information : tu payes l'accès au truc en partageant des données qui seront exploitées par le fournisseur du service. C'est quand même très différent de l'abonnement ou de la souscription professionnelle, dans laquelle tu payes la confidentialité. Et à moins de suspecter une trahison du fournisseur, dont les raisons seraient quand même assez obscures vu les enjeux, tu peux quand même imaginer que tes données sont à peu près autant protégées que le reste des services auxquels tu souscris (stockage, CPU, cloud bureautique, etc). Je ne suis pas favorable à partager une paranoïa généralisée sur la confidentialité; quand tu souscris un service qui te garantit une forme de confidentialité, rien ne prouve que cet engagement n'a aucune valeur. Évidemment, quand le fournisseur reçoit des demandes émanant d'un service étatique ou de la justice, ou quand le fournisseur se fait hacker, etc., tes données peuvent se retrouver dans la nature, mais ça n'arrive pas "naturellement".
L'option "config dédiée" reste quand même assez intéressante, puisqu'elle reste compatible avec l'esprit du libre, comme peut l'être un serveur Mastodon ou un serveur email communautaire. Ça ne veut pas dire que c'est gratuit, mais ça veut dire éventuellement que Linuxfr pourrait, si besoin était par exemple de faire tourner des LLM pour filtrer automatiquement le spam, pour corriger les fautes, pour vérifier les liens, etc., accéder à un modèle hébergé par un tiers de confiance (associatif?), sans nécessairement collaborer avec des entreprises US.
Pour revenir aux configs dédiées, on parle de machines dont le coût d'achat doit tourner autour des 20k€ (évidemment, il n'y a pas de limite haute), ce qui reste accessible pour une structure moyenne (grosse association, petite entreprise, etc).
Personne n'évoque par contre des configurations sous-optimales, mais peut-être plus accessibles, comme une grille de PC. Sur les forums, on voit trainer des perfs de l'ordre de 1 token par seconde pour un PC standard sans GPU, ce qui en effet est trop lent pour la plupart des usages, mais même avec un rendement de 10%, une grappe de 100 PC (par exemple dans un immeuble de bureaux) pourrait permettre d'accéder à 10 tokens par seconde, ce qui est apparemment suffisant pour des opérations classiques sur des textes (génération de lettres ou d'emails, relecture et correction des fautes, traduction…).
[^] # Re: Cohérence sur cette histoire de coût
Posté par Tarnyko (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 19 mai 2026 à 12:14.
Certes ; mais tu sais ce qu'on dit, une bonne offre n'attends que d'être compromise…
En parlant de confidentialités critique, genre R&D ou teneur de contrats ; ou pour un perso, l'équivalent (ce qu'il veut que personne ne sache 😶).
De mon point vue, chaque fournisseur est un "maillon faible" sur cette chaîne, quelles que soient les garanties qu'il donne.
Dans un contexte business, on paie AMHA le service mais aussi une "décharge" ; si problème, c'est la faute du fournisseur, avec des amendes croissantes selon la faute.
Quand tu es en perso, tu n'as que très peu ce levier ; tu reçois les dédommagements plancher. Tu as tous les inconvénients.
Pour ça, je trouve pertinent d'utiliser le cloud pour une entreprise ; mais un particulier devrait se discipliner.
Un genre de projet SETI (calcul partagé) mais pour les LLM ? Très intéressant, je crois que j'en ai trouvé un.
[^] # Re: Cohérence sur cette histoire de coût
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
Mais cela est donc un problème qui limite certains cas d'usage. Typiquement les professions règlementées où le secret professionnel implique que tu n'héberges pas les données des clients ou des affaires n'importe où (médical, juridique, comptabilité, autre) ou des secteurs hautement stratégiques ou critiques ce qui recouvrent pas mal d'industries.
Surtout quand ces fournisseurs sont pour l'essentiel des entreprises américaines et avec le gouvernement américain actuel et peut être à venir.
C'est un risque qu'on ne peut pas balayer d'un revers de la main d'autant qu'il y a des précédents.
[^] # Re: Cohérence sur cette histoire de coût
Posté par arnaudus . Évalué à 3 (+1/-1).
Certes, mais il n'est pas nouveau. C'est exactement le même problème que d'héberger tes données sur AWS ou tes mails chez Google ou Microsoft. Pourtant, de très nombreuses entreprises et organismes publics le font. On pourrait même penser d'ailleurs que les emails sont bien plus critiques que les prompts de LLM, puisque le rapport signal/bruit est bien plus faible avec les prompts: au mieux, les entrées et sorties des prompts vont te donner un accès très partiel, aléatoire, et pas à jour à des documents qui sont proprement rangés et identifiés dans le cloud.
Si tu devais classer les différentes pratiques d'hébergement de données en fonction du risque, je pense que l'utilisation de LLM via des abonnements pro arrive très, très loin. À mon avis, un risque beaucoup plus concret, c'est l'utilisation non contrôlée (sauvage) de LLM grand public à l'intérieur d'une organisation, puisque là il va y avoir de la diffusion de documents confidentiels dans un cadre où la réutilisation est possible. N'importe quel organisme devrait avoir l'obligation en 2026 de fournir un accès contrôlé à un LLM, puisqu'il est certain que les employés le feront de manière sauvage si cet accès contrôlé n'existe pas.
# au niveau du matos
Posté par Ecran Plat (site web personnel) . Évalué à 8 (+6/-0).
Moi, j'utilise un vieux Dell de 2018 avec un Xeon, 32 Go de RAM DDR4 et deux Nvidia Quadro P5000.
Je fais tourner des modèles jusqu'à 32B dessus, et les architectures MoE (Mixture of Experts) carburent carrément bien. Les Nemotron fonctionnent bien aussi. Sinon, Qwen 3.6 est vachement chouette… bon, par contre, il prend son temps pour réfléchir.
Mon serveur d'inférence tourne occasionnellement : ça bouffe un jus pas possible, et pour mon usage, c'est finalement moins cher (et plus rapide) de taper sur une API.
Côté matos, les NPU et GPU Intel se défendent. Ça marche bien, même si c'est un poil plus lent que chez les verts. Sur mon laptop (un HP sous Ubuntu avec un Ultra 7 Lunar Lake), je fais tourner Qwen 2.5 sur le NPU (qu'est-ce qu'il est bête celui-là, au passage) et Ministral 4 14B sur le GPU avec Ollama.
Par contre, si j'avais le budget, je n'irais pas claquer mon PEL dans une RTX *090. Je partirais plutôt sur une DGX Spark de Nvidia, ou sur son alternative moins chère avec les mêmes entrailles : une Lenovo ThinkStation PGX (128 Go de RAM unifiée avec un GB10 de Nvidia) pour le prix d'une RTX 5090.
Autre bon plan à connaître : chez OpenAI, si vous acceptez de leur donner votre trafic pour entraîner leurs modèles (le fameux "si c'est gratuit, c'est toi le produit"), ils vous filent des tokens gratuits selon votre niveau. En Tier 2 (à partir de 50$ dépensés chez eux), je reçois jusqu'à 1 million de tokens par jour sur les gros LLM et 10 millions sur les petits (attention, uniquement les modèles texte et omni). En Tier 1, c'est peau de chagrin. Ça permet de bricoler et d'expérimenter gratuitement, mais attention : on n'y envoie rien de confidentiel.
En général, je privilégie les petits LLM (qui demandent par contre d'être bien mieux promptés) et je sors l'artillerie lourde uniquement quand ça coince. J'utilise aussi OpenRouter, c'est le couteau suisse parfait pour tester pas mal de modèles.
Enfin, pitié, n'utilisez pas de LLM pour des actions déterministes. C'est un immense gâchis de ressources (et je soupçonne beaucoup de gens de le faire). J'ai pas mal d'automatisations chez moi, et j'y intègre finalement très peu d'IA : juste là où ça a vraiment du sens, comme la traduction de flux RSS ou le résumé de vidéos YouTube.
texte corrigé avec l'aide de gemini (parce que je suis une bille en français)
[^] # Re: au niveau du matos
Posté par Tarnyko (site web personnel) . Évalué à 5 (+3/-0).
Intéressant les Spark.
En résumé, pour faire un truc répétitif, tu encourages à demander à l'IA de produire un script réutilisable plutôt qu'à lui déléguer à chaque fois, c'est bien ça ?
Ça me paraît aussi une évidence, mais je soupçonne les No-Code friands de ça, et pas forcément toujours au su de leurs utilisateurs (juste une supposition).
[^] # Re: au niveau du matos
Posté par Ecran Plat (site web personnel) . Évalué à 3 (+2/-1).
Oui, c'est exactement ça : je lui demande de me générer le script, ou bien je le code moi-même.
J'ai d'ailleurs développé mon propre outil qui ressemble un peu à OpenClaw (un agent que j'ai baptisé Germain, et qui tourne sur mon VPS). En gros, je lui demande de créer un "plugin" pour effectuer une série d'opérations (en Python ou Bash). Ensuite, un déclencheur (trigger : cron, webhook, e-mail reçu…) va lancer ce plugin. Soit le LLM s'occupe de tout, soit c'est moi, mais dans tous les cas, ça tourne tout seul en arrière-plan.
Je gère aussi des tâches spécifiques où c'est le LLM qui fait tout le boulot (toujours lancées par un déclencheur), ainsi que des workflows où j'enchaîne les tâches et les plugins les uns aux autres.
Du côté des plugins, j'ai par exemple le monitoring de mon site web et de mon Proxmox à la maison. Là, pas besoin de LLM : un simple if suffit pour savoir si la machine répond ou pas. S'il y a un souci, le système m'envoie un e-mail et me notifie sur Telegram.
J'ai aussi un workflow matinal qui me prépare une sorte de bulletin d'information avec la météo locale, que je lis au petit-déjeuner. C'est une approche hybride : la collecte de données est scriptée de manière classique, mais la rédaction finale est confiée à un LLM.
Enfin, une autre tâche tourne chaque matin pour me faire un topo de mes rendez-vous du jour et du lendemain (via un accès en lecture seule à mes calendriers), ainsi que des tâches en retard ou arrivant à échéance. Pour le coup, c'est géré par un LLM qui utilise des appels d'outils (tools).
Voilà en gros comment j'organise mes automatisations !
# bc250
Posté par Benjamin Henrion (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 18 mai 2026 à 18:09.
"Ça fait un total de 2200€ pour 48 Go de VRAM"
J'ai commandé une carte bc250 a 150EUR (sans alim, sans fan), qui a 15GB de VRAM disponible:
https://bc250.info/
"Can it do AI / LLM inference?
Yes! The 16GB GDDR6 shared memory makes it decent for local AI inference. You can run smaller LLMs and other AI workloads. Set the kernel parameters ttm.pages_limit=3959290 and ttm.page_pool_size=3959290 to access the full 16GB of memory."
Une petite video:
https://www.tiktok.com/@techmakesart/video/7590782693441326367
# Merci
Posté par Luc-Skywalker . Évalué à 6 (+4/-0).
Merci pour ce REX et les commentaires associés.
Plaisant à lire et instructif.
Avec les autres journaux publiés dernièrement ici même, je retiens surtout que c'est le GPU (si possible NVidia si j'ai bien compris) qui compte.
=> Des configs musclées et chères en somme
Mais alors, à quoi peuvent bien servir les NPU vendus d'office dans les procs/configs actuelles ?
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Merci
Posté par gUI (Mastodon) . Évalué à 7 (+4/-0).
Tout dépend de ce que tu veux faire. Dans le cadre de ce journal comme du mien, on parle pas mal de générer du code. Là on est dans une utilisation complexe du LLM et oui faut du matos.
Mais sans matériel compliqué, et même en pur CPU, on peut déjà faire pas mal de chose comme résumer un texte, le corriger, le traduire… Idem pour la vision et l'OCR ça demande bcp moins de ressources.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Merci
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
en l'occurrence c'est plus: "qu'est ce que je peux faire (d’intéressant, de funky, de drôle, …) avec mon NPU" ? ;)
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Merci
Posté par Andréas Livet . Évalué à 6 (+4/-0).
J'ai expérimenté hier avec mon NPU de mon AMD AI 9 HX 370.
Ce sont des puces assez intéressantes tout de même. Tu peux arriver à faire tourner des petits LLMs avec genre du 3b/4b peut-être un peu plus mais après on atteint la limite de la bête. La sur du gemma 4 e2b (de mémoire) j'étais à 15 token/s la où je serai à 30 ou plus avec le GPU (présent sur le même SoC), mais le tout pour une fraction de l'énergie utilisé (au final c'est peut-être 4 à 5 fois plus efficient).
Donc ça peut servir à avoir un petit LLM en tâche de fond pour des trucs simples, mais je pense qu'à la base c'est plus fait pour pouvoir lancer des algos de retouche photo, peut-être OCR, des trucs comme Wisper pour faire du speech-to-text en temps réel (faudrait que j'essaie d'ailleurs), du décodage de format utilisant des deep learning des trucs comme ça.
Pour AMD, l'outil pour lancer des LLM sur le NPU s'appelle FastFlowLM : https://github.com/FastFlowLM/FastFlowLM
Voici la liste des modèles qu'il peut gérer (c'est une quantification particulière) : https://fastflowlm.com/docs/models/
Et à ce que j'ai compris, tout ce petit monde est codé avec le compilateur IRON : https://github.com/amd/IRON/ qui permet d'utiliser au mieux le NPU sans toutefois coder en assembleur (mais j'ai pas du tout mis le nez dedans pour l'instant).
[^] # Re: Merci
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
Merci bien.
Le processeur (RK3588 et 8Go de RAM) de ma machine est loin derrière !
Je viens de (re)regarder la doc du constructeur et il y a pas mal d'infos en fait: https://docs.radxa.com/en/rock5/rock5b/app-development/ai
Mais tout repose sur le BSP de Rockchip sous Linux 6.1.
Et j'utilise Linux Mainline, mais je me souviens à présent pourquoi j'attendais la v6.18: https://www.kernel.org/doc/html/v6.18/accel/rocket/index.html
L'info sur le blog du développeur: https://blog.tomeuvizoso.net/2025/07/rockchip-npu-update-6-we-are-in-mainline.html?m=1
Ça a l'air assez efficace avec de la reconnaissance d'images. Je vais chercher pour l'OCR/speak2text/traduction qui m’intéresseraient beaucoup plus.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Merci
Posté par sjub . Évalué à 3 (+3/-0).
Merci à toi pour avoir relayé mes interrogations sur les NPU et à Andréas pour son retour d'expérience !
Je trouve dommage que les CPU embarquent tout ça, pour un usage limité et un matériel qui risque de devenir obsolète rapidement. Une solution NPU à brancher sur un port M2 façon NVMe serait nettement plus souple.
Personnellement je n'en ai pas l'utilité, pas de traitement d'images, de conversion, … beaucoup de transistors inutilisés !
[^] # Re: Merci
Posté par Andréas Livet . Évalué à 3 (+1/-0). Dernière modification le 19 mai 2026 à 21:57.
Oui c'est encore tout frais ce genre de trucs. Par exemple pour mon NPU il faut Linux 7.0 pour qu'il soit intégré nativement, mais y a un module dkms qui permet de le faire tourner sur des versions plus ancienne, mais attention, pas sur des kernel ubuntu d'origine… il faut donc un kernel OEM etc. Bref, comme je disais dans un autre commentaire, on est vraiment loin du "out of the box"…
J'ai pas encore regardé autour de wisper sur NPU mais j'imagine qu'il y a des projets de ce genre, ça peut être super cool, si jamais tu trouves quelque chose je suis preneur ;).
[^] # Re: Merci
Posté par fearan . Évalué à 7 (+4/-0).
Perso j'ai une AMD (RX7900 xtx) 24Go de ram acheté avant la folie, ça tourne bien, et sur mon PC portable avant que la télé ne me crame la CG, j'avais aussi une CG qui fonctionnait bien.
L'avantage des AMD c'est que ça tourne sans devoir y foutre un blob propriétaire dont on ne sais pas combien de temps il sera maintenu.
A chaque fois j'utilise koboldcpp (windows ou linux) pour faire tourner les modèles. Sur le git de koboldcpp y'a la version cuda et la version sans cuda, la seconde est bien plus légère en Mo :D
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Merci
Posté par YBoy360 (site web personnel) . Évalué à 3 (+1/-0).
Même chose ici, et on a le choix entre vulkan ou rocm, même les cpu avec GPU intégré, (comme celui du SteamDeck) se débrouille pas trop mal.
Pour le coup, utiliser CachyOS peut s'avérer intéressant.
I use Arch BTW
[^] # Re: Merci
Posté par Luc-Skywalker . Évalué à 2 (+0/-0). Dernière modification le 19 mai 2026 à 13:36.
Merci pour vos réponses.
$ lsmod|grep rocket
rocket 28672 0
gpu_sched 45056 2 rocket,panthor
drm_shmem_helper 24576 2 rocket,panthor
La suite maintenant :)
"Si tous les cons volaient, il ferait nuit" F. Dard
# Une alternative : RamaLama
Posté par rahan . Évalué à 7 (+6/-0).
Merci pour ce tour d'horizon. De mon coté, j'utilise RamaLama. Ça ressemble à ollama mais en utilisant des containeurs podman. C'est open-source (je crois) et soutenu par Red Hat. Il s'installe facilement grâce à
pipdans unvenvpython. Il utilise parfaitement ma vielle carte AMD avec seulement 8 Go de VRAM : je n'ai rien eu à configurer, il a détecter ma carte tout seul et utilisé le containeur podman adapté. Cela propose par défaut une interface terminal, web ou par API.# précision sur llama.cpp
Posté par i M@N (site web personnel) . Évalué à 3 (+2/-0).
llama-server contient tout ce qu'il faut : moteur d'inférence, chat, api
Avec le mode routeur de llama.cpp on peut tout a fait gérer plusieurs modèles et les charger à la volée. llama-swap devient inutile sauf si on veut aussi lui faire gérer une instance pour générer des images comme stable-diffusion.cpp par exemple.
Je recommande llama.cpp car c'est l'original et son développement est phénoménal, ça me fait penser à un Linux des LLM.
Après j'ai beaucoup lu que vLLM conviendrait mieux pour la mise à l'échelle, mais comme je n'ai pas de ferme de servers juste une 3090 j'utilise llama.cpp
Un chouette journal bravo, j'encourage les anglophones à aller faire un tour sur LocalLLaMA et bien sûr huggingface.co
wind0w$ suxX, GNU/Linux roxX!
# Mode RPC de llamacpp
Posté par wataru . Évalué à 3 (+3/-0).
Bonjour,
Merci pour cet article très intéressant.
Il y a une fonctionnalité de llamacpp que je trouve très intéressante, qui est de permettre de faire de l'inférence sur plusieurs pc à la fois. On peut donc utiliser les cartes graphiques qui se trouvent dans plusieurs pc.
Du coup, on peut se permettre d'utiliser son pc gaming qui a une carte graphique nvidia avec 12 Go de vram par exemple en plus de son serveur qui a une autre carte graphique nvidia avec 12 Go de vram et llamacpp pourra faire tourner des modèles de 24Go de vram.
Ca permet de faire des économies en achat de carte mère spéciale ou alors d'aller plus loin avec 2 pc pro :)
Par contre, je ne sais pas si llamacpp permet de se connecter à plus de 1 pc distant pour utiliser sa carte graphique.
[^] # Re: Mode RPC de llamacpp
Posté par Tarnyko (site web personnel) . Évalué à 4 (+2/-0).
Intéressant ; mais n'as-tu pas des perfs abyssales après ? C'est un truc que tu as vu tourner ?
[^] # Re: Mode RPC de llamacpp
Posté par Andréas Livet . Évalué à 4 (+2/-0).
Perso j'ai fait des tests avec 2 mac mini m4 16Gb branché sur le thunderbolt 4 en pensant que ça aiderait et les perfs sont pas top.
Il faut une jonction thunderbolt 5 pour que ça fonctionne bien et c'est que sur les m4 pro…
J'avais un peu de foi dans ces techniques, mais je crois que c'est plus de la bidouille qu'autre chose, ou alors c'est bien utile pour de l'inférence à plusieurs, mais pour un seul utilisateur je pense que c'est limité.
[^] # Re: Mode RPC de llamacpp
Posté par wataru . Évalué à 1 (+1/-0).
Je l'ai fait tourner chez moi avec une nvidia 4060 Ti 16GB sur le serveur principal et une 3070 Ti 8 GB en distant par rpc avec le modèle gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf , j'ai ma réponse en 15 secondes environ sur open webui.L'ihm de llama-server indique que j'étais à une production de 51 token/s, ce qui me parait très bien.
De toute façon, sans la carte graphique distante, le modèle ne pourrait pas tourner et encore moins avec le contexte de 64k que j'ai mis.
# GPU AMD
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4 (+2/-0).
Je ne fais pas de code, je fais de l'audio. Sur ma workstation AMD (CPU 7800X3D, GPU RX7800XT). Je fais tourner ubuntu studio ollama3 et gemma27B (et aussi mistral-nemo). J'ai fait mes premiers essais sur un ancienne install et un vieux disque. J'ai rencontré pas mal de subtilités en montant de version OS et en changeant de disque, puis en réinstallant mes jouets. Par exemple ollama se lançait sur le CPU :) J'ai la flemme de faire un journal mais si quelqu'un galère sur une config similaire, on peut comparer nos configs.
PS : Dédé la bricole approuve ce journal
[^] # Re: GPU AMD
Posté par Andréas Livet . Évalué à 5 (+3/-0).
J'ai eu des grosses galère aussi sur mon proc AMD pour le faire tourner sur le GPU, il se trouve que j'avais mal installé les drivers ROCm, pour les Ryzen, il ne faut pas le mode dkms, y' a 2 méthodes d'installation dans la doc AMD, j'avais lu la mauvaise… je peux te dire que j'en ai passé du temps pour comprendre le prob…
[^] # Re: GPU AMD
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2 (+0/-0).
Ici j'ai galéré en discutant avec gemini, on a mis que 2 heures mais on a du avoir du bol.
# "L'écologie, l'économie, tout ça ?"
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Puisque tu poses la question de l'éthique dans l'usage de LLM en local (et que tu remarques, à juste titre, que les LLM opensource n'existent virtuellement pas), je me permets de relayer ce fil récent de zzt (un pote à David Gerard, qui est du genre vénère sur les réseaux sociaux) sur la question. En gros, il reproche aux modèles locaux de n'être qu'une passerelle vers les LLM cloud, car trop médiocres pour être réellement utiles :
En ce qui me concerne, je sais qu'il y a quelques années on a entraîné des modèles sur le supercalculateur Jean Zay du CNRS, donc pas un truc de multinationale (enfin un peu, le matos vient d'HP et Nvidia), mais je ne sais pas si ce genre de matos est suffisant pour ré-entraîner des modèles "locaux" pertinents aujourd'hui, ni à quel coût.
[^] # Re: "L'écologie, l'économie, tout ça ?"
Posté par Jérôme Flesch (site web personnel) . Évalué à 4 (+3/-1).
Je pense que c'est là où son avis et le mien diffèrent. Je suspecte qu'il parle de vibe-coding. Et comme je l'ai mentionné, vibe-coder avec un LLM auto-hébergé n'est pas une bonne expérience (ni avec un LLM cloud d'ailleurs). Mais il y a d'autres utilisations où un LLM auto-hébergé suffit. Ils ne seront clairement jamais aussi intelligents que les LLM cloud, mais ils sont suffisants.
Pour les LLMs réellement opensource, j'ai regardé, il y en a quelques-uns, par exemple OpenLlama. Mais ils sont clairement anecdotiques à ce stade.
Pour l’entraînement, on est d'accord.
Par curiosité, j'ai demandé à Claude si le supercalculateur Jean Zay pourrait entraîner assez facilement un modèle de 32 milliards de paramètres. Il dit que ça prendrait quelques semaines, et que c'est limite surdimensionné pour ce problème (je note d'ailleurs que "quelques semaines" est visiblement considéré comme rapide pour de l’entraînement). Par contre, il est déjà dépassé pour des modèles de la taille de Kimi K2.5 ou Claude Sonnet.
Sur un ordinateur simple, bien chargé en cartes graphiques, de ce que j'en comprends, le mieux qu'on puisse espérer entraîner from-scratch serait du 3 milliards.
# Complement d’information
Posté par BenTpe . Évalué à 3 (+3/-0).
Merci pour ce journal! Je n’ai qu’un Mac mini m4 avec 24GB de ram mais de manière surprenante oss20b (q4) accompagné de Hermes Agent tourne correctement en prenant 20GB de RAM, ce qui semble cohérent avec votre règle.
Ma question est sur le confort d’utilisation. Le Mac mini n’a que 120gb de bande passante, mais le modèle tourne a une vitesse acceptable. Je me demande si vous avez une idée sur l’utilisation d’une APU comme Halo Strix avec environ 200gb de bande passante et l’avantage d’avoir 128gb de ram à un prix abordable? Moins rapide, plus cher à upgrader, mais plus simple, plus confortable et pas un gros four :)
Sinon j’utilise Hermes Agent, et je ne comprends pas bien à quelle partie de votre description il correspond? Ça permet de lier son chat à une messagerie (Signal pour moi) et d’avoir une mémoire dans l’ordinateur, par exemple je peux passer de Codex à Oss en conservant la même conversation. Et sans doute beaucoup d’autres choses.
[^] # Re: Complement d’information
Posté par Jérôme Flesch (site web personnel) . Évalué à 3 (+1/-0).
Intéressant. Je ne connaissais pas Hermes Agent.
Dans ma description, c'est un frontend. Au même titre que opencode ou openclaw (que j'ai oublié de mentionner d'ailleurs). Il interface le LLM avec le reste du monde, et lui met à disposition des outils.
Avec une bande passante de 120Go/s, il y a deux points qui vont déterminer la vitesse du LLM:
Il faut aussi voir ce qu'on entend par "vitesse acceptable". Pour certaines utilisations, une lecture à 100 tokens/s et une génération à 3 tokens/s suffisent largement (ceux qui s'en servent dans des batchs par exemple). Pour d'autres utilisations comme la programmation agentique, ça serait totalement insuffisant.
[^] # Re: Complement d’information
Posté par Andréas Livet . Évalué à 3 (+1/-0).
J'ai pris un AMD Ryzen AI 9 HX 370 avec 64GB de ram justement pour ça (il a la même bande passante de que les Strix Halo il me semble) et franchement je suis assez déçu.
Avec 64Gb tu peux charger des modèles potentiellement plus gros, mais il vont tourner trop lentement…
J'ai fait des tests avec Qwen 3.6 27b dense et Gemma 4 31b dense et même avec le mtp (truc qui vient tout juste d'être mis en place chez llamma.cpp, quand je dis tout juste c'est hier) qui boost les perfs entre 1,4X et 2,5X, bah je suis genre à 6 tokens/s avec un contexte vierge, donc ça doit vite retomber à du 4 t/s, voir moins avec un contexte important. J'aimerai me tromper, mais j'ai fait pas mal d'essais, tester plusieurs config (Vulkan ou HIP), je me suis cassé les dents avec les problèmes de drivers ROCm, les noyaux linux, la config grub, bios etc. J'ai vraiment passé du temps pour m'assurer que tout était bon, car l'expérience actuelle n'est pas du tout "out of the box" sur une machine AMD Ryzen sous Linux.
Sur du Strix Halo t'es sans doute un peu plus rapide car le processeur est plus puissant, donc t'arrives peut-être à du 10 tokens/s, 15 grand max je dirai. Mais ça reste assez limite je trouve.
Les nouveaux modèles comme DeepSeek v4-flash qui sont un mélange d'expert de 13b sont peut-être l'avenir pour ce genre de config. Par contre, ils sont encore trop gros (154B pour v4-flash), mais ils ont plein d'optimisation sur la taille du contexte et tout, donc avec un Strix Halo et 128Gb de RAM, j'imagine que ça commence à être utilisable, pas lu de retours détaillés la dessus.
En tout cas, c'est une piste, mais ça fait quand même des machines à minimum 3000€ aujourd'hui et non upgradable (tous les modèles que je connais ont de la mémoire soudée, y a peut-être moyen d'acheter le processeur à part - jamais vu - et mettre des barettes en LPCAMM2 dessus).
Si ça se confirme qu'un modèle comme deepseek v4-flash est utilisable sur ce genre de config avec un large contexte, alors ça rendrait l'usage d'un LLM local très probable pour faire du code. Soit en "vibe codant", soit en ayant une approche plus structurée qu'on appelle "agentic engineering", j'ai de très très bon retours de collègues sur ce genre d'approche. Bon par contre, ça change de manière drastique la façon de travailler… Les retours sont que c'est plus le même boulot et que le plaisir n'y est plus…
[^] # Re: Complement d’information
Posté par BenTpe . Évalué à 1 (+1/-0).
Merci pour votre retour… mais il y a quand même pas mal de différence entre la HX370 et la Max 395, au niveau de la puce graphique 8060S est bien plus rapide, et il y a 2x plus de bande passante, le tout au détriment de la consommation.
La première est résolument une puce mobile, avec une conso bien maîtrisée et la deuxième a presque plus de sens pour un desktop comme le Framework, au moins sur le papier.
Vous faites un peu face au même problème que moi: sur le mini c'est la RAM qui coince, sur le votre la puissance graphique on dirait.
Sur du Strix Halo, Oss20b est annoncé à 40t/s, j'ai vraiment envie d'essayer haha parce que pour moi cette vitesse est acceptable. Et les gb en plus sont du luxe, mais ca permet peut-etre de faire tourner en q8 et d'avoir encore de la RAM, attractif sur le papier.
Le Framework desktop dans lequel je veux l'utiliser permet de remplacer l'APU, ça coûte un bras (le module est vendu au prix de l'ordi) mais au moins on peut garder les autres pièces et le chassis.
Je pense que je vais tester tout ça et faire un retour. Hermes Agent a la possibilité de faire des recherches sur internet, c'est ce qui me manquait jusqu'ici pour utiliser les modèles locaux pour autre chose que du code.
Quant à changer la manière de travailler c'est sûr! Mais je ne suis pas codeur, je vibe code mes modules au boulot parce que je n'aurais jamais le temps ni la capacité de faire autrement, et j'apprends le code en partant de rien dans mes loisirs parce que je trouve ça fascinant. Comme je le fais sérieusement ma fille de 9 ans commence à s'y intéresser aussi lol.
[^] # Re: Complement d’information
Posté par Andréas Livet . Évalué à 2 (+1/-1).
C'est carrément acceptable, sur ma machine, j'ai une bonne vitesse aussi sur du gemma4 26b, vu que c'est des mélanges d'experts (comme oss-20B il me semble) c'est assez rapide (chez moi on est plus autour des 20t/s si je me rappelle bien). Mais bon pour faire du code en mode agentic c'est très limite en terme de qualité.
Le LLM se perd rapidement, ne suit pas des prompts simple genre "met à jour la documentation avec ce qu'on s'est dit", c'est juste un résumé à faire et sauvegarder un fichier, bah une fois sur deux il va se perdre en route, même avec un contexte pas trop gros.
Par contre, c'est pas mal avec OpenWebUi, pour faire du RAG et du chatbot "classique" (poser des questions, creuser des sujets, bien sûr c'est pas très "fiable" mais sur des explications de choses très connues, ça fonctionne bien je pense), de l'analyse d'image etc.
[^] # Re: Complement d’information
Posté par Luc-Skywalker . Évalué à 4 (+2/-0).
pas de doutes, je suis au niveau -1 sur l'échelle de gUi
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Complement d’information
Posté par Faya . Évalué à 2 (+0/-0).
L'échelle de gUI est trompeuse parce qu'elle met 'LLM local' au niveau 1 avant l'utilisation des agents fournis 'batteries included' genre codex, gemini, claude code… Alors que la vraie complexité est dans les LLM locaux. J'aime bien son échelle mais j'aurais réorganisé ça.
[^] # Re: Complement d’information
Posté par gUI (Mastodon) . Évalué à 3 (+0/-0).
Oui clairement on peut réorganiser 2 ou 3 trucs. Je l'ai écris comme je l'ai vécu, mais c'était en tâtonnant donc pas forcément optimal.
Mais en tous cas il m'a clairement manqué cette information de "progression" pour qui "veut se mettre à l'IA".
On peut préparer une dépêche collective si vous voulez.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Plusieurs cartes en SLI ?
Posté par Andréas Livet . Évalué à 3 (+1/-0).
Merci pour ce journal, franchement je me tâtais à faire un retour de ce genre en journal et en l'espace de 2 jours on a eu 2 journaux sur ce sujet donc pas besoin d'en faire un troisième.
Je me questionne sur les 3 cartes graphiques que tu as sur ta machine. J'imagine que c'est du SLI ? De ce que j'ai compris le gain de perf est pas si important que ça, certes on a plus de VRAM, mais la machine n'arrive pas à faire les calculs plus rapidement, voir peut-être l'inverse non ?
De plus, ça fait 3 cartes graphiques à alimenter donc ça doit consommer un max non ?
En tout cas c'est clairement pas évident d'auto héberger des "gros" LLM aujourd'hui. Peut-être que ça ne le sera jamais ? Vu les perspectives de production de RAM etc sur les années à venir, on risque d'attendre un peu pour avoir des machines avec plein de VRAM ou de mémoire partagée rapide pour pas cher…
J'ai parfois l'impression de perdre mon temps (et mon argent) avec toutes ces expérimentations…
[^] # Re: Plusieurs cartes en SLI ?
Posté par Jérôme Flesch (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 19 mai 2026 à 16:08.
De ce que j'en comprends, SLI et Crossfire ont été abandonné. Les jeux n'exploitent plus qu'une seule carte vidéo.
Pour le gain de perf, d'après ce que je comprends, ça dépend de ton moteur d'inférence.
llama.cpp est bête et méchant: il met les N premières couches du réseau de neurones sur une carte graphique, les N couches suivantes sur une autre carte graphique, etc. Et pour chaque token, il interroge chaque carte graphique, les unes après les autres. Du coup, il y a un gain de perf que lorsqu'il y a plusieurs requêtes en parallèle. Mais sinon, il y a même un peu de perte de vitesse à cause du temps perdu à passer par le bus PCIe et le CPU entre chaque carte.
vLLM, lui distribue ça plus intelligemment : chaque couche est répartie entre les cartes graphiques --> toutes les cartes travaillent en parallèle et s'échangent, à chaque sortie de couche, une partie de leur résultat. Ça sollicite plus intensément le bus PCIe et le CPU, mais augmenter le nombre de GPU augmente les performances. Par contre, pour cette raison, vLLM est plus exigeant et préfère des cartes graphiques identiques. C'est pour ça que je n'ai pas pu l'utiliser efficacement sur mon montage.
La conso, ça dépend. Comme llama.cpp ne parallélise pas le calcul, tu n'as qu'une carte vraiment active à la fois. Je n'ai pas pu tester avec vLLM.
[^] # Re: Plusieurs cartes en SLI ?
Posté par Andréas Livet . Évalué à 3 (+1/-0).
Merci pour les précisions :)
[^] # Re: Plusieurs cartes en SLI ?
Posté par YBoy360 (site web personnel) . Évalué à 3 (+1/-0).
Tu as Phoronix qui a benchmarké des R9700 en SLI :
AMD Radeon AI PRO R9700 Linux Performance For Single & Dual GPU Benchmarks
N.B. : C'était en décembre 2025, ROCm et Vulkan on beaucoup évolué (et vLLM). Utiliser une rolling distrib est plutôt judicieux pour ce cas d'usage. Y en a une très populaire depuis peu qui est vraiment efficace (voir sur distrowatch)…
I use Arch BTW
# De l'entrisme ?
Posté par David Thenon (site web personnel) . Évalué à 2 (+3/-1).
Franchement je rejette de toute mon âme les LLM et tout ce qui en découle, mais comme le dev c'est mon boulot j'ai quand même essayé de tâter le terrain en local, pour moi c'est à peu près la seule façon de m'y mettre, mais c'est au dessus de mes moyens.
En fait j'ai aucune machine chez moi qui a un vrai GPU et donc zéro VRAM réellement disponible, alors en voyant qu'avec Llama il y avait des modèles de faibles contexte capables de tourner seulement avec un CPU je m'y suis essayé.
L'installation a pas été un soucis mais au final l'opération a échoué pour une raison obscure et du coup j'ai tout viré par impatience sans vraiment creuser.
Quoiqu'il en soit en lisant les commentaires ici je me dis qu'utiliser du LLM en local ça tient un peu de l'entrisme puisque c'est voué à un usage assez restreint par rapport à ce qui inonde le secteur, alors au mieux on va commencer dessus et puis passer rapidement aux plateformes en lignes.
[^] # Re: De l'entrisme ?
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
Peux tu préciser ta notion de "l'entrisme": je ne comprends pas si c'est l'acte d'un infâme social traitre ou d'un révolutionnaire radical ;)
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: De l'entrisme ?
Posté par David Thenon (site web personnel) . Évalué à 4 (+4/-0).
Un infâme révolutionnaire social bien radical !
Non en vrai je ne suis pas certain du terme à employer, c'est ce qui m'est venu à l'esprit en essayant de le formaliser.
Ce que je remarque c'est que c'est une solution technique qu'on remonte souvent mais au final ça peut pas couvrir les capacités qu'on peut attendre des LLM actuellement par rapport à tout ce qu'on voit en usage courant.
Dans le même principe un peu, je vois beaucoup d'articles ici et là dont l'auteur dit qu'il n'est pas trop fan des LLM mais au final produit un tutorial complet pour s'y mettre. Il y a aussi souvent l'expression "l'ia n'est qu'un outil" mais en pratique au final on a dépassé le côté technique, ce n'est plus seulement un outil à mon avis c'est devenu bien plus par tout ce qu'il change dans le monde.
[^] # Re: De l'entrisme ?
Posté par Jérôme Flesch (site web personnel) . Évalué à 3 (+1/-0).
C'est une remarque intéressante. Ceci dit, pour ma part, j'ai l'impression que c'est plutôt l'inverse. Je pense que l'entrisme est plutôt du coté des LLMs cloud.
Les LLMs cloud sont nettement plus accessibles et faciles à utiliser que les LLMs auto-hébergés. Le prix d'entrée des LLMs cloud est nettement plus bas aussi. Les LLMs auto-hébergés sont, eux, très difficiles à mettre en place de façon viable. D'ailleurs, je viens d'acheter deux cartes Intel Arc Pro B60, et j'ai encore envie d'hurler tellement elles sont ridiculement difficiles à utiliser pour faire tourner des LLMs.
Mais comme mentionné, les LLMs cloud ont des limitations tarifaires. Je pense que c'est surtout ces limitations qui vont pousser les gens qui ont une utilisation plus intense des LLMs vers les LLMs auto-hébergés. Je suppose que la plupart feront alors, comme moi, un mix des deux : LLMs auto-hebergés pour ce qu'ils savent faire, et occasionnellement LLMs cloud pour les tâches qui demandent un peu plus d'intelligence ou de fiabilité.
# Merci
Posté par Guillaume Denry (site web personnel) . Évalué à 7 (+5/-0).
Salut Jérôme,
Merci pour ce post détaillé, moi qui regarde encore l'IA agentique de loin, j'ai appris des tas de trucs.
# Retour d'expérience sur une config bon marché.
Posté par ilhooq . Évalué à 0 (+1/-1).
Avec un processeur Ryzen 5 8600G intégrant un Radeon 760M (183 € en 2025) + 64Go de DDR5 dont 16Go dédiés au GPU (180 euros avant la flambé des prix), je fais tourner sans problème des LLMs tels que GPT-OSS, Gemma3 ou Ministral3-14b en utilisant llama-server avec le backend Vulkan et llama-swap.
Je m'en sers régulièrement comme assistants de code pour des tâches simples ou pour m'aider dans l'administration système et, contrairement à ce que j'ai lu dans les commentaires, je trouve ces petits LLMs locaux assez efficaces.
Je suppose que toute personne possédant un processeur moderne (amd ou intel) intégrant un GPU et au moins 32G de DDR4 ou 5 pourrait en faire de même sans investir dans une CG onéreuse.
# Jeu de rôle?
Posté par jean_clume . Évalué à 2 (+1/-0).
Que veux tu dire par l'usage jeux de rôle? Écrire des scénarios imaginaires?
[^] # Re: Jeu de rôle?
Posté par Jérôme Flesch (site web personnel) . Évalué à 3 (+1/-0).
Ça serait plutôt l'écriture de nouvelles ça.
Pour le jeu de rôle, il s'agit de demander au LLM de soit jouer le rôle du Maître du Jeu, soit le rôle d'un autre personnage, soit les deux.
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.