Images NSFW SillyTavern avec 8–16 GB de VRAM : garder le chat réactif

Votre personnage SillyTavern écrit enfin comme vous le voulez. Vous demandez une image, ComfyUI commence à charger, puis l’image échoue ou la prochaine réponse devient terriblement lente. Une carte de 8GB ou 16GB peut parfaitement convenir à chaque tâche séparément et pourtant souffrir lorsque les deux sont actives.

Pour générer des images NSFW SillyTavern avec peu de VRAM, la première décision utile est de choisir la tâche qui garde le GPU. Si le roleplay local sans interruption compte le plus, générez les images à distance. Si checkpoint et LoRA locaux d’image comptent le plus, passez la conversation sur une API de chat. Si tout doit rester local, créez d’abord le prompt visuel, déchargez le backend textuel, générez l’image puis rechargez le texte. Cette troisième voie préserve la conversation enregistrée, mais ne promet pas une génération ininterrompue pendant le changement de tâche du GPU.

Ce sont des choix pratiques, pas un benchmark garantissant qu’une paire précise tient sur toute carte 8GB. Nous n’avons pas chronométré une exécution locale couplée pour ce guide. Les connexions viennent des documentations et sources des projets ; l’ordre de travail proposé isole les échecs courants sans changer cinq réglages ensemble.

Le problème apparaissait clairement dans une discussion SillyTavern du 2 octobre : un utilisateur de carte AMD 16GB utilisait déjà la mémoire pour du roleplay local et voulait ajouter Z-Image. La question n’est pas si Z-Image tourne sur un GPU grand public, mais s’il tourne avec votre modèle de chat occupant encore ce GPU.

Choisissez le rôle du GPU avant un nouveau téléchargement

Commencez par la partie de votre soirée que vous voulez le moins interrompre. Longue conversation avec modèle favori, workflow d’image soigneusement réglé et exigence de ne rien envoyer hors de l’ordinateur conduisent à des configurations différentes.

Avec 8GB, commencez généralement par une seule charge locale. Avec 16GB, vous avez plus de marge, mais la décision reste la même si le LLM utilise presque toute la carte. Télécharger un autre checkpoint quantifié sans décider qui utilise la mémoire restante donne souvent un autre téléchargement et le même échec.

Ne confondez pas API de chat et backend d’image. Un modèle peut décrire parfaitement un adulte fictif sans produire de pixels. Un modèle acceptant des images peut seulement les analyser. La connexion dans API Connections exécute la conversation ; la source dans Image Generation dessine l’image. Gardez ces réglages séparés.

Gardez une charge distante ou laissez chat et images locaux utiliser le GPU à tour de rôle.

Pourquoi un chat inactif peut garder presque toute la VRAM

Le chat paraît inactif : aucune réponse générée, utilisation GPU basse, machine calme. ComfyUI ne peut pourtant pas charger. L’utilisation mesure le travail actuel ; l’occupation mémoire, les ressources retenues pour le prochain. Un backend peut ne presque rien faire en gardant une grande allocation.

Le poids du téléchargement n’explique qu’une partie. Le LLM a besoin du cache de conversation et de calculs temporaires. Un contexte plus grand augmente la charge même sans changer les poids. L’image possède ses composants et son travail temporaire. Le pic peut arriver après un chargement apparemment réussi, pas au téléchargement ou à la connexion.

Une explication d’un mainteneur llama.cpp sur la mémoire documente poids, cache de contexte et buffers de calcul séparés. Soustraire la taille GGUF au chiffre de la boîte du GPU juge donc mal la marge ComfyUI.

Pour illustrer, supposons une carte 16GB avec 1GB pour bureau et applications, et 11GB pour le texte. Il reste environ 4GB avant l’image. Ces chiffres sont inventés pour expliquer le calcul, pas mesurés pour Z-Image ni recommandés. Dire qu’un modèle tourne sur 16GB ne signifie pas qu’il tourne dans ces 4GB restants.

Le dépôt officiel Z-Image décrit Turbo sur appareils grand public 16GB et propose le déchargement CPU pour mémoire limitée. Cette déclaration concerne le déploiement d’image. Elle ne réserve pas de place pour un LLM séparé, long cache, plusieurs adaptateurs et inférence simultanée.

