Guía práctica para afinar modelos LLM locales

Última actualización: abril 13, 2026
  • La afinación fina de LLM permite especializar modelos generales con pocos datos bien anotados, especialmente mediante PEFT (LoRA, QLoRA).
  • La elección de modelo base, tamaño, cuantización y formato (GGUF, GPTQ) es clave para equilibrar calidad y recursos en entornos locales.
  • Herramientas como LM Studio y Ollama facilitan ejecutar, afinar y exponer modelos LLM en local con APIs compatibles con OpenAI.
  • La combinación de fine‑tuning y RAG habilita asistentes privados y especializados en sectores regulados usando hardware relativamente modesto.

Guía práctica para afinar modelos LLM locales

Si has llegado hasta aquí es porque quieres que tu propio asistente de IA deje de ser un “generalista” y pase a comportarse como un experto en tu dominio, funcionando en tu propio ordenador o servidor, sin depender de la nube. La buena noticia es que hoy eso es totalmente posible incluso con hardware relativamente modesto, siempre que planifiques bien qué modelo usar, cómo preparas los datos y qué herramientas pones en juego.

En esta guía práctica vamos a recorrer, paso a paso, todo lo que necesitas para afinar (fine‑tunear) modelos LLM en local: desde conceptos básicos (qué es exactamente afinar y en qué se diferencia de usar RAG), hasta la elección de hardware, formatos de modelos, tipos de cuantización, herramientas como LM Studio y Ollama, y ejemplos reales de rendimiento en máquinas sin GPU o con gráficas de consumo. El objetivo es que termines con un mapa claro y práctico, sin “haz esto y ya está”, sino con criterios concretos para tomar decisiones.

Qué significa realmente afinar un LLM y cuándo tiene sentido hacerlo

Ajuste fino de modelos LLM en local

Cuando hablamos de afinación fina (fine‑tuning) nos referimos a tomar un modelo de lenguaje ya preentrenado con cantidades masivas de texto genérico y volver a entrenarlo, pero esta vez con datos específicos de tu dominio (medicina, legal, servicio al cliente, documentación interna de empresa, etc.). No empiezas de cero: aprovechas el conocimiento general del modelo y lo especializas.

Esto permite que un LLM que ya sabe “un poco de todo” pase a entender matices como terminología médica, normativa financiera o políticas internas, respondiendo con mucha más precisión en ese contexto. Es similar a contratar a alguien con una carrera generalista y luego formarle intensivamente en el sector concreto de tu empresa.

La gran ventaja es que, frente a entrenar un modelo desde cero, el fine‑tuning requiere muchísimos menos datos y recursos de cómputo. Aun así, sigue siendo un proceso costoso comparado con simplemente usar RAG (Retrieval Augmented Generation), donde el modelo general se apoya en documentos externos recuperados en cada consulta sin modificar sus pesos internos.

¿Cuándo tiene sentido afinar y cuándo te basta con RAG? El fine‑tuning compensa cuando necesitas que el modelo: se adapte al tono y estilo de tu organización, aprenda patrones complejos que no salen bien solo con contexto (por ejemplo, redacción jurídica muy específica), funcione de forma robusta sin tener que enviar siempre grandes bloques de contexto, o se ejecute en local con restricciones de memoria y desees que “de fábrica” ya se comporte bien en tu dominio.

El enfoque híbrido es muy potente: un modelo ligeramente afinado a tu caso de uso y, además, un sistema RAG para inyectar datos siempre actualizados (manuales, FAQs, políticas que cambian). Así evitas tener que reentrenar cada vez que publicas nueva documentación.

Tipos de afinación: full fine‑tuning vs PEFT (LoRA, QLoRA)

En el mundo real no todos los ajustes de modelos se hacen igual. Existen dos grandes enfoques para adaptar un LLM a tu caso de uso: el afinamiento completo (full fine‑tuning) y el afinamiento eficiente de parámetros (PEFT, Parameter‑Efficient Fine‑Tuning), donde destacan LoRA y QLoRA.

En el afinamiento completo se actualizan todos los parámetros del modelo. Esto tiene sentido cuando tu conjunto de datos específico es grande y muy distinto del corpus genérico con el que se entrenó el modelo base. Por ejemplo, si quieres un LLM médico de alto nivel a partir de un modelo generalista y cuentas con muchos historiales y textos clínicos cuidadosamente anonimizados y anotados.

