Faire du roleplay avec une IA entièrement en local — LLM, images et voix

En 2026, le roleplay avec une IA locale ne signifie plus forcément :

Ouvrir un terminal, installer 48 paquets Python, casser CUDA, pleurer, réinstaller Windows.

Bon. Parfois, ça signifie encore ça.

Mais on peut désormais assembler un système qui fonctionne entièrement sur son ordinateur :

Le personnage pense en local → répond en local → génère l'image de la scène en local → parle avec une voix locale.

Une fois les modèles téléchargés, pas besoin d'internet. Aucune API cloud. Les composants communiquent tout de même par des API locales sur ton ordinateur.

Pas de facturation au token. Pas de quota de messages. Pas d'envoi de ton historique à un serveur extérieur.

Et surtout, les différents éléments peuvent déjà produire une expérience qui ne ressemble pas à une démo technique destinée aux gens qui aiment regarder l'utilisation de la VRAM.

Voici un ensemble pratique de quatre composants : LLM → interface → génération d'images → TTS. Voyons aussi ce qui est raisonnable avec 6, 8, 12 ou 16+ Go de VRAM.

Qu'est-ce qu'on construit exactement ?

Si tu veux d’abord voir le jeu autour de ce setup, l’aperçu du roleplay IA dans Multiic montre comment s’articulent cartes de personnage, scènes de groupe, mémoire et images.

Un personnage IA local ressemble, en simplifiant, à ceci :

                 ┌─────────────────┐
Ton message →   │       LLM       │
                 │ KoboldCpp/GGUF  │
                 └────────┬────────┘
                          │
                  Réponse du personnage
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
         Interface      ComfyUI        TTS
                         Image        Voix
             │            │            │
             └────────────┴────────────┘
                          │
                        Scène

Un point essentiel : ce n'est pas un seul immense modèle d'IA. Plusieurs modèles spécialisés sont généralement plus pratiques.

Le LLM s'occupe de :

• Dialogues.
• Personnalité.
• Mémoire.
• Logique de la scène.

Le modèle d'images s'occupe de :

• Apparence du personnage.
• Pose.
• Décor.
• Éclairage.
• Caméra.

Le TTS s'occupe de :

• Voix.
• Intonation.
• Émotion.
• Prononciation.

L'interface relie tout cela. Cette modularité fait l'intérêt du système local. La voix ne te plaît pas ? Change de TTS. Le style visuel ne convient pas ? Change de checkpoint.

Tu trouves un nouveau modèle RP sur Hugging Face à trois heures du matin ? Charge un autre GGUF.

Dix minutes plus tard, tu te persuades encore que télécharger un modèle de 9 Go constitue une recherche scientifique.

La configuration que je recommande

Pour commencer par la réponse courte :

Ces programmes précis ne sont pas obligatoires. C'est simplement un bon point de départ.

Partie 1. Un LLM local

Commençons par le cerveau.

Les modèles au format GGUF sont pratiques pour le RP local. Avec un moteur compatible, ils peuvent fonctionner :

• Entièrement sur GPU.
• Partiellement sur GPU.
• Avec une partie des poids en RAM.
• Entièrement sur CPU, si tu as la patience d'un moine.

Sous Windows, KoboldCpp est une solution simple.

KoboldCpp

KoboldCpp est passé d'un simple lanceur llama.cpp à un outil assez monstrueux. Un exécutable autonome fait tourner les GGUF compatibles sur CPU/GPU avec déchargement GPU total ou partiel, et expose la génération par une API. Le projet prend aussi en charge les images, la reconnaissance vocale, le TTS et plusieurs API compatibles.

Sous Windows, en gros :

1. Télécharger koboldcpp.exe.
2. Télécharger un modèle .gguf.
3. Choisir le modèle.
4. Régler la taille du contexte.
5. Activer CUDA pour un GPU NVIDIA compatible.
6. Lancer.

Pas d'installation Python séparée, de conda ni de sacrifices rituels à requirements.txt. Voilà pourquoi je le recommande aux gens qui veulent jouer, plutôt que décrocher un deuxième diplôme en gestion des dépendances.

KoboldCpp propose aussi une API compatible OpenAI sous /v1. L'interface n'a donc pas forcément besoin de savoir qu'un modèle local travaille derrière. Adresse typique :

