ComfyUI-MiniMaxH3-CLIPCached : cache disque pour le conditionnement H3

ComfyUI Wikinews

Un nouveau noeud ComfyUI met en cache disque le conditionnement Qwen3-VL de MiniMax H3 : les relances avec le meme prompt evitent l'encodeur de 14,6 Go, soit 29,9 s contre 1,1 s.

ComfyUI-MiniMaxH3-CLIPCached (GitHub) est un nouveau pack de nœuds sous licence MIT qui met en cache sur disque le conditionnement texte/vision MiniMax H3. Les générations répétées avec le même prompt et les mêmes entrées de référence contournent entièrement l'encodeur Qwen3-VL : l'étape de conditionnement passe d'environ 30 secondes à environ 1 seconde, et l'encodeur de 14,6 Go n'est jamais chargé.
Flux de travail CLIPCached avec le nœud de cache en place

Le nœud de cache remplace le nœud de conditionnement H3 d'origine ; l'étape de diffusion reste inchangée.

Ce qu'il met en cache, et ce qu'il ne met pas

Ce n'est pas un accélérateur d'échantillonnage. Ce n'est ni TeaCache ni FirstBlockCache, et il ne touche pas aux étapes d'échantillonnage. Le nœud remplace le nœud de conditionnement H3 standard de ComfyUI : en cas de succès du cache, il charge depuis le disque le conditionnement texte/vision précédemment calculé au lieu d'exécuter l'encodeur Qwen3-VL, et l'étape de diffusion se poursuit sans changement.

ModificationNouvelle entrée de cache ?
Texte du promptOui
Checkpoint de l'encodeurOui
Pixels d'image clé/de référence visibles par l'encodeurOui, lorsque le contenu visible par l'encodeur change
Graine, échantillonneur, scheduler, étapesNon
LoRA en aval ou intensitéNon

Cette distinction est importante pour les flux de travail itératifs : si vous relancez le même prompt en ne modifiant que les paramètres de l'échantillonneur ou les poids du LoRA, chaque exécution après la première sera un succès.

Résultats mesurés

Le benchmark contrôlé de l'auteur (5 cas par mode, médianes, RTX 5080 16 Go sous WSL2, lectures volontairement à froid de l'encodeur pour le mode natif et l'échec du cache) :

ModeConditionnementVRAM maximaleRAM maximale du processus
Natif29,85 s15,24 Gio29,25 Gio
Échec du cache32,23 s15,24 Gio28,25 Gio
Succès du cache1,12 s2,67 Gio3,38 Gio

Un échec n'est volontairement pas un chemin rapide : le nœud exécute toujours l'encodeur et écrit le résultat sur disque, ce qui coûte environ 2 secondes supplémentaires. Mais une fois l'encodage terminé, l'encodeur est déchargé au lieu de rester résident, si bien que l'échantillonnage s'exécute avec cette mémoire libérée. Dans la capture d'écran de l'auteur, le mode natif maintient résidents à la fois le modèle H3 de 11,7 Go et l'encodeur de 14,6 Go pendant l'échantillonnage, tandis qu'un succès du cache ne laisse chargé que le DiT et fait chuter la RAM du processus de 40 Go à 25,5 Go.

Nœuds et gestion du cache

Le pack comprend des versions avec cache des nœuds H3 Image-to-Video (FL2VA) et Reference-to-Video (Ref2VA) d'origine, ainsi que des variantes à double résolution qui préparent le conditionnement à la fois pour le passage de base et pour une cible d'upscale, et un sélecteur de nom d'encodeur partagé.

Chaque demande de conditionnement unique devient une entrée de cache qui persiste jusqu'à sa suppression, et elles s'accumulent si vous itérez beaucoup. Un panneau de gestion du cache intégré permet de parcourir, d'étiqueter et de purger les entrées. Exigences : ComfyUI 0.30.0 ou plus récent, avec les nœuds H3 natifs.

Disponibilité

Le nœud est disponible dans ComfyUI Manager et le registre sous le nom minimaxh3-clipcached, ou vous pouvez cloner le référentiel dans custom_nodes. La version actuelle n'offre aucune éviction automatique du cache, Ref2VA utilise des emplacements de référence fixes, et les encodeurs GGUF ne sont pas testés.

Commentaires

Connectez-vous avec GitHub pour rejoindre la discussion.

Chargement des commentaires…
ComfyUI-MiniMaxH3-CLIPCached : cache disque pour le conditionnement H3 | ComfyUI Wiki