Actualizado: 2026-07-07

La pregunta "¿deberíamos fine-tunear nuestro propio LLM?" llega a mesas de arquitectura casi cada mes. La respuesta corta, casi siempre, es todavía no. La respuesta larga es que existen casos legítimos, que los costes han bajado gracias a LoRA y QLoRA (aunque siguen siendo considerables), y que alternativas como RAG o prompt engineering resuelven el 80 % de las necesidades sin los costes operativos del entrenamiento.

Puntos clave

  • El fine-tuning es el tercer nivel de personalización: el más caro y el que más tarda.

  • LoRA y QLoRA han bajado el umbral de GPU de "8 × A100" a "una RTX 4090".

  • El coste real no son las GPUs: son los datos, la evaluación y la operación continua.

  • Para la mayoría de equipos, RAG + prompt engineering cubre el caso sin entrenar nada.

  • Fine-tuning se justifica cuando el problema de estilo, formato o coste ha tocado techo con las otras dos vías.

Los tres niveles de personalización

Para situar el problema, hay tres capas de personalización de un LLM, de menor a mayor coste:

  • Prompt engineering. Ajustar instrucciones, ejemplos few-shot, chain-of-thought. Coste marginal, iteración en minutos. Cubre la gran mayoría de tareas bien definidas.

  • Retrieval-Augmented Generation (RAG). Recuperar fragmentos relevantes de una base de conocimiento y pasarlos al modelo en el contexto. Coste medio (embeddings + vector store), iteración en días.

  • Fine-tuning. Modificar los pesos del modelo con ejemplos propios. Coste alto (datos, GPUs, validación), iteración en semanas.

Saltar directamente al fine-tuning es el error más común. La mayoría de equipos que lo intentan podrían haber obtenido resultados equivalentes o mejores con un RAG bien diseñado. Véase la comparativa de bases de datos vectoriales como base del pipeline.

Cuándo fine-tuning tiene sentido real

Tres casos donde el fine-tuning justifica su coste:

  • Estilo o voz muy específicos. Si necesitas que el modelo responda con la personalidad exacta de una marca, con modismos o estructuras gramaticales que no puedes capturar con un system prompt largo, el fine-tuning lo internaliza.

  • Formato de salida muy estructurado. Modelos afinados para devolver siempre un JSON específico o para seguir un esquema de markup propio son más fiables que los prompteados: el formato pasa a estar "cosido" al modelo.

  • Reducción de coste y latencia con modelos pequeños. Un modelo de 7B parámetros fine-tuneado sobre tu dominio puede igualar o superar a GPT-3.5 para esa tarea concreta, con un 10–20 % del coste por token y mejor latencia.

Fuera de estos casos, RAG suele ganar.

LoRA y QLoRA: fine-tuning accesible

El gran cambio reciente es que el fine-tuning ha pasado de "necesitas 8 A100" a "puedes hacerlo en una RTX 4090". La técnica clave es LoRA[1] (Low-Rank Adaptation): en vez de entrenar todos los pesos, añades matrices de rango bajo sobre el modelo congelado. El resultado es prácticamente idéntico al full fine-tuning con el 1 % del coste de GPU.

QLoRA[2] combina LoRA con cuantización a 4 bits. Permite fine-tunear modelos de 65 mil millones de parámetros en una sola GPU con 48 GB de VRAM, algo que antes era impensable.

Librerías como PEFT[3] de Hugging Face y axolotl[4] envuelven estos métodos con configuración declarativa. Un pipeline de LoRA sobre Llama 2 7B se expresa en un YAML de 30 líneas, relacionado directamente con lo que describe el post sobre LLaMA 2 y los modelos abiertos.

Lo que realmente cuesta

El coste real del fine-tuning no son las GPUs: es todo lo demás.

  • Preparar el dataset. Entre 500 y 5 000 ejemplos de calidad (prompt + respuesta ideal) requieren inversión manual sustancial. Los ejemplos mal diseñados envenenan el modelo con sesgos y fallos.

  • Iteración y evaluación. Un fine-tune malo puede parecer bueno en el caso feliz y fallar catastróficamente en los casos frontera. Hacen falta evals automatizados antes y después.

  • Operación en producción. Un modelo propio significa gestionar inferencia, actualizaciones y monitorización de drift. Esto ya no es "llamar a una API".

Presupuesto realista para un primer fine-tune serio: 2–3 semanas de ingeniería + 1–5 k USD en GPU + un MLOps pipeline básico para evaluación.

Alternativas antes de decidir

Antes de comprometerse con fine-tuning, conviene agotar estas opciones:

  • RAG sobre tu dominio. Con pgvector o Pinecone más un buen reranking, cubres "el modelo necesita conocer datos específicos de la empresa" sin entrenar nada.

  • Prompts más largos con ejemplos cuidadosos. GPT-4 con 16 ejemplos few-shot a menudo supera a un modelo 7B fine-tuneado si los ejemplos son buenos.

  • Function calling con respuesta estructurada. Si lo que buscas es estructura, function calling resuelve casi todo sin entrenar.

  • Modelos especializados ya existentes. Para tareas comunes (código, médico, legal) existen modelos fine-tuneados de la comunidad: CodeLlama[5], Med-PaLM, entre otros.

Conclusión

Fine-tuning ha democratizado técnicamente gracias a LoRA y QLoRA, pero operacionalmente sigue siendo una inversión seria. Para la gran mayoría de equipos, empezar por prompt engineering + RAG es la vía correcta; el fine-tuning queda reservado a problemas donde los otros dos han tocado techo con evidencia clara. Cuando sí se acomete, una evaluación rigurosa antes y después del entrenamiento es tan importante como el entrenamiento en sí.

Lee este artículo en inglés: LLM Fine-Tuning: When It’s Worth Training Your Own.

Fuentes

  1. LoRA
  2. QLoRA
  3. PEFT
  4. axolotl
  5. CodeLlama