http://127.0.0.1:5001

L'interface y envoie un prompt et reçoit du texte.

Quel LLM choisir ?

J'ai un guide consacré aux modèles locaux pour le RP, donc faisons court.

6 Go de VRAM

Stheno 8B Q4 pour le RP en anglais. Ou une quantification plus petite de Qwen3.5-9B si l'intelligence et le multilinguisme comptent davantage.

8 Go

Qwen3.5-9B Q4 comme option polyvalente.

Pour le russe : Saiga Nemo 12B Q4_K_M. Le fichier seul pèse environ 7,5 Go : prévois un contexte réduit ou une exécution partielle sur CPU.

12 Go

Mon favori pour le russe : Saiga Nemo 12B Q5/Q6.

Pour l'anglais : Rocinante-X / Impish Bloodmoon / d'autres bons ajustements RP de Nemo.

16 Go et plus

Tu peux envisager les modèles 20–30B et MoE : Gemory 26B-A4B, Gemma 4 et des Qwen plus grands.

La quantification et la taille totale des poids restent importantes. Pour un MoE, le nombre de paramètres actifs ne donne pas la mémoire nécessaire à l'ensemble des poids.

Quelle taille de contexte ?

Ne choisis pas automatiquement le maximum indiqué sur la page du modèle. Un modèle compatible 128k ne signifie pas :

Parfait, je vais mettre 128000.

Le contexte consomme de la mémoire via le cache KV. Pour du RP habituel, je commencerais autour de :

8192–16384

Puis j'augmenterais seulement si nécessaire. Un contexte utilisable de 16k vaut souvent mieux que 128k qui repoussent la moitié du modèle en RAM et lui donnent la vitesse d'une tortue contemplative.

Le CPU n'est pas une défaite

Il existe cette idée étrange :

Le modèle doit tenir entièrement sur le GPU.

Pas forcément. KoboldCpp peut laisser certaines couches en RAM et les calculer sur CPU. C'est plus lent, mais le RP n'exige pas 100 tokens/s.

8–20 tokens/s peuvent déjà être agréables, surtout avec le streaming. Le texte apparaît progressivement pendant que la suite se génère. Pour démarrer la voix de la même manière, il faut une intégration TTS compatible avec la synthèse progressive.

Partie 2. L'interface

Un LLM seul ne gère pas :

• Fiches de personnages.
• Relations.
• Mémoire persistante.
• Apparence.
• Images.
• Voix.
• Monde.

C'est généralement le rôle de l'interface. Deux possibilités :

• SillyTavern : si tu veux assembler toi-même les composants.
• Multiic : pour réunir texte, images, personnages, voix et bac à sable dans un système.

SillyTavern

SillyTavern est devenu une interface de référence pour les conversations locales avec des personnages. Il propose :

• Fiches de personnages.
• Conversations de groupe.
• Lorebooks.
• Personas.
• Fonctions de mémoire.
• TTS.
• Génération d'images.
• Connexion à KoboldCpp.
• Connexions API.

Sa documentation décrit KoboldCpp comme une API autonome pour GGML/GGUF, avec un démarrage rapide NVIDIA. Si ton but est :

Discuter avec un personnage et assembler moi-même tout le système.

C'est une bonne option.

Multiic

Multiic prend une autre direction : LLM + images + voix + personnages + état de la scène + bac à sable. Le LLM répond au sein d'une scène visuelle.

Tu peux utiliser :

• Des modèles GGUF locaux.
• Des API externes.
• Un moteur d'images local.
• ComfyUI.
• Un TTS local.

L'avantage apparaît lorsque plusieurs modalités travaillent ensemble. Exemple :

Joueur :
Je vais à la fenêtre et demande à Dina ce qu'elle a vu.

↓

LLM :
Génère la réaction de Dina.

↓

Mise en scène :
Détermine position, expression et caméra.

↓

ComfyUI :
Génère la scène.

↓

TTS :
Prononce la réplique.

L'expérience commence alors à ressembler à un visual novel sans fin plutôt qu'à un chatbot.

Partie 3. Générer des images en local

La couche suivante, ce sont les images. Pour adapter précisément la génération à tes personnages et scènes, je choisirais ComfyUI. Pas parce que son interface est particulièrement accueillante.