La contrapartida es que el full fine‑tuning es muy exigente en GPU, VRAM y tiempo. Afinar completamente un modelo de 14B parámetros en una máquina doméstica (aunque sea una Mac potente o un PC gaming) suele ser poco realista salvo que tengas varias GPUs grandes o alquiles máquinas en la nube con tarjetas tipo H100, L40S, RTX 6000 Ada o equivalentes.

Ahí es donde entra PEFT. En vez de tocar todas las “tripas” del modelo, congelas los pesos originales y añades un conjunto pequeño de parámetros adicionales, que sí se entrenan. Imagina que al libro de 1000 páginas del modelo base solo le añades post‑its con notas especializadas, en lugar de reescribirlo entero.

Los métodos más populares son LoRA (Low‑Rank Adaptation) y QLoRA (LoRA aplicado sobre modelos cuantizados). Ambos reducen drásticamente la memoria necesaria para afinar y permiten entrenar en GPUs de consumo o incluso en algunos casos en CPU, pagando un coste mínimo en precisión frente al full fine‑tuning. Para la mayoría de usos típicos (chatbots de empresa, asistentes técnicos, soporte al cliente, etc.) LoRA/QLoRA es hoy la opción más razonable.

Cómo deben ser los datos de entrenamiento y qué tamaño necesitas

Una de las dudas más frecuentes al plantearse afinar un LLM local es: ¿cuántos datos necesito y en qué formato? La respuesta corta: menos de lo que crees, pero mejor calidad de la que sueles tener.

Más allá de si los guardas en CSV o JSON, lo importante es la estructura lógica de los ejemplos. Para tareas conversacionales o de QA típicas (chatbots, soporte), el estándar de facto son pares de instrucción → respuesta ideal, por ejemplo:

Usuario: “¿Cuál es el horario de atención de soporte técnico?”
Asistente (ideal): “Nuestro soporte técnico está disponible de lunes a viernes de 9:00 a 18:00 (hora peninsular), excepto festivos nacionales.”

Puedes enriquecer estos pares añadiendo contexto o sistema (rol del asistente, normas de estilo, restricciones). Lo importante es que la respuesta refleje exactamente el comportamiento que quieres interiorizar en el modelo: tono, precisión, nivel de detalle, idioma, límites, etc.

¿Hace falta incluir ejemplos negativos? No es obligatorio, pero ayuda. Ejemplos donde el modelo debería rechazar una petición (por seguridad, confidencialidad o política interna) refuerzan el comportamiento seguro. Por ejemplo, peticiones de datos personales que el asistente debe negar, o preguntas claramente fuera de dominio donde debe decir que no sabe.

Respecto al tamaño, para un modelo mediano (~7B-14B) afinado con LoRA para un dominio concreto puedes obtener mejoras muy visibles con miles o decenas de miles de ejemplos bien curados. Si tu dataset tiene apenas unos cientos pero son de altísima calidad, sigue mereciendo la pena, sobre todo si el ajuste es muy enfocado (por ejemplo, responder sobre 3 o 4 productos concretos).

En cambio, si pretendes cambiar completamente el “oficio” del modelo (de modelo general a experto médico de primer nivel), te hará falta mucho más: cientos de miles de ejemplos y/o mezcla con datasets públicos. En entornos locales y empresariales, lo habitual es centrarse en segmentos más acotados (preguntas frecuentes, procedimientos internos, documentación técnica de producto) donde el volumen de datos razonable sí está al alcance.

Elección del modelo base, tamaño y formato para uso local

Antes de tocar una sola línea de código o de configuración, tienes que decidir qué modelo vas a usar como base. No es lo mismo afinar un modelo de 3.8B parámetros que uno de 20B, y la elección condiciona VRAM, tiempo de inferencia y experiencia de usuario.

En el ecosistema actual destacan familias como Llama (Meta), Gemma (Google), Phi-3 (Microsoft), Mistral, Qwen, OpenChat, WizardLM o mezclas tipo Mixtral 8x7B. Cada una ofrece variantes “base”, “instruct”, “chat” o “code”, además de tamaños distintos (desde modelos diminutos de 0.5B hasta gigantes de decenas de miles de millones de parámetros).

