IA en local: cómo ejecutar modelos de IA en tu propio equipo (guía 2026)

Cada prompt que escribes en ChatGPT viaja a un servidor que no controlas, te cuesta dinero (directa o indirectamente) y deja de funcionar en cuanto te quedas sin internet. Durante años esa fue la única forma de usar IA decente. Ya no.

En 2026, descargar un modelo de lenguaje y correrlo en tu propio equipo es cuestión de minutos y de unos pocos gigas de RAM. No es un experimento para frikis del terminal: hay apps con interfaz que lo hacen tan simple como instalar Spotify. Esta guía te lleva del "no tengo ni idea" al "tengo un modelo respondiéndome offline", entendiendo cada decisión por el camino.

Por qué ejecutar IA en local

Hay tres razones que se sostienen solas, y el resto son matices.

Privacidad real. Tus prompts y las respuestas nunca salen del equipo. Nada de logs en un servidor ajeno, nada de "podemos revisar tus conversaciones", nada de filtraciones por una brecha en la nube. Si trabajas con datos de clientes, borradores legales, información médica o cualquier cosa que no quieras subir a un tercero, esto cambia las reglas del juego.

Coste cero por uso. Pagas una vez —el hardware que ya tienes— y luego generas todo lo que quieras sin contador de tokens corriendo. Si haces volumen (clasificar miles de textos, resumir en bucle, prototipar a base de prueba y error), la diferencia frente a una API de pago es brutal.

Funciona offline. Sin internet, sin caídas de servicio, sin "el modelo está saturado, inténtalo más tarde". En un avión, en una zona sin cobertura o el día que el proveedor tiene un incidente, tu IA sigue ahí.

A cambio renuncias a algo: el techo de calidad. Hablaremos de eso al final, pero adelanto la conclusión honesta: para la mayoría de tareas cotidianas, un buen modelo local de 2026 te sobra.

El flujo, de un vistazo

Antes de tocar nada, conviene tener el mapa mental. Usar IA en local son siempre las mismas cuatro decisiones encadenadas:

Si entiendes estos cuatro pasos, entiendes el 90% del tema. El resto es elegir bien dentro de cada uno.

Requisitos de hardware (la pregunta que todos hacen)

La duda número uno es "¿lo aguantará mi equipo?". La respuesta depende del tamaño del modelo y de la cuantización, pero hay reglas prácticas claras.

Lo que manda es la memoria: cuánta RAM (si corres en CPU) o VRAM (si tienes GPU dedicada) tienes libre para cargar el modelo. Como referencia, con cuantización a 4 bits (Q4_K_M):

• Modelos de 7-8B parámetros → unos 5 GB de archivo, corren con 8 GB de RAM/VRAM. Es el punto de partida recomendado.
• Modelos de 13-14B → piden alrededor de 16 GB.
• Modelos de 70B → rondan los 40 GB; territorio de equipos potentes o varias GPU.

Tres aclaraciones importantes:

1. Sin GPU también vale. Cualquier portátil moderno corre un 7B en CPU; irá más lento (unas pocas palabras por segundo) pero funciona. Con una GPU dedicada de 8 GB en adelante, la cosa vuela.
2. Mac con Apple Silicon juega con ventaja. Los chips M comparten la memoria entre CPU y GPU (memoria unificada), así que un Mac con 16 GB mueve modelos que en un PC pedirían una gráfica dedicada. Además, en 2026 las herramientas usan el motor MLX nativo de Apple, que va más rápido y consume menos.
3. Deja margen. El modelo no es lo único que ocupa memoria: la ventana de contexto (el KV cache), el sistema operativo y el resto de programas también tiran. Regla sana: no llenes la memoria al 100%, deja un 10-15% de aire.

Cuantización y GGUF, sin tecnicismos

Esta es la pieza que más asusta y la más fácil de entender con una analogía. Un modelo "original" guarda cada uno de sus miles de millones de parámetros con mucha precisión (16 bits). Cuantizar es redondear esos números a menos bits —8, 5 o 4— para que el archivo ocupe mucho menos y vaya más rápido. Es como pasar de un WAV sin comprimir a un MP3 de buena calidad: ocupa una fracción y, en la práctica, casi no notas la diferencia.

GGUF es simplemente el formato de archivo estándar para esto en local: un único fichero que empaqueta los pesos, el tokenizador y los metadatos. Cuando busques modelos verás nombres como modelo-7B-Q4_K_M.gguf. Ese sufijo es el nivel de cuantización, y esto es lo único que necesitas recordar:

• Q4_K_M → el punto dulce. Reduce el tamaño ~75% con apenas un 3-5% de pérdida de calidad. Si dudas, este.
• Q5_K_M / Q6_K → un pelín más grandes y mejores; útil para código o razonamiento si te sobra memoria.
• Q8_0 → casi idéntico al original; solo si vas sobrado de RAM/VRAM.
• Q3_K_M / Q2_K → para cuando vas muy justo de memoria; se nota más la pérdida.

