ComfyUI-MiniMaxH3-CLIPCached : cache disque pour le conditionnement H3
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.
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.
| Modification | Nouvelle entrée de cache ? |
|---|---|
| Texte du prompt | Oui |
| Checkpoint de l'encodeur | Oui |
| Pixels d'image clé/de référence visibles par l'encodeur | Oui, lorsque le contenu visible par l'encodeur change |
| Graine, échantillonneur, scheduler, étapes | Non |
| 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) :
| Mode | Conditionnement | VRAM maximale | RAM maximale du processus |
|---|---|---|---|
| Natif | 29,85 s | 15,24 Gio | 29,25 Gio |
| Échec du cache | 32,23 s | 15,24 Gio | 28,25 Gio |
| Succès du cache | 1,12 s | 2,67 Gio | 3,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.