Fine-tuning local con QLoRA: guía honesta para cuando no tienes GPU de investigador

Antes de empezar: la confusión que cuesta horas y dinero

Llevas meses oyendo que puedes entrenar tu propio modelo en local. Vídeos de YouTube, hilos de Twitter, gurús de LinkedIn con portátil en la playa. Y nadie te ha contado la letra pequeña.

Yo sí voy a hacerlo, porque me la comí entera.

Entrené un SLM con LoRA en mi propia CPU. Sin GPU de investigador, sin presupuesto de startup, con la frustración de ver que el hype no te cuenta qué pasa cuando el hardware no acompaña. Así que antes de que te descargues nada, necesitas entender una distinción que el 80% de la gente que habla de esto ignora o mezcla deliberadamente.

Darle contexto a un modelo no es entrenarlo. Son dos cosas distintas con costes distintos y casos de uso distintos.

Darle contexto es meter un prompt bien construido, un system message con tus instrucciones, conectar documentos vía RAG o usar proyectos con instrucciones persistidas. El modelo no cambia. Tú le estás hablando mejor. Esto resuelve el 80% de los casos en los que alguien me dice "quiero fine-tunear mi modelo para que hable como nuestra empresa".

Fine-tuning de verdad (lo que cubre esta guía) implica modificar los pesos del modelo con datos tuyos. El modelo cambia. Necesitas datos, infraestructura, tiempo y dinero. No mucho dinero si lo haces bien, pero dinero. Y si no sabes exactamente qué problema estás resolviendo, es un agujero negro.

Cuando acabes de leer esto sabrás cuándo tiene sentido meterte en el fine-tuning local, qué herramientas usar, qué hardware mínimo necesitas y dónde están los límites reales cuando no tienes un rack de A100 en el garaje.

Cuándo NO es para ti (y qué usar en su lugar)

Esta es la sección que la mayoría de guías se salta porque arruina el gancho del título.

Fine-tuning no es la respuesta si:

Quieres que el modelo "conozca" tus documentos internos → usa RAG con búsqueda semántica
Quieres que responda con el tono de tu empresa → un system prompt bien escrito lo resuelve en 20 minutos
Estás prototipando → prompting primero, siempre
Tu conocimiento cambia cada semana → fine-tuning fija el conocimiento en el tiempo del entrenamiento; RAG lo actualiza en tiempo real

Según el análisis de Beltsys Labs (dev.to, marzo 2026), la comparativa real es esta:

Enfoque	Datos necesarios	Coste inicial	Latencia	Personalización
Prompting	Ninguno	$0	Alta	Baja
RAG	Documentos	$500–5.000	Media	Media
Fine-tuning	Cientos a miles de pares input-output	$10–10.000	Baja	Alta

Fine-tuning tiene sentido cuando tienes un comportamiento estable que quieres que el modelo exhiba siempre: formato de salida fijo, tono muy específico, dominio técnico cerrado (un cardiólogo, un asistente legal con terminología propia, un parser de facturas). Y cuando ese comportamiento no puedes lograrlo con prompting porque el modelo base se sale del patrón el 30% de las veces.

También tiene sentido por privacidad: con fine-tuning, los datos nunca salen de tu servidor. Con una API, viajan a la nube. Para sectores regulados (fintech, salud, legal) esto puede ser determinante antes de plantearte el coste computacional.

La letra pequeña del hardware: VRAM antes que ilusiones

El primer error que comete todo el mundo: descargarse un modelo de 14 GB, configurar todo, arrancar el entrenamiento y descubrir que se queda sin memoria a los cinco minutos.

La regla de dimensionamiento viene de Worldstream (enero 2026): para entrenamiento de transformers en precisión mixta con AdamW, planifica aproximadamente 18 bytes por parámetro, más memoria de activaciones. Para inferencia en precisión mixta, unos 6 bytes por parámetro más el KV cache.

En números concretos, con LLaMA Factory (jenova.ai, abril 2026):

LoRA en 16-bit:

Modelo 7B → 16 GB VRAM
Modelo 14B → 32 GB VRAM
Modelo 70B → 160 GB VRAM (aquí ya estamos fuera del territorio doméstico)

QLoRA 4-bit (la opción realista para hardware de consumo):

Modelo 7B → 6 GB VRAM
Modelo 14B → 12 GB VRAM
Modelo 70B → 48 GB VRAM

QLoRA 2-bit (el modo Dios del apretado):

Modelo 7B → 4 GB VRAM
Modelo 14B → 8 GB VRAM
Modelo 70B → 24 GB VRAM