Elle ressemble au schéma électrique d'un réacteur nucléaire branché accidentellement à un générateur de filles d'anime.

Mais elle est extrêmement flexible. Il faut apprendre à utiliser cette souplesse : comprendre les nœuds, choisir des modèles compatibles, construire ou configurer un workflow. Cela prend du temps.

Pour démarrer vite et générer directement des images dans le jeu, KoboldCpp est plus simple. Il génère des images et est déjà intégré à Multiic : pas besoin d'apprendre ComfyUI ni d'assembler un graphe de nœuds pour commencer. Il faut tout de même télécharger et choisir un modèle d'images compatible.

Je commencerais avec KoboldCpp, puis passerais à ComfyUI pour davantage de contrôle : LoRA personnelles, références de personnages, poses et workflows complexes.

Pourquoi ComfyUI ?

Au lieu d'une chaîne fixe :

Prompt → image

Tu construis un workflow :

Prompt
  ↓
Référence du personnage
  ↓
Pose
  ↓
Checkpoint
  ↓
LoRA
  ↓
ControlNet
  ↓
Échantillonneur
  ↓
Retouche du visage
  ↓
Agrandissement
  ↓
Image

L'interface peut lui envoyer les données automatiquement. Tu construis le workflow une fois, puis le jeu change :

• Prompt.
• Personnage.
• Seed.
• Référence.
• Pose.
• Vêtements.
• Décor.

Quel modèle d'images utiliser ?

Tout évolue encore plus vite ici que pour les LLM. En 2026, on peut distinguer quelques grandes familles.

Le bon vieux SD1.5

Avantages :

• Léger.
• Immense écosystème de LoRA.
• Entraînement de personnages relativement accessible.
• Génération rapide.
• Utilisable sur des GPU modestes.

Inconvénients :

• Anatomie moins fiable.
• Compréhension moindre des prompts complexes.
• Résolution et composition en retrait des modèles récents.

Avec 4–6 Go de mémoire GPU, SD1.5 peut rester intéressant, surtout si tu possèdes déjà de bonnes LoRA de personnages.

SDXL

SDXL est aussi devenu un classique, mais reste pratique pour le RP local. Avantages :

• Nombreux checkpoints.
• Nombreuses LoRA.
• Exigences relativement modérées.
• Bon équilibre vitesse/qualité.
• Outils pour garder un personnage reconnaissable.

Avec 8 Go, c'est une option accessible selon le workflow et les autres modèles chargés.

FLUX

FLUX comprend mieux les prompts en langage courant. Il est plus facile de dire :

Une fille près de la fenêtre regarde la caméra par-dessus son épaule. Sa main gauche touche la vitre, une ville au crépuscule apparaît dehors.

Que d'assembler :

1girl, window, looking_back, hand_on_window,
night_city, masterpiece, best_quality...

Certaines variantes récentes sont plus légères. Le guide officiel ComfyUI pour FLUX.2 Klein 4B indique environ 8,4 Go de VRAM pour la version distillée sur la RTX 5090 testée, et vise les workflows interactifs rapides.

Pour le RP, cette direction est intéressante : la rapidité compte davantage qu'une image parfaite en deux minutes.

Qwen Image et les modèles guidés par instructions

Autre tendance : les modèles comprennent mieux les phrases normales, les références et les demandes de retouche. C'est plus pratique pour les jeux que les anciens prompts à tags. Le LLM peut écrire :

Fiona est assise de côté sur un canapé usé, regardant le joueur d'un air agacé. Lumière chaude de la cuisine, plan moyen, caméra à hauteur des yeux.

Puis l'envoyer au modèle d'images. Le LLM devient aussi un petit metteur en scène. C'est ainsi que je construirais l'intégration aujourd'hui.

La cohérence du personnage

C'est là que commence la vraie difficulté. Dessiner une jolie fille est facile. Dessiner la même fille vingt fois l'est moins. Quelques solutions :

LoRA de personnage

Une méthode éprouvée : entraîner une LoRA du personnage et l'ajouter au workflow. Avantages :

• Aide à conserver l'identité.
• Petit fichier.
• Rapide à utiliser.

Inconvénient :

• Une LoRA à entraîner pour chaque personnage.

Adaptateurs de référence

