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. 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.

  • Mientras no toques techo en estilo, formato o coste, 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. Los 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 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 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 supera a un modelo 7B fine-tuneado cuando 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. Hu et al. LoRA: Low-Rank Adaptation of Large Language Models (arXiv:2106.09685)[1]
  2. Dettmers et al. QLoRA: Efficient Finetuning of Quantized LLMs (arXiv:2305.14314)[2]
  3. Hugging Face: documentación de PEFT[3]
  4. axolotl-ai-cloud: repositorio de axolotl en GitHub[4]

Preguntas frecuentes

¿Puedo hacer fine-tuning de un LLM con una sola GPU de consumo?

Sí, gracias a LoRA y QLoRA el umbral ha bajado de 8 A100 a una RTX 4090. LoRA añade matrices de rango bajo sobre el modelo congelado en lugar de entrenar todos los pesos, con un resultado prácticamente idéntico al full fine-tuning por el 1 % del coste de GPU. QLoRA suma cuantización a 4 bits y permite afinar modelos de 65 mil millones de parámetros en una GPU de 48 GB de VRAM. Librerías como PEFT de Hugging Face y axolotl lo expresan en un YAML de unas 30 líneas.

¿Cuánto cuesta realmente un primer fine-tuning serio?

El presupuesto realista es de 2–3 semanas de ingeniería más 1–5 k USD en GPU y un pipeline MLOps básico de evaluación. Las GPUs no son el coste principal: lo es preparar entre 500 y 5 000 ejemplos de calidad, porque los mal diseñados envenenan el modelo. Lo es montar evals automatizados antes y después, ya que un fine-tune malo parece bueno en el caso feliz y falla en los casos frontera. Y lo es operar en producción la inferencia, las actualizaciones y la monitorización de drift.

¿Qué debería probar antes de decidirme por el fine-tuning?

Agotar las alternativas, que cubren el 80 % de las necesidades: la primera es RAG sobre tu dominio con pgvector o Pinecone más un buen reranking, si el modelo necesita datos de la empresa. La segunda son prompts más largos con ejemplos cuidadosos, porque GPT-4 con 16 ejemplos few-shot bien elegidos supera a un modelo 7B afinado. Quedan function calling si buscas salida estructurada y modelos especializados ya existentes como CodeLlama o Med-PaLM. El fine-tuning se justifica cuando el problema de estilo, formato o coste ha tocado techo con esas vías.

Fuentes

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