Para uso local equilibrado (buen rendimiento y consumo razonable), los modelos entre 3B y 8B parámetros son el punto dulce. Ejemplos muy interesantes en pruebas reales sobre CPUs sin GPU han sido Gemma 7B instruct, Phi‑3 3.8B mini instruct o Qwen 4B/7B, que ofrecen una combinación excelente de calidad de respuesta y tiempos de inferencia aceptables.

También influye la cuantización. La cuantización reduce la precisión numérica de los pesos (por ejemplo, de FP32 a 8, 5 o 4 bits) para ahorrar memoria y acelerar la inferencia. Con 4‑bit bien hecha es posible meter modelos muy competentes en GPUs con 8-12 GB de VRAM o incluso en CPU con bastante RAM. A cambio, pierdes algo de fidelidad, pero en muchos escenarios empresariales la pérdida es asumible.

En formato, para inferencia local son muy populares GGUF (heredero de GGML, ideal para llama.cpp y herramientas compatibles), GPTQ (cuantización optimizada para GPU) y safetensors (formato seguro inicial, que luego puedes convertir a otros). Si tu idea es jugar en local con CPU y GPU de forma flexible, GGUF es un comodín muy conveniente, sobre todo si piensas usar proyectos como llama.cpp, LM Studio u Ollama.

Requisitos de hardware para afinar e inferir LLM en local

La pregunta incómoda: ¿necesitas una GPU monstruosa para hacer algo útil? No necesariamente, pero conviene tener claro qué papel juega cada componente: GPU, VRAM, CPU y RAM.

Para inferencia pura (usar el modelo ya afinado), lo que más pesa es la VRAM de la GPU. Si puedes cargar el modelo entero en la tarjeta gráfica, se evitan swaps a RAM de sistema y el rendimiento se dispara. Tarjetas como las NVIDIA GeForce RTX 4090/5090 o equivalentes AMD Radeon RX 7900 XTX / serie 9000 son ideales para modelos medianos y grandes con cuantización razonable.

En entornos profesionales de alto nivel, entran en juego GPUs tipo H100, L40S, RTX 6000 Ada o AMD Instinct MI300X, donde se maneja VRAM abundante y memorias HBM. Pero para quien monta un servidor de IA casero o un PC de sobremesa, el objetivo es encontrar un equilibrio decente entre precio, VRAM disponible y consumo eléctrico.

Con CPU también se puede hacer inferencia, especialmente con modelos cuantizados y motores tipo llama.cpp u Ollama. Se ha demostrado que en servidores con Xeon de varias generaciones, 64 GB de RAM y SSD es viable ejecutar modelos de menos de 8B parámetros con tiempos razonables, incluso orientados a asistentes virtuales con RAG.

Para el afinamiento en sí, incluso con LoRA, una GPU ayuda muchísimo. Afinar un modelo de 14B en una Mac M‑series o un PC con GPU de gama media es factible si lo haces con PEFT + cuantización (por ejemplo QLoRA), asumiendo tiempos de entrenamiento de varias horas a unos pocos días según dataset y número de épocas. Sin GPU, el entrenamiento se vuelve mucho más lento, aunque para ajustes muy pequeños y dirigidos sigue siendo posible.

En local, además del cómputo puro, entra un factor que casi nadie menciona: la factura eléctrica y el ruido. Tener un PC gaming o servidor con la GPU al 100 % de forma constante no es trivial. Muchos usuarios optan por dejar el equipo en reposo y encenderlo o despertarlo (Wake‑on‑LAN) solo cuando van a usar la IA, o programar ventanas horarias de entrenamiento para no tenerlo rindiendo a tope 24/7.

Herramientas prácticas para trabajar con LLM locales: LM Studio y Ollama

Una vez decidido el modelo y el hardware, necesitas una capa de software amigable para bajar modelos, ejecutarlos, afinarlos y exponerlos vía API. Aquí destacan dos piezas muy utilizadas: LM Studio y Ollama, además de otras alternativas complementarias.

LM Studio es una aplicación de escritorio que te permite descargar, probar y ajustar modelos LLM en tu propia máquina, con una interfaz gráfica muy similar a la de ChatGPT. Funciona en Windows, macOS y Linux (como AppImage) y se integra con modelos de Hugging Face, facilitando empezar con modelos preentrenados como BERT, GPT o Llama sin pelearte con demasiadas opciones técnicas.