Davantage de workflows et de modèles acceptent une ou plusieurs images de référence. Pratique pour les personnages créés par les utilisateurs : enregistrer des portraits et les réutiliser dans les scènes suivantes.

Retouche d'images

Encore plus intéressant : modifier une image existante plutôt que tout régénérer. Exemple :

Image originale:
Dina est assise sur un canapé.

Nouvelle scène:
Make her stand up and look toward the door.

À long terme, cela pourrait être l'approche la plus pratique pour les visual novels IA. Elle peut aider à conserver :

• La personne.
• Les vêtements.
• La pièce.
• L'éclairage.

Partie 4. Une voix locale

Les progrès ont été importants ces deux dernières années. Autrefois, le TTS local signifiait souvent :

Techniquement, c'est de la parole humaine.

Aujourd'hui, certains modèles conviennent aux jeux. Je les répartirais en trois groupes.

Option 1 : Supertonic 3 — la vitesse

Pour un TTS local très rapide, Supertonic 3 reste intéressant. Il utilise ONNX et vise l'inférence rapide sur l'appareil. Supertonic 3 est sorti en avril 2026 avec 31 langues, une lecture plus précise et moins de répétitions ou d'omissions. Son atout principal :

La latence.

En RP, attendre cinq secondes après une réplique pour entendre la voix tue vite la magie. Un TTS rapide commence à parler plus tôt.

Mise à jour importante

Le projet open source original a été archivé en septembre 2026. Développement et assistance officiels sont terminés. Les modèles et fichiers ONNX restent disponibles et utilisables en local, mais il ne faut pas compter sur un support continu. Cela ne dégrade pas le modèle, mais compte pour un nouveau projet.

Option 2 : Kokoro — petit et rapide

Kokoro est intéressant pour :

• Sa petite taille.
• L'inférence CPU.
• La faible latence.

Kokoro ne compte que 82M de paramètres. Des implémentations locales fonctionnent hors ligne après téléchargement. SillyTavern le prend en charge via kokoro.js, avec WebGPU dans les navigateurs compatibles. Une voix simple peut ainsi consommer peu de ressources.

Option 3 : Qwen3-TTS — le clonage vocal

Voilà qui devient intéressant. Qwen3-TTS est sorti en janvier 2026 en versions 0.6B et 1.7B. Les modèles officiels prennent en charge dix langues :

• Chinois.
• Anglais.
• Japonais.
• Coréen.
• Allemand.
• Français.
• Russe.
• Portugais.
• Espagnol.
• Italien.

Selon la variante, la famille propose :

• Parole en streaming.
• Clonage vocal.
• Création de voix.
• Contrôle par instructions en langage naturel.

Le clonage est particulièrement intéressant pour le RP. Le checkpoint officiel 0.6B Base clone une voix à partir d'environ trois secondes d'audio de référence. Chaque personnage peut avoir sa voix sans entraîner un modèle complet.

Pourquoi c'est important pour le RP

L'ancienne approche :

Dina → voix 7
Fiona → voix 11
Laura → voix 3

La nouvelle :

Dina → reference_dina.wav
Fiona → reference_fiona.wav
Laura → reference_laura.wav

Le TTS essaie de préserver cette identité vocale. Une variante adaptée de Qwen3-TTS accepte aussi des instructions comme :

Speak quietly, slightly irritated,
trying not to show that she is scared.

Les versions 1.7B CustomVoice et VoiceDesign contrôlent le style par instructions ; Base emploie un mode différent pour le clonage. Pour un livre audio, c'est sympa. Pour le RP, très sympa : le LLM connaît déjà l'état émotionnel.

On peut relier :

LLM:
emotion = angry
intensity = 0.65

↓

TTS:
Speak in a restrained but clearly angry voice.

Le personnage fait alors plus que lire du texte.

Et XTTS-v2 ?

XTTS-v2 existe et fonctionne toujours. Son avantage : l'infrastructure existe déjà autour. Serveurs API, intégration SillyTavern, nombreux guides.

SillyTavern documente un serveur local XTTSv2 et le clonage à partir de WAV d'environ dix secondes. Aujourd'hui, je regarderais d'abord Qwen3-TTS. XTTS correspond plutôt à :

J'ai besoin d'un pipeline éprouvé que je connais déjà.

Comparaison des TTS