Si tienes una GPU de consumo con 8–12 GB de VRAM (una RTX 3080, una 4070), QLoRA 4-bit en un modelo de 7B es tu punto de entrada realista. Si tienes 6 GB (una 3060), también entra, pero con poco margen para aumentar el batch size o la longitud de contexto.

El fine-tuning completo de un modelo 70B en bf16 exige 1.200 GB de memoria GPU. Eso no es un error tipográfico.

Si trabajas en Mac con Apple Silicon, MLX y vMLX te dan acceso a la memoria unificada sin necesitar CUDA. Un M3 Pro o M4 Max con 36–48 GB de memoria unificada tiene más potencia de la que parece para modelos de 7B–14B en cuantización.

Si no tienes GPU propia, las opciones de nube (con la advertencia de que los precios varían por proveedor, región y disponibilidad en el momento):

Google Colab (T4 15 GB, gratis, sesiones limitadas)
Kaggle (P100/T4, 30 horas semanales gratis)
Lambda Labs (A100 80 GB, orientativamente ~$1,10/hora)
RunPod (A100/H100, orientativamente desde ~$0,39/hora)
Vast.ai (mercado de GPUs, orientativamente desde ~$0,10/hora)

Un fine-tuning básico de modelo 7B con LoRA tarda unas 2–4 horas en Colab gratis. Un modelo 70B con QLoRA puede tardar 4–8 horas en Lambda Labs (lo que sale a unos 5–9 dólares aproximadamente, no garantizados).

Qué técnica usar: SFT, LoRA, QLoRA, DPO

No todas las técnicas de fine-tuning son iguales, y elegir la equivocada te cuesta tiempo o calidad. El resumen sin adornos:

SFT (Supervised Fine-Tuning): entrenas el modelo con pares input-output. La forma más directa. Necesitas datos etiquetados: pregunta + respuesta esperada. Cientos de pares para resultados básicos, miles para resultados consistentes.

LoRA (Low-Rank Adaptation): no tocas los pesos originales del modelo. Entrenas unos adaptadores de bajo rango (matrices pequeñas que se añaden encima) y reduces la memoria necesaria entre 10 y 100 veces respecto al fine-tuning completo. Es el estándar actual para hardware de consumo.

QLoRA: cuantización de 4 bits más LoRA. El modelo base se comprime a 4 bits (perdiendo algo de precisión, ganando mucho en memoria), y los adaptadores LoRA se entrenan en precisión normal. Permite fine-tunear modelos de 65B+ en una GPU de consumo de 24 GB VRAM. Es la técnica que hace posible esta guía para la mayoría de lectores.

DPO (Direct Preference Optimization): optimización de preferencias. En lugar de pares input-output, usas comparaciones: "esta respuesta es mejor que esta otra". Más simple que RLHF (que requiere un reward model separado) y útil cuando quieres afinar el comportamiento en términos de preferencia humana, no solo de formato.

Para la mayoría de casos prácticos (dominio específico, formato de salida, tono controlado) QLoRA con SFT es el punto de entrada sensato.

Qué modelo elegir (y por qué no hay respuesta universal)

Los modelos recomendados en 2026 para fine-tuning, según Beltsys Labs (dev.to, marzo 2026):

Llama 3 (8B, 70B, 405B): conjunto de herramientas HuggingFace más completo, documentación extensa, comunidad grande
Mistral (7B, 8x7B): mejor ratio calidad/parámetros en muchos benchmarks, arquitectura eficiente
DeepSeek (7B, 67B, V3): fuerte en razonamiento, pero puede generar caracteres chinos en algunos outputs (letra pequeña que duele en producción si tu usuario es hispanohablante)
Qwen (7B, 14B, 72B): multilingüe, buen rendimiento en español
Gemma (2B, 7B): ligero, bueno para hardware muy limitado
Phi (3B): ultra-ligero, sorprendentemente capaz para su tamaño

La experiencia real de Beltsys: Mistral 7B funcionó mejor que DeepSeek y Llama en su caso de uso específico.

La mía: resultados distintos en un dominio distinto. Esto importa. No existe un modelo universalmente superior para fine-tuning. El modelo que funciona es el que funciona en tu dominio con tus datos. Prueba al menos dos antes de comprometerte.

LLaMA Factory: el entorno que evita escribir código desde cero