Avant de modifier, regardez la mémoire plutôt que le pourcentage GPU. Sous Windows, ouvrez Gestionnaire des tâches, Performance et le vrai GPU dédié. Distinguez mémoire dédiée et partagée. Ailleurs, utilisez les outils du fabricant ou journaux d’allocation. L’observation utile est le processus restant chargé, pas l’inactivité momentanée du graphique.

Localisez l’échec en quatre vérifications courtes

Faites cela avant nouvelle quantification, réinstallation ou nœud de déchargement. Depuis le chat, connexion et VRAM se ressemblent : aucune image dans les deux cas.

D’abord, testez la conversation seule. Fermez complètement le backend d’image, démarrez le texte habituel et générez une réponse normale. Notez s’il est déjà lent. Alors le problème n’est pas encore le partage : le LLM est trop exigeant, utilise un backend inadapté ou traite un grand prompt.

Ensuite, testez l’image seule. Arrêtez le texte, lancez ComfyUI et générez dans son interface, une image avec les réglages prévus. Si cela échoue sans LLM, réduire le contexte du chat ne résout rien. Corrigez installation, fichiers manquants, nœuds non pris en charge ou mémoire d’image d’abord.

Puis connectez SillyTavern au backend d’image fonctionnel. Gardez le LLM arrêté, désactivez Extend free-mode prompts dans Image Generation et utilisez une commande manuelle comme /sd a fictional adult lounge singer age 29 in a black satin evening outfit, seated beside an amber lamp. Vous évitez l’étape textuelle supplémentaire. Si ComfyUI fonctionne seul mais aucune soumission n’arrive, examinez source, adresse et workflow au format API. Baisser la résolution ne répare pas une URL de mauvais service.

Enfin, recommencez avec LLM chargé. La seule grande différence est le texte supplémentaire. Si les étapes précédentes fonctionnent et celle-ci échoue, la séparation mémoire est justifiée. Si l’image marche mais le chat ralentit ensuite, regardez si ComfyUI retient ses modèles ou si le texte utilise un mode plus lent.

Une cinquième comparaison utile est le prompt manuel contre /sd last. Ce dernier ajoute une étape textuelle décrivant la conversation récente. Si le manuel atteint ComfyUI mais pas le contextuel, l’échec peut venir de l’écriture du prompt. Refus, réponse vide ou description mal formée du LLM ne se répare pas en libérant la mémoire d’image.

Notez l’étape exacte d’échec : chargement, encodage textuel, échantillonnage, décodage ou détails suivants. Elle indique quoi retirer. Un échec d’agrandissement final peut se résoudre en le reportant ; celui du modèle principal demande un autre plan mémoire.

Première voie : roleplay local, images ailleurs

C’est mon premier choix si votre modèle local vous plaît déjà et vous demandez peu d’images. Gardez le texte et déplacez l’image plutôt que réduire la conversation jusqu’à perdre ce que vous vouliez.

Une source déjà prise en charge par SillyTavern

Ouvrez Extensions puis Image Generation. Dans Source, choisissez un service figurant réellement dans la liste actuelle. Configurez ses propres identifiants et modèle, pas l’adresse du modèle textuel. La documentation officielle Image Generation référence liste et contrôles spécifiques.

Générez un portrait modeste non explicite avant les déclencheurs automatiques. Vous vérifiez service, identifiants, modèle et résultat ensemble. Une intégration listée ne promet pas que chaque modèle derrière accepte votre scène adulte.

Ne remplacez pas l’URL d’image d’un service par l’API générique d’une autre entreprise en attendant une traduction. Même avec un prompt, corps de requête, statut des jobs, retour d’image, authentification et erreurs peuvent différer. Un champ API URL ne rend pas toutes les API interchangeables.

Placez ComfyUI sur un autre ordinateur

Si vous voulez checkpoint et LoRA existants, gardez le workflow et déplacez son exécution. Faites-le fonctionner sur l’autre ordinateur d’abord : logiciel compatible, modèles et nœuds installés nécessaires. Le JSON référence les composants sans les embarquer.

Dans Image Generation, choisissez ComfyUI puis Standard Server. Entrez l’adresse accessible depuis la machine du serveur SillyTavern et Connect. Le fait que le téléphone ouvre la page distante ne prouve pas l’accès de l’hôte SillyTavern.

