ML in a Box: Analyzing Containerization Practices in Open Source ML Projects
Este artículo presenta el primer estudio empírico a gran escala de 1.993 Dockerfiles de aprendizaje automático (ML) de código abierto, revelando que, si bien los contenedores desempeñan funciones distintas en los flujos de trabajo de ML, a menudo son grandes e ineficientes debido a las reconstrucciones frecuentes desencadenadas por la experimentación, lo que impulsa la identificación de siete patrones de refactorización específicos para mejorar la eficiencia de la construcción y reducir la huella.
Artículo original dedicado al dominio público bajo CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
Imagina que eres un chef dirigiendo una cocina masiva y de alta tecnología. En el mundo del Aprendizaje Automático (ML), tus "recetas" son código, tus "ingredientes" son datos y modelos, y tu "cocina" es un contenedor. Un contenedor es como una caja de cocina autónoma y portátil que contiene todo lo necesario para cocinar un plato específico, asegurando que sepa igual ya sea que estés cocinando en Nueva York, Tokio o en una nave espacial.
Durante mucho tiempo, la gente supo que estas cajas de cocina eran útiles. Pero nadie sabía realmente qué tan grandes eran, cuánto tiempo tardaban en empacarse o qué tan seguido los chefs tenían que tirar toda la caja a la basura y empezar de nuevo solo porque movieron un frasco de especias.
Un equipo de investigadores decidió echar un vistazo al interior de 1,993 de estas cajas de cocina de ML de 392 proyectos diferentes para ver qué estaba pasando realmente. Aquí está lo que encontraron, servido con una dosis de realidad.
El tamaño de las "Cajas de Cocina": Es un gran problema
Primero, pesaron las cajas. Podrías pensar que un contenedor es ligero y ágil, pero estas cajas de ML son gigantes.
- En promedio, una caja pesa 10.27 GB. Eso es como cargar toda una biblioteca de enciclopedias en tu mochila solo para hacer un sándwich.
- Las cajas de "Entrenamiento" (donde la IA aprende) son las más pesadas, con un promedio de 17.25 GB. ¡Algunos de estos monstruos incluso alcanzan los 125 GB!
- Las cajas de "Inferencia" (don donde la IA simplemente hace el trabajo) son más pequeñas, alrededor de 1.72 GB, pero tampoco son precisamente de bolsillo.
¿Y empacar estas cajas? Eso toma tiempo. El promedio de un "build frío" (empacar una caja desde cero) es de 8.84 minutos. Para las grandes cajas de entrenamiento, puede tomar más de 14 minutos. Es mucho tiempo para esperar solo para ver si tu código funciona.
El momento "Ups": Por qué tiramos las cajas a la basura
Aquí está la parte complicada. En una cocina normal, si cambias una receta, solo ajustas las instrucciones. Pero en el mundo de ML, la cocina trabaja con un sistema estrico de "capas". Imagina construir una torre de bloques. Si cambias el color del tercer bloque, tienes que desarmar el tercero, el cuarto, el quinto y así hasta llegar arriba, incluso si los bloques superiores no cambiaron en absoluto.
Los investigadores descubrieron que el 44.4% de todos los cambios que los desarrolladores hacían a sus proyectos provocaban una reconstrucción total del contenedor. Eso significa que casi la mitad de las veces, estaban tirando todo ese trabajo duro y empezando de nuevo.
¿Qué causó el descarte?
No fue usualmente la receta en sí (el Dockerfile). ¡Fueron los ingredientes!
- El 96.4% de las reconstrucciones ocurrieron porque alguien cambió un archivo que se copió dentro de la caja (como un conjunto de datos o un archivo de código).
- Solo el 1.1% de las reconstrucciones fueron porque alguien cambió las instrucciones reales de cómo construir la caja.
El desperdicio: El 70% del trabajo es para nada
Esta es la parte más triste de la historia. Cuando la "torre de capas" se rompe, la cocina intenta reutilizar los bloques que ya construyó. Pero los investigadores descubrieron que el 71% del trabajo se desperdició.
- Piénsalo así: Pasas 10 minutos construyendo una torre de bloques. Derribas el tercer bloque. Intentas reutilizar los dos primeros bloques, pero luego tienes que reconstruir el resto. Al final, solo reutilizaste cerca del 30% de tu esfuerzo. El otro 70% fue simplemente volver a hacer el trabajo que ya habías hecho.
¿Por qué sucede esto?
Depende de qué estés cambiando.
- Si estás ajustando el experimento (cambiando el cerebro o los datos de la IA), es más probable que rompas la torre. Esto sucede el 46% de las veces para las cajas de entrenamiento.
- Si estás actualizando la infraestructura (como la plomería o la electricidad de la cocina), casi siempre rompes la torre y pierdes casi todo tu progreso.
La buena noticia: Los chefs inteligentes encontraron atajos
A pesar del desorden, los investigadores encontraron que algunos chefs inteligentes ya estaban solucionando estos problemas. Observaron las "mejores" cocinas (aquellas que desperdiciaron menos tiempo) y encontraron 7 trucos específicos que usaron para detener el desperdicio. Estos no son solo suposiciones; son cambios reales que los desarrolladores hicieron y que realmente funcionaron.
Aquí están los 7 trucos:
- No empaques los comestibles: En lugar de copiar enormes conjuntos de datos dentro de la caja, solo dile a la caja dónde encontrarlos cuando comience a cocinar.
- No empaques el modelo: Lo mismo para el modelo de IA. No lo hornees dentro de la caja; cárgalo desde el exterior cuando sea necesario.
- Mueve el trabajo pesado: Si tienes que descargar un modelo grande, hazlo temprano en la receta. De esa manera, si cambias un archivo pequeño más tarde, la descarga grande se mantiene en caché (guardada).
- Divide la cocina: Si necesitas una caja tanto para CPUs como para GPUs, no hagas una sola caja gigante con todo. Haz dos cajas más pequeñas y especializadas.
- Elige las herramientas adecuadas: No instales la versión de "GPU" de una herramienta si solo necesitas la versión de "CPU". Eso ahorra un montón de espacio.
裙6. Mueve lo volátil: Si cambias tus archivos de configuración a menudo, ponlos después de las instalaciones pesadas en la receta para que no rompan las capas pesadas. - No descargues todo el historial: Cuando obtengas código de internet, no descargues todo el historial del proyecto. Solo toma la última instantánea.
La conclusión
El artículo no dice que estos problemas estén "solucionados". Dice que, en este momento, los contenedores de ML son enormes, lentos y frágiles. Los desarrolladores están desperdiciando una cantidad masiva de tiempo (aproximadamente el 70% de su esfuerzo de reconstrucción) porque están empacando demasiadas cosas en la caja y rompiendo el caché demasiado pronto.
Pero la buena noticia es que sabemos cómo arreglarlo. Al usar estos 7 trucos, los equipos pueden hacer que sus contenedores sean más pequeños y sus construcciones más rápidas. No es magia; es solo una mejor organización. Los investigadores midieron todo esto construyendo realmente las cajas y contando los minutos, por lo que sabemos que estos números son reales. La próxima vez que veas un proyecto de aprendizaje automático, recuerda: no se trata solo del código; se trata de cómo empacas la cocina.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.