Ejecutar LLMs Locales en 2026: Guía Completa de Ollama, LM Studio y Jan

Hace tres años, correr un modelo de lenguaje en tu propia máquina era territorio de investigadores con acceso a clústeres de GPUs. Hoy, con un portátil decente o una workstation razonable, puedes tener Llama 4, Mistral, Gemma o Qwen corriendo completamente offline, sin mandar ni un token a ningún servidor externo. Esta guía cubre las tres herramientas que dominan ese ecosistema en 2026: Ollama, LM Studio y Jan, con ejemplos concretos y criterios claros para elegir entre ellas.

Por qué vale la pena ejecutar LLMs locales

¿Para qué molestarse, si las APIs cloud son baratas y cada vez más potentes? Es la pregunta razonable, y la respuesta depende mucho de tu situación concreta.

Privacidad y compliance. Si trabajas con datos sensibles —historiales médicos, contratos legales, código propietario— enviar contexto a una API externa introduce riesgo. Muchas empresas en sectores regulados directamente no pueden usar APIs cloud para ciertos flujos. Con LLMs locales, el dato no sale del perímetro.

Latencia y coste a escala. Para prototipado intensivo o pipelines de procesamiento por lotes, el coste de tokens se acumula rápido. Una GPU local amortizada procesa millones de tokens sin factura por token.

Control total sobre el modelo. Puedes fine-tunear, cuantizar agresivamente, modificar el system prompt a nivel de servidor, integrar con herramientas internas sin limitaciones de rate limit, o simplemente trabajar sin internet.

Lo que sí pierdes: los modelos locales que caben en hardware consumer, aunque mejoran año a año, siguen siendo inferiores en razonamiento complejo a los modelos frontier de 70B+ parámetros corriendo en infraestructura dedicada. Elige en consecuencia.

Ollama: la CLI que convirtió los LLMs locales en algo usable

Ollama es la opción más popular entre desarrolladores porque su filosofía es simple: hace que ejecutar LLMs locales se parezca lo máximo posible a usar Docker. Pull, run, API compatible con OpenAI. Sin más ceremonias.

Es también la herramienta que más uso en el día a día. El tiempo desde “quiero probar este modelo” hasta tenerlo respondiendo en un script suele ser menos de cinco minutos.

Instalación

En Linux y macOS:

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

En Windows, hay instalador .exe desde la web oficial. Una vez instalado, el daemon arranca automáticamente como servicio del sistema.

Primeros pasos

# Descargar y correr Llama 3.3 de 8B (requiere ~5GB)
ollama run llama3.3:8b

# O Mistral Nemo, que es más ligero
ollama run mistral-nemo

# Ver modelos disponibles localmente
ollama list

# Borrar un modelo
ollama rm llama3.3:8b

Ollama expone automáticamente una API REST en localhost:11434 con compatibilidad casi total con la API de OpenAI. Eso significa que puedes apuntar cualquier cliente que ya tengas hacia esa URL:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",  # valor ignorado, pero requerido por el cliente
)

response = client.chat.completions.create(
    model="llama3.3:8b",
    messages=[
        {"role": "system", "content": "Eres un asistente técnico experto en Python."},
        {"role": "user", "content": "Explica el GIL de Python en dos párrafos."}
    ]
)

print(response.choices[0].message.content)

Si ya tienes código usando el SDK de OpenAI, migrar a un modelo local es cambiar base_url y api_key. Dos líneas, nada más.

Modelfiles: personalización sin fricción

Una funcionalidad infrautilizada de Ollama son los Modelfile, que permiten crear variantes de modelos con configuración propia:

# Modelfile
FROM llama3.3:8b

PARAMETER temperature 0.2
PARAMETER num_ctx 8192

SYSTEM """
Eres un revisor de código senior especializado en Python y seguridad.
Responde siempre en español. Señala problemas de seguridad antes que
problemas de estilo. No añadas ejemplos si no te los piden.
"""

ollama create code-reviewer -f ./Modelfile
ollama run code-reviewer

Para equipos, esto resuelve el clásico problema de “en mi máquina el modelo responde diferente”: committeas el Modelfile junto al código y todos trabajan con exactamente la misma configuración.