Sur deux machines, 127.0.0.1 désigne celle qui fait la requête, pas l’autre ordinateur. Utilisez l’adresse réellement accessible. Pour un hôte en ligne, choisissez une connexion protégée ; exposer un ComfyUI sans restrictions publiquement est inutile chez soi.

Après le premier rendu, ajoutez le workflow API sauvegardé. Gardez mêmes checkpoint et adaptateurs pour des résultats concordants. Si le GPU distant utilise une autre variante quantifiée, actualisez le chargeur plutôt que supposer le même comportement d’un nom proche. Le LLM local reste chargé puisque l’image utilise une autre mémoire.

C’est intéressant si vous connaissez ComfyUI, moins si vous voulez deux images ce soir et devez apprendre l’administration serveur. Un générateur navigateur peut être plus pratique même moins intégré.

Utilisez SpicyAPI à côté du chat

Les tâches d’image SpicyAPI ne figurent pas comme source native dans l’implémentation SillyTavern inspectée. Le contrat asynchrone ne se colle pas dans l’URL ComfyUI et n’est pas un endpoint AUTOMATIC1111. Ce guide ne fournit ni ne prétend avoir testé un adaptateur rendant ces protocoles interchangeables.

Vous pouvez garder le roleplay local et ouvrir la page Z-Image Spicy dans un deuxième onglet. Ouvrez Playground, collez la description visuelle, fixez les dimensions, générez et téléchargez. Le GPU reste au LLM puisque l’inférence d’image est distante.

Pour un premier portrait, choisissez 832 par 1216 pixels, expansion désactivée, un adulte fictif dans tenue et pièce précises. Les deux côtés sont dans la plage publique de 256 à 1536 pixels. C’est une composition initiale proposée, pas une scène rendue ni une comparaison avec votre checkpoint.

Le service distant reçoit prompt et images téléversées. Inutile d’envoyer tout l’historique. Copiez seulement traits visibles et scène actuelle ; retirez notes privées, vrais noms et détails inutiles à la photo.

Deuxième voie : image locale, chat par API

Choisissez-la si l’image est votre partie soigneusement réglée : checkpoint d’illustration, LoRA de personnage, contrôle de pose ou workflow irremplaçable. Déplacer le chat est souvent plus simple que refaire ces images ailleurs.

La première action est d’arrêter le backend textuel, pas seulement changer le sélecteur. llama.cpp, Ollama ou un autre serveur en fond peut garder la mémoire à récupérer. Sauvegardez le profil existant puis connectez le chat hébergé choisi.

SillyTavern prend en charge le chat hébergé séparément des images. Suivez la documentation API Connections du protocole. Le chat peut être local ou hébergé même si la catégorie s’appelle Chat Completion ou Text Completion : cela décrit l’envoi du prompt, pas le GPU.

Pour SpicyAPI, notre guide de connexion roleplay SillyTavern fournit les réglages Custom OpenAI-compatible et la gestion des paramètres non pris en charge par modèle. Suivez-les plutôt que placer un ID de tâche d’image dans le modèle de chat. Le but ici est de libérer le GPU ; inutile de répéter tous les réglages de chat.

Revenez à ComfyUI et au workflow exact réussi seul. N’ajoutez pas immédiatement d’étapes parce que le GPU semble libre. Gardez la première requête intégrée identique à celle isolée ; cela vérifie la disparition de l’interférence.

Le LLM hébergé sert toujours le pipeline visuel. Il transforme la scène en prompt avant la soumission du workflow local. C’est une requête textuelle vers le service, sans autre gros modèle chargé sur la carte.

Le coût est confidentialité de conversation et facturation par tokens. L’API reçoit le contexte SillyTavern, qui peut contenir personnage, instructions, lore sélectionné et messages. Si le chat uniquement local est impératif, cette voie n’est pas un petit ajustement : elle change le lieu de traitement.

Surveillez la première réponse après l’image. Si elle est réactive et ComfyUI termine proprement, la concurrence principale est résolue. Si l’image reste lente comme lorsqu’elle tournait seule, le goulot est l’image, pas le chat hébergé.

Chat et images sont des connexions séparées. Un générateur navigateur à côté du chat est manuel, pas une intégration native ComfyUI.

Troisième voie : tout local, à tour de rôle

