Cómo construir modelos a medida con ML‑Intern en Hugging Face

Introducción

Hace poco necesitaba una versión ligera de un reescritor de prompts que viene con Qwen‑Image 2.1. El modelo oficial era un 9B que requiere cerca de 20 GB de memoria y tarda en procesar miles de tokens antes de generar un párrafo. En el Hub sólo encontré versiones comprimidas de ese 9B, así que pedí a ML‑Intern que construyera una alternativa más pequeña. El resultado fue un modelo de 0.8B que corre en CPU, entrega salida válida el 99.7% de las veces y usa aproximadamente una cuarta parte de los tokens del “teacher”. Todo el proyecto —incluyendo que el 9B etiquetara 8,797 solicitudes de ejemplo— costó USD 16.

En los días siguientes repetí el proceso y convertí ideas en modelos públicos alojados en Hugging Face, con las evaluaciones disponibles en las model cards. En este artículo explico cómo funciona ML‑Intern, cómo estructuro mis prompts y detallo tres proyectos ilustrativos, con énfasis en lecciones prácticas para equipos en América Latina.

¿Qué hace ML‑Intern y por qué importa?

ML‑Intern actúa como un asistente automatizado que planifica el trabajo, pide permiso antes de gastar dinero, ejecuta pruebas iniciales, entrena, evalúa y publica modelos en la infraestructura de Hugging Face. Algunos puntos clave del flujo:

• Comienza sin presupuesto y necesita autorización explícita para emplear recursos pagos; esto hace que los límites de gasto sean estrictamente respetados.
• Ejecuta una prueba corta (smoke test) antes de lanzar el entrenamiento completo, lo que evita gastar tiempo y dinero en pipelines rotos.
• Publica el modelo y la evaluación final en el Hub, incluyendo la model card.

Esto habilita a equipos con restricciones de cómputo o presupuesto a iterar rápidamente sobre ideas, produciendo modelos útiles que corren incluso en CPU o en GPUs de gama media.

Cómo redacto el prompt para ML‑Intern (estructura y recomendaciones)

La primera entrada es donde invierto la mayor parte del esfuerzo. Mis prompts evolucionaron: el primer brief tenía alrededor de 450 palabras y, para el sexto proyecto, llegué a escribir casi 2,000 palabras. Todos mis prompts están disponibles tal cual en GitHub: yvrjsharma/ml-intern-prompts.

Elementos que siempre incluyo:

• Idea en una línea y objetivo: qué quiero y por qué.
• Componentes exactos: dataset, modelo base, script de entrenamiento y pasos reproducibles.
• Sección “Verified facts, do not re-derive” con validaciones que ya comprobé (por ejemplo, compatibilidad de trainers, issues abiertos en GitHub, paths de datos). Esto hace que el agente gaste su presupuesto de cómputo en el trabajo y no en redescubrir cosas que ya sé.
• Dos líneas críticas: 1) pedir un baseline (zero‑shot) del modelo base en la misma métrica antes de entrenar, y 2) definir un smoke test con una verificación (por ejemplo, 50 pasos y comprobar que los pesos guardados cambiaron) antes de aprobar la ejecución completa.
• Entregables esperados y tope de gasto: especificar qué debe incluir la model card y limitar el costo, por ejemplo “Cap total spend at USD 12 and ask me before exceeding it.”

Si no incluyo presupuesto, ML‑Intern propone opciones y me pide elegir. Aunque no todo es imprescindible en el primer intento, las secciones de baseline y smoke test son especialmente útiles para saber si el esfuerzo aporta mejora real.

Caso 1: clasificador de enfermedades cítricas (visión aplicada)

Problema: un modelo general de visión describe una hoja amarillenta, pero diagnosticar si se trata de ácaros, una deficiencia de magnesio o proponer remedios es más complejo.

Qué hice: reuní un dataset combinando tres fuentes del proyecto Project‑AgML en el Hub y obtuve 3,017 imágenes anotadas que cubren 21 plagas, enfermedades, deficiencias nutricionales y enfoques de tratamiento.