Les étoiles sont mon appréciation approximative pour le RP, pas un benchmark commun. Vitesse et qualité dépendent du matériel, de la langue et de l'intégration.

Le point crucial : un seul GPU pour tout le monde

Ce que beaucoup de tutoriels oublient. Tu as :

LLM
Modèle d'images
TTS

Tous les trois veulent de la VRAM.

Les deux premiers se regardent comme deux chats devant l'unique carton.

Exemple : RTX 3060 de 12 Go

Imagine Saiga Nemo Q5 consommant environ :

~9 GB

SDXL/FLUX réclame plusieurs gigaoctets supplémentaires. Ils ne tiennent plus confortablement ensemble. Que faire ?

Option 1 : charger et décharger les modèles

C'est pertinent si l'intégration sait gérer leur chargement. Deux serveurs distincts ne déchargent pas automatiquement leurs modèles l'un pour l'autre.

Conversation :
Le LLM est sur le GPU.

↓

Une image est nécessaire :
Décharger une partie ou tout le LLM.
Charger le modèle d'images.
Générer l'image.
Libérer le modèle d'images.

↓

Recharger le LLM.

Pas idéal pour la latence, mais cela permet des modèles capables sur un GPU grand public.

Option 2 : garder une partie du LLM en RAM

Un compromis possible pour le RP :

• 70 % des couches du LLM → GPU.
• Le reste → CPU/RAM.
• Une partie de la VRAM reste libre pour ComfyUI.

Le texte devient plus lent. Les images peuvent en revanche éviter un rechargement complet à chaque fois.

Option 3 : deux GPU

Une deuxième carte NVIDIA rend la configuration multimodale plus confortable :

GPU 0:
LLM

GPU 1:
ComfyUI

Le TTS peut rester sur CPU ou sur un GPU. Cela peut réduire l'attente entre texte et image.

Option 4 : images à la demande

Une image après chaque phrase n'est pas nécessaire, et peut même agacer. Mieux vaut en générer quand :

• Le lieu change.
• Les vêtements changent.
• Un autre personnage apparaît.
• Une action importante se produit.
• Le joueur demande une image.

Le LLM peut aider à détecter ces moments. La charge diminue fortement.

Quel matériel faut-il vraiment ?

Très approximativement. Ce sont des pistes, pas une garantie que tous les modèles tiennent simultanément en VRAM :

La VRAM ne fait pas tout. Je voudrais aussi :

RAM

16 Go comme minimum de départ. 32 Go sont plus confortables. 64 Go aident pour les gros GGUF et l'exécution CPU partielle.

SSD

Les modèles mangent le disque comme s'il était gratuit. Un LLM : 5–20 Go. Modèles d'images, encodeurs de texte et VAE : encore des dizaines de Go. LoRA : d'autres dizaines avec la collection. Sorties ComfyUI après quelques mois :

D'où viennent ces 180 Go d'images ?

Un espace dédié de 500 Go–1 To disparaît étonnamment vite.

Tout peut fonctionner sans internet ?

Oui, avec une réserve : une fois tous les modèles et fichiers nécessaires téléchargés. KoboldCpp est local. ComfyUI avec checkpoints locaux aussi. Supertonic/Kokoro/Qwen3-TTS peuvent l'être. L'interface communique via :

localhost
127.0.0.1

Les données n'ont pas besoin de quitter l'ordinateur.

Vérifier le fonctionnement hors ligne

Le test le plus simple :

Déconnecte internet.

Sérieusement. C'est plus direct pour tester le mode hors ligne que vingt politiques de confidentialité. Si ensuite :

• Le LLM répond.
• ComfyUI génère des images.
• Le TTS parle.

La chaîne principale sait fonctionner localement. Vérifie séparément les accès réseau lorsque la connexion est active. Télécharge aussi les fichiers que les logiciels récupèrent au premier appel.

Exemple d'une configuration entièrement locale

Pour une configuration simple Windows + NVIDIA :

Interface:
Multiic / SillyTavern

↓

LLM:
KoboldCpp
localhost:5001

Modèle:
Saiga Nemo 12B Q4/Q5
ou Qwen3.5-9B

↓

Images:
ComfyUI
localhost:8188

Modèle:
SDXL / FLUX / Qwen Image workflow

↓

Voix:
Qwen3-TTS
ou Supertonic/Kokoro

