ComfyUI-MiniMaxH3-CLIPCached: cache en disco para H3

ComfyUI Wikinews

Nuevo nodo de ComfyUI que cachea en disco el condicionamiento Qwen3-VL de MiniMax H3: repite ejecuciones con el mismo prompt saltandose el encoder de 14,6 GB, de 29,9 s a 1,1 s.

ComfyUI-MiniMaxH3-CLIPCached (GitHub) es un nuevo paquete de nodos con licencia MIT que guarda en una caché de disco el conditioning de texto/visión de MiniMax H3. Las generaciones repetidas con el mismo prompt y con las mismas entradas de referencia omiten por completo el codificador Qwen3-VL: la etapa de conditioning se reduce de unos 30 segundos a alrededor de 1 segundo, y el codificador de 14.6 GB nunca llega a cargarse.
Flujo de trabajo CLIPCached con el nodo con caché en el grafo

El nodo con caché reemplaza al nodo de conditioning H3 estándar; la etapa de diffusion no se modifica.

Qué guarda en caché y qué no

No es un acelerador de muestreo. No es TeaCache ni FirstBlockCache y deja intactos los pasos de muestreo. El nodo reemplaza al nodo de conditioning H3 estándar de ComfyUI: cuando hay un acierto de caché, carga desde el disco el conditioning de texto/visión ya calculado en lugar de ejecutar el codificador Qwen3-VL, y la etapa de diffusion continúa sin cambios.

Cambio¿Nueva entrada de caché?
Texto del prompt
Checkpoint del codificador
Fotogramas clave o píxeles de referencia visibles para el codificadorSí, cuando cambia el contenido que ve el codificador
Semilla, sampler, scheduler y pasosNo
LoRA posterior o su intensidadNo

Esa división es relevante para los flujos de trabajo iterativos: si vuelves a ejecutar el mismo prompt ajustando solo la configuración del sampler o los pesos de LoRA, cualquier ejecución posterior a la primera será un acierto de caché.

Mediciones

El benchmark controlado del autor (5 casos por modo, medianas, RTX 5080 de 16 GB en WSL2 y lecturas del codificador deliberadamente en frío en los modos nativo y de fallo) arroja los siguientes resultados:

ModoConditioningPico de VRAMPico de RAM del proceso
Nativo29.85 s15.24 GiB29.25 GiB
Fallo de caché32.23 s15.24 GiB28.25 GiB
Acierto de caché1.12 s2.67 GiB3.38 GiB

Un fallo no es, deliberadamente, una vía rápida: aun así ejecuta el codificador y escribe el resultado en el disco, lo que cuesta unos 2 segundos extra. Pero, después de la codificación, el codificador se descarga en lugar de permanecer residente, por lo que el muestreo se ejecuta con esa memoria liberada. En la captura de pantalla del autor, el modo nativo mantiene residentes durante el muestreo tanto el modelo H3 de 11.7 GB como el codificador de 14.6 GB, mientras que un acierto de caché deja únicamente el DiT cargado y reduce la RAM del proceso de 40 GB a 25.5 GB.

Nodos y gestión de la caché

El paquete incluye versiones con caché de los nodos H3 estándar Image-to-Video (FL2VA) y Reference-to-Video (Ref2VA), además de variantes de doble resolución que preparan el conditioning tanto para la pasada base como para un objetivo de upscale, y un selector compartido del nombre del codificador.

Cada solicitud de conditioning distinta genera una entrada de caché que se conserva hasta que se elimina, y las entradas se acumulan si iteras mucho. Un panel integrado de administración de caché permite explorarlas, etiquetarlas y podarlas. Los requisitos son ComfyUI 0.30.0 o posterior, con los nodos H3 nativos.

Disponibilidad

El nodo está en ComfyUI Manager y en el registro como minimaxh3-clipcached, o puedes clonar el repositorio en custom_nodes. La versión actual no implementa expulsión automática de caché, Ref2VA usa ranuras de referencia fijas y los codificadores GGUF no se han probado todavía.

Comentarios

Inicia sesión con GitHub para unirte a la conversación.

Cargando comentarios…
ComfyUI-MiniMaxH3-CLIPCached: cache en disco para H3 | ComfyUI Wiki