LLaMA Factory es un framework open-source que permite hacer fine-tuning de más de 100 LLMs y modelos visión-lenguaje sin tener que construir el loop de entrenamiento desde cero. Soporta SFT, DPO, RLHF, KTO y ORPO, con LoRA, QLoRA (2–8 bits), DoRA, PiSSA y GaLore (jenova.ai, abril 2026).

Tiene dos modos de uso:

LlamaBoard: interfaz web para configurar y lanzar entrenamientos sin tocar terminal
CLI: línea de comandos para automatización y más control

Aquí la advertencia honesta que esta guía no se salta: LLaMA Factory no es "completamente sin código". Necesitas preparar tu dataset en el formato correcto (estructura JSON para ajuste de instrucciones), configurar hiperparámetros clave como el learning rate, el batch size y el número de épocas, y entender qué estás configurando para no lanzar un entrenamiento que va a destrozar el modelo en lugar de mejorarlo. La interfaz elimina fricción, no elimina criterio.

Lo que sí hace solo: gestiona la memoria, aplica las optimizaciones (FlashAttention-2, Unsloth que acelera LoRA un 170%, Liger Kernel) y exporta el modelo entrenado listo para inferencia. NVIDIA publicó en febrero de 2026 un manual oficial para DGX Spark con arquitectura Blackwell usando LLaMA Factory, lo que da una idea de que no es un juguete de hobby.

Paso a paso: fine-tuning de un modelo 7B con QLoRA

Este es el flujo mínimo funcional. No es el tutorial con cada línea de código (eso no consta en las fuentes disponibles y no voy a inventarme comandos que no puedo verificar), pero sí el mapa completo de lo que tienes que hacer y en qué orden.

1. Prepara tu dataset

El formato que espera LLaMA Factory para SFT es JSON con pares instrucción-respuesta. Necesitas como mínimo algunos cientos de pares representativos de lo que quieres que el modelo haga. La calidad importa más que la cantidad: 200 pares bien curados superan a 2.000 generados con descuido.

Estructura básica:

[
  {
    "instruction": "Clasifica esta factura como válida o inválida",
    "input": "Factura nº 2024-001, importe 1.200€, fecha 2024-01-15",
    "output": "Válida. Todos los campos requeridos están presentes."
  }
]

No inventes pares. Si los generas con otro LLM, revísalos manualmente antes de usarlos.

2. Verifica tu VRAM antes de descargar nada

Modelo 7B + QLoRA 4-bit = mínimo 6 GB VRAM. Si tienes menos, baja a QLoRA 2-bit (4 GB) o usa Colab/Kaggle.

Comprueba tu VRAM disponible en Linux/Windows antes de empezar:

nvidia-smi

En Mac con Apple Silicon, la memoria unificada actúa como VRAM. Un M2 con 16 GB debería manejar un 7B en 4-bit.

3. Instala LLaMA Factory

git clone https://github.com/hiyouga/LLaMA-Factory.git
cd LLaMA-Factory
pip install -e ".[torch,metrics]"

Para la interfaz web (LlamaBoard):

llamafactory-cli webui

4. Configura el entrenamiento

En LlamaBoard seleccionas el modelo base (por ejemplo, Mistral-7B-Instruct), el método (QLoRA), la cuantización (4-bit), cargas tu dataset y ajustas los hiperparámetros clave:

Learning rate: empieza con 2e-4 para LoRA, baja si el modelo colapsa
Batch size: empieza con 2–4 según tu VRAM; batch pequeño = más estable, más lento
Épocas: 3–5 para datasets pequeños; más épocas con más datos
LoRA rank: 8–64; rank más alto = más parámetros entrenables = más memoria

5. Lanza y monitoriza

El entrenamiento de un 7B con QLoRA tarda 2–4 horas en Colab con T4 para datasets de cientos de pares. Observa la curva de pérdida: si no baja, el learning rate es demasiado bajo o los datos tienen problemas. Si baja muy rápido y el modelo empieza a repetir, estás sobreentrenando.

6. Evalúa antes de cantar victoria

El caso real del IIC-UAM (dev.to, marzo 2026) es ilustrativo: un chatbot RAG con GPT-3.5 obtuvo 3,59/5 en calidad de respuesta. Al añadir fine-tuning, mejoraron la calidad y el control de formato. La conclusión: RAG aporta conocimiento, fine-tuning aporta comportamiento; la combinación supera a ambos por separado.

Evalúa siempre con un conjunto de datos que el modelo no haya visto durante el entrenamiento. Si solo evalúas con datos de entrenamiento, estás mirando cómo copia, no cómo generaliza.

Los costes reales (con la letra pequeña que otros no ponen)

