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". Esta falta de reproducibilidad y rastreo de linaje no es una inconveniencia de herramientas — es un bloqueador fundamental para llevar modelos ajustados a producción.

The Solution

Ertas proporciona el pipeline unificado que los ingenieros de ML han estado ensamblando de forma fragmentada con herramientas de código abierto. El lienzo visual de Studio te permite diseñar pipelines de entrenamiento componiendo bloques modulares — carga de datos, preprocesamiento, configuración de LoRA/QLoRA, entrenamiento, evaluación y exportación — mientras expone toda la superficie de configuración que los profesionales experimentados esperan. Cada parámetro es editable, cada bloque puede ser reemplazado con código personalizado, y toda la definición del pipeline es exportable como un archivo de configuración reproducible. Esta no es una interfaz simplificada pegada encima de una biblioteca de entrenamiento — es un verdadero orquestador de flujos de trabajo que resulta tener una interfaz visual.

Las capacidades de seguimiento y comparación de experimentos cierran la brecha de reproducibilidad por completo. Cada ejecución de entrenamiento en Ertas se versiona automáticamente con su linaje completo: qué versión del dataset de Vault se usó, qué modelo base de Hub, qué hiperparámetros se configuraron y qué métricas de evaluación se lograron. Las vistas de comparación lado a lado permiten a los ingenieros evaluar múltiples experimentos de QLoRA a través de curvas de pérdida, puntuaciones de benchmark y calidad de generación en una sola pantalla. Cuando se identifica el mejor experimento, la exportación a GGUF con un clic maneja el pipeline de conversión y cuantización — incluyendo conversión consciente de la arquitectura que selecciona automáticamente la ruta correcta de llama.cpp. El GGUF exportado puede desplegarse en Ollama, llama.cpp, vLLM o cualquier otro runtime de inferencia sin pasos de conversión manual. Todo el camino desde el dataset en bruto hasta el modelo de producción desplegado vive en una sola plataforma con registro de auditoría completo.

Key Features

Example Workflow

Un ingeniero de ML en una startup en etapa intermedia tiene la tarea de destilar las capacidades de razonamiento de GPT-4o en un modelo compacto para despliegue en dispositivo. Comienza curando un dataset de 50,000 ejemplos de salidas de GPT-4o a través de los casos de uso principales de la empresa — clasificación de consultas de clientes, recomendación de productos y resumen — cargando el dataset versionado en Vault. En Hub, evalúa tres modelos base candidatos: Qwen 2.5 14B, Mistral Nemo 12B y LLaMA 3.1 8B, comparándolos en el conjunto de benchmarks internos de la empresa. Qwen 2.5 14B muestra el rendimiento base más fuerte, así que procede con él. En Studio, el ingeniero configura 5 experimentos de QLoRA con rango variado (8, 16, 32), programas de tasa de aprendizaje y longitudes de secuencia, lanzando los cinco en paralelo en Cloud. Después de que el entrenamiento se completa, la vista de comparación lado a lado revela que rango-16 con recocido coseno y longitud de secuencia de 4096 produce el mejor balance entre puntuación de evaluación (91.3% en el benchmark interno) y tamaño del adaptador (48MB). El ingeniero profundiza en la pestaña de calidad de generación, revisando salidas en las tres categorías de tareas y confirmando que el modelo destilado iguala la calidad de salida de GPT-4o en el 94% de los casos de prueba. Un clic exporta el experimento ganador como un archivo GGUF Q5_K_M, con Ertas seleccionando automáticamente la ruta de conversión correcta de llama.cpp para la arquitectura Qwen. El modelo exportado se despliega en una instancia de vLLM detrás del API gateway de la empresa, sirviendo 2,000 solicitudes por minuto con latencia p95 de 180ms. Todo el historial de experimentos — las 5 ejecuciones, sus datasets, configuraciones y métricas — se preserva en Vault para referencia futura y auditoría.