Si ni conversation ni prompts d’image ne doivent quitter la machine, utilisez successivement le GPU. La création d’image devient une courte pause. Vous ne supprimez pas le personnage ni ne recommencez : vous changez temporairement le backend tenant les allocations.

Conversation sauvegardée et cache chargé diffèrent. SillyTavern garde les données ; le cache en mémoire du backend accélère la suite. Arrêter ou décharger peut le perdre. Au retour, la prochaine requête peut retraiter le contexte. L’histoire reste disponible, mais la première réponse peut être plus longue.

L’ordre de travail

1. Terminer la réponse et arrêter régénérations ou déclencheurs automatiques.
2. Créer et sauvegarder le prompt visuel avec le texte encore chargé, ou l’écrire soi-même.
3. Sauvegarder la conversation et conserver la description à coller.
4. Décharger ou arrêter le texte, puis confirmer la baisse réelle de mémoire dédiée.
5. Générer une image ComfyUI avec la description sauvée.
6. Garder l’image terminée, puis décharger les modèles ComfyUI ou arrêter le backend.
7. Confirmer la mémoire disponible, redémarrer le texte avec réglages enregistrés et reconnecter si besoin.
8. Continuer la même conversation ; attendre une reconstruction du contexte si le cache est perdu.

L’écriture du prompt précède le déchargement. Arrêter le LLM puis demander /sd last via ce backend supprime le service nécessaire à la première moitié de la demande. Utilisez la description déjà sauvée dans un /sd manuel, Extend free-mode prompts désactivé pendant l’image.

Commencez manuellement. Arrêt-redémarrage visible est moins élégant qu’une extension, mais vérifie le plan mémoire fondamental. Si l’image échoue encore sans processus textuel, un outil automatique répétera l’échec plus vite sans le corriger.

Avec Ollama : déchargez le modèle, pas seulement la fenêtre

Ollama documente une commande d’arrêt et keep_alive. L’action manuelle immédiate est ollama stop YOUR_MODEL_NAME, avec le nom exact installé. Sa FAQ officielle décrit aussi keep_alive à zéro dans les requêtes API compatibles pour décharger après usage.

Terminez d’abord la description, arrêtez le modèle puis commencez l’image. Au prochain chat, Ollama peut le recharger. Désactivez l’écriture automatique de prompts en fond pendant ComfyUI pour ne pas recharger au mauvais moment.

Ne supposez pas tous les paramètres Ollama réglables par tous les clients et protocoles. Utilisez un réglage explicitement pris en charge ou l’arrêt documenté. Un curseur de contexte ou champ de corps générique n’implémente pas automatiquement les contrôles de cycle de vie natifs.

Avec llama.cpp : utilisez le cycle de vie du backend

Pour un llama-server à modèle unique, arrêter le processus est le moyen manuel le plus clair de libérer avant l’image. Redémarrez ensuite avec les mêmes paramètres. Fermer le navigateur, laisser le chat inactif ou changer le nom sélectionné ne stoppe pas un processus séparé.

Les versions récentes offrent aussi gestion des modèles, mais les opérations dépendent du lancement et de la version. Modèle unique et routeur multi-modèles sont distincts. Suivez le serveur réel, pas une requête de déchargement d’un autre backend.

Avec ComfyUI : libérer ses modèles ne libère pas le LLM

L’implémentation officielle du serveur expose /free avec unload_models et free_memory. Cela place des drapeaux traités par l’exécution. Cela ne tue pas un llama.cpp séparé et l’acceptation ne prouve pas une libération immédiate de chaque octet.

Utilisez le contrôle de déchargement de votre frontend ou installation après rendu. Sinon, arrêter le backend est une base manuelle claire. Fermer son onglet ne stoppe pas le serveur.

Un nœud personnalisé peut aider si l’ordre est correct. Avant un passage de détails nécessitant encore le modèle, celui-ci peut être rechargé. S’il ne décharge que ComfyUI, le roleplay reste intact. Lisez sa documentation avant de supposer une orchestration des deux.

Faites fonctionner la connexion ComfyUI avant de régler la mémoire

La prise en charge ComfyUI de SillyTavern est une vraie intégration de workflow, pas un pont universel d’API image. Elle soumet un graphe au format API et récupère le résultat. Un workflow correct sur le bureau peut échouer via SillyTavern s’il est mal exporté ou garde un prompt fixe.

