curl -fsSL https://ollama.com/install.sh | sh

Descargar modelo según tu hardware

ollama pull phi4-mini # para 8 GB
ollama pull llama3.1:8b # para 16 GB
ollama pull qwen3:32b # para 32-48 GB
ollama pull gemma4:26b # alternativa para 32-48 GB
ollama pull llama3.1:70b # para 64 GB o AMD Ryzen AI Max+

Lanzar el modelo

ollama run qwen3:32b

Una vez que Ollama está corriendo, expone una API REST compatible con el formato de OpenAI en `http://localhost:11434`. Cualquier herramienta que apunte a esa URL puede usar tu modelo local sin cambiar el código de integración.

### Alternativas a Ollama

- **LM Studio**: interfaz gráfica, ideal para explorar y comparar modelos sin tocar la terminal. Buena opción si quieres probar varios modelos antes de decidir cuál integrar.
- **MLX**: framework nativo de Apple Silicon. En modelos de menos de 14B es entre un 20% y un 87% más rápido que llama.cpp. Si trabajas exclusivamente en Mac y quieres exprimir el hardware, MLX es la mejor opción para ese rango.
- **llama.cpp**: más control, más bajo nivel. Útil cuando necesitas cuantización específica o experimentar con configuraciones no estándar.

Para developers que integran modelos en flujos de trabajo, el stack que funciona en 2026 es **Ollama como servidor + tu herramienta habitual como cliente**. Sin más.

---

## Cuándo tiene sentido y cuándo no

Esta es la parte que más se omite en los tutoriales.

### Tiene sentido correr LLMs locales cuando:

- **Privacidad del código**: tienes código propietario o contractualmente restringido que no puede salir de tu máquina. Enviar un contexto de 50.000 tokens con lógica de negocio crítica a la API de terceros es un riesgo que algunas empresas no pueden asumir.
- **Costo a escala**: si generas miles de peticiones al día en un pipeline automatizado, el coste por token se acumula rápido. Un modelo local bien configurado tiene coste cero por petición una vez amortizado el hardware.
- **Trabajo offline o con latencia cero**: demos, entornos sin acceso a internet, o flujos donde la latencia de red es un problema real.
- **Experimentación sin rate limits**: probar prompts, evaluar respuestas, hacer benchmarks a tu ritmo.

### No tiene sentido cuando:

- **Necesitas calidad frontier para producción**: la diferencia entre un Qwen 3 32B local y Claude Fable 5 en tareas de razonamiento complejo multi-paso sigue siendo real. Para agentes que toman decisiones críticas o generan código de arquitectura compleja, la API sigue ganando. Si quieres integrar la API de Claude en tus proyectos, el [crash course de Claude API para TypeScript](https://www.dominicode.com/posts/claude-api-introduccion-crash-course) cubre el setup completo.
- **Tienes menos de 16 GB**: con 8 GB la experiencia es frustrante, no productiva.
- **Tareas de razonamiento complejo**: cadenas de pensamiento largas, análisis que requieren mantener contexto amplio con alta fidelidad. Ahí los modelos frontier siguen siendo superiores.

La pregunta no es "API local o API remota". La pregunta es: ¿qué tarea estás haciendo y cuánto contexto necesitas? Si en el [curso de Construye con IA](https://www.udemy.com/course/construye-con-ia-de-la-idea-al-producto-con-claude-code/?referralCode=AECD9EA3796054DEDD5D) hablo de agentes que procesan código propio en bucles automatizados, el caso de uso para LLMs locales es obvio. Para tareas de planeamiento de arquitectura complejas, Claude sigue siendo la elección correcta.

El stack ideal en 2026 no es elegir uno. Es saber cuándo usar cada uno.

---

## El contexto de mercado que importa

El ecosistema de LLMs se fragmenta: los modelos locales, los modelos especializados y las APIs alternativas han madurado lo suficiente para competir en casos de uso concretos. Ya no estamos en el momento en que solo había una opción viable para cada tarea.

Eso es bueno para los developers. Significa que la decisión ya no es "uso OpenAI o no". Es una decisión de ingeniería sobre qué modelo, ejecutado dónde, para qué tarea específica.

En [Dominicode Labs](https://labs.dominicode.com) hemos estado documentando exactamente esos patrones — qué modelos locales integramos en qué partes del pipeline de desarrollo y cómo medimos la diferencia. Si quieres explorar ese material con proyectos reales, ahí está el acceso.

---

## FAQ

**¿Qué modelo local es el mejor en 2026 para desarrolladores?**

Depende de tu hardware. Si tienes 32 GB o más, Qwen 3 32B es el más equilibrado: buen razonamiento, soporte de contexto largo y rendimiento estable. Para 16 GB, Llama 3.1 8B sigue siendo sólido. Para trabajo de código específicamente, Qwen 2.5 Coder en su variante 7B o 14B es fuerte para el rango de memoria que ocupa.

**¿Necesito una GPU dedicada para correr LLMs locales?**

No si tienes Apple Silicon. La memoria unificada de los chips M hace que el requisito de "GPU con mucha VRAM" deje de aplicar. En Windows, una RTX 4090 con 24 GB de VRAM sigue siendo el estándar para modelos de 32B, pero el AMD Ryzen AI Max+ 395 con su arquitectura de memoria compartida es una alternativa seria para laptops.

**¿Ollama funciona en Windows?**

Sí. Ollama tiene instalador nativo para Windows. Para GPUs AMD en Windows, el soporte ROCm es inconsistente — si usas hardware AMD en Windows y tienes problemas de rendimiento, considera Linux.

**¿Cuánto tarda en responder un modelo 32B corriendo en local?**

En un MacBook Pro M4 Max con 48 GB, Qwen 3 32B genera aproximadamente 25-35 tokens por segundo, dependiendo de la longitud del contexto. Para conversaciones normales es fluido. Para respuestas muy largas o contextos de 100K+ tokens, es notablemente más lento que la API.

**¿Los modelos locales pueden usarse con herramientas como Cursor o VS Code?**

Sí. Ollama expone una API compatible con el formato de OpenAI. Herramientas que permiten configurar un endpoint de API personalizado (como Continue.dev en VS Code) pueden apuntar directamente a tu instancia local de Ollama.

**¿Vale la pena el hardware nuevo solo para correr LLMs locales?**

Si ya tienes un Mac con 32 GB o más, no necesitas hardware nuevo. Si estás en el mercado de una actualización, el Mac Studio M4 Max con 64 GB es el punto de entrada más potente para correr modelos de 70B con rendimiento real. Para Windows, una RTX 4090 sigue siendo la opción más accesible para modelos de 32B.

---

*Por [Bezael Pérez](https://dominicode.com) — Developer senior con más de 15 años de experiencia y fundador de Dominicode.*

Si tu siguiente paso es probarlo hoy: corre `ollama pull qwen3:32b` si tienes 32 GB, o `ollama pull llama3.1:8b` si tienes 16 GB. En diez minutos tienes el modelo corriendo. El resto lo tienes en el canal de [YouTube de Dominicode](https://www.youtube.com/@dominicode) — pipelines reales, no teoría.

Un cliente me mostró su arquitectura hace unos meses. Había pasado seis semanas haciendo fine-tuning de un modelo para que respondiera preguntas sobre la documentación interna de su empresa.

Seis semanas. Un dataset de 4.000 pares de pregunta-respuesta construidos a mano. Costes de entrenamiento en GPU. Y al final, el sistema seguía inventándose respuestas cuando la pregunta tocaba un documento que no estaba en el training data.

Le pregunté por qué no había usado RAG. Me dijo que pensó que fine-tuning era “la solución profesional”. Que RAG era para hacer demos rápidas. Ese malentendido sobre RAG vs Fine-tuning es más común de lo que parece, y sale caro.

El error conceptual que lo complica todo

La mayoría de developers que se acercan a este problema lo enmarcan mal desde el principio.

Piensan en términos de “qué técnica es más potente”. Y ahí ya van por el camino equivocado.

La pregunta correcta no es cuál es más potente. Es: ¿qué problema tienes exactamente?

Si tu modelo no sabe cosas que necesita saber — información privada, documentos internos, datos recientes — tienes un problema de conocimiento. RAG lo resuelve.

Si tu modelo sabe las cosas pero no las comunica como necesitas — tono diferente, formato específico, comportamiento distinto al por defecto — tienes un problema de comportamiento. Fine-tuning lo resuelve.

Son problemas distintos. Las soluciones no son intercambiables.

Qué es RAG (Retrieval-Augmented Generation) y cuándo usarlo

RAG (Retrieval-Augmented Generation) no modifica el modelo. El modelo base sigue siendo exactamente el mismo.

Lo que hace RAG es intervenir en el momento en que llega una pregunta. Antes de pasársela al modelo, busca en una base de datos vectorial los fragmentos de tus documentos más relevantes para esa consulta, y los inyecta en el prompt. El modelo entonces responde con acceso real a esa información.

Usuario pregunta: "¿Cuál es la política de devoluciones?"
                         ↓
             Sistema RAG busca en vectorDB
                         ↓
      Encuentra: chunk del doc "politica-devoluciones-2026.pdf"
                         ↓
    Prompt al modelo: "Contexto: [chunk]. Pregunta: ¿Cuál es...?"
                         ↓
            Modelo responde con información real

La ventaja clave: tus documentos pueden cambiar mañana. Actualizas la base vectorial. El modelo ya tiene acceso a la nueva información. Sin reentrenar nada.

Si estás explorando qué modelo usar para el componente generativo, este análisis sobre el mejor modelo LLM local en 2026 te ayuda a elegir sin sobreingenierizar la infraestructura.

Esto es lo que lo hace ideal para documentación interna, bases de conocimiento, FAQs, soporte técnico — cualquier caso donde la información cambia y necesitas que el modelo cite fuentes reales en lugar de fabricar respuestas.

El límite de RAG está en que no cambia cómo se comporta el modelo. Si necesitas que responda en un tono muy específico, siga un formato exacto, o haga razonamientos que el modelo base no hace bien de forma natural, RAG no te ayuda. Solo le das más información. No lo entrenas.

Qué es Fine-tuning de LLMs y cuándo tiene sentido aplicarlo

Fine-tuning sí modifica el modelo. Tomas un modelo base preentrenado y lo sigues entrenando con tu propio dataset, ajustando sus pesos para que aprenda los patrones que te interesan.

El resultado es un modelo diferente. Uno que ha interiorizado un estilo, un formato, un tipo de razonamiento específico. No necesitas darle instrucciones en el prompt porque ya las tiene grabadas en sus pesos.

# Sin fine-tuning: necesitas el prompt completo
prompt = """Eres un asistente técnico especializado en Kubernetes.
Responde siempre con: 1) causa del problema, 2) solución paso a paso, 
3) cómo prevenirlo. Usa terminología técnica precisa. No añadas 
disclaimers. El tono es directo, de senior a senior.

Problema: Mi pod no arranca después de actualizar la imagen..."""

# Con fine-tuning: el modelo ya sabe cómo comportarse prompt = "Problema: Mi pod no arranca después de actualizar la imagen..."

El modelo fine-tuneado responde directamente en el formato correcto porque ese comportamiento está en sus pesos. No porque se lo estés recordando en cada llamada.

Lo que fine-tuning no resuelve: inyectar conocimiento factual nuevo. Si entrenas el modelo en el estilo de tu empresa pero no en los documentos de tu empresa, seguirá sin saber qué contienen esos documentos. Habrá aprendido a comunicarse como tú quieres, pero no a responder con información real que no tenía.

RAG vs Fine-tuning: la matriz de decisión con cuatro casos reales

Hay cuatro combinaciones que aparecen una y otra vez en proyectos reales. Aquí están con sus soluciones.

Caso 1: Chatbot sobre documentación interna

Necesitas que el modelo responda preguntas sobre tus PDFs, wikis, Notion, Confluence. La información cambia regularmente. El tono puede ser el del modelo base.

Solución: RAG. Indexas los documentos en una vectorDB (Pinecone, pgvector, Weaviate), configuras el pipeline de retrieval, y el modelo responde con fuentes reales. No reentrenar nada.

Caso 2: Generador de código en el estilo de tu empresa

Quieres que el modelo genere código que siga tus convenciones internas, use tus abstracciones propias, evite los patrones que prohíbes. El modelo base lo entiende pero tienes que recordárselo en cada prompt.

Solución: Fine-tuning. Un dataset de ejemplos de código en tu estilo — antes/después — y el modelo interioriza esas preferencias. El prompt se simplifica radicalmente.

Caso 3: Asistente de soporte que responde sobre tus productos Y en tu tono

Quieres las dos cosas: información factual sobre tus productos (que cambia) y un comportamiento de comunicación muy específico (directo, sin ambigüedades, con formato concreto).

Solución: Fine-tuning + RAG. Fine-tuning para el comportamiento y el formato. RAG para la información factual. Son complementarios, no excluyentes.

Caso 4: Clasificador de texto o extractor de entidades

Necesitas que el modelo clasifique tickets de soporte, extraiga entidades de contratos, o haga tareas de NLP muy específicas.

Solución: Fine-tuning en casi todos los casos. Para tareas de clasificación y extracción, un modelo fine-tuneado en tu dominio supera consistentemente a uno general con prompts elaborados, y además es más barato en inferencia porque los prompts son más cortos.

Los costes reales — lo que nadie te dice antes de empezar

Costes de RAG:

• Configurar el pipeline de chunking, embedding y retrieval: 2-5 días de desarrollo
• Inferencia: coste del modelo base + coste de las llamadas a la vectorDB (bajo)
• Mantenimiento: actualizar la base vectorial cuando cambian los documentos (automatizable)
• Problema principal: calidad del retrieval — si buscas mal, el modelo responde mal aunque los documentos sean perfectos

Costes de Fine-tuning:

• Construir el dataset de entrenamiento: semanas (es el cuello de botella real)
• Entrenamiento: desde $50 hasta miles de dólares dependiendo del modelo y el tamaño del dataset
• Inferencia: más cara que el modelo base porque tienes que hostear tu propio modelo o pagar por el endpoint custom
• Problema principal: degradación con el tiempo — si tu tarea evoluciona, tienes que reentrenar

La mayoría de proyectos que han hecho fine-tuning cuando lo que necesitaban era RAG han pagado semanas de trabajo y costes de entrenamiento para resolver un problema que RAG hubiera resuelto en cuatro días.

El árbol de decisión que uso en consultoría

Cuando alguien me pregunta qué usar, le hago estas cuatro preguntas en orden:

1. ¿Tu problema es que el modelo no tiene la información o que no se comporta como quieres?

• No tiene la información → RAG
• No se comporta bien → Fine-tuning

2. ¿La información cambia con frecuencia?

• Sí → RAG (actualizar embeddings es trivial vs. reentrenar)
• No → Fine-tuning empieza a tener más sentido

3. ¿Tienes datos de entrenamiento de alta calidad?

• No los tienes → empieza con RAG mientras los recopilas
• Sí los tienes → Fine-tuning es viable

4. ¿Tienes restricciones de latencia o coste de inferencia?

• Sí, necesitas prompts muy cortos → Fine-tuning reduce el prompt dramáticamente
• No es crítico → RAG es suficiente

En la práctica, el 70% de los casos que veo en producción son candidatos a RAG, no a fine-tuning. Fine-tuning es potente pero requiere un problema muy bien definido, datos de calidad y tiempo para construirlos.

Qué pasa cuando combinas los dos

La combinación más efectiva en sistemas de producción serios sigue un patrón concreto. Y es parte de una arquitectura más amplia — si quieres entender cómo el LLM encaja con el resto del sistema, el post sobre qué es un agent harness lo explica con detalle.

• Fine-tuning para que el modelo entienda el dominio, la terminología y el formato de respuesta esperado
• RAG para que el modelo tenga acceso a la información factual actualizada

Un ejemplo real: un asistente jurídico. Fine-tuneado para entender terminología legal española, responder en formato jurídico y estructurar los análisis como lo haría un abogado. RAG conectado a la base de legislación actualizada y a los expedientes del despacho.

El modelo habla como un jurista (fine-tuning). Responde con la ley real y los documentos del caso (RAG). Ninguna de las dos técnicas sola lo consigue.

Esta es la arquitectura que más vemos en productos de IA serios. No es glamorosa. Pero funciona. En el curso Construye con IA: de la idea al producto con Claude Code, trabajo este tipo de decisiones de arquitectura desde la fase de especificación — antes de escribir una línea de código — para que no llegues a la semana seis arrepintiéndote de la técnica que elegiste.

Tabla comparativa RAG vs Fine-tuning

Guarda esta tabla. Te va a ahorrar más de una conversación.

FAQ

¿Puedo usar RAG con cualquier LLM?

Sí. RAG es agnóstico al modelo. Funciona con GPT-4, Claude, Gemini, Llama, Mistral o cualquier modelo que acepte un prompt de texto. Lo único que necesitas es que el modelo tenga una ventana de contexto suficiente para recibir los chunks recuperados junto con la pregunta. Los modelos modernos (128k-200k tokens) raramente tienen problemas con esto.

¿El fine-tuning de GPT-4 o Claude vale la pena frente a usar el modelo base con un buen prompt?

En la mayoría de casos de uso, un buen prompt de sistema con ejemplos (few-shot prompting) iguala o supera al fine-tuning cuando el dataset de entrenamiento es pequeño (menos de 1.000 ejemplos). Fine-tuning empieza a tener sentido claro cuando tienes +5.000 ejemplos de calidad, cuando el coste de inferencia del prompt largo es un problema real, o cuando necesitas consistencia de comportamiento imposible de garantizar solo con prompts.

¿RAG siempre “alucina” menos que el modelo base?

RAG reduce alucinaciones relacionadas con hechos específicos de tus documentos — porque el modelo tiene el texto real delante. Pero no elimina las alucinaciones del modelo base sobre razonamientos o inferencias. Si el modelo alucina porque hace mal el razonamiento lógico, RAG no te ayuda. Ese es un problema de capacidad del modelo, no de conocimiento.

¿Qué vectorDB recomendas para empezar?

Para proyectos nuevos: pgvector si ya usas PostgreSQL (cero infraestructura adicional), o Pinecone si quieres un servicio gestionado sin fricción operativa. Weaviate y Chroma son buenas opciones open-source si necesitas auto-hosting. Evita sobre-ingenierizar esto al principio — pgvector resuelve el 80% de los casos sin añadir complejidad. Puedes consultar la documentación oficial de pgvector para la instalación y configuración básica.

¿Cuánto cuesta hacer fine-tuning con GPT-4o mini o Llama 3?

GPT-4o mini fine-tuning en OpenAI cuesta aproximadamente $3-5 por millón de tokens de entrenamiento (junio 2026). Un dataset de 10.000 ejemplos con prompts de 500 tokens cada uno te sale a menos de $30 de entrenamiento. El coste real no es el GPU — es el tiempo de construir el dataset de calidad. Con Llama 3, puedes hacer fine-tuning con frameworks como Unsloth en una GPU A100 por $2-4/hora. Un run de fine-tuning de 3-4 horas es completamente asequible.

¿RAG vs Fine-tuning cambia con los modelos de razonamiento (o1, Gemini Thinking)?

Sí, hay un matiz importante. Los modelos de razonamiento son mucho mejores siguiendo instrucciones complejas en el prompt, lo que reduce la necesidad de fine-tuning para casos de comportamiento. Pero siguen sin tener acceso a información privada o actualizada — ahí RAG sigue siendo indispensable. El fine-tuning con modelos de razonamiento es técnicamente más complejo y menos documentado a fecha de hoy.

Si quieres ver estos patrones aplicados en proyectos reales con código y arquitectura completa, en Dominicode Labs trabajamos este tipo de decisiones técnicas con la comunidad. Proyectos reales, problemas reales, decisiones que puedes aplicar esta semana.

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.