Cómo hacer fine-tuning de un LLM pequeño con tus propios datos (guía completa)

Traducción fiel del artículo de Rahul (@sairahul1), publicado originalmente en X el 18/09/2026.

No necesitás un modelo de 70B.

No necesitás $100.000 en cómputo.

No necesitás un equipo de machine learning.

Un modelo de 1.5B de parámetros fine-tuneado con 200-500 buenos ejemplos puede superar a un modelo frontier usado con un prompt genérico en tu tarea específica.

Esta es la guía completa.

Recolección de datos. Limpieza. Creación del dataset. Entrenamiento QLoRA. Google Colab. Evaluación. Deploy.

Código funcionando en cada paso.

Guardala. Pasásela a una IA y fine-tuneá tus datos.

La mayoría de la gente piensa que el fine-tuning hace al modelo más inteligente.

No es así.

El fine-tuning hace que el modelo sea consistentemente mejor en una tarea específica y acotada.

Esa es toda la propuesta de valor.

Este es el ejemplo que vamos a usar a lo largo de la guía:

Un modelo que recibe un brief de startup como este:

Y produce copy de pitch de financiamiento como este:

Limpio. Con fundamento. Sin métricas inventadas. Sin estructura de slides forzada.

Un modelo de 1.5B haciendo esto de forma confiable vale más que un modelo de 70B haciéndolo de forma inconsistente.

Esa es la apuesta que estamos haciendo.

Antes de entrenar nada, construí tres baselines:

El fine-tuning puede mejorar: tono, estructura, consistencia, vocabulario de dominio, cumplimiento de instrucciones.

El fine-tuning no puede darte de forma confiable datos de mercado actuales, inteligencia de la competencia o hechos en tiempo real.

Si tu modelo necesita saber tamaños de mercado actuales o tendencias de financiamiento, usá retrieval. No entrenamiento.

La arquitectura que funciona:

Empezá el fine-tuning solo cuando tu baseline solo-prompt falle en algo específico.

Empezá entre 0.5B y 3B de parámetros.

Buenos puntos de partida:

Para esta guía: Qwen/Qwen2.5-1.5B-Instruct

Lo suficientemente chico para QLoRA en una GPU T4. Lo suficientemente grande para escritura de negocio útil.

No empieces con 7B o 14B. Los modelos más grandes implican:

El modelo chico primero. Subí solo si falla la evaluación.

Este es el paso que todos se saltean.

Y es el más peligroso.

Que algo sea público no significa que tengas permiso para entrenar con eso.

Para cada fuente de datos, registrá esto antes de descargar un solo archivo:

Qué va a tu repositorio público de GitHub:

Qué se queda privado:

Hacé bien esto primero. El resto es solo ingeniería.

Nunca hagas crawling a ciegas. Usá una allowlist explícita de URLs aprobadas.

Para cada archivo:

Cada archivo lleva: un hash, un timestamp, una entrada en el manifest.

Duplicados salteados por hash de contenido. Sin re-descargas silenciosas.

Los pitch decks son documentos difíciles.

Texto largo. Notas al pie diminutas. Gráficos. Tablas. Texto rotado. Números embebidos en imágenes. Múltiples columnas.

Usá una cascada:

Registrá todo — incluyendo los fallos:

Regla crítica: no descartes en silencio las páginas donde el OCR no devuelve nada.

Los resultados vacíos son tus casos más difíciles. Te muestran dónde se rompe el pipeline.

Borrador de máquina ≠ ground truth. Nunca los confundas.

Limpiar significa sacar ruido de extracción. No hacerlo "más lindo".

Operaciones seguras:

Nunca auto-corrijas números.

Si el OCR devuelve $12.SM en vez de $12.5M — mandalo a revisión. No lo arregles con un modelo de lenguaje.

Un modelo entrenado con números equivocados va a producir output fluido pero financieramente incorrecto.

Seguí cada string numérico por separado:

Los números se evalúan de forma independiente de la calidad del texto. Siempre.

Las páginas crudas de un pitch deck no son datos de entrenamiento.

Una página de deck puede contener un slogan, un gráfico, un descargo legal o una pared de logos.

Tu tarea de entrenamiento es:

startup brief → copy de pitch de financiamiento