Commencez dans ComfyUI. Générez une image avec checkpoint, encodeur, VAE et nœuds prévus. Sauvegardez le workflow ordinaire pour le rouvrir visuellement. Exportez ensuite sa version API via l’option du frontend ; les noms de menus varient.

Dans SillyTavern, choisissez ComfyUI, Standard Server pour une installation locale normale et l’adresse affichée par le serveur. Le défaut documenté est http://127.0.0.1:8188. Cette adresse locale appartient au réglage applicatif, pas à un site public ni à une adresse à publier pour autrui.

Faites Connect, créez ou choisissez le workflow et placez le graphe API dans l’éditeur. L’intégration fournit des substitutions comme %prompt% pour le prompt positif. Utilisez-les seulement là où le graphe reçoit cette valeur. Sans substitutions, un JSON ComfyUI valide peut toujours dessiner son exemple initial.

Avec CLIP Text Encode, trouvez le vrai champ alimentant le conditionnement positif et remplacez sa description par la substitution. Si un chargeur personnalisé ou autre nœud reçoit le texte, placez-la là. N’ajoutez pas un nœud textuel déconnecté seulement pour une validation verte.

Envoyez deux demandes volontairement différentes : chanteuse adulte de salon puis pièce vide éclairée aux bougies. Si les deux donnent le même sujet, inspectez le graphe avant seeds ou nouveau modèle. Commencez probablement par le prompt fixe. Si seules couleur ou ambiance changent, cherchez encore le personnage original dans un préfixe ou champ actif.

Réglages mémoire utiles et réglages trompeurs

N’appliquez pas tous les drapeaux d’un commentaire ensemble. Déterminez si vous réduisez texte, image ou rétention de mémoire inutilisée. Ce sont des interventions différentes, aux effets différents sur la réponse suivante.

Raccourcissez le contexte du backend avant de réduire la qualité du personnage

Un réglage 32K ou plus peut réserver davantage que nécessaire. Essayez un profil enregistré plus petit, par exemple 4096 ou 8192 tokens, s’il contient encore carte, instructions, lore pertinent et conversation récente. Ce sont des tailles d’exemple, pas une garantie de mémoire pour chaque modèle.

Réglez aussi le contexte de requête SillyTavern selon le backend. Réduire seulement l’historique côté client ne réduit pas nécessairement un cache alloué au lancement serveur. Monter le curseur client n’augmente pas magiquement la capacité serveur. Pour une allocation backend, changez-y le réglage et redémarrez ou rechargez selon l’implémentation.

La référence serveur llama.cpp documente taille de contexte, couches GPU, types de cache et déchargement KV. Utilisez les noms de l’aide installée. L’ajustement automatique du texte au GPU ne promet pas de laisser la place au futur pic d’image d’une autre application.

Réduire les couches GPU déplace une partie de l’inférence hors du GPU, libérant potentiellement de la place au prix de lenteur. Quantifier le cache est distinct du fichier de modèle quantifié. Des poids Q4 ne signifient pas automatiquement un cache quatre bits.

Réduisez les pics d’image par un rendu simple

Utilisez un lot de taille un. Générer plusieurs images à la suite n’est pas gérer un lot simultané. Gardez le ratio habituel du modèle et une taille raisonnable, sans deuxième passage d’échantillonnage haute résolution avant réussite de base.

Si le graphe échoue au décodage VAE, un décodeur tuilé pris en charge peut aider. S’il échoue au chargement principal, le tuilage ne réduit pas ces poids. Si seul détail facial ou agrandissement échoue, retirez cette étape du flux live et faites-la ensuite avec texte arrêté.

Lisez le sens de Low VRAM dans votre programme

Les définitions actuelles des arguments ComfyUI distinguent gestion dynamique et anciens drapeaux. --lowvram n’agit pas avec DynamicVRAM ; sans celui-ci, il déplace les encodeurs textuels vers CPU. Son sens est plus limité que « faire tenir tout modèle dans la mémoire restante ».

ComfyUI propose aussi réservation de mémoire et déchargement plus agressif. Réserver peut garder de la place pour d’autres logiciels, mais ne forme pas un ordonnanceur commun au chat. Si les minima combinés ne tiennent pas, aucune réserve ne crée de mémoire. Testez un changement puis la même demande d’une image.