Entre sus puntos fuertes están el entrenamiento local (ideal donde la privacidad manda), una interfaz sencilla para usuarios no técnicos, compatibilidad con modelos preentrenados, controles de hiperparámetros (temperatura, top‑k, top‑p…), soporte creciente para GPUs, y la posibilidad de levantar un servidor API local compatible con OpenAI. Esto último es oro para desarrolladores que quieren integrar un modelo local en sus aplicaciones sin cambiar apenas el código orientado a la API de OpenAI.

Además, LM Studio puede ejecutarse en modo headless: lo configuras para que arranque como servicio, escuche en un puerto (por defecto 1234) y acepte peticiones desde la red local. De esta forma, puedes tener un servidor de IA en una habitación y consumirlo desde cualquier otro equipo usando clientes compatibles (como Chatbox, por ejemplo) apuntando a la URL http://IP_DEL_SERVIDOR:1234/.

Ollama, por su parte, se centra más en el entorno de desarrolladores y CLI. Es open source, funciona en Linux, Windows y macOS, y te permite arrancar modelos locales con un simple comando del estilo ollama run llama3. Su API es también compatible con la de OpenAI, lo que facilita usarlo desde frameworks, SDKs y herramientas de terceros.

En Linux es muy común desplegar Ollama en contenedores Docker, montando un volumen para los modelos y exponiendo el puerto 11434. Encima de eso se puede añadir una interfaz web como Open WebUI, que ofrece una experiencia muy parecida a ChatGPT pero utilizando el backend local de Ollama. En Windows, Ollama se ejecuta como servicio y puede configurarse para atender peticiones en todas las interfaces (por ejemplo, ajustando la variable de entorno OLLAMA_HOST=0.0.0.0).

Casos de uso: RAG, asistentes empresariales y ejecución sin GPU

Uno de los patrones más interesantes cuando trabajas con LLM locales es combinar un modelo relativamente ligero con una capa de RAG (Retrieval Augmented Generation). Básicamente, antes de preguntar al modelo, recuperas fragmentos relevantes de tu base de conocimiento (PDF, webs internas, documentación técnica) y se los añades al prompt como contexto.

Este enfoque resulta clave cuando tus clientes necesitan control absoluto sobre sus datos y no quieren subir documentación interna a la nube de terceros, aunque estos prometan no usarla para reentrenar modelos. Con RAG y modelos locales (por ejemplo, ejecutados en Ollama) puedes montar asistentes especializados sin sacar una sola línea de texto fuera de tu infraestructura.

En entornos con hardware muy ajustado, se ha demostrado que es posible lograr RAG funcional sin GPU usando servidores con CPUs Xeon, 64 GB de RAM y SSDs rápidos. En este tipo de pruebas se comparan modelos como Gemma 7B, Phi‑3 mini, Qwen 4B/7B, Mistral, Dolphin‑Llama3 e incluso Mixtral 8x7B cuantizado, midiendo tiempos de respuesta y calidad de las respuestas en distintos tipos de preguntas.

Por ejemplo, se han realizado tests con preguntas estándar como “¿Por qué el cielo es azul?”, trampas lógicas del tipo “¿qué pesa más, un kilo de paja o medio kilo de hierro?”, y preguntas con contexto RAG como “¿Qué es Dattabot y en qué puede ayudarme?”, donde se inyecta información de producto en el prompt. Un jurado independiente puntúa las respuestas por redacción, tono, exactitud y longitud, sin saber qué modelo las generó.

Los resultados muestran que modelos como Gemma 7B instruct cuantizado a q4_K_M ofrecen una calidad de respuesta muy alta, mientras que Qwen 4B y Phi‑3 3.8B mini instruct destacan por rapidez. De hecho, Qwen 4B aparece como uno de los mejores en relación calidad/tiempo, lo que lo convierte en candidato ideal para asistentes virtuales locales en hardware modesto.

Sectores donde más se aprovecha el fine‑tuning y la IA local

La capacidad de afinar modelos y ejecutarlos localmente no es solo un capricho técnico. En muchos sectores es una condición necesaria para poder usar IA por requisitos de privacidad, regulación o simplemente por tiempos de respuesta y costes.

En salud y medicina, por ejemplo, trabajar con historiales clínicos, exploraciones e informes médicos implica un nivel de confidencialidad máximo. Modelos como MedPalm o variantes médicas de Llama demuestran el potencial, pero muchas organizaciones necesitan infraestructura on‑premise. Afinar un modelo en local con datos médicos anotados y desplegarlo en un entorno controlado evita exponer información sensible a proveedores cloud externos.

