Ertas para Ingenieros de ML y Profesionales de Fine-Tuning

The Challenge

El ecosistema de fine-tuning de código abierto es poderoso pero profundamente fragmentado. Unsloth optimiza la velocidad de entrenamiento pero no tiene una historia de despliegue. Axolotl proporciona configuración flexible pero requiere manipulación manual de YAML y no ofrece seguimiento de experimentos. LLaMA-Factory te da una interfaz web pero te ata a sus abstracciones específicas. Cada herramienta resuelve una pieza del rompecabezas de manera brillante e ignora el resto, dejando a los ingenieros de ML pegando flujos de trabajo con scripts de shell, celdas de notebooks y convenciones de nombres de carpetas que inevitablemente se rompen cuando un miembro del equipo se une o un proyecto se retoma después de dos semanas. Las restricciones de memoria de GPU añaden otra capa de fricción: un ingeniero puede pasar un día entero averiguando la combinación correcta de cuantización, tamaño de lote, acumulación de gradientes y longitud de secuencia para que una ejecución de entrenamiento quepa en su hardware disponible.

La brecha de despliegue es donde la mayoría de los proyectos de fine-tuning mueren. Un ingeniero de ML produce un hermoso conjunto de pesos de adaptador en un notebook, logra métricas de evaluación sólidas y luego enfrenta la pregunta: ¿y ahora qué? Convertir a GGUF requiere encontrar el commit correcto de llama.cpp que soporte la arquitectura del modelo. Cuantizar a la profundidad de bits correcta requiere prueba y error entre variantes Q4_K_M, Q5_K_M y Q6_K. No hay una forma estándar de rastrear qué experimento produjo qué adaptador, qué versión del dataset se usó o cómo se comparan las métricas de evaluación entre ejecuciones. Cuando un interesado pregunta "¿puedes reproducir el modelo de hace tres semanas?" la respuesta honesta suele ser "probablemente, si puedo encontrar el notebook correcto y los datos de entrenamiento no han sido sobrescritos". Sin reproducibilidad y sin un registro de qué datos y qué configuración produjeron cada modelo, los modelos ajustados rara vez llegan a producción.

The Solution

Ertas Studio reúne en un solo flujo de trabajo visual las piezas que los ingenieros de ML suelen ensamblar a partir de distintas herramientas de código abierto. En el canvas conectas a un módulo Fine-Tune un modelo base, un dataset, una configuración de entrenamiento y una configuración de LoRA, con los ajustes que un profesional espera tener a mano: tasa de aprendizaje, pasos o épocas, tamaño de lote y acumulación de gradientes, optimizador, y rango, alpha, dropout y módulos objetivo de LoRA. Los datasets pueden venir de una subida JSONL, de una importación desde Hugging Face o de Data Craft, el constructor guiado de datasets de Studio, donde editas y versionas ejemplos y controlas cuáles se han aprobado. El entrenamiento se ejecuta en las GPU en la nube gestionadas por Ertas, así que no hay que pelearse con cuotas ni depurar drivers, y el conjunto de entrenamiento se sube a Ertas para la ejecución.

Las ejecuciones en paralelo abaratan los barridos en tiempo real: duplicas un módulo, cambias un parámetro en cada copia y las lanzas todas. El panel Run conserva de cada ejecución una instantánea de la configuración, la pérdida final, los créditos usados y la duración, y los datasets quedan guardados, de modo que un resultado de hace tres semanas se puede rastrear hasta sus datos y su configuración y volver a entrenar. Cada ejecución terminada muestra algunas muestras de inferencia como comprobación rápida de coherencia, y la evaluación de verdad se hace con tu propio conjunto reservado una vez descargado el modelo. Exporta un GGUF Q4_K_M para llama.cpp, Ollama o LM Studio, el adaptador LoRA o, en los planes de pago, safetensors completos para vLLM y otros runtimes de servidor, sin tener que buscar el commit correcto de llama.cpp. Hub muestra todos los modelos que has entrenado, y los archivos son tuyos para ejecutarlos donde quieras, sin depender de Ertas en tiempo de ejecución.

Key Features

Example Workflow

A un ingeniero de ML de una startup en fase de crecimiento le piden destilar el comportamiento de GPT-4o en las tareas principales de la empresa (clasificación de consultas de clientes, recomendación de productos y resúmenes) en un modelo compacto para ejecutarlo en el dispositivo. Tras confirmar que los términos del proveedor lo permiten, genera un dataset de 50.000 ejemplos con respuestas de GPT-4o a los propios prompts de la empresa, reserva 2.000 como conjunto de prueba y sube el resto a Studio en formato JSONL. En el canvas prepara una comparación de modelos base con Qwen 2.5 3B, Llama 3.2 3B y Phi-4 Mini con la misma configuración, además de un barrido de rango de LoRA (8, 16 y 32) sobre el candidato que mejor arranca, todo en paralelo. Un primer vistazo a las curvas de pérdida muestra dos variantes que se quedan claramente atrás, así que el ingeniero las cancela y sus créditos retenidos vuelven a estar disponibles. Cuando terminan las demás ejecuciones, descarga cada GGUF y pasa por todos ellos el conjunto reservado con el script de evaluación del propio equipo, revisando a mano salidas de cada categoría de tarea. El modelo ganador se integra en la app mediante llama.cpp, y su ejecución en Studio conserva la configuración y el dataset que lo produjeron, de modo que el siguiente reentrenamiento parte de una base conocida.