No es:

página de PDF → texto extraído

Tenés que construir el puente.

Cada ejemplo de entrenamiento necesita:

Este es el formato JSONL:

El output es deliberadamente texto plano.

Sin cantidad forzada de slides. Sin JSON. Sin campo de título. Sin campo de bullets.

La app downstream convierte el output al formato que necesite.

No generes ejemplos de entrenamiento de forma casual.

Orden seguro:

Si la fuente no verifica una métrica, no incluyas la métrica.

Usá: "La empresa reporta una tracción inicial fuerte." Solo si la fuente realmente lo dice.

Si no: "La empresa está enfocada en expandir la adopción temprana de clientes."

Este es el error de datos que hace que la evaluación no signifique nada.

Si la misma empresa aparece en training y en validación:

Página 1 del pitch deck de la Empresa A → training
Página 2 del pitch deck de la Empresa A → validación

El modelo memoriza lenguaje específico de la empresa y parece generalizar. No generaliza.

Dividí por empresa:

Empresa A → training
Empresa B → training
Empresa C → validación
Empresa D → test

Split objetivo:

Training: 80%
Validación: 10%
Test: 10%

Mantené un manifest del split:

Nunca cambies el set de test después de mirar los resultados.

Una vez que evaluás contra el set de test, quedó quemado. Se convierte en tu señal de entrenamiento, no en tu evaluación real.

Tu VPS de 2 vCPU y 4GB no es una máquina de entrenamiento.

Es perfecto para:

✓ API gateway
✓ Autenticación y rate limiting
✓ Colas de requests
✓ Redis
✓ Servicio de logging
✓ Health checks
✓ Controlador de deploy

Es incorrecto para:

✗ Entrenar un modelo QLoRA de 1.5B
✗ Correr inferencia en GPU
✗ Servir tráfico real a un modelo de lenguaje

Usá la máquina correcta para cada trabajo.

QLoRA carga el modelo base en precisión de 4 bits y entrena un adaptador chico.

Mucha menos memoria que el fine-tuning completo. Resultados casi iguales.

Correlo:

Hiperparámetros clave explicados:

No aumentes las epochs solo porque el training loss baja.

El modelo puede memorizar tus ejemplos mientras empeora con empresas que no vio.

Training loss más bajo ≠ mejor generalización.

Colab es ideal para los primeros experimentos. GPU gratis. Sin servidor que mantener.

Los tradeoffs a tener en cuenta:

✓ GPU T4 gratis para experimentos
✓ Sin mantenimiento de infraestructura
✓ Ideal para notebooks

✗ Las sesiones se pueden cortar en cualquier momento ✗ La disponibilidad de GPU varía según la hora del día ✗ El storage se resetea entre sesiones ✗ No es un servicio de entrenamiento de producción

Arrancá un notebook con GPU. Chequeá tu runtime:

Montá Drive para guardar checkpoints:

Instalá dependencias:

Poné tus paths en Drive:

Guardá en Drive cada 50 pasos, no solo al final.

Si Colab se corta al 95%, querés retomar, no empezar de nuevo.

Registrá tu entorno antes de cada corrida:

La reproducibilidad exige saber exactamente qué versión corrió.

Usá infraestructura distinta para etapas distintas.

Google Colab:

Usalo para: primeros experimentos, debugging, trabajos QLoRA chicos
Evitalo para: producción, corridas largas, scheduling confiable

Proveedores de GPU spot (RunPod, Vast.ai, Modal, Lambda, Paperspace):

Usalos para: trabajos de entrenamiento más largos, billing por segundo, entornos Docker reproducibles
Evitalos para: servir en producción, requerimientos de latencia estable

Chequeá los precios en vivo antes de cada corrida. Las tarifas de GPU cambian seguido.

Hosting de GPU dedicado:

Usalo para: serving público, latencia estable, deploy de producción
Evitalo para: experimentación (pagás mientras está inactivo)

Costo estimado de entrenamiento:

Tarifa de GPU: $0.40/hora
Tiempo activo: 3 horas
Reintentos: 1 hora
Storage: $0.10

Total: ($0.40 × 4) + $0.10 = $1.70

Lo caro no es la primera corrida.

Es la experimentación repetida:

Cambiar prompts
Reconstruir datasets después de bugs
Probar múltiples ranks (r=8, r=16, r=32)
Probar distintos modelos base
Correr evaluación
Servir GPU continuamente para testing

Presupuestá 5-10x tu primera estimación.

No compares tu modelo fine-tuneado contra el training loss.

Comparalo contra el modelo que estabas usando antes.

Métricas de evaluación fijas:

Cumplimiento de texto plano (sin JSON, sin estructura de slides)
Utilidad del output (rating humano 1-10)
Tasa de claims sin fundamento
Precisión de preservación numérica
Tasa de repetición
Legibilidad
Latencia
Uso de tokens y costo por request

Chequeo de consistencia numérica:

Un número generado que no está en la evidencia fuente es una alucinación.

Agarralo antes de que lo hagan tus usuarios.

Scorecard de ejemplo:

Solo afirmá mejora si el set de test fue aislado antes de que empezaras a evaluar.

Si miraste el set de test, esos resultados no significan nada.

Dos opciones según tu tráfico.

Opción A: vLLM (alto throughput)

Chequeá la documentación actual de LoRA de vLLM antes de deployar. Las opciones cambian entre versiones.

Opción B: FastAPI + Transformers (tráfico bajo)

Nunca expongas un servidor de modelo crudo a internet.

Tu setup de producción:

Cliente → HTTPS + auth → rate limiter del VPS → cola de requests → servidor de modelo en GPU → respuesta en texto plano

El VPS maneja: TLS, auth, rate limits, colas.

La GPU maneja: inferencia.

Seguí estas métricas desde el día uno:

Latencia de requests
Tiempo en cola
Memoria y utilización de GPU
Tasa de error
Outputs vacíos
Cantidad de tokens por request
Tasa de reintentos del usuario
Reportes de claims sin fundamento
Versión de modelo + versión de adaptador

No recopiles datos de usuario automáticamente para reentrenar.

Usá un opt-in explícito:

Este request puede usarse para mejorar el modelo.
[ ] Sí, consiento [ ] No

Incluso con consentimiento, limpiá antes de guardar:

✗ Números de teléfono personales
✗ Direcciones de email
✗ Nombres de clientes
✗ Cifras de ingresos privadas
✗ Términos de financiamiento confidenciales
✗ Datos de contacto de inversores

Mantené los datos de entrenamiento de producción separados de los de evaluación. Siempre.

No todo envío de usuario dispara un reentrenamiento.

Reentrená cuando tengas:

✓ Una cantidad significativa de ejemplos revisados (no envíos crudos) ✓ Un patrón de falla claro y documentado ✓ Un set de evaluación estable ✓ Una versión de dataset documentada ✓ Un plan de rollback

Una cadencia razonable:

v0: baseline solo-prompt v1: 200 ejemplos revisados v2: 1.000 ejemplos revisados v3: dataset más grande + retrieval

Cada versión registra:

Nunca deployes sin un camino de rollback documentado.

Esto es lo que yo haría para este proyecto exacto:

La mejora de mayor apalancamiento casi nunca es el learning rate.

Son los ejemplos.

Eso es lo que convierte 1.5B de parámetros en algo genuinamente útil.

Datos crudos privados. Código de procesamiento público. Código de evaluación público.

Tu pipeline de entrenamiento es reproducible incluso si los datos crudos se mantienen privados.

• Hugging Face TRL SFTTrainer → huggingface.co/docs/trl/en/sft_trainer
• PEFT quantization guide → huggingface.co/docs/peft/en/developer_guides/quantization
• bitsandbytes integration → huggingface.co/docs/bitsandbytes
• Google Colab FAQ → research.google.com/colaboratory/faq.html
• Qwen2.5-1.5B-Instruct model card → huggingface.co/Qwen/Qwen2.5-1.5B-Instruct
• vLLM LoRA serving → docs.vllm.ai/en/latest/features/lora.html
• RunPod pricing → runpod.io/pricing
• Modal pricing → modal.com/pricing

Más artículos relacionados:

• Guía Definitiva: Mac Mini Headless para Agentes AILeer →
• Vibe coding y agentic engineering se están fusionandoLeer →
• La Mayor Transferencia de Riqueza de la HistoriaLeer →