1. Conserva el mensaje y el contexto antes de relanzar
Deja de añadir tareas a la cola. Anota el texto exacto del error, el archivo o la consulta afectados, el número de elementos procesados juntos y el paso alcanzado. ¿El modelo se estaba cargando, el cálculo avanzaba o la salida se estaba escribiendo? Guarda los ajustes en una nota y los resultados ya terminados en su carpeta.
Una pantalla congelada o una aplicación cerrada sin explicación no bastan para identificar la causa. Recupera su registro cuando exista. Un fallo de conexión, una entrada no válida y una memoria saturada pueden producir síntomas parecidos en la interfaz. Si el software no precisa nada, escribe «causa no determinada» y prepara una prueba mínima en lugar de inventar un diagnóstico.
2. Separa la memoria de la GPU, la memoria del sistema y el espacio en disco
La memoria de la GPU se usa para los elementos del cálculo en la tarjeta. La RAM del servidor y el almacenamiento responden a otras necesidades. Las capacidades mostradas en las fichas de GPU de BriefGPU no describen la RAM o el disco realmente disponibles. Comprueba el recurso mencionado por el mensaje y la información de tu entorno.
En Python, MemoryError designa un fallo de asignación de memoria; ese nombre por sí solo no indica una falta de VRAM. El código ENOSPC corresponde a una falta de espacio en el dispositivo de destino. Estas referencias orientan la búsqueda, pero el registro de la aplicación sigue siendo necesario para localizar la operación.
| Observación | Primera comprobación | Lo que una GPU más grande no resuelve por sí sola |
|---|---|---|
| Mensaje CUDA out of memory durante el cálculo | Memoria de la tarjeta utilizada, otras tareas y tamaño del grupo | Una incompatibilidad del software o un archivo corrupto |
| MemoryError durante la lectura de los archivos | Memoria del proceso, cantidad de datos cargados en RAM | La carga de toda la carpeta en la memoria del sistema |
| No space left on device durante una exportación | Espacio y posible cuota de la carpeta de salida o temporal | Un disco lleno o un límite de almacenamiento |
| Aplicación cerrada sin mensaje aprovechable | Registro, paso alcanzado y prueba con una sola entrada | Una causa aún desconocida |
3. Vuelve a una entrada y a un solo trabajo activo
Comprueba primero los procesos que tú mismo hayas lanzado. Una vista previa, una sesión antigua o una segunda herramienta pueden seguir trabajando. Cierra correctamente las tareas que ya no sean útiles después de conservar su estado. No termines un proceso que no reconozcas ni reinicies todo el entorno para ahorrar unos minutos de diagnóstico.
Retoma la entrada que falló, sola, sin disminuir su calidad. Si pasa de forma aislada pero falla en grupo, el número de elementos simultáneos se convierte en una pista. Reduce, por ejemplo, un grupo de cuatro a dos y luego a uno si es necesario. El número de archivos de la carpeta sigue siendo el mismo; solo cambia la cantidad procesada al mismo tiempo.
Algunas herramientas ofrecen un procesamiento secuencial para limitar los picos de memoria. Diffusers documenta, en particular, el fraccionamiento de la decodificación de un grupo de imágenes. Esta posibilidad depende del pipeline utilizado: consulta sus opciones antes de activar un ajuste encontrado para otro modelo.
4. Reduce la carga sin perder el resultado solicitado
Si una entrada sola falla, examina sus dimensiones o su longitud. Para una imagen, pasar de 2048 × 2048 a 1024 × 1024 divide el número de píxeles por cuatro. Esto no garantiza una memoria total dividida por cuatro: el modelo y los demás elementos mantienen sus propias necesidades. Una reducción solo es aceptable si la salida conserva los detalles necesarios.
Para un asistente, distingue los documentos proporcionados, la pregunta y la respuesta generada. La caché de generación puede consumir más memoria con un contexto largo; los mecanismos exactos dependen del modelo. Prueba una solicitud más corta o una sola petición a la vez. No elimines el fragmento que contiene la respuesta y luego concluyas que el problema está resuelto.
Conserva siempre la entrada original. Nombra la variante de prueba y escribe qué cambia. Si la herramienta ofrece un particionado en mosaicos o un traslado de ciertos elementos a la RAM, consulta su documentación y controla las uniones, la calidad y el tiempo observado. Una opción que ahorra VRAM puede trasladar la limitación a otro lugar.
5. No confundas memoria reservada con memoria útil
Con PyTorch, la memoria reservada por el asignador y la ocupada por los tensores son dos medidas distintas. Vaciar la caché no utilizada no libera los tensores aún activos. Por lo tanto, un comando de limpieza no convierte una carga demasiado grande en una carga compatible.
Si reiniciar limpiamente tu aplicación ayuda, vuelve a ejecutar después el mismo caso pequeño y anota el resultado. Un éxito tras el reinicio no demuestra por sí solo que se haya corregido una fuga de memoria. Si el uso aumenta en cada pasada idéntica, guarda esa observación y consulta la documentación o el soporte del software antes de acumular reinicios.
Ejemplo: aislar el problema en una carpeta de doce imágenes
Este es un escenario ilustrativo, sin mediciones de hardware. Una freelancer prepara doce imágenes, de las cuales dos tienen grandes dimensiones y texto fino. El procesamiento por grupos de cuatro falla. Ella guarda el mensaje y luego prueba una de las imágenes grandes sola, con la calidad inicial. La tabla muestra cómo interpretar posibles observaciones.
En este escenario, ella adopta los grupos de dos solo después de haber comprobado juntas las dos imágenes grandes y algunas imágenes corrientes. Verifica el texto y los contornos en los archivos exportados. No generaliza este resultado a todos los tamaños de imagen, a todos los modelos ni a otro software.
| Prueba del escenario | Observación hipotética | Decisión local |
|---|---|---|
| Cuatro imágenes simultáneas | Fallo de memoria | Conservar el error y reducir el grupo |
| Una imagen grande, mismos ajustes | Salida completa y aceptable | La calidad objetivo puede funcionar en este caso aislado |
| Dos imágenes grandes juntas | Salidas completas y aceptables | Probar este grupo en una tanda corta |
| Imagen reducida drásticamente | Cálculo terminado, texto ilegible | Descartar esta reducción a pesar del éxito técnico |
Cuándo otra capacidad se convierte en una pista justificada
Compara otra tarjeta cuando la falta de memoria GPU esté identificada, el caso imprescindible falle por sí solo y las reducciones compatibles con tu calidad no sean suficientes. Conserva el software, la versión, los parámetros y la entrada en cuestión: este expediente hace que la próxima prueba sea comparable. No permite deducir exactamente cuántos GB adicionales serán suficientes.
Un error al cargar el modelo también puede limitar el interés de reducir el grupo: una parte importante de la carga existe antes de la primera entrada. Las opciones de precisión o de cuantización cambian las condiciones de ejecución y a veces los resultados; requieren una prueba aparte. Añadir lotes no unifica automáticamente la memoria de varias tarjetas.
Termina con un diagnóstico utilizable
Tu nota final cabe en cinco elementos: mensaje y paso, recurso sospechoso, entrada conservada, ajuste que funciona o falla, control de calidad realizado. Añade lo que sigue siendo desconocido. Si ningún caso pequeño funciona, deja de repetir el lote completo y pide ayuda con esta información.
No borres tus únicos originales para liberar disco, no bajes varios parámetros a la vez y no cuentes una salida parcial como un éxito. Reserva tiempo para guardar los resultados válidos. El diagnóstico debe reducir la incertidumbre; no necesita convertirse en una sesión interminable de ajustes.