Rendimiento realista en hardware consumer

En una máquina con NVIDIA RTX 4070 (12GB VRAM), puedes esperar:

Con Apple Silicon (M3 Pro, 36GB RAM unificada), los números son similares gracias a Metal y la memoria compartida CPU/GPU.

LM Studio: cuando necesitas interfaz gráfica y flexibilidad

LM Studio cubre un caso de uso distinto: es la opción para quienes quieren explorar modelos sin tocar la terminal, y también para quienes necesitan ajustar parámetros de inferencia con feedback visual inmediato.

Instalación y primer uso

Descarga desde lmstudio.ai (disponible para macOS, Windows y Linux). La interfaz permite buscar y descargar modelos directamente desde Hugging Face con filtros por tamaño, arquitectura y cuantización.

Honestamente, la UI me pareció más útil de lo que esperaba. Los sliders para temperatura, top-p, top-k, repetition penalty y longitud de contexto dan feedback inmediato —ideal cuando estás calibrando el comportamiento del modelo para un caso de uso concreto y no quieres editar configs a mano en cada iteración.

Servidor local compatible con OpenAI

Al igual que Ollama, LM Studio incluye un servidor local que expone la API de OpenAI. Lo activas desde la pestaña “Local Server”:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:1234/v1",
    api_key="lm-studio",
)

# Listar modelos cargados actualmente
models = client.models.list()
for model in models.data:
    print(model.id)

Una diferencia práctica respecto a Ollama: LM Studio solo sirve el modelo que tienes cargado en ese momento. No puedes cambiar de modelo por API sin interacción manual en la interfaz. Para pipelines automatizados, eso es una limitación real.

Multi-model y uso con embeddings

LM Studio 0.3.x introdujo soporte para cargar múltiples modelos simultáneamente, incluyendo modelos de embeddings. Esto permite montar un stack RAG completo localmente:

# Generar embeddings con un modelo local
embed_client = OpenAI(base_url="http://localhost:1234/v1", api_key="lm-studio")

embedding = embed_client.embeddings.create(
    model="nomic-embed-text",
    input="¿Cómo funciona la atención en los transformers?"
)

vector = embedding.data[0].embedding
print(f"Dimensión del embedding: {len(vector)}")

Para prototipar sistemas de búsqueda semántica con datos sensibles —donde no puedes usar la API de OpenAI para embeddings— este stack funciona bien y no requiere nada externo.

Jan: el cliente open-source y self-hosteable

Jan es la opción menos conocida de las tres, pero merece atención por su arquitectura: es completamente open-source (Apache 2.0), tiene una extensión marketplace, y su motor de inferencia —Nitro, basado en llama.cpp— puede desplegarse también como backend independiente.

Instalación

Descarga desde jan.ai. La interfaz es más minimalista que LM Studio pero cubre lo esencial: gestión de modelos, conversaciones, y servidor local.

# Jan también expone una API REST
curl http://localhost:1337/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistral-ins-7b-q4",
    "messages": [
      {"role": "user", "content": "Escribe un test unitario en Python para una función que valida emails"}
    ]
  }'

Extensiones y personalización

El sistema de extensiones de Jan permite integrar motores de inferencia alternativos (TensorRT-LLM, OpenVINO para Intel) o conectar con APIs remotas manteniendo la misma interfaz. Para equipos que necesitan una UI unificada que apunte a distintos backends según el entorno (local en dev, cloud en prod), Jan ofrece esa flexibilidad.

Cuándo elegir Jan sobre las otras opciones

Jan tiene sentido cuando:
– Necesitas un cliente auditable al 100% (el código está en GitHub, sin componentes propietarios)
– Quieres integrar motores de inferencia especializados para hardware específico (Intel Arc, AMD ROCm)
– Tu organización necesita self-hostear también la interfaz, no solo el backend

En mi experiencia, es la opción que aparece menos en tutoriales pero que más sentido tiene en contextos enterprise con requisitos de auditoría estrictos. El hecho de que sea Apache 2.0 sin componentes propietarios simplifica bastante la conversación con el equipo legal.

Comparativa práctica: ¿cuál usar en cada situación?

No hay una respuesta única. La elección depende de cómo vayas a consumir los LLMs locales en tu flujo de trabajo.

