Por qué desactivar Gradient Checkpointing causa OOM en AI Toolkit

Si no tienes completamente claro por qué Gradient Checkpointing está desactivado, la regla más segura es sencilla:

Vuelve a activarlo.

En los modelos de imagen grandes de AI Toolkit, desactivar gradient_checkpointing es una de las formas más rápidas de convertir un entrenamiento estable en un fallo por OOM.

Esta guía explica:

qué hace Gradient Checkpointing
por qué desactivarlo puede disparar el consumo de VRAM
qué familias de modelos son las más sensibles
cuándo es razonable probar GC desactivado
qué cambiar en su lugar si lo que realmente buscas es velocidad

Respuesta rápida

Gradient Checkpointing es fundamentalmente un intercambio memoria vs velocidad.

Activado = menor pico de VRAM, generalmente más seguro
Desactivado = mayor pico de VRAM, a veces más rápido, mucho más fácil que ocurra OOM

Para la mayoría de usuarios, especialmente con modelos de imagen grandes, no es un control de calidad. Es un control de estabilidad.

Lista rápida de verificación

✅ Haz clic en Show Advanced
✅ Dentro de train:, asegúrate de que gradient_checkpointing: true
✅ Reintenta con el mismo Batch Size y las mismas resoluciones primero
✅ Si sigue dando OOM, reduce el Batch Size y elimina el bucket de resolución más alto
✅ Si tu problema real es el muestreo de vista previa, reduce Sample Width / Height / Sample Steps en vez de desactivar GC

1) Qué hace realmente Gradient Checkpointing

No necesitas la teoría profunda de PyTorch para usarlo correctamente.

Una forma práctica de entenderlo:

con GC activado, AI Toolkit retiene menos datos de activación intermedios en memoria y recalcula algunos cuando los necesita
con GC desactivado, más datos quedan residentes en VRAM, así que el entrenamiento puede ir más rápido si hay memoria disponible

Suena bien hasta que se combina con:

alta resolución
múltiples buckets de resolución
batch size grande
muestreo costoso
arquitecturas pesadas como Qwen Edit, Z-Image, FLUX / modelos tipo Flex

Entonces el margen de memoria desaparece muy rápidamente.

2) Por qué desactivarlo causa OOM "de repente"

Los usuarios suelen pensar:

"Solo cambié un interruptor."

Pero ese interruptor determina cuánta memoria de activación se retiene durante el entrenamiento.

Una configuración que era "pesada pero viable" con GC activado se convierte en "al límite o imposible" con GC desactivado.

Por eso el fallo parece tan repentino:

mismo dataset
mismo modelo
mismos prompts de vista previa
mismo batch size
solo se cambió GC
ahora falla por OOM en el paso 2, paso 3 o durante la primera vista previa

3) Familias de modelos de alto riesgo con GC desactivado

Basándonos en patrones reales y recurrentes de OOM en AI Toolkit, estas combinaciones deben considerarse peligrosas por defecto:

Familia de modelo	Alto riesgo con GC desactivado	Primer intento más seguro
Z-Image	Buckets de 1024–1536 con batch grande	GC activado, empezar conservador, luego escalar
Qwen-Edit	Workflows de 1024 con batch grande / múltiples condiciones pesadas	GC activado, Batch Size 1, reducir carga de vista previa
FLUX-dev / modelos tipo Flex	batches grandes o entrenamiento multi-bucket de alta resolución	GC activado, Batch Size 1–4 según el margen disponible

Un modelo mental útil:

Z-Image se vuelve peligroso rápidamente al combinar alta resolución + batch grande + GC desactivado
Qwen Edit se vuelve peligroso rápidamente al combinar 1024 + condicionamiento pesado + GC desactivado
FLUX / tipo Flex se vuelven peligrosos rápidamente al combinar batch grande + GC desactivado

4) Dónde cambiarlo en RunComfy AI Toolkit

En la interfaz actual de RunComfy puedes ver directamente ajustes como:

Batch Size
Gradient Accumulation
Steps
Unload TE
Cache Text Embeddings

Sin embargo, gradient_checkpointing se verifica más fácilmente a través de la configuración avanzada.

Paso a paso

Abre tu trabajo
Haz clic en Show Advanced
Busca el bloque train:
Configura:

train:
  gradient_checkpointing: true

Guarda el trabajo
Reintenta sin cambiar nada más

Si la misma configuración funciona ahora, has confirmado que GC era el problema.

5) Qué hacer en su lugar si tu objetivo real es la velocidad

Muchos usuarios desactivan GC porque quieren un entrenamiento más rápido.

Es comprensible, pero normalmente es el primer experimento de velocidad equivocado.

Prueba esto antes de desactivar GC:

A. Abaratar el muestreo de vista previa

En el panel Sample:

reduce Width / Height
reduce Sample Steps
aumenta Sample Every
activa temporalmente Disable Sampling para verificar la estabilidad del entrenamiento

Esto suele dar más velocidad práctica que perseguir una configuración arriesgada con GC desactivado.

B. Mantener el batch pequeño, escalar con acumulación si es necesario

En el panel Training:

mantén Batch Size conservador
aumenta Gradient Accumulation solo si quieres un batch efectivo ligeramente mayor sin un gran salto en el pico de VRAM

C. Eliminar primero el bucket más alto

En Datasets:

mantén 512 / 768
reincorpora 1024 / 1536 solo después de un entrenamiento estable

D. Usar la ruta de baja memoria prevista para el modelo

Para algunas arquitecturas, la ruta correcta no es "GC desactivado", sino:

low_vram: true
cuantización específica del modelo
optimización del text-encoder específica del modelo

Sigue la guía del modelo, no suposiciones genéricas.

6) ¿Cuándo es realmente aceptable probar GC desactivado?

Trata GC desactivado como un experimento avanzado, no como valor por defecto.

Condiciones razonables:

ya tienes un entrenamiento estable
el Batch Size sigue siendo conservador
no estás ya al límite con el bucket más grande
las vistas previas son baratas o están desactivadas
tienes suficiente margen de VRAM
estás cambiando una sola variable, no varias

Un buen flujo de prueba:

estabiliza el trabajo con GC activado
mantén el resto de la configuración idéntica
desactiva GC
vigila:

OOM en los primeros pasos
OOM durante el muestreo
picos intermitentes de bucket

Si ocurre alguno de esos casos, reactiva GC y déjalo así.

7) Qué no es GC desactivado

Gradient Checkpointing no es:

un potenciador mágico de calidad
un interruptor para mejorar el parecido
la primera solución correcta para muestras malas
un buen primer experimento cuando ya tienes OOM

Si tus muestras son débiles, revisa:

calidad del dataset
captions
rank
steps
paridad de vista previa

No asumas que GC desactivado es la respuesta.

8) Preguntas frecuentes

¿Activar GC afecta la calidad de salida?

Normalmente no es el compromiso que los usuarios notan en la práctica.

El intercambio real es principalmente memoria vs velocidad.

Activé GC y sigo teniendo OOM. ¿Qué hago ahora?

Tus siguientes palancas son:

Batch Size
bucket de resolución más alto
coste del muestreo de vista previa
para vídeo, Num Frames

¿Debería empezar alguna vez un primer entrenamiento con GC desactivado?

Para la mayoría de usuarios: no.

Demuestra estabilidad primero, luego experimenta.

Resumen en una línea

Si estás teniendo OOM en AI Toolkit y gradient_checkpointing está desactivado, corrígelo primero.

GC activado es el valor seguro por defecto. GC desactivado es un experimento avanzado de velocidad.