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
La pregunta legítima es: ¿para qué molestarse, si las APIs de los proveedores cloud son baratas y potentes?
Hay tres razones que, dependiendo de tu proyecto, pueden ser determinantes:
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.
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
Lo interesante es que 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)
Este patrón es especialmente útil para migrar proyectos existentes a LLMs locales con cambios mínimos.
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
Esto es especialmente útil para equipos que quieren estandarizar el comportamiento del modelo en distintas máquinas.
Rendimiento realista en hardware consumer
En una máquina con NVIDIA RTX 4070 (12GB VRAM), puedes esperar:
| Modelo | Cuantización | Tokens/s (aprox.) |
|---|---|---|
| Llama 3.3 8B | Q4_K_M | 60–80 |
| Mistral Nemo 12B | Q4_K_M | 35–50 |
| Qwen2.5 32B | Q4_K_M | 15–20 |
| Llama 3.3 70B | Q4_K_M | 4–8 (offload parcial) |
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.
Una vez cargado un modelo, tienes acceso a controles como temperatura, top-p, top-k, repetition penalty y longitud de contexto mediante sliders. Esto es útil cuando estás calibrando el comportamiento del modelo para un caso de uso concreto y quieres iterar rápido sin editar configs a mano.
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)}")
Este flujo es especialmente útil para prototipar sistemas de búsqueda semántica con datos sensibles donde no puedes usar la API de OpenAI para embeddings.
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
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
| Criterio | Ollama | LM Studio | Jan |
|---|---|---|---|
| Instalación | CLI/script | GUI installer | GUI installer |
| API compatible OpenAI | Sí | Sí | Sí |
| Cambio de modelo por API | Sí | No | Parcial |
| Interfaz gráfica | No | Sí | Sí |
| Open-source completo | Sí | No | Sí |
| Multi-modelo simultáneo | Sí | Sí (v0.3+) | No |
| Soporte embeddings | Sí | Sí | Limitado |
| Mejor para | Dev/CI | Exploración | Auditoría |
Configuración de hardware: lo que realmente importa
La teoría es bonita, pero ejecutar LLMs locales de forma fluida requiere tomar decisiones de hardware concretas.
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. Si tu caso de uso no requiere ventanas de contexto largas, limítalo:
# En Ollama, vía Modelfile
PARAMETER num_ctx 4096
Conclusión
Ejecutar LLMs locales en 2026 es técnicamente accesible, pero elegir bien la herramienta y el hardware sigue siendo determinante. 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 y 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.
Top comments (0)