Deep learning desde cero: optimiza el entrenamiento

Si hoy entrenas modelos de deep learning, probablemente ya conoces la parte cómoda: eliges una arquitectura, lanzas el script y esperas a que suba la métrica. El problema aparece cuando el entrenamiento tarda demasiado, se come toda la memoria de la GPU, escala mal o cuesta más de lo que justifica el resultado. Ahí es donde ya no basta con “usar modelos”. Necesitas entender qué pasa por dentro para tomar decisiones con criterio.

La idea de este artículo es bajar el tema a tierra. No vamos a venderte magia ni fórmulas universales. Vamos a mirar el entrenamiento desde sus primeros principios: qué se optimiza, dónde se va el tiempo, cómo se usa la memoria y qué cambios sí suelen mover la aguja. Si trabajas en un equipo de producto, data o infraestructura en Latinoamérica, esta guía te sirve para discutir costos, throughput y calidad sin depender de intuiciones vagas.

Qué significa optimizar deep learning de verdad

Optimizar entrenamiento no es solo hacer que el modelo llegue a una métrica alta. Es encontrar el punto donde calidad, tiempo y costo se equilibran para tu caso de uso. En producción, un modelo que mejora 0.2 puntos de accuracy pero duplica el costo de entrenamiento puede ser una mala decisión. Lo mismo pasa si tu equipo tarda 12 horas en iterar y podría hacerlo en 2.

Cuando hablamos de optimización, conviene separar tres variables: throughput, memoria y convergencia. Throughput es cuántos ejemplos procesas por segundo. Memoria es cuánto cabe en la GPU sin hacer trucos raros. Convergencia es cuántos pasos necesitas para llegar a una calidad aceptable. Si mejoras una y rompes otra, no ganaste nada.

El triángulo que manda: tiempo, memoria y calidad

Piensa en esto como un triángulo de trade-offs. Si aumentas batch size, normalmente mejoras throughput, pero puedes empeorar convergencia si no ajustas el learning rate. Si activas mixed precision, sueles bajar memoria y acelerar cómputo, pero debes vigilar estabilidad numérica. Si usas gradient accumulation, simulas batches grandes con menos memoria, pero aumentas el tiempo por update efectivo.

Un ejemplo realista: entrenar un modelo de visión con batch size 256 en una GPU de 24 GB puede ser viable con AMP, pero no necesariamente sin ella. Si tu equipo no sabe por qué funciona, termina probando valores al azar. Si lo entiendes, puedes decidir si conviene cambiar precisión, arquitectura o estrategia de batching.

Qué mide un equipo con criterio

No basta con mirar la loss. Un equipo serio suele seguir al menos estas métricas durante entrenamiento:

• tiempo por step
• ejemplos por segundo
• uso de GPU memory
• utilization de GPU
• estabilidad de loss
• número de pasos hasta converger

La clave es relacionarlas. Por ejemplo, si el tiempo por step baja 20% pero la loss final empeora, no optimizaste el entrenamiento, solo lo aceleraste a costa de calidad. Si la GPU está al 35% de utilization, probablemente tienes un cuello de botella en data loading, no en cómputo.

Primeros principios: qué pasa en un step de entrenamiento

Un step de entrenamiento tiene una secuencia bastante concreta: cargas un batch, haces forward pass, calculas la loss, ejecutas backward pass y actualizas los pesos. En cada uno de esos pasos hay costos distintos. El forward y backward dominan el cómputo, pero el input pipeline puede arruinar todo si llega lento o con transformaciones pesadas.

La intuición útil es esta: entrenar no es solo multiplicar matrices. También es mover datos entre disco, CPU, RAM y GPU. Muchas veces el modelo no está lento por el modelo, sino por el camino que recorren los datos antes de llegar a la GPU.

Forward, backward y optimizer step

El forward pass calcula predicciones. El backward pass calcula gradientes. El optimizer step aplica esos gradientes a los parámetros. En modelos grandes, el backward suele costar tanto o más que el forward, porque necesitas guardar activaciones y derivarlas después.

Si quieres entender dónde se va el tiempo, mira la proporción entre cómputo y memoria. Algunas capas son compute-bound: la GPU trabaja al máximo y el cuello es matemático. Otras son memory-bound: la GPU espera datos porque el acceso a memoria es el límite. Saber cuál domina te evita optimizar lo incorrecto.

Por qué el data pipeline importa tanto

Si tus datos llegan desde un disco lento, una red saturada o un preprocesamiento pesado en CPU, la GPU se queda esperando. Eso baja utilization y eleva el costo por experimento. En práctica, esto pasa mucho cuando se usan augmentations complejas, decodificación de imágenes en runtime o datasets mal shardados.

Una regla simple: si tu GPU reporta baja utilización y el step time es inestable, revisa el pipeline antes de tocar la arquitectura. En muchos casos, el problema no es el modelo sino la alimentación del modelo.

Las palancas que más impactan el entrenamiento

No necesitas 40 trucos. Necesitas conocer las palancas que de verdad mueven el rendimiento. Las más importantes suelen ser batch size, learning rate, precisión numérica, optimizador, data loading y distribución del entrenamiento. Cada una afecta el sistema de manera distinta.

La tabla siguiente resume efectos típicos. No la tomes como receta fija, sino como mapa mental para decidir qué tocar primero.

Batch size no es solo un número grande

Un batch más grande no siempre es mejor. Sí puede mejorar el uso de hardware y reducir ruido en el gradiente, pero también cambia la dinámica de optimización. Si duplicas batch size, muchas veces necesitas ajustar learning rate para mantener una trayectoria parecida. La relación exacta depende del modelo y del optimizador, así que no conviene asumir que “más grande” equivale a “mejor”.

En equipos pequeños, el error común es elegir batch size por memoria disponible y listo. Mejor piensa al revés: define el batch que te da un buen throughput, luego verifica si la convergencia sigue siendo aceptable. Si no, ajusta learning rate, warmup o acumulación de gradientes.

Mixed precision y por qué casi siempre aparece

Mixed precision usa formatos más livianos, como FP16 o BF16, para reducir memoria y acelerar cómputo en hardware compatible. La documentación oficial de PyTorch explica el uso de AMP y sus casos comunes en detalle: https://pytorch.org/docs/stable/amp.html. En práctica, suele ser una de las primeras optimizaciones serias que vale la pena probar.

Pero mixed precision no es un botón mágico. Si tu modelo es sensible a underflow o overflow, necesitas monitorear la estabilidad. En algunos casos, el scaler de pérdida ayuda; en otros, BF16 es más estable que FP16. La decisión depende del hardware y del tipo de modelo.

Optimizers, schedules y estabilidad

Adam, AdamW y SGD no se comportan igual. AdamW suele ser una base fuerte para muchos modelos modernos, especialmente cuando regularización y convergencia importan. Los schedules de learning rate también pesan mucho: warmup, cosine decay o step decay cambian la velocidad con la que el modelo aprende al inicio y al final.

Lo importante no es memorizar nombres, sino entender que el optimizador define cómo se mueven los pesos. Si cambias precision, batch size o arquitectura, probablemente debas revisar también el schedule. Si no lo haces, puedes terminar comparando configuraciones que no son equivalentes.

Cómo leer el cuello de botella sin adivinar

Antes de tocar hiperparámetros al azar, mide. Si no mides, optimizas a ciegas. Un entrenamiento lento puede venir de GPU, CPU, disco, red o del propio modelo. La buena noticia es que muchas veces puedes identificar el cuello con pocos datos.

Empieza por mirar tiempo por step, utilization de GPU y memoria. Si tienes acceso a profiling, mejor. Si no, incluso logs simples con timestamps ya ayudan a distinguir si el problema está en el loader, el forward o el backward.

Señales típicas y qué significan

• GPU utilization alta y memoria casi llena: probablemente estás limitado por cómputo o capacidad de memoria.
• GPU utilization baja y CPU alta: el data pipeline puede estar frenando el entrenamiento.
• Step time muy variable: hay I/O irregular, augmentations costosas o sincronizaciones entre procesos.
• Loss que explota al subir batch size: el learning rate quedó desalineado.

Un ejemplo práctico: si entrenas una red de segmentación y ves que cada step tarda entre 180 y 260 ms sin patrón claro, sospecha del loader. Si además el CPU está al 90% y la GPU al 45%, casi seguro el cuello no está en la red neuronal.

Herramientas que sí conviene mirar

Para PyTorch, el profiler oficial te da una vista bastante útil del tiempo por operación: https://pytorch.org/tutorials/recipes/recipes/profiler_recipe.html. No necesitas usarlo en cada experimento, pero sí cuando una optimización no da el resultado esperado.

También vale la pena revisar métricas del sistema: uso de VRAM, transferencia PCIe, consumo de CPU por proceso y latencia de lectura del dataset. Si trabajas con clusters, agrega métricas de red y colas de jobs. En infraestructura de IA, el entrenamiento no termina en el notebook; termina cuando entiendes el sistema completo.

De un script a una operación de infraestructura

Cuando un equipo pasa de entrenar modelos aislados a operar infraestructura de IA, cambia la conversación. Ya no preguntas solo “¿subió la métrica?”. Preguntas “¿cuánto cuesta cada corrida?”, “¿cuánto tarda en fallar?”, “¿qué parte del pipeline es frágil?” y “¿qué optimización se puede sostener en producción?”.

Ese cambio mental importa mucho en equipos de Latinoamérica, donde el acceso a GPUs puede ser limitado y caro. Si tienes pocas horas de cómputo, no puedes darte el lujo de iterar sin orden. Necesitas un stack que priorice reproducibilidad, observabilidad y eficiencia.

Checklist mínimo para equipos que operan IA

1. Define una métrica de negocio y una métrica técnica por experimento.
2. Registra tiempo por step, memoria máxima y throughput en cada corrida.
3. Separa claramente el costo de data loading del costo del modelo.
4. Usa mixed precision si el hardware lo soporta y valida estabilidad.
5. Ajusta learning rate cuando cambies batch size de forma relevante.
6. Versiona datos, código y configuración para poder repetir resultados.
7. Documenta qué optimización funcionó y cuál no, con números.

Si quieres llevar esto más lejos, te conviene conectar el entrenamiento con prácticas de MLOps. Un pipeline ordenado evita que la optimización dependa de una sola persona que “se sabe los trucos”. También facilita comparar experimentos sin sesgo humano.

Cuándo vale la pena distribuir entrenamiento

Distribuir entrenamiento no es gratis. Agrega complejidad de comunicación, sincronización y debugging. Solo vale la pena cuando una sola GPU ya no alcanza por tiempo o memoria, o cuando el tamaño del modelo exige paralelismo.

Antes de saltar a varias GPUs, pregúntate si ya exprimiste bien una sola. Muchas veces un mejor data loader, mixed precision y un batch size razonable te dan una mejora suficiente sin multiplicar la complejidad operativa. Si igual necesitas escalar, entonces sí toca pensar en DDP, sharding o estrategias más avanzadas.

Tabla resumen

Entender deep learning desde cero no significa aprender solo arquitectura de modelos. Significa entender el sistema completo que hace posible entrenarlos. Si dominas los trade-offs entre cómputo, memoria, datos y convergencia, dejas de depender de recetas y empiezas a operar con criterio.

Ese criterio es el que separa a un equipo que “corre notebooks” de uno que realmente puede sostener infraestructura de IA. Y no hace falta inventar nada raro para llegar ahí: basta con medir bien, cambiar una variable a la vez y saber qué efecto esperas ver.