KoboldCpp utilise d’autres contrôles. Son quickstart SillyTavern avertit de ne pas cocher Low VRAM sur la capture. Il décrit un ancien lanceur : consultez aussi l’aide installée. Évitez de copier un réglage seulement parce qu’une autre application utilise le même nom.

Une carte AMD change l’installation, pas le calcul mémoire

La question récente impliquait AMD et Vulkan de llama.cpp. Vérifiez les chemins d’exécution compatibles plutôt que coller une commande CUDA NVIDIA. Accélération, formats numériques et opérateurs dépendent du GPU, système, build et backend réellement installés.

Confirmez d’abord chaque application seule. Une réussite Vulkan textuelle ne prouve pas un backend d’image accéléré adapté dans ComfyUI. Un modèle d’image fonctionnel ne prouve pas le build voulu du LLM. Regardez démarrage et appareil réellement utilisé dans les tests isolés.

Si texte et images sont rapides séparément mais échouent ensemble, changer l’argument de marque GPU résoudra rarement le manque de place. Rendez une charge distante ou successive. Si une application est lente seule, corrigez-la avant l’exécution simultanée.

Méfiez-vous d’un modèle quantifié « adapté à 8GB » sans configuration complète. Cela peut exclure l’encodeur, dépendre du déchargement, d’un nœud précis ou d’un GPU libre. Avant téléchargement, lisez les exigences de chargeur et vérifiez la quantification dans votre backend.

Faites correspondre l’image à la scène adulte sans envoyer tout le récit

Une fois l’installation correcte, la mémoire n’explique plus toutes les déceptions. Le modèle peut décrire les sentiments plutôt que ce qu’une caméra voit, donnant un portrait plausible ignorant pièce, tenue ou action.

Pour Mara, adulte fictive, séparez apparence durable et scène actuelle. Les constantes peuvent être 29 ans, carré foncé court, manchette d’oreille argentée et petit tatouage de croissant à l’épaule. Le présent peut être tenue noire en satin, fauteuil de velours, lumière chaude basse et regard latéral assuré. Seul ce second groupe doit changer avec la pièce.

Voici une description proposée adaptable, non utilisée comme test pour cet article :

Chanteuse adulte fictive de salon, 29 ans, carré foncé court et manchette d’oreille argentée, en tenue de soirée noire ajustée en satin, assise de côté dans un fauteuil de velours bordeaux profond. Expression assurée et joueuse. Lumière ambrée chaude d’une lampe de table, salon de fin de soirée doucement flou derrière. Portrait moyen, mains détendues et visibles, ambiance éditoriale intime, aucun lettrage.

Si elle passe au balcon, changez lieu et lumière plutôt que tous les traits d’identité. Si la tenue a changé dans le chat, indiquez la nouvelle et retirez l’ancienne. Des descriptions contradictoires donnent la mauvaise scène même si le modèle suit au mieux le texte.

Les préfixes propres au personnage aident la continuité descriptive, sans garantir le même visage. Pour une identité nécessitant références concordantes ou LoRA, le workflow doit réellement accepter la méthode. Texte de carte et avatar ne deviennent pas automatiquement des références pour chaque source.

Sauvegardez la description avant déchargement ; reprenez ensuite le chat enregistré.

Le coût réel d’images distantes occasionnelles

Envisagez le navigateur avant d’acheter du matériel pour éviter quelques changements de modèle. Dans le catalogue public actuel, Z-Image Spicy coûte $0.01235 par image sans expansion et $0.0133 avec expansion. Z-Image Spicy Pro coûte $0.019 par image. Ce sont des frais d’image, pas un abonnement ni le chat hébergé.

Le calcul multiplie simplement le tarif par image. Il ne prédit pas le nombre d’essais utiles. Quatre alternatives dont une gardée exigent le budget de quatre générations. Écriture du prompt par chat, édition et agrandissement restent séparés si ajoutés.

Pour dix photos dans la soirée, la composante image est donc assez petite pour la comparer à l’arrêt et rechargement local. Cela ne tranche pas si vous avez besoin d’usage hors ligne, LoRA exactes ou prompts sur la machine. Ces exigences peuvent primer sur un prix faible.