localhost:<port TTS>

C'est tout. De l'extérieur, un personnage IA. À l'intérieur, trois réseaux différents travaillent et font semblant d'être une seule personne.

Franchement, assez réaliste.

À quoi ressemble un tour de jeu ?

Tu écris par exemple :

Dina, tu savais qu'il viendrait, n'est-ce pas ?

Étape 1

L'interface assemble le prompt :

Système
Fiche du personnage
Mémoire
Scène actuelle
Dialogue récent
Message du joueur

Étape 2

KoboldCpp → Saiga Nemo :

Dina détourne les yeux.

« Peut-être. Quelle différence ça fait maintenant ? »

Étape 3

L'interface extrait l'état de la scène :

character: Dina
emotion: defensive
location: kitchen
pose: looking away
camera: medium shot

Étape 4

Elle construit un prompt d'image :

Dina standing in a dim kitchen at night,
looking away from the viewer,
defensive expression,
arms slightly crossed,
medium shot,
warm practical lighting

Étape 5

ComfyUI génère l'image.

Étape 6

L'intégration TTS reçoit :

text:
Peut-être. Quelle différence ça fait maintenant ?

voice:
Dina

emotion:
restrained, defensive, slightly angry

Elle traduit ces champs en réglages pris en charge par le modèle vocal choisi.

Étape 7

L'audio démarre. On se rapproche déjà d'un petit visual novel procédural.

La mémoire du personnage

Autre erreur : mettre toute la vie du personnage directement dans le contexte. Cela fonctionne souvent mal. Mieux vaut séparer :

Fiche de personnage

Ce qui change rarement :

Personnalité
Biographie
Manière de parler
Relations

État de la scène

Ce qui se passe maintenant :

Lieu
Vêtements
Émotion
Personnages présents
Heure

Mémoire à long terme

Les événements importants :

Le joueur a menti à Dina à propos de Josephine.
Dina l'a découvert plus tard.
La confiance a diminué.

Messages récents

Le contexte des derniers échanges. Le LLM reçoit des informations utiles sans transformer le contexte en benne de 80k tokens.

Les images ont aussi besoin de mémoire

C'est essentiel. Si le LLM sait :

Dina porte une veste rouge aujourd'hui.

Mais que le prompt d'image vient seulement de la dernière réplique :

Dina a l'air en colère.

Une minute plus tard, elle a :

• Un nouveau visage.
• Une robe verte.
• Trois centimètres supplémentaires de décolleté.
• Peut-être une queue.

Le metteur en scène visuel doit recevoir un état structuré, pas seulement la réponse. Exemple :

{
  "character": "Dina",
  "hair": "curly dark hair",
  "clothes": "oversized red jacket",
  "location": "kitchen",
  "emotion": "annoyed"
}

Cela améliore la cohérence visuelle.

Séparer les instructions TTS du dialogue

Ne demande pas au LLM d'écrire :

[voix triste]
Je ne sais pas...

Puis de faire lire les crochets au TTS. Récupère plutôt des métadonnées séparées :

text: "Je ne sais pas."
emotion: sad
energy: low
speed: 0.9

L'intégration les convertit en paramètres vocaux compatibles. Les variantes adaptées de Qwen3-TTS acceptent des instructions de style en langage naturel.

Tout faire avec KoboldCpp ?

Étonnamment, beaucoup de choses sont possibles. KoboldCpp prend en charge, au-delà du texte GGUF :

• Génération d'images.
• Retouche d'images.
• Whisper.
• TTS.
• Compréhension d'images.
• Plusieurs endpoints compatibles API.

Un système minimaliste peut s'appuyer largement sur un seul moteur. Pratique pour débuter. Je préfère néanmoins KoboldCpp pour le LLM + ComfyUI pour les images + un TTS séparé.

Pourquoi ? Les composants évoluent à des rythmes différents. Si un excellent modèle d'images sort demain, je veux remplacer un workflow plutôt qu'attendre son intégration à un moteur monolithique.

La solution la plus simple

Si tu te dis maintenant :

Super. Plus qu'à installer cinq programmes et devenir administrateur système.

Oui. C'est compréhensible. Voilà pourquoi certains projets connectent les composants. Multiic rassemble par exemple :