Entrenamiento y resultados: ML‑Intern afinó Qwen3.5‑2B con esos ejemplos y, crucialmente, benchmarking del modelo base antes del entrenamiento. En 335 fotos de prueba el modelo base acertaba la etiqueta correcta el 14.9% de las veces; tras dos épocas en una A10G, el modelo afinado alcanzó 52.8%. El costo de cómputo fue de aproximadamente USD 1.90.

Impacto: un salto de precisión así convierte un modelo general en una herramienta con aplicabilidad directa para agronomía, extensión agrícola y startups agrotech en la región.

Caso 2: LoRA para un personaje (generación de estilo)

Problema: quería que un personaje llamado Huggy, dibujado en el estilo plano asociado a los assets de marca, estuviera disponible para generar imágenes coherentes.

Qué hice: pedí un LoRA sobre FLUX.2 klein base 4B, entrenado con 84 dibujos captioned del dataset Chunte/huggy_for_training. El agente guardó checkpoints cada 100 pasos y renderizó el mismo conjunto de prompts para cada checkpoint, lo que facilitó elegir el punto óptimo.

Resultados: en el paso 200 Huggy apareció completamente on‑model; a partir del paso 500 el estilo empezó a filtrarse en prompts no relacionados. El LoRA también resultó utilizable en el modelo klein destilado con apenas 4 pasos. Costo aproximado: USD 7.60.

Lección: guardar checkpoints frecuentes y visualizar el efecto en un conjunto fijo de prompts simplifica la selección de versiones y evita sobreajuste estilístico.

Caso 3: LoRA de ángulo de cámara (nueva capacidad)

Problema: ofrecer vistas rotadas de un objeto (p. ej. 45° a la izquierda) para Qwen‑Image 2.1.

Qué hizo ML‑Intern: renderizó 1,030 objetos escaneados de Google Scanned Objects en 24 ángulos cada uno (24,722 imágenes transparentes) en un trabajo CPU de coste insignificante, seleccionó 461 objetos para entrenamiento y 40 para pruebas, y generó 1,844 pares antes‑después distribuidos en 23 instrucciones de cámara.

Entrenamiento: 2,000 pasos en cerca de 90 minutos en una A100 (~USD 3.75). El proyecto ocupó medio día y 48 jobs en total (incluyendo reenvíos por issues menores). Costo total aproximado: USD 16.

Resultado práctico: añadir una capacidad puntual al modelo base con un dataset sintético y una pipeline automatizada resulta rápido y barato.

Lecciones prácticas y recomendaciones para equipos latinoamericanos

• Pequeños modelos pueden bastar: un 0.8B que corre en CPU permite despliegues más accesibles para mercados con limitaciones de infraestructura.
• Controlar presupuesto desde el prompt evita sorpresas: exigir que el agente pida permiso antes de gastos mayores es una buena práctica para equipos con recursos limitados.
• Validar con baseline y smoke tests: siempre comparar con la capacidad zero‑shot y asegurar que los pesos cambian en pruebas cortas.
• Documentar y publicar: publicar modelos y model cards en el Hub facilita colaboración, auditoría y adopción local.

Para América Latina, estas prácticas son útiles en agro, salud pública local, educación y startups que necesitan soluciones concretas sin invertir en infraestructuras costosas.

Conclusión

ML‑Intern no es magia, es una orquestación disciplinada: plantea, prueba y ejecuta trabajos reproducibles con límites de gasto. Con prompts bien estructurados y datos relevantes pueden generarse modelos prácticos —desde diagnóstico de cultivos hasta LoRAs de estilo— con costos sorprendentemente bajos. Si están considerando prototipar soluciones ML en la región, revisar los prompts en yvrjsharma/ml-intern-prompts y empezar con un proyecto pequeño y un tope de gasto estricto es una buena manera de validar ideas rápidamente.