Choisissez la page Spicy Pro pour sa plage publique jusqu’à 2560 pixels par côté ; Spicy ordinaire si 1536 suffit. La limite plus grande est une différence vérifiée, pas la preuve de supériorité dans chaque scène adulte.

Corrigez le symptôme réellement visible

ComfyUI génère, mais SillyTavern indique les images indisponibles

Choisissez une source configurée dans Image Generation. Une installation récente ou ancienne peut garder une source déconnectée. Vérifiez son adresse, pas l’URL du chat. Pour le cloud, utilisez ses identifiants et configuration image. Un texte fonctionnel n’établit pas une connexion d’image.

Essayez ensuite une courte demande manuelle. Si elle marche, passez aux prompts contextuels. Un déclencheur élaboré au début masque la différence entre source inaccessible et déclencheur jamais activé.

SillyTavern se connecte, mais toutes les images ressemblent à l’exemple

Ouvrez le graphe API et trouvez le vrai texte positif. Remplacez l’exemple fixe par la substitution à cette entrée. Cherchez aussi l’ancien sujet dans les autres champs et préfixes. Changer les seeds produit seulement des variantes du texte encore fixe.

L’image échoue seulement avec le chat chargé

Gardez le workflow isolé réussi et séparez la mémoire : images distantes, chat hébergé ou local successif. Pour le local simultané, réduisez d’abord allocation réelle de contexte ou couches GPU. Répéter la même charge ne change pas la mémoire disponible.

La première image réussit puis le chat ralentit

Inspectez la mémoire après la photo. ComfyUI peut retenir les modèles, le texte utiliser une mémoire plus lente. Déchargez l’image terminée avant la réponse ou rendez-la distante. Si redémarrer le chat restaure la vitesse, gardez un profil partagé plus petit plutôt que refaire concurrencer le profil pleine mémoire.

ComfyUI déchargé, VRAM toujours pleine

Identifiez le processus gardant l’allocation. ComfyUI libère ses modèles, pas le LLM d’un autre programme. Distinguez cache alloué et mémoire rendue au GPU. Pour la base manuelle, arrêtez volontairement les backends et vérifiez avant tout relancement.

L’image ne démarre pas après demande de dernière scène

Essayez la même scène en demande manuelle free-mode avec extension désactivée. Si elle marche, inspectez l’écriture textuelle. Endpoint arrêté, réponse vide ou prose incompatible avec le workflow sont possibles. Libérer la mémoire image ne corrige pas une réponse manquante.

Le rendu démarre puis échoue à la finition

Retirez detailer, second passage ou upscaler du graphe live et générez la base. Si elle marche, sauvegardez puis faites la finition séparément avec texte déchargé. Gardez le workflow élaboré pour les œuvres finies sans l’imposer à chaque photo spontanée.

GPU non plein, mais ensemble très lent

Vérifiez l’appareil accéléré utilisé et la RAM système. Un fort déchargement CPU peut fonctionner techniquement mais être pénible en direct. Une autre optimisation VRAM peut ajouter encore du déchargement ; rendre une charge distante peut améliorer plus clairement.

Chiffres illustratifs seulement : un modèle tenant sur une carte 16GB libre peut ne pas tenir avec un LLM occupant l’essentiel.

Un départ réaliste pour la prochaine session

Avec 8GB, gardez une seule charge exigeante locale. Si le roleplay local est bon, laissez-le chargé et créez occasionnellement des images via source distante compatible ou deuxième onglet. Si l’image locale est bonne, arrêtez le texte et utilisez le chat hébergé. Choisissez le local successif lorsque garder les données importe plus que le rythme continu.

Avec 16GB, commencez pareil si le LLM occupe presque tout. Si vous pouvez expérimenter, prouvez d’abord l’image seule puis testez un profil de chat réduit avec une image, sans finition et contexte borné. Une paire stable est utile ; une configuration tenant seulement avant la croissance de conversation n’est pas fiable pour la soirée.

Le but est de lire et écrire au lieu de redémarrer des tâches ratées. Donnez une mission claire au GPU, connectez l’image par un protocole réellement pris en charge et gardez le premier workflow live assez petit pour diagnostiquer. Ensuite, ajoutez le contrôle de personnage ou la finition qui manque le plus, un à la fois.