En finanzas y seguros, los modelos ajustados ayudan en detección de fraude, scoring de riesgo, análisis de normativa y generación de informes. Un fine‑tuning bien hecho sobre datos financieros internos permite que el modelo entienda términos y regulaciones muy específicas, y que responda de forma alineada con las políticas de la entidad.

En el ámbito legal, los LLM afinados son cada vez más habituales para análisis de contratos, búsqueda de jurisprudencia y redacción asistida. Aquí el ajuste fino es crítico para que el modelo domine el lenguaje jurídico y respete los matices de cada jurisdicción. Ejecutarlo en local minimiza riesgos de fuga de información en documentos extremadamente sensibles.

Otros sectores se benefician de forma similar: en servicio al cliente, los chatbots ajustados al vocabulario y procesos de una compañía ofrecen respuestas mucho más coherentes; en industria manufacturera, los modelos especializados analizan datos de sensores para mantenimiento predictivo; en marketing, los LLM ajustados a datos de clientes permiten campañas hipersegmentadas; y en educación, los modelos se adaptan a currículos concretos y niveles de alumnos.

Todos estos casos comparten un patrón: partir de un modelo generalista robusto, añadirle datos anotados específicos del dominio, controlar bien los hiperparámetros de ajuste y desplegarlo en una infraestructura (local, híbrida o en la nube) que respete las limitaciones de seguridad, coste y rendimiento de cada organización.

Otras herramientas útiles en el ecosistema de LLM locales

Aunque LM Studio y Ollama son piezas muy prácticas para trabajar en local, el ecosistema es más amplio y conviene conocer otras opciones para completar tu stack. Cada herramienta resuelve una parte distinta del rompecabezas del ciclo de vida de un LLM: anotación de datos, monitorización de experimentos, frontends de chat, ejecución en móviles, etc.

Para anotación de datos y preparación de conjuntos de entrenamiento destacan plataformas como Kili Technology y SuperAnnotate, que ayudan a organizar flujos de trabajo de etiquetado, controlar la calidad de las anotaciones y coordinar equipos. Una anotación cuidada marca la diferencia cuando quieres que tu modelo se comporte con precisión quirúrgica en un dominio concreto.

En la parte de experimentación, Weights & Biases (W&B) es casi un estándar para registrar métricas, hiperparámetros y resultados a lo largo de múltiples pruebas de entrenamiento y fine‑tuning. Esto resulta clave cuando estás iterando con distintos modelos base, cuantizaciones y datasets, y no quieres depender de notas sueltas para saber qué configuración rindió mejor.

Para la inferencia optimizada, además de llama.cpp, existen librerías como vLLM, que se centran en exprimir al máximo el hardware disponible, especialmente en GPU, y frameworks como LocalAI, orientado a ejecutar modelos sobre CPU. También hay soluciones 100 % offline orientadas a escritorio como Jan, que recuerdan a LM Studio pero con un enfoque distinto.

Por último, en la capa de interacción y frontends, herramientas como Chatbox, ChatterUI, GPT4All, AnythingLLM o Maid permiten conectar a múltiples backends (APIs remotas, servidores locales tipo Ollama o LM Studio, etc.) y ofrecer a los usuarios finales una experiencia de chat unificada. En el móvil aparecen asistentes como PocketPal, Private LLM, Llamao y Layla, que ejecutan modelos diminutos directamente en el dispositivo, incluso sin conexión.

En conjunto, este ecosistema te permite montar desde un pequeño asistente personal en tu portátil hasta una plataforma corporativa de IA local con RAG, monitorización y múltiples frontends, todo ello partiendo de modelos de código abierto afinados a tu medida.

Si juntamos todo lo anterior, el panorama es claro: hoy puedes tomar un buen modelo base abierto, elegir el tamaño y cuantización adecuados, afinarlo con PEFT sobre unos cuantos miles de ejemplos bien anotados, desplegarlo en herramientas como LM Studio u Ollama, añadir una capa de RAG para acceder a tu documentación viva y servirlo via API a aplicaciones internas, todo corriendo en tu propio hardware y respetando la privacidad de tus datos; el reto ya no es si se puede, sino qué combinación exacta de modelo, datos, infraestructura y herramientas encaja mejor con tus necesidades, tu presupuesto y el nivel de especialización que buscas para tu LLM local.