Forum général.hors-sujets Quelqu'un a testé un ai porn chat sous Linux ?

Posté par  . Licence CC By‑SA.
Étiquettes :
-10
13
mai
2026

Bonjour! Je cherche a faire tourner un ai porn chat en local sur ma machine et franchement c'est un peu le bordel pour trouver des infos claires. J'suis sur Arch (oui je sais, "btw") et j'ai déjà installé des trucs comme ollama pour les LLM classiques, sa tourne nickel pour du texte normal, mais dès que je veux quelque chose d'un peu plus spécialisé genre un ai porn chat avec des modèles finetunés, je sais plus trop ou chercher.
Le truc c'est que j'ai regardé des repo GitHub y'a genre deux semaines, j'ai vu passer des forks de SillyTavern et des trucs basés sur llama.cpp avec des modèles GGUF qui auraient l'air de marcher pour ça. Mais les instructions d'install c'est souvent du "ça marche chez moi" sans vraiment détailler les dépendances, et moi j'ai une RX 6700 XT du coup ROCm c'est toujours un peu la loterie sous Linux, je suis pas sur que mes drivers vont pas foutre tout en l'air. J'ai essayé un premier truc la semaine dernière, j'ai réussi a lancer un backend mais l'inférence était tellement lente que ça servait a rien (genre 3 tokens par seconde, abusé). Du coup j'ai stoppé. Quelqu'un ici a réussi a monter un stack propre pour ce genre d'usage en local, avec un GPU AMD ? Et est-ce que SillyTavern c'est vraiment le front le plus utilisé pour ça ou y'a des alternatives qui demandent moins de config ? Perso j'ai pas envie de passer par des services en ligne, le but c'est justement tout en local. Si quelqu'un a un guide ou même juste les grandes étapes qui marchent, je suis preneur.

  • # humm

    Posté par  . Évalué à 3 (+1/-1).

    Je ne comprends pas bien, il me semble que ce qui va permettre d'avoir un tel contenu c'est un modèle adapté, quel modèle utilise tu?

    Perso j'ai trouvé que le plus simple pour faire tourner un modèle c'est koboldcpp, prendre la version sans cuda. Par contre j'aivais remarqué que selon les modèles ça passait nickel, et d'autres étaient atrocement lents.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Auto-hébergement de LLM

    Posté par  (site web personnel) . Évalué à 10 (+12/-1). Dernière modification le 13 mai 2026 à 13:22.

    Sommaire

    Je vais mettre de coté de le coté porn pour me concentrer sur l'auto-hébergement de LLM et SillyTavern. Après, chacun est libre de faire ce qu'il veut, hein ;-)

    TL;DR: avec 12Go de VRAM, ça risque d'être chaud.

    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.

    La VRAM

    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 VRAM va déterminer la taille du LLM que tu peux utiliser. Si tu tentes de charger un LLM trop gros pour ta VRAM, la plupart des outils comme llama.cpp, ollama, etc vont le faire déborder sur le CPU et la RAM. Ça va marcher, mais les performances vont s'effondrer très rapidement (ce que tu as observé).

    Les moteurs d'inférence

    Ollama, llama.cpp, llama-server, etc, sont des moteurs d'inférences.

    J'ai longtemps utilisé Ollama (qui utilise llama.cpp), 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.

    Actuellement, je recommanderais plutôt llama-swap (qui intègre llama-server, qui utilise llama.cpp).

    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, ça complexifie plus que ça 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 dont il a besoin.

    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 les plus fréquentes sont:
    - le nombre de paramètres
    - la quantification
    - dense ou mixture-of-experts

    Le nombre de paramètres est actuellement en milliards pour les modèles self-hosted (les modèles cloud tapent les trilliards). Ç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 self-hosted, 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 c'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 performance, on doit déterminer dès le départ la taille maximum du contexte.

    Cette taille est exprimée en tokens. Un token, c'est un mot, ou une syllabe, ou un symbole. Pour simplifier à mort, on peut considérer que c'est le nombre de mots.

    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 met 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 supporte. Bientôt devrait aussi arriver une nouvelle optimisation, "TurboQuant".

    Un grand contexte est particulièrement nécessaire en programmation agentic (opencode, etc): il faut au moins un contexte de 64K, si pas 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 role-play avec SillyTavern.

    À 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.

    Attention aux débordements ! L'effet sur les performances est sournois: si 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.

    Du coup, avec 12Go de VRAM ?

    Avec une carte graphique de 12Gb, tu peux déjà oublier fp16 et q8. Tu as des petits modèles qui rentrerait à cette quantification (du 3b et 7b par exemple), mais tu n'en tireras rien de bon. Donc ça sera forcément q4 pour toi.

    Tu peux oublier l'idée de la programmation agentic: il faut des LLM d'au moins 27b, avec un gros contexte.

    Pour le role-play avec SillyTavern, à essayer. Mais je ne pense pas que les petits modèles (≤14b) te donneront satisfaction.

    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.

    Dense ou Mixture-of-Expert

    Au début, il n'y avait des LLMs denses: quand on leur envoi une requête, une grande partie du réseau de neuronnes est utilisée. Puis sont arrivés les MoE (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 entre-croisés, donc ils sont potentiellement plus bêtes.

    Exemple:
    - qwen-27b est dense
    - qwen-35b-a3b est un MoE, avec max 3 milliards de paramètres actifs simultanément uniquement (autrement dit, des experts de 3 milliards de paramètres)

    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:
    - mistral-3 est un généraliste, mais qui sait suivre des instructions et utiliser des outils (mon préféré ;)
    - qwen3-coder est spécialisé programmation
    - qwen3.6 .. je ne suis pas sûr, mais il se débrouille très très bien en code. C'est probablement le meilleur à l'heure actuelle.

    Exemple de configuration llama-swap

    docker-compose.yml

    services:
  llama.cpp:
    build: .
    restart: "always"
    runtime: nvidia
    privileged: true
    ports:
      - "8123:8080"
    volumes:
      - /data/llama.cpp/models:/models
      - /data/stable-diffusion.cpp/models:/models-sd
      - ./config.yaml:/app/config.yaml:ro
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]

    config.yaml

    models:
  Gemma4-q4-uncensored:
    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-uncensored-Q4_K_M.gguf
  Gemma4-q4:
    cmd: >
      llama-server --port ${PORT} --jinja
      --ctx-size 131072 --flash-attn auto
      --model /models/gemma4/gemma-4-31B-it-UD-Q4_K_XL.gguf
      --mmproj /models/gemma4/mmproj-BF16.gguf

    Où choper les modèles ?

    Ollama a très bien streamliné la récupération des modèles. Mais comme dit, je déconseille Ollama actuellement. En plus, le dépot sur ollama.com n'a finalement que peu de modèles, et la recherche de modèle non-cloud est devenue pénible.

    Le gros des modèles est sur huggingface (cocorico!). Personnellement, je suis un peu fâché avec la recherche sur huggingface. Donc j'utilise plutôt un mélange de recherche sur ollama.com puis de recherche Google. Par exemple: huggingface gguf gemma-4 uncensored

    Et SillyTavern dans tout ça ?

    Pour du role-play, c'est effectivement le seul frontend opensource que je connaisse.
    J'ai commencé à jouer un peu avec récemment. Gemma4-31b et Gemma4-26b-a4b m'ont donné des résultats satisfaisant.

    • [^] # Re: Auto-hébergement de LLM

      Posté par  (site web personnel) . Évalué à 5 (+4/-1). Dernière modification le 13 mai 2026 à 13:33.

      Typo: je voulais parler de ministral-3 et non de mistral-3.

      D'ailleurs, pour du role-play, je pense que tu peux commencer par essayer ministral-3-14b-q4. Au doigt mouillé, ça rentrera peut-être sur ton GPU.

      Ah oui, aussi, pour savoir si ça rentre: sur l'interface web de llama-swap, tu peux filter les logs de l'"upstream" (llama-server) sur "GPU". Si toutes les layers sont sur le GPU, tu as gagné.

    • [^] # Re: Auto-hébergement de LLM

      Posté par  (site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 13 mai 2026 à 15:18.

      Ah et zut, pour le docker-compose.yml, j'ai oublié que j'avais customisé mon llama-swap. Du coup, le même, sans ma customisation:

      services:
  llama.cpp:
    image: ghcr.io/mostlygeek/llama-swap:cuda
    restart: "always"
    runtime: nvidia
    ports:
      - "8123:8080"
    volumes:
      - /data/llama.cpp/models:/models
      - ./config.yaml:/app/config.yaml:ro
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]

    • [^] # Re: Auto-hébergement de LLM

      Posté par  . Évalué à 10 (+8/-0).

      Ce commentaire est beaucoup trop intéressant pour être perdu sur une question de forum !

    • [^] # Re: Auto-hébergement de LLM

      Posté par  (Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 13 mai 2026 à 17:04.

      Je ne sais que utiliser ollama (c'est tellement simple en plus…) mais maintenant je voudrais jouer un peu avec des modèles "fine tunés" de Hugging Faces.

      Tu conseilles quoi comme local app ?

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Auto-hébergement de LLM

      Posté par  . Évalué à 6 (+4/-0).

      Le peuple réclame une dépèche !!!
      (merci au passage)

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.