• Modèles GGUF locaux.
• KoboldCpp.
• Génération locale d'images.
• Workflows ComfyUI.
• TTS local.
• Mémoire des personnages.
• Scènes visuelles.

Dans une seule interface. Les connexions sont expliquées dans l'aide Multiic. Au lieu d'assembler :

SillyTavern
 + KoboldCpp
 + ComfyUI
 + TTS server
 + Scripts personnels

Tu peux utiliser une configuration déjà reliée. La philosophie reste identique : des modèles spécialisés travaillent ensemble.

Ce que j'installerais aujourd'hui

PC modeste / 6 Go de VRAM

LLM:
Stheno 8B Q4

Images:
SD1.5

Voix:
Kokoro / Supertonic 3

Interface:
Multiic ou SillyTavern

Un ensemble relativement léger.

8 Go de VRAM

LLM:
Qwen3.5-9B Q4
ou Saiga Nemo Q4 avec exécution CPU partielle

Images:
SDXL

Voix:
Qwen3-TTS 0.6B / Kokoro

Interface:
Multiic / SillyTavern

Une configuration utile selon moi, avec la gestion mémoire décrite plus haut.

12 Go de VRAM

Mon compromis préféré :

LLM:
Saiga Nemo 12B Q5/Q6

Images:
SDXL / workflow ComfyUI moderne

Voix:
Qwen3-TTS

Interface:
Multiic

Prévois de charger et décharger les modèles LLM et d'images selon les besoins.

16–24 Go

Plus de place pour expérimenter :

LLM:
20–30B / modèle MoE

Images:
FLUX / Qwen Image / workflow de retouche moderne

Voix:
Qwen3-TTS 1.7B

Personnage:
Plusieurs références / LoRA

Contexte:
16–32k+

Les résultats deviennent intéressants. Les choix précis dépendent toujours de la consommation mémoire combinée.

Combien ça coûte ?

Si tu as déjà l'ordinateur :

0 dollar de frais d'inférence cloud par message.

Après le téléchargement des modèles. C'est un atout du local. Pendant des heures de RP, un LLM cloud traite régulièrement :

Prompt système
Personnage
Mémoire
Historique
Scène actuelle

Ces tokens d'entrée peuvent augmenter la facture. Puis viennent les images et le TTS. En local, le coût devient environ :

Électricité + matériel + temps passé à expliquer à CUDA qui commande.

La qualité est-elle moins bonne que dans le cloud ?

Parfois oui.

Un grand modèle cloud de pointe surpasse souvent un petit 8B pour :

• Raisonnement.
• Instructions complexes.
• Intrigues compliquées.

Les modèles d'images cloud peuvent aussi fournir d'excellents résultats sans réglages. Le local gagne sur d'autres points :

Liberté

Tu peux changer les composants.

Confidentialité

Avec stockage et connexions locaux, l'historique peut rester sur ta machine.

Coût

Tu ne comptes pas chaque message sur une facture d'inférence.

Latence

Un TTS léger peut être particulièrement réactif.

Personnalisation

LoRA, ajustements de modèles, voix de personnages et workflows personnels.

Reproductibilité

Un modèle téléchargé ne disparaît pas parce qu'une entreprise remplace sa version hébergée. Un .gguf ne peut pas changer de marque.

Et c'est merveilleux.

Tu quittes Character.AI ? Voici un comparatif de neuf alternatives à Character.AI, des services en ligne aux configurations entièrement locales.

Pour finir

En 2026, on peut réellement construire du RP IA entièrement local : LLM local + personnage persistant + images + clonage vocal sur un PC de jeu ordinaire, en choisissant bien les modèles et la gestion des ressources.

Pas besoin de cluster, de clé API cloud ni d'abonnement pour l'inférence locale. Un point de départ :

KoboldCpp
+
8–12B GGUF
+
ComfyUI
+
TTS léger

Ensuite, tu peux ajouter :

• Une LoRA de personnage.
• Des images de référence.
• De la mémoire.
• La détection d'émotions.
• Le clonage vocal.
• La retouche d'images.
• Plusieurs personnages.
• Un état du monde.
• La génération locale de vidéos.

Un jour, tu réalises que tu voulais assembler un chatbot et que tu as construit un petit moteur de jeu procédural.

C'est à peu près ainsi qu'est né Multiic.