Journal Auto-héberger ses IA

Sommaire

• Introduction
• Quelques définitions
• Pourquoi auto-héberger ?
  • Le respect de votre vie privée
  • Le coût des API cloud
  • Les abonnements cloud
  • Accès à des modèles spécialisés
  • L'écologie, l'économie, tout ça ?
• Open-source et open-weight
• Comment faire ?
  • Pourquoi la carte graphique est super duper importante ?
  • Choisir son matériel
  • Choisir le moteur d'inférence
    • llama.cpp
    • Ollama
    • llama-server et llama-swap
    • vllm
    • Ma recommandation
    • Docker ?
  • Choisir son modèle
    • La taille du modèle
    • La taille du contexte
    • La vitesse du modèle
      • Modèles pensants
      • Modèles denses ou mélanges d'experts (MoE)
    • Autre caractéristiques
      • Les modèles instruct
      • Support des outils
    • La spécialisation du modèle
  • Choisir son front-end
  • Les all-in-one
• L'importance de la vitesse d’exécution
• Exemple: configuration de llama-swap
  • CUDA et Nvidia Container Toolkit
  • Dockerfile
  • docker-compose.yml
  • config.yaml
  • Ça rentre ?
• Utilisations concrètes et limites
  • Vibe-coding
  • Relecture de code
  • Traduction
  • OCR
  • Domotique
  • Jeu de rôle
  • Encyclopédie
  • Relecture d'article LinuxFr
• Trouver le matériel
  • Les ordinateurs Apple M
  • La solution de Dédé la bricole
• 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:

• CUDA
• Nvidia Container Toolkit

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.