La "K_M" significa que reparte mejor los bits en las capas que más importan para la calidad. Por eso casi siempre vale más un Q4_K_M que un Q4 a secas.

Qué herramienta elegir (y para quién)

Todas las herramientas serias leen GGUF y usan por debajo el mismo motor (llama.cpp o, en Mac, MLX), así que la velocidad entre ellas es casi idéntica. Eliges por interfaz y por lo que vayas a hacer, no por rendimiento.

Esta es la guía rápida según tu perfil:

• LM Studio — para empezar sin complicarte. App de escritorio con interfaz pulida: buscas el modelo por nombre, ves cuánta RAM pide y si tu máquina lo aguanta, le das a descargar y chateas. Cero terminal, cero archivos de configuración. Si nunca has tocado esto, empieza aquí.
• Jan — para quien prioriza privacidad y open source. Offline por defecto y con todo el código auditable. Trae su propia interfaz de chat y filosofía "tus datos son tuyos". La elección si la apertura no es negociable.
• Ollama — para programar e integrar. Funciona por línea de comandos y, lo importante, levanta una API local compatible con OpenAI. Eso significa que puedes conectar tu modelo local a cualquier app o script que ya usara la API de OpenAI cambiando solo la URL. Es la pieza para construir cosas. Tenemos una guía dedicada a Ollama.
• llama.cpp — para exprimir el hardware. No es una app con interfaz: es el motor que mueve a las demás. Solo bajas aquí si quieres optimizar al milímetro. Para empezar, ignóralo.

Paso a paso: tu primer modelo en local

Vamos con el camino más rápido a un resultado. Lo planteo con Ollama porque deja la API lista para integrar, pero con LM Studio sería literalmente "buscar → descargar → chatear" desde la interfaz.

1. Instala Ollama. Descárgalo de su web (macOS, Windows y Linux) e instálalo como cualquier programa. En Mac y Windows trae app de escritorio; en Linux va por terminal.

2. Descarga y ejecuta tu primer modelo. Un solo comando baja el modelo cuantizado y lo arranca:

# Arranca un modelo de 8B (lo descarga la primera vez)
ollama run llama3.1:8b

# A partir de ahí, escribes y conversas en el terminal.
# Para salir: /bye

La primera vez tarda lo que pese el archivo (unos GB). Las siguientes, el modelo ya está en disco y arranca al instante.

3. Comprueba qué tienes instalado. Útil cuando acumulas varios modelos:

# Lista los modelos que tienes descargados
ollama list

# Prueba un modelo pequeño y rápido para tareas ligeras
ollama run llama3.2:3b

# Borra uno que ya no uses para liberar disco
ollama rm llama3.1:8b

4. Intégralo en tus apps (opcional). Aquí está la magia para quien programa. Ollama expone una API local en localhost:11434 compatible con el formato de OpenAI:

curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Resume esto en una frase: ..."}]
}'

Cambiando la URL base de tu código de api.openai.com a localhost:11434, cualquier app que usara OpenAI pasa a correr contra tu modelo local. Sin coste, sin enviar nada fuera.

Los límites (para que no te lleves sorpresas)

Ninguna review honesta esconde la letra pequeña, así que aquí va:

• Calidad con techo. Un 7-14B local no razona como GPT o Claude en problemas complejos, código difícil o cadenas largas de lógica. Para eso, la nube sigue ganando.
• Contexto más corto. Las ventanas de contexto gigantes consumen mucha memoria en local. Si necesitas meter documentos enormes de una vez, vas a sufrir.
• El hardware es el límite. No puedes correr un modelo de 70B en un portátil de 8 GB, por mucho que lo cuantices. La memoria manda.
• Velocidad variable. En CPU pura, un 7B escupe unas pocas palabras por segundo. Es usable, pero no esperes la fluidez de un servicio en la nube con GPUs dedicadas.

Ninguno de estos es un defecto: son el precio de tener la IA en tu propia casa. Saberlos de antemano evita la decepción de pedirle a un modelo local algo para lo que no está.

¿Para quién es la IA en local?

Te interesa si: trabajas con datos sensibles que no quieres subir a la nube, haces volumen y el coste por token te duele, necesitas que funcione offline, o simplemente quieres aprender cómo funciona la IA por dentro sin depender de nadie. También si eres desarrollador y quieres prototipar e integrar sin gastar en API cada vez que pruebas algo.

No te interesa si: solo usas IA de forma puntual y la calidad máxima te importa más que la privacidad o el coste, tu equipo va muy justo de memoria, o no quieres dedicar ni diez minutos a instalar nada. Para ese caso, una IA en la nube —o una intermedia como OpenRouter, que te da muchos modelos por una sola API— encaja mejor.

La pregunta honesta no es "¿es la IA local mejor que ChatGPT?". No lo es en el techo, ni lo pretende. La pregunta es "¿cuánto vale para mí que mis datos no salgan de mi equipo, no pagar por cada uso y poder trabajar sin internet?". Si la respuesta es "bastante", en 2026 montarlo te cuesta diez minutos y unos gigas de disco. Nunca fue tan fácil tener tu propia IA, de verdad tuya.