Para desarrollo y automatización

Ollama es la opción por defecto. Su API es estable, el cambio de modelos es instantáneo por CLI, y la compatibilidad con OpenAI SDK significa que prácticamente cualquier librería de Python funciona sin modificaciones. Si estás construyendo un agente, un pipeline de procesamiento de documentos o integrando un LLM en una aplicación existente, empieza por aquí.

# Ejemplo: pipeline de resumen con Ollama y Python puro
echo "$(cat documento.txt)" | ollama run llama3.3:8b \
  "Resume este texto en tres puntos clave, en español:"

Para exploración y prototipado visual

LM Studio gana cuando quieres ajustar parámetros con feedback inmediato, comparar el output de distintas cuantizaciones del mismo modelo, o cuando trabajas con personas no técnicas que necesitan interactuar con el modelo directamente.

Para entornos con requisitos de auditoría

Jan es la opción cuando la naturaleza open-source del software es un requisito, no una preferencia. También es una buena base si planeas contribuir o modificar el cliente para adaptarlo a necesidades específicas del equipo.

Tabla resumen

Configuración de hardware: lo que realmente importa

Ejecutar LLMs locales de forma fluida requiere tomar decisiones de hardware concretas. Y hay un par de trampas que no son obvias hasta que te las encuentras.

GPU vs CPU

La regla básica: si el modelo cabe entero en VRAM, la GPU gana siempre. Si tienes que hacer offload a RAM, la ventaja se reduce dependiendo del ancho de banda de memoria del sistema.

En la práctica:
– Solo CPU (Apple Silicon): Modelos hasta ~30B en Q4 son usables (>10 tok/s). La memoria unificada elimina el cuello de botella de la transferencia CPU-GPU.
– NVIDIA con 12GB VRAM: Modelos hasta ~14B en Q4 sin offload. Hasta ~34B con offload parcial (rendimiento variable).
– NVIDIA con 24GB VRAM: El punto dulce para uso serio. Modelos de 34B caben cómodos; 70B requiere offload.

Cuantización: no todas son iguales

Las cuantizaciones Q4_K_M y Q5_K_M ofrecen el mejor equilibrio calidad/tamaño para la mayoría de modelos. Q2 y Q3 pierden calidad notablemente en razonamiento; Q8 casi no pierde calidad respecto a FP16 pero ocupa el doble que Q4.

# Ollama descarga la cuantización por defecto (generalmente Q4_K_M)
ollama pull llama3.3:8b

# Para especificar cuantización explícita
ollama pull llama3.3:8b-instruct-q8_0

Contexto: el factor olvidado

El tamaño de contexto tiene un impacto enorme en memoria. Un modelo de 8B con contexto de 128K puede necesitar casi tanta VRAM como uno de 14B con contexto de 4K.

Trampa habitual: asumir que el modelo de 8B siempre cabe en 8GB de VRAM. Algunos modelos vienen configurados con ventanas de contexto largas por defecto (32K o más), y puedes quedarte sin memoria en el primer arranque sin entender por qué. Si tu caso de uso no requiere ventanas largas, limita el contexto explícitamente:

# En Ollama, vía Modelfile
PARAMETER num_ctx 4096

Conclusión

Ejecutar LLMs locales en 2026 es técnicamente accesible, pero la elección de herramienta y hardware sigue importando. Ollama es el punto de entrada natural para desarrolladores: bajo overhead, API limpia, integración directa con el ecosistema Python. LM Studio cubre el espacio de exploración visual y calibración. Jan es la opción cuando el control total sobre el software es un requisito no negociable.

El ecosistema mejora rápido: los modelos son más capaces por parámetro que hace doce meses, las herramientas de cuantización producen menos degradación de calidad, y el soporte de hardware —especialmente AMD e Intel— ya no es ciudadano de segunda.

Si quieres empezar hoy: instala Ollama, descarga llama3.3:8b o mistral-nemo, y apunta tu stack existente a localhost:11434. En menos de veinte minutos tienes un LLM local funcionando. A partir de ahí, los Modelfiles y la API te dan todo el control que necesitas para integrar el modelo en cualquier flujo de trabajo real.