Fine-tuning 7B con LoRA/QLoRA: entre $10 y $100 en GPU más $50–200 al mes en hosting si lo despliegas. Fine-tuning 70B con QLoRA: entre $50 y $500 en GPU más $200–1.000 al mes en hosting.

Un modelo de 7B puede costar menos de $5 en una ejecución básica en 2026 (Spheron Network, marzo 2026). Pero los flujos de producción con ciclos iterativos escalan rápido. Y lo que nadie te dice: la carga operativa de mantener un modelo fine-tuneado a menudo se subestima (Atomic Loops, abril 2026). Tienes que re-entrenar cuando tus datos cambian, gestionar versiones del modelo, monitorizar que no ha degradado. Eso no es gratis.

El EU AI Act y el fine-tuning: lo que te puede costar ignorarlo

Si estás en la Unión Europea y haces fine-tuning para un caso de uso comercial, hay una fecha que anotar: 2 de agosto de 2026.

Un modelo fine-tuneado podría considerarse un nuevo sistema de IA si modifica sustancialmente el comportamiento del modelo base, requiriendo compliance con el EU AI Act. Si el fine-tuning es menor (ajuste de tono, formato de salida) probablemente no. Pero la línea no está definida con precisión quirúrgica todavía.

Las multas llegan hasta 35 millones de euros o el 7% de la facturación global. La recomendación es documentar el proceso: qué modelo base usaste, qué datos empleaste, qué evaluaciones hiciste y qué cambios de comportamiento introdujiste. Es burocracia, pero es burocracia que puede salvarte de una multa que hace que el coste del entrenamiento parezca propinas.

Errores comunes (y cómo evitarlos antes de perder el tiempo)

Confundir "quiero que el modelo sepa cosas de mi empresa" con necesitar fine-tuning. En el 80% de los casos, RAG con búsqueda semántica resuelve el problema sin tocar pesos ni montar infraestructura de entrenamiento.

No comprobar la VRAM antes de descargar el modelo. Mira los requisitos del modelo cuantizado que te interesa y compáralos con lo que tienes. Después descarga. No al revés.

Dataset de baja calidad. Pares generados automáticamente sin revisión manual, ejemplos inconsistentes, mezcla de estilos de respuesta. El modelo aprende exactamente lo que le das. Si los datos son basura, el modelo será basura con más confianza.

Sobreentrenamiento en datasets pequeños. Demasiadas épocas con pocos datos y el modelo empieza a memorizar en lugar de generalizar. Evalúa con datos separados desde el principio.

Asumir que Mistral 7B (o cualquier otro modelo) es la mejor opción sin probar en tu dominio. Funciona bien en muchos casos. No en todos. Prueba al menos dos modelos base antes de comprometerte con uno.

Ignorar la carga operativa post-entrenamiento. Fine-tuning no es un paso único. Es un proceso que necesita mantenimiento. Si no tienes capacidad para eso, valora si una API con un buen sistema prompt no resuelve el mismo problema con menos fricción operativa.

Herramientas de inferencia cuando el fine-tuning ya está hecho

Una vez tienes el modelo entrenado, necesitas servirlo. Las opciones principales para hardware sin GPU de datacenter:

Ollama sirve para explorar y prototipar: dos comandos y el modelo responde. No es para producción con múltiples clientes concurrentes.

vLLM convierte el modelo en un servidor compatible con la API de OpenAI, con batching continuo y PagedAttention para gestionar VRAM eficientemente. Si varios agentes van a llamar al modelo a la vez, vLLM evita el cuello de botella.

SGLang es más eficiente que vLLM para workloads agentivos con salidas estructuradas: JSON forzado, tool calling, patrones de prompts repetidos. Si tu caso de uso es un agente que llama herramientas y necesita respuestas en formato fijo, SGLang gana en ese patrón concreto.

ExLlamaV3 para GPUs de consumo cuando la VRAM importa. Formato EXL3, cuantización, paralelismo tensor. Si tienes una RTX 3090 y quieres correr un 30B sin que explote la VRAM, por aquí.

vMLX para Apple Silicon. Memoria unificada, sin CUDA, sin drivers de Linux. Si tienes un M3 Pro o M4 Max, empieza aquí antes de considerar montar un servidor dedicado.

Abre terminal. Comprueba tu VRAM. Decide si tu problema es realmente de fine-tuning o de un prompt mejor escrito. Si es lo primero, ya tienes el mapa. Si es lo segundo, acabas de ahorrarte semanas.