Destilando Claude/GPT en un Modelo 7B para Producción: Paso a Paso

Tienes un sistema corriendo en Claude Sonnet o GPT-4o. Funciona. La calidad es sólida. Pero cada solicitud cuesta dinero, cada solicitud agrega latencia, y cada solicitud envía tus datos a los servidores de alguien más. Quieres ser dueño del modelo que potencia tu producto.

Este tutorial te guía a través del pipeline completo de destilación: desde definir tu tarea, pasando por generar datos sintéticos, ajustar un modelo 7B y desplegarlo localmente vía Ollama. Cada paso incluye parámetros concretos, outputs esperados y guía de solución de problemas.

Tiempo total: 3-4 horas (incluyendo tiempo de espera de entrenamiento) Costo total: $10-30 por todo el pipeline Resultado esperado: 85-95% de la calidad del modelo teacher en tu tarea específica

Prerrequisitos

Antes de empezar, necesitas:

• Una cuenta de Ertas (el tier gratuito es suficiente para este tutorial)
• Acceso API a tu modelo teacher — ya sea una API key de Anthropic (para Claude) o una API key de OpenAI (para GPT-4o)
• Una tarea claramente definida — clasificación, extracción, formateo o Q&A de dominio
• 50 ejemplos semilla de tu tarea, con pares input-output correctos
• Una máquina para despliegue local — GPU con 8GB+ de VRAM o 16GB+ de RAM para inferencia en CPU

Recorramos cada paso.

Paso 1: Define el Alcance de Tu Tarea

La destilación funciona en tareas estrechas. Cuanto más estrecha, mejor. Tu definición de tarea debería caber en una oración:

Buenas definiciones de tarea:

• "Clasificar emails de soporte al cliente en una de 8 categorías y devolver un objeto JSON con categoría y confianza."
• "Extraer nombre del proveedor, número de factura, fecha y monto total de PDFs de facturas (pre-procesados a texto)."
• "Convertir consultas de búsqueda en lenguaje natural a queries Elasticsearch DSL para nuestro esquema de catálogo de productos."
• "Responder preguntas sobre nuestra documentación de API usando la sección de docs relevante como contexto."

Malas definiciones de tarea (demasiado amplias):

• "Ayudar a los clientes con sus preguntas."
• "Procesar documentos."
• "Escribir respuestas a emails."

Tu definición de tarea debe especificar:

1. Formato de input: ¿Qué recibe el modelo? ¿Qué tan largo es un input típico? ¿Cuál es el rango?
2. Formato de output: ¿Qué exactamente debe producir el modelo? ¿JSON? ¿Una etiqueta? ¿Texto estructurado?
3. Espacio de output: ¿Cuántos outputs posibles hay? (12 categorías, 5 campos extraídos, etc.)
4. Métrica de calidad: ¿Cómo medirás si el output es correcto? ¿Accuracy? ¿F1? ¿Exact match?

Escríbelo. Te referirás a ello durante todo el proceso.

Para este tutorial, usaremos un ejemplo continuo: clasificar feedback de producto SaaS en 6 categorías (bug report, feature request, usability issue, performance complaint, positive feedback, question) y extraer el área de producto afectada.

Paso 2: Crea 50 Ejemplos Semilla Manualmente

Este es el paso que se siente tedioso pero determina la calidad de todo lo que viene después. Necesitas 50 pares input-output hechos a mano que representen el estándar de oro para tu tarea.

¿Por qué 50? Porque estos ejemplos semilla sirven tres propósitos:

1. Calibración de prompts — te ayudan a escribir el prompt para el modelo teacher
2. Referencia de calidad — definen cómo se ve "correcto"
3. Base del set de prueba — 20 de ellos se convertirán en tu set de evaluación inicial

Guías para ejemplos semilla:

• Cubre todas las categorías/tipos de output. Si tienes 6 categorías, incluye al menos 8 ejemplos por categoría.
• Incluye casos extremos. Agrega 5-10 ejemplos que sean ambiguos, multi-etiqueta o inusuales.
• Coincide con la distribución de producción. Si el 40% de tus inputs reales son bug reports, aproximadamente el 40% de las semillas deberían ser bug reports.
• Sé preciso en los outputs. Tus outputs deberían ser exactamente lo que quieres que el modelo produzca — mismo esquema JSON, mismo formato, mismo nivel de detalle.

Formatea tus ejemplos semilla como JSONL:

{"input": "The dashboard keeps crashing when I try to export reports. This has been happening since the last update.", "output": "{\"category\": \"bug_report\", \"confidence\": 0.95, \"product_area\": \"dashboard\", \"summary\": \"Dashboard crashes on report export since last update\"}"}
{"input": "It would be amazing if you could add a dark mode to the mobile app.", "output": "{\"category\": \"feature_request\", \"confidence\": 0.92, \"product_area\": \"mobile_app\", \"summary\": \"Request for dark mode on mobile app\"}"}

Dedica 1-2 horas a este paso. La calidad de tus ejemplos semilla determina directamente la calidad de tu modelo final.

Paso 3: Genera 2,000 Ejemplos Sintéticos Usando el Modelo Teacher

Ahora escalas. Usarás Claude o GPT-4o como modelo teacher para generar 2,000 ejemplos etiquetados.

3a: Escribe el Prompt del Teacher

Usa tus ejemplos semilla para crear un system prompt para el modelo teacher. El prompt debe:

• Describir la tarea con precisión
• Incluir 3-5 de tus ejemplos semilla como demostraciones few-shot
• Especificar el formato exacto de output
• Incluir guía para casos extremos

You are a product feedback classifier. Given a piece of user feedback about a SaaS product, classify it and extract the relevant product area.

Output a JSON object with these fields:
- category: one of [bug_report, feature_request, usability_issue, performance_complaint, positive_feedback, question]
- confidence: float between 0.0 and 1.0
- product_area: the affected product area (e.g., dashboard, api, mobile_app, billing, onboarding, integrations, general)
- summary: one-sentence summary of the feedback

Examples:
[Include 3-5 seed examples here]

Classify the following feedback:

3b: Genera Inputs Diversos

Necesitas inputs diversos para alimentar al teacher. Hay varias fuentes:

Datos de producción. Si tienes feedback histórico, esto es ideal. Los datos reales tienen la distribución, vocabulario y casos extremos correctos.

Generación de inputs sintéticos. Usa el modelo teacher mismo para generar inputs realistas. Hazle un prompt con: "Generate 50 diverse examples of SaaS product feedback that cover all six categories. Make them realistic, varying in length (1-5 sentences), tone (frustrated, neutral, excited), and specificity."

Generación basada en templates. Crea templates con slots y llénalos programáticamente. "The {feature} is {problem_description} when I try to {action}."

Apunta a 2,500 inputs crudos. Perderás algunos durante el filtrado de calidad.

3c: Ejecuta el Modelo Teacher

Procesa los 2,500 inputs a través del modelo teacher. Este es el paso más caro del pipeline, pero es un costo único.

Estimación de costos para 2,500 ejemplos:

• Claude Sonnet: ~$3-5 (a ~200 tokens de input + 100 tokens de output por ejemplo)
• GPT-4o: ~$4-7

Usa procesamiento por lotes para reducir costos. Tanto Anthropic como OpenAI ofrecen APIs de lotes con 50% de descuento. Con batching:

• Claude Sonnet batch: ~$1.50-2.50
• GPT-4o batch: ~$2-3.50

Guarda todos los pares input-output como JSONL. Este es tu dataset de entrenamiento crudo.

3d: Rate Limit y Manejo de Errores

Al ejecutar 2,500 llamadas API, llegarás a rate limits. Implementa:

• Exponential backoff con jitter (empieza en 1s, máximo 60s)
• Lógica de reintentos para errores 429 y 500 (3 reintentos máximo)
• Checkpointing — guarda progreso cada 100 ejemplos para poder reanudar si el script se cae
• Solicitudes paralelas — 5-10 solicitudes concurrentes es usualmente seguro para tiers de API estándar

Un script bien implementado procesa 2,500 ejemplos en 15-30 minutos.

Paso 4: Filtra el Dataset por Calidad

Los outputs crudos del teacher no son todos usables. Espera descartar ~25% de los ejemplos durante el filtrado de calidad. Esto es normal e importante.

Filtros Automatizados

Ejecuta estas verificaciones programáticamente:

1. Validación de esquema. Parsea cada output como JSON. Descarta cualquier ejemplo donde el output no sea JSON válido o no coincida con tu esquema esperado. (Espera 2-5% de tasa de fallo.)

2. Validación de categoría. Verifica que el campo de categoría contenga uno de los valores válidos. El modelo teacher ocasionalmente alucina una categoría que no existe. (Espera 1-3% de tasa de fallo.)

3. Umbral de confianza. Descarta ejemplos donde la confianza del teacher esté por debajo de 0.70. Los outputs de baja confianza frecuentemente son incorrectos o ambiguos, y entrenar con ellos confunde al student. (Espera 5-10% de remoción.)

4. Deduplicación. Elimina inputs cuasi-duplicados. Usa similaridad coseno en embeddings con un umbral de 0.95. Entrenar con cuasi-duplicados desperdicia cómputo y sesga el modelo. (Espera 5-10% de remoción.)

5. Outliers de longitud. Elimina ejemplos donde el input u output es anormalmente largo o corto (más allá de 2 desviaciones estándar de la media). Estos frecuentemente están malformados. (Espera 2-3% de remoción.)

Verificación Manual por Muestreo

Después del filtrado automatizado, muestrea aleatoriamente 100 ejemplos y revísalos manualmente. Busca:

• Errores del teacher (categoría incorrecta, extracción incorrecta)
• Formato inconsistente (a veces incluye markdown, a veces no)
• Ejemplos ambiguos donde la respuesta "correcta" es debatible

Si más del 10% de tu muestra de verificación tiene problemas, tu prompt del teacher necesita mejoras. Regresa al Paso 3a y refina.

Resultado esperado: Empieza con 2,500 ejemplos, termina con ~1,800-2,000 ejemplos limpios. Esto es suficiente para fine-tuning.

Paso 5: Fine-Tune en Ertas Studio

Sube tu dataset JSONL filtrado a Ertas Studio. Aquí está la configuración para una corrida estándar de destilación.

Selección de Modelo

Para este tutorial, elige Llama 3.3 8B o Qwen 2.5 7B. Ambos son excelentes objetivos de destilación.

• Llama 3.3 8B — comunidad más grande, más tutoriales si encuentras problemas
• Qwen 2.5 7B — ligeramente mejor en benchmarks, licencia Apache 2.0

Configuración de LoRA

Parámetros de Entrenamiento

Tiempo y Costo de Entrenamiento

Con 2,000 ejemplos y la configuración anterior:

• En Ertas Studio: 30-45 minutos, costo ~$8-12
• En tu propia A100 (80GB): 20-30 minutos
• En tu propia RTX 4090 (24GB): 40-60 minutos (con cuantización QLoRA)

Ertas Studio muestra métricas de entrenamiento en tiempo real: curva de loss, schedule de learning rate y métricas de evaluación en cada límite de epoch.

Qué Observar Durante el Entrenamiento

• Training loss debería disminuir de forma constante durante los epochs 1-2 y comenzar a estabilizarse en el epoch 3
• Evaluation loss debería seguir al training loss de cerca. Si el eval loss empieza a aumentar mientras el training loss disminuye, estás haciendo overfitting. Detén el entrenamiento.
• Si el loss tiene un spike en los primeros 100 pasos, tu learning rate es demasiado alto. Prueba 1e-4.
• Si el loss apenas disminuye, tu learning rate es demasiado bajo. Prueba 5e-4.

Paso 6: Evalúa Contra el Modelo Teacher

Después de que el entrenamiento se complete, evalúa el modelo student en tu set de prueba reservado (los 20 ejemplos semilla que reservaste, más el 10% de tus datos de entrenamiento reservados automáticamente por Ertas).

Métricas a Verificar

Accuracy de clasificación: ¿Qué porcentaje de ejemplos clasifica correctamente el student?

• Objetivo: 90%+ de acuerdo con el teacher
• Aceptable: 85%+
• Necesita trabajo: Por debajo del 85%

Exact match en output estructurado: ¿Qué porcentaje de outputs son exactamente correctos (todos los campos coinciden)?

• Objetivo: 85%+
• Aceptable: 75%+

Desglose por categoría: Verifica la accuracy para cada categoría por separado. Si una categoría es significativamente peor que otras, probablemente necesitas más ejemplos de entrenamiento para esa categoría.

Comparación Lado a Lado

Ertas Studio proporciona una vista de comparación lado a lado donde puedes ver los outputs del teacher y student para cada ejemplo de prueba. Revisa los desacuerdos manualmente. Frecuentemente encontrarás que:

• 40-50% de los desacuerdos son casos donde el student realmente está correcto (el teacher cometió un error)
• 30-40% son casos donde ambas respuestas son razonables (inputs ambiguos)
• 10-20% son errores genuinos del student que podrían corregirse con más datos de entrenamiento

Si la Calidad Está Por Debajo del Objetivo

Si tus puntajes de evaluación están por debajo de tu objetivo:

1. Verifica la calidad de datos primero. Revisa 50 ejemplos aleatorios de entrenamiento. Si más del 5% tienen etiquetas incorrectas, limpia tus datos y reentrena.
2. Agrega más datos para categorías débiles. Si una categoría rinde por debajo, genera 200-300 ejemplos adicionales específicamente para esa categoría.
3. Aumenta el LoRA rank. Pasa de rank 16 a rank 32. Esto le da al modelo más capacidad para aprender patrones complejos.
4. Prueba un modelo más grande. Si Qwen 7B no es suficiente, prueba Qwen 14B o Llama 8B.
5. Agrega más target modules. Incluye las capas MLP (gate_proj, up_proj, down_proj) además de las capas de atención.

Paso 7: Exporta a GGUF y Despliega vía Ollama

Una vez que estés satisfecho con los resultados de evaluación, exporta el modelo para despliegue local.

Exportación GGUF

En Ertas Studio, selecciona tu modelo entrenado y haz clic en Export. Elige tu nivel de cuantización:

Recomendación: Empieza con Q5_K_M. Ofrece un excelente balance calidad-tamaño. Solo baja a Q4 si tienes restricciones de hardware. Solo usa Q8 si necesitas el último 1-2% de calidad.

La exportación toma 2-5 minutos. Obtendrás un solo archivo .gguf.

Despliega con Ollama

Crea un Modelfile:

FROM ./your-model-Q5_K_M.gguf

PARAMETER temperature 0.1
PARAMETER top_p 0.9
PARAMETER num_ctx 512

SYSTEM """You are a product feedback classifier. Given user feedback, classify it and extract the relevant product area. Output a JSON object with: category, confidence, product_area, summary."""

Registra y ejecuta:

ollama create feedback-classifier -f Modelfile
ollama run feedback-classifier "The search function is incredibly slow, takes 10+ seconds to return results"

Output esperado:

{"category": "performance_complaint", "confidence": 0.94, "product_area": "search", "summary": "Search function has 10+ second response times"}

Integración

Para producción, usa la API HTTP de Ollama:

curl http://localhost:11434/api/generate -d '{
  "model": "feedback-classifier",
  "prompt": "The search function is incredibly slow, takes 10+ seconds to return results",
  "stream": false
}'

Ollama sirve solicitudes a 30-120 tokens/segundo dependiendo de tu hardware. Para un output típico de clasificación de 50 tokens, espera tiempos de respuesta de 50-150ms.

Paso 8: Monitorea el Rendimiento en Producción e Itera

El despliegue no es el final. Los datos de producción revelarán casos extremos que tus datos de entrenamiento no cubrieron.

Checklist de Monitoreo

1. Registra todos los inputs y outputs. Cada solicitud de producción es un ejemplo potencial de entrenamiento para la próxima iteración.

2. Rastrea puntajes de confianza. Si el modelo produce confianza por debajo de 0.70, señala la solicitud para revisión. Un porcentaje creciente de solicitudes de baja confianza indica drift de distribución.

3. Auditorías de calidad basadas en muestreo. Revisa 50 outputs aleatorios de producción semanalmente. Calcula tu accuracy del mundo real y compárala con la accuracy de tu set de evaluación.

4. Monitoreo de distribución de categorías. Rastrea la distribución de categorías predichas a lo largo del tiempo. Si la distribución cambia significativamente, investiga si la distribución de inputs ha cambiado o si el modelo está sufriendo drift.

5. Monitoreo de latencia. Rastrea latencia p50, p95 y p99. Si la latencia aumenta, verifica contención de recursos en el servidor de despliegue.

Ciclo de Iteración

Cada 2-4 semanas (o cuando la calidad caiga por debajo de tu umbral):

1. Recopila ejemplos señalados de baja confianza y predicciones incorrectas
2. Corrige las etiquetas manualmente (o usa el modelo teacher para casos ambiguos)
3. Agrega 200-500 nuevos ejemplos a tu set de entrenamiento
4. Reentrena (el entrenamiento incremental toma 15-20 minutos)
5. Evalúa y redespliega

Cada iteración típicamente mejora la accuracy en 1-3 puntos porcentuales. Después de 3-4 iteraciones, la mayoría de los modelos convergen a su techo de calidad para el tamaño de modelo dado.

Resultados Esperados y Resumen de Costos

Calidad: 85-95% de acuerdo con el modelo teacher en tu tarea específica. En muchas tareas (clasificación, extracción), el modelo fine-tuned supera el 90%.

Desglose de costos total:

Compara esto con el costo continuo de ejecutar el modelo teacher en producción:

• A 10,000 solicitudes/mes: $10-50/mes en costos de API
• A 100,000 solicitudes/mes: $100-500/mes
• Break-even: 1-4 semanas

Estimación de tiempo:

• Paso 1 (definición de tarea): 30 minutos
• Paso 2 (ejemplos semilla): 1-2 horas
• Paso 3 (generación del teacher): 30 minutos activo, 15-30 minutos procesando
• Paso 4 (filtrado de calidad): 30-45 minutos
• Paso 5 (entrenamiento): 10 minutos activo, 30-45 minutos esperando
• Paso 6 (evaluación): 20-30 minutos
• Paso 7 (exportación y despliegue): 15-20 minutos
• Total: 3-5 horas incluyendo tiempos de espera

Empezaste la mañana pagando por token. Para el almuerzo, eres dueño del modelo.

---

Para los fundamentos técnicos detrás de este tutorial, lee nuestra Model Distillation with LoRA guide. ¿Quieres hacer esto con modelos completamente open-source y cero riesgo legal? Ve How to Distill Open-Source Models Legally. Para la ética y estrategia detrás de la destilación, lee Model Distillation Is Not Theft — But Here's Why You Should Do It Yourself. ¿Nuevo en Ertas? Empieza con Getting Started with Ertas.