en el aprendizaje automático son los mismos.
Codificar, esperar resultados, interpretarlos, volver a codificar. Además, algunas presentaciones intermedias del progreso. Pero que las cosas sean prácticamente iguales no significa que no haya nada que aprender. ¡Todo lo contrario! Hace dos o tres años, comencé el hábito diario de escribir las lecciones que aprendí de mi trabajo de ML. Al repasar algunas de las lecciones de este mes, encontré tres lecciones prácticas que se destacan:
Usar documentos README para usted mismo Solicitar cortes MIG en lugar de GPU completas Movimientos de dispersión a lo largo del día
Mantenga un archivo README para su yo futuro
La mayoría de los archivos README se escriben pensando en otras personas. Están ahí para incorporar nuevos colaboradores o para hacer que un repositorio de código abierto sea utilizable por extraños.
Escribe uno para ti también, especialmente para tu yo futuro.
Cuando estás en medio de un proyecto, todas las rutas, comandos y configuraciones sutiles viven en tu cabeza. Después de una pausa, no tanto. Me encontré con esto recientemente cuando tuve que preparar una actualización para un artículo. En la investigación de ML, las revisiones suelen tardar meses. En ese tiempo, pasa al siguiente proyecto con nuevos conjuntos de datos, nuevo código, nuevas convenciones. Cuando finalmente llega la revisión, regresas al proyecto anterior y… pasas medio día reconstruyendo qué guión produjo qué figura.
Esto supone mucho estrés si la fecha límite se acerca pronto.
Prepararse para el propio olvido es parte del trabajo. Un pequeño README ahorra un gran dolor de cabeza.
Qué capturar (para ti)
Mantenlo práctico. Tu yo futuro no quiere prosa; Quieren el “cómo”:
Inicio rápido del proyecto. Configuración del entorno, versión exacta de Python, archivo env o comandos conda/pip. Ubicaciones de datos. Dónde viven los datos sin procesar y procesados; cómo descargar, almacenar en caché y suma de comprobación. Tenga en cuenta cualquier error (por ejemplo, “los mosaicos NDVI se voltean de sur a norte después de volver a muestrear”, como se indica en mis publicaciones anteriores). Reproducir resultados. Un comando por artefacto: figuras, tablas y puntos de control. Entrenamiento y evaluación. Los comandos exactos para ejecutar los experimentos principales; cómo reanudar; cómo poner semillas. Búsqueda de hiperparámetros. El comando que realmente usaste, con rangos; donde se registran los resultados. Errores comunes. Todo lo que sepa lo olvidará (variaciones de entorno requeridas, indicadores de GPU, convenciones de nomenclatura de archivos). Registro de cambios. Viñetas de una línea de cambios significativos.
Una plantilla mínima y genérica que puedes adaptar a todos los proyectos:
# ## Inicio rápido # env conda create -n proj python=3.10 -y conda enable proj pip install -r requisitos.txt ## Datos # descargar y preprocesar herramientas de python/download_data.py –out data/raw python tools/preprocess.py –in data/raw –out data/procesado ## Train python train.py –cfg cfgs/base.yaml –seed 42 ## Evaluar python eval.py –ckpt run/exp123/best.ckpt –split test ## Reproducir figuras python scripts/fig_1.py # salidas a figs/fig_1.png python scripts/tab_2.py # escribir tablas/tab_2.csv ## Búsqueda de hiperparámetros pythonweep.py –study local.pkl –n-trials 100 ## Notas / Errores – Requiere CUDA 12.1 – Establezca `WANDB_MODE=offline` si no hay Internet
Cortes MIG para una programación rápida
Para entrenar la generación actual de modelos de lenguaje grandes se necesitan cientos (o miles) de GPU de alta gama. Pero la mayor parte del trabajo diario de ML no requiere modelos a escala LLM. Muchos problemas se resuelven con CNN compactas o MLP pequeñas, y esas no necesitan una GPU A100/H100 completa.
Solicitar una GPU completa para un modelo pequeño desperdicia recursos y te lleva al final de la cola. Aprendí esto de la manera más difícil este mes: estaba entrenando un MLP de 4 capas y esperando mucho tiempo para programarme. En mis solicitudes de programación, solicité una GPU de gama alta. Por supuesto, estos tienen una gran demanda en aquellos trabajos que realmente los necesitan (como perfeccionar los LLM).
Una vez que cambié a un corte MIG, los trabajos comenzaron inmediatamente y mi velocidad de iteración aumentó.
¿Qué es MIG y por qué usarlo?
MIG (GPU de instancias múltiples) le permite dividir una GPU NVIDIA reciente en varios “porciones” aisladas. Una GPU grande se convierte en hasta siete GPU virtuales más pequeñas y la VRAM completa se divide entre estas porciones. En esencia, cada segmento es una GPU más pequeña. Y para muchas cargas de trabajo, esas pequeñas porciones son más que suficientes.
Hay un beneficio adicional: menos personas solicitan porciones (porque no conocen la oportunidad), por lo que los programadores pueden adaptar su trabajo de inmediato. Esto le permite iterar sobre sus modelos más rápido, reduciendo el tiempo para obtener buenos resultados.
Para aplicarlo en la práctica.
Consultar disponibilidad. Pregunte a los administradores de su clúster o consulte los documentos del programador para conocer los nombres de las particiones MIG (por ejemplo, 1g.10gb, 2g.20gb). Adapte el tamaño de su solicitud. Empiece poco a poco. Si VRAM OOM, aumente un tamaño. No utilice GPU completas de forma predeterminada. Memoria de perfil temprana. Ejecute un pequeño lote para leer el pico de VRAM; Elija la porción más pequeña que deje entre un 10% y un 20% de espacio libre. Modela tu trabajo. Mantenga un script de trabajo para MIG y otro para GPU completas; cambiar por bandera.
Combatir la permanencia prolongada con movimiento
La mayoría de los trabajos informáticos se realizan frente a una, bueno, computadora. Todos hemos notado que cuanto más tiempo pasamos, más encorvada se vuelve nuestra postura. Estamos redondeados hacia adelante; todo el trabajo está hecho frente a nosotros*.
No es una buena posición para mantenerla durante mucho tiempo, pero es bastante común hoy en día. Para la gente de ML, las computadoras son nuestro conjunto de herramientas y (necesitamos) dedicar un tiempo considerable a este conjunto de herramientas.
Afortunadamente, no necesitamos pasar tiempo en malas posturas cuando trabajamos en una pantalla (no, esas dos no están vinculadas por definición).
Me di cuenta de esto (nuevamente, porque parece que vuelvo a caer en viejos hábitos) este mes: horas de lectura, codificación y reuniones empujaron mis hombros hacia adelante y bloquearon la parte superior de la espalda. Luego, después de unos días de leer mucho, mis hombros me recordaron que debía cambiar algo.
Resultó que la solución era fácil y no requiere un gimnasio ni un entrenamiento completo. Sólo requiere alternar posiciones y breves refrigerios de movimiento.
Reuní un pequeño programa, del cual utilicé partes a lo largo del día (consulte YouTube para ver cualquiera de esos ejercicios si no los conoce. Ese es un metaconocimiento que podría ayudarlo a hacer su trabajo mejor, por más tiempo y de manera más saludable):
Reuniones de solo audio: levántese y camine. Si debe permanecer cerca del escritorio, adopte una postura dividida (un pie hacia adelante) para abrir las caderas. Reinicios de dos minutos (p. ej., después de una pausa para el café o al salir de la impresora, etc.): Separaciones de banda o tirones de cara (10 a 15 repeticiones) Estiramiento de pectorales de pared (30 a 45 segundos de cada lado) Estiramiento de flexores de cadera/estiramiento en sofá (30 a 45 segundos de cada lado) Bloques de lectura de pie: imprima un documento o lea en una tableta mientras está de pie; bloques alternos de pie y sentado.
Más allá, descubrí que una sesión corta por la mañana hace que mis hombros se sientan mejor y mejora la concentración a lo largo del día, una ventaja adicional bienvenida, ya que el trabajo de ML exige concentración:
5 min de cardio fácil (caminar o subir escaleras) 5 min de movilidad (rotaciones torácicas, círculos de hombros, sentadilla profunda) 5 min de fuerza ligera (estocadas, flexiones contra el escritorio, remo con banda)
* Un argumento que se plantea con frecuencia: ¿acaso no tenemos todos los trabajos hechos delante de nosotros? O, dicho de otra manera: ¿qué trabajo requiere que trabajemos con las manos detrás de nosotros? Bien, excepto quizás las gimnastas, prácticamente todos los trabajos suceden frente a nosotros. Después de todo, ¡ahí es donde están nuestros ojos! Pero: los trabajos no informáticos reciben movimientos diversificados a lo largo del día: coger algo de un estante, arrastrar algo, etc. Lo que cuenta es la alternancia.