Guía rápida para ejecutar LLMs locales con Ollama Desktop

Hace apenas unos años, levantar un modelo de lenguaje en tu propio ordenador era cosa de laboratorios y equipos con granjas de GPU. Hoy, con un portátil medio decente o una torre con una GPU razonable, puedes tener Llama, Mistral, Gemma o Qwen corriendo en tu máquina, sin enviar ni un solo token a la nube. En esta guía vamos a ver, de forma directa y sin rodeos, cómo montar en minutos un entorno práctico con Ollama Desktop y otras herramientas clave para trabajar con LLMs locales.

La idea es que, al terminar de leer, seas capaz de instalar, configurar y exprimir modelos en local para tareas de chat, programación, análisis de documentos o integración en tus propias apps. Todo con foco en privacidad, costes y control, y usando un lenguaje lo más claro posible, sin entrar en matemáticas raras pero sin ocultar los conceptos importantes.

Por qué ejecutar LLMs locales en tu propio equipo

La pregunta lógica es: si ya existen ChatGPT, Claude y compañía, ¿por qué molestarse en montar LLMs locales? No es solo capricho techie, hay motivos muy serios, sobre todo cuando hablamos de empresas o datos sensibles.

En primer lugar está la privacidad y el cumplimiento normativo. Si trabajas con historiales médicos, contratos, información financiera, código propietario o documentos internos, enviar ese contexto a una API externa puede ser inasumible. En sectores regulados (salud, banca, administración pública) a menudo está directamente prohibido. Con un LLM local, todo el procesamiento se hace dentro de tu perímetro de seguridad.

Otra razón de peso es la latencia y el coste cuando escalas. Mientras estás probando cuatro cosas en un prototipo, la factura por token puede parecer poca cosa; cuando pasas a pipelines de miles de documentos o agentes que no paran de llamar a la API, los costes crecen muy rápido. Una máquina local con GPU amortizada puede procesar millones de tokens sin que suba la factura de la nube.

El tercer pilar es el control total sobre el modelo. Al ejecutar el modelo localmente puedes elegir la cuantización, ajustar parámetros finos de inferencia, cambiar el system prompt a tu gusto, montar RAG con tus propios índices, integrar con herramientas internas sin límites de rate limit, e incluso trabajar sin conexión a Internet. No dependes de que un proveedor cambie políticas, precios o funcionalidades de un día para otro.

Por el lado negativo, es importante tener claro que los modelos que caben en hardware de consumo siguen estando por debajo, en razonamiento complejo, de los grandes modelos frontier de decenas o cientos de miles de millones de parámetros ejecutados en infra dedicada. Para muchas tareas de uso diario van sobradamente bien, pero si buscas el tope absoluto de capacidad en cada benchmark, la nube seguirá siendo referencia.

Qué es un LLM y por qué la arquitectura importa

Antes de entrar de lleno en Ollama Desktop conviene repasar rápido qué es un LLM y cómo funciona por debajo. Un Large Language Model es una red neuronal entrenada con cantidades masivas de texto (y a veces también imágenes, código, audio…) usando aprendizaje automático auto-supervisado. Aprende patrones estadísticos del lenguaje para predecir la siguiente palabra dada una secuencia y su contexto.

La mayoría de LLMs modernos usan la arquitectura Transformer. Esta arquitectura convierte las palabras en vectores numéricos (embeddings), calcula cómo se relacionan entre sí mediante mecanismos de atención y, a partir de ahí, genera la siguiente palabra con una distribución de probabilidades. Con cada paso añade el nuevo token al contexto y repite el proceso, de manera iterativa, hasta completar la respuesta.

Dentro de un Transformer clásico tenemos dos piezas principales: un encoder, que se encarga de “entender” el texto de entrada generando embeddings contextualizados, y un decoder, que a partir de esos embeddings y de la información previa genera la salida palabra a palabra. Muchos LLMs actuales usan variantes solo con decoder, optimizadas específicamente para tareas de generación.

En la práctica, todo esto se traduce en que el modelo asigna probabilidades a cada token posible en cada paso. Mediante parámetros como temperatura, top-p o top-k podemos hacer que la generación sea más creativa o más conservadora. Estos diales están muy presentes tanto en interfaces gráficas como LM Studio o Jan, como en APIs tipo Ollama.

Otro concepto clave es el de embeddings. Cada palabra (o más bien, cada token) se representa como un vector en un espacio de muchas dimensiones. Esa representación es la que permite hacer búsqueda semántica, clustering, RAG y otras técnicas avanzadas de recuperación de información. Muchos stacks locales combinan un LLM generativo con un modelo de embeddings para ofrecer experiencias tipo “chatea con tus documentos”.

Cuantización: cómo encajar modelos grandes en máquinas normales

Cuando llevamos estos modelos al mundo real, la primera barrera suele ser el tamaño. Un modelo en formato de coma flotante de 16 o 32 bits puede resultar totalmente inviable para un PC doméstico. Aquí entra en juego la cuantización: reducir la precisión numérica de los pesos (por ejemplo de 16 bits a 4 u 8 bits) a cambio de una ligera pérdida de calidad.

En términos prácticos, la cuantización afecta directamente a los embeddings y a todas las capas internas del modelo. Al usar representaciones más compactas, el fichero del modelo ocupa menos y, sobre todo, baja el consumo de RAM o VRAM necesario para ejecutarlo. Esto a su vez permite correr modelos con más parámetros en el mismo hardware y acelerar inferencia.

Las familias de cuantización tipo Q4_K_M o Q5_K_M suelen dar un punto óptimo entre tamaño y calidad: la caída de rendimiento en razonamiento es moderada mientras el ahorro de memoria es enorme. En el otro extremo, Q2 y Q3 comprimen mucho más pero tienden a degradar bastante el comportamiento en tareas complejas, y Q8 o fp16 apenas pierden calidad respecto al modelo completo, a costa de requerir muchos más recursos.

Hay benchmarks publicados donde se compara, por ejemplo, un modelo de 7B parámetros en distintas cuantizaciones: se ve cómo la perplexity (una métrica de calidad de predicción: cuanto menor, mejor) empeora un poco al bajar de fp16 a Q4, pero a cambio se reduce brutalmente el tamaño en disco y el tiempo por token, tanto en CPU como en GPU.

La cuantización es crítica en escenarios con recursos limitados: móviles, iot, drones, vehículos autónomos… y también en escritorios con 8 o 16 GB de RAM. Gracias a ella puedes correr Llama, Gemma o Mistral en una máquina que, en bruto, no podría ni cargar el modelo original.

Requisitos de hardware para LLMs locales

Vamos a lo que interesa a la hora de la verdad: qué necesitas para que esto vaya fluido. La teoría está bien, pero si el modelo tarda 20 segundos en escupir una frase, lo usarás dos días y lo olvidarás.

El recurso más crítico suele ser la memoria. Una regla orientativa para modelos populares cuantizados es: con 8 GB de RAM puedes usar modelos pequeños (1B, 3B, 7B) asumiendo que la experiencia será justa; con 16 GB ya te puedes mover cómodo con 7B y 13B; con 32 GB o más puedes aspirar a 30B, 40B e incluso ciertos 70B en configuraciones muy afinadas o con buen apoyo de GPU.

La GPU marca la diferencia en velocidad. Si el modelo cabe entero en VRAM, la GPU arrasa frente a la CPU. Con 12 GB de VRAM (por ejemplo una RTX 4070) puedes correr modelos de hasta 14B en Q4 sin offload y subir hasta la treintena de miles de millones con parte del modelo en RAM, aceptando una caída de rendimiento. Con 24 GB de VRAM (RTX 4090, 4080 Super…) entras en terreno serio para modelos de 34B bien cómodos y opciones algo más arriesgadas con 70B.

En arquitecturas como Apple Silicon, donde la memoria es unificada, modelos de hasta ~30B cuantizados pueden funcionar solo en CPU con rendimientos más que decentes, sin cuellos de botella de transferencia CPU-GPU. En PCs sin GPU dedicada también se puede, pero hay que elegir bien el tamaño del modelo y ser paciente.

No hay que olvidar el almacenamiento: Ollama, LM Studio o Jan como programas ocupan poco, pero los modelos no. Como referencia, un modelo pequeño cuantizado puede rondar los 2 GB, uno mediano 5 GB, un grande 40 GB y los muy grandes irse a 200 GB o más. Tener un SSD rápido ayuda a que el modelo se cargue más ágilmente y a no sufrir al cambiar entre modelos.

Por último, la CPU también cuenta. Para un uso razonable, lo ideal es partir de 4 núcleos físicos y, si quieres varias instancias o tareas concurrentes, 8 o más. Casi cualquier procesador moderno puede con un 7B, pero si pretendes hacer otras cosas en paralelo, agradecerás tener margen.

Ollama Desktop: el estándar de facto para LLMs locales

Dentro del ecosistema actual, Ollama se ha convertido en la opción más popular para desarrolladores y usuarios que quieren algo simple pero potente. Su filosofía recuerda mucho a Docker: haces pull de un modelo, lo ejecutas con run y ya tienes API lista en localhost, prácticamente plug-and-play.

En Linux y macOS la instalación suele pasar por un script oficial tipo curl -fsSL https://ollama.com/install.sh | sh. En Windows hay instaladores .exe descargables desde la web de Ollama. Una vez instalado, se levanta un servicio (daemon) que arranca automáticamente con el sistema, de modo que siempre tienes el servidor listo.

La gran baza de Ollama es que expone una API HTTP en localhost:11434 con un diseño muy parecido al de la API de OpenAI. Eso significa que puedes apuntar cualquier cliente ya existente (librerías de Python, extensiones de VS Code, frontends como Open WebUI o AnythingLLM) a esa URL y, en muchos casos, basta con cambiar el endpoint y la clave para pasar de la nube a local.

En sistemas tipo Linux, Ollama guarda los modelos en una carpeta configurable, por ejemplo /usr/share/ollama/.ollama/models. A través de variables de entorno puedes personalizar esa ruta (OLLAMA_MODELS), definir el host y puerto (OLLAMA_HOST), ajustar tiempos de keep-alive de modelos en memoria (OLLAMA_KEEP_ALIVE) o habilitar logs detallados (OLLAMA_DEBUG). En instalaciones como servicio systemd, estos ajustes se suelen hacer editando el unit file correspondiente.

Además, Ollama mantiene un fichero de historial de conversaciones por usuario (por ejemplo en ~/.ollama/history) y logs de servicio consultables con herramientas propias del sistema (journalctl en Linux). Esto te permite auditar qué se ha hecho, depurar problemas de GPU/CPU (mensajes tipo “no compatible GPUs were discovered”) o detectar errores de permisos al escribir modelos.

Comandos básicos de Ollama para el día a día

Con el servicio corriendo, el corazón de la experiencia Ollama son unos cuantos comandos de terminal muy sencillos. El más habitual es ollama pull, que descarga o actualiza un modelo desde el registro oficial: por ejemplo, ollama pull llama3.2:1b bajará la variante de 1B parámetros.

La nomenclatura de los modelos en el registro incluye varias etiquetas: el tamaño (1b, 3b, 7b, 13b, 32b, 70b…), la cuantización (q2_K, q4_K_M, q8_0, fp16…) y, a veces, variantes como instruct, chat, code, vision o “latest”. Estas últimas indican si el modelo está afinado para seguir instrucciones, conversar, programar o trabajar con imágenes. “Latest” suele ser un equilibrio razonable entre calidad y recursos.

Para hablar con un modelo desde la terminal se usa ollama run, por ejemplo ollama run llama3.2:1b. Si el modelo no está descargado, lo bajará primero. A continuación aparece un prompt interactivo donde puedes escribir tus peticiones y recibir respuestas, manteniendo el contexto dentro de la sesión.

Dentro de ese prompt, Ollama ofrece comandos especiales que empiezan por barra: /? o /help para ver ayuda, /set parameter <nombre> <valor> para cambiar parámetros de generación sobre la marcha, /show para ver detalles del modelo (plantilla, metadatos, licencia), /save <nombre> y /load <nombre> para guardar y cargar sesiones, /clear para limpiar el contexto y /bye o /exit para salir.

Más allá de run, hay comandos de gestión muy útiles: ollama list lista los modelos instalados con tamaño y fecha; ollama show <modelo> muestra su configuración detallada; ollama rm <modelo> lo elimina del disco. Con ollama cp <origen> <destino> creas una copia lógica de un modelo (no duplica los gigas, solo el manifiesto), ideal para personalizar sin ocupar el doble.

Para ver qué modelos están cargados en memoria se usa ollama ps, que indica tamaño, procesador usado (CPU o GPU) y tiempo desde el último acceso. Desde ahí puedes comprobar si la aceleración por GPU está activa (valores 100% GPU en PROCESSOR) o si se está tirando solo de CPU. Si quieres detener un modelo concreto, ollama stop <modelo> hace el trabajo.

Finalmente, ollama push permite subir modelos personalizados al registry oficial, con ventajas como distribución fácil, versionado mediante tags y disponibilidad permanente aunque pierdas tu copia local. Y ollama serve fuerza el arranque del servidor en primer plano si, por ejemplo, no lo tienes configurado como servicio de sistema.

Ollama Desktop en Windows: instalación y configuración básica

En Windows, Ollama se suele usar a través de su instalador gráfico, pero por debajo el funcionamiento es el mismo. Tras descargarlo desde ollama.com e instalarlo, el programa queda corriendo en segundo plano, visible en el área de notificaciones. Desde ese momento ya tienes el servidor activo en el puerto por defecto.

Un detalle importante es el arranque automático. Por defecto, Ollama se inicia cada vez que enciendes el PC. Si no quieres tenerlo siempre cargado, puedes ir al Administrador de tareas, pestaña “Aplicaciones de inicio”, localizar la entrada de Ollama y deshabilitarla. Así solo lo lanzarás cuando realmente lo vayas a usar.

Otro ajuste muy conveniente en Windows es definir la variable de entorno OLLAMA_MODELS para controlar en qué disco se guardan los modelos. Desde “Editar las variables de entorno del sistema” puedes crear una variable de usuario con nombre OLLAMA_MODELS y valor igual a la ruta de la carpeta donde quieras almacenar los ficheros (por ejemplo, en un disco secundario con más espacio).

Una vez aplicada la configuración, basta con abrir una ventana de CMD o PowerShell y escribir “ollama” para ver los comandos disponibles. Desde ahí, el primer paso típico es descargar un modelo ligero, por ejemplo ollama run llama3.2, que además de bajarlo lo ejecutará automáticamente.

Durante la descarga verás el progreso en la propia terminal. Cuando termine, ya puedes escribir preguntas como si se tratara de un chat. Desde ese mismo entorno puedes consultar con “/?” la lista de comandos internos, usar “/show” para ver información del modelo o “/bye” para cerrar la sesión. Para ver qué modelos has descargado, ollama list te mostrará la lista con sus tamaños.

Elección de modelos según el caso de uso

Una vez tienes Ollama Desktop en marcha, llega la gran duda: ¿qué modelo descargo? El catálogo actual es enorme, pero se puede ordenar por casos de uso y recursos disponibles para no volverse loco.

Para chat general y uso tipo asistente, modelos como Llama 3.x, Mistral, Gemma o Qwen en tamaños 7B-9B son una apuesta segura. Son capaces de mantener conversaciones coherentes, explicar conceptos, ayudar con redacciones y responder preguntas generales. Dentro de muchos de ellos hay variantes “instruct” que suelen comportarse mejor siguiendo órdenes concretas.

Si lo que buscas es generación y ayuda con código, conviene tirar de modelos especializados como Code Llama, DeepSeek Coder o WizardCoder, afinados específicamente en repositorios de programación. Esto se nota en que completan funciones, explican errores y siguen mejor patrones idiomáticos de distintos lenguajes.

Para resumen y análisis de texto (clasificación, análisis de sentimientos, extracción de entidades…), muchos modelos generalistas funcionan bien pero, en la práctica, los afinados tipo “instruct” suelen ser más fiables y menos propensos a divagar. En cualquier caso, conviene hacer pruebas con tus propios documentos.

En el terreno multimodal (texto + imagen) tienes modelos como LLaVA, Moondream o variantes vision de las familias grandes. En la web de Ollama puedes filtrar por la etiqueta “Vision” para localizar aquellos que aceptan imágenes como parte del prompt y son capaces de describir, responder preguntas sobre ellas o incluso ayudar a replicar estilos.

La selección final también depende de tu hardware: un modelo de 2B o 3B correrá prácticamente en cualquier equipo, uno de 7B va bien en la mayoría de portátiles modernos, y a partir de 13B es recomendable contar con 16 GB de RAM y, si es posible, GPU. No hay sustituto para las pruebas: descarga dos o tres candidatos y quédate con el que mejor rinda en tu caso concreto.

Más allá de Ollama: LM Studio, Jan y ecosistema local

Aunque Ollama Desktop es una pieza central, el ecosistema de LLMs locales es amplio y tiene herramientas que cubren necesidades distintas. Entre las más relevantes está LM Studio, orientada a quienes prefieren una interfaz gráfica completa tanto para chatear como para ajustar parámetros.

LM Studio se descarga desde su web oficial y está disponible para Windows, macOS y Linux. Al abrirla, te encuentras con un buscador de modelos integrado que tira de Hugging Face, permitiendo filtrar por tamaño, arquitectura, cuantización o tipo de tarea. La descarga y carga de modelos se hace con un par de clics.

Una vez tienes un modelo cargado, la aplicación ofrece controles visuales para temperatura, top-p, top-k, repetition penalty, longitud de contexto y otros parámetros de inferencia, todo manejable con sliders. Es muy útil cuando quieres ver de forma inmediata cómo cambia el comportamiento del modelo con distintos ajustes, sin editar configs a mano.

Al igual que Ollama, LM Studio puede levantar un servidor local compatible con la API de OpenAI. Desde la pestaña “Local Server” activas el servicio y ya puedes apuntar clientes externos a esa instancia. La diferencia práctica es que LM Studio solo sirve el modelo que tengas cargado en ese momento, por lo que para cambiar de modelo hace falta interacción manual en la interfaz.

Versiones recientes de LM Studio han incorporado soporte multi-modelo y para embeddings, algo clave si quieres montar RAG en local: puedes tener un modelo generativo para responder y otro especializado en generar vectores para indexar documentos y hacer búsqueda semántica. Es una forma rápida de prototipar “chats con tus PDFs” en entornos donde no puedes usar OpenAI para embeddings por motivos de privacidad.

Otra herramienta a tener en el radar es Jan, un cliente de chat totalmente open-source (licencia Apache 2.0) que combina una interfaz muy limpia con un sistema de extensiones. Su motor de inferencia, Nitro, basado en llama.cpp, puede ejecutarse como backend independiente, y mediante extensiones puedes conectarlo tanto a motores locales especializados (TensorRT-LLM, OpenVINO para Intel, backends AMD/ROCm) como a APIs remotas, manteniendo la misma UI.

Jan destaca allí donde la auditabilidad y el self-hosting completo son imprescindibles. Si tu organización quiere revisar el código, desplegar la propia interfaz en servidores internos y tener la libertad de modificar el cliente a medida, Jan es una muy buena base. Además, soporta múltiples perfiles y backends, por lo que puedes usar un modelo local en desarrollo y uno cloud en producción sin cambiar de aplicación para el usuario final.

Integración con otras herramientas: ComfyUI, Apidog y compañía

Una virtud de usar Ollama como backend es que se integra muy bien con otras piezas del ecosistema local, tanto para generación de imágenes como para pruebas de APIs y RAG. Un ejemplo claro es su uso conjunto con ComfyUI, el popular entorno nodal para Stable Diffusion.

En flujos avanzados de generación de vídeo o imagen a vídeo, es habitual usar un LLM para expandir prompts, describir imágenes o ajustar descripciones. Some nodos de terceros (como los de Plush-for-ComfyUI) permiten elegir Ollama como fuente del LLM. Basta con tener Ollama corriendo en segundo plano, instalar los nodos adecuados y seleccionar el modelo descargado desde un desplegable dentro del propio flujo.

Así, por ejemplo, puedes tener un primer modelo vision describiendo una imagen (tipo Florence2 o LLaVA) y un segundo modelo, servido por Ollama, que reescribe ese texto para convertirlo en un prompt más rico orientado a vídeo. Todo el proceso se queda en tu máquina y puedes cambiar de modelo con un clic para comparar resultados.

En el plano de las APIs y la depuración, herramientas como Apidog están empezando a ofrecer funciones específicas para LLM locales. Partiendo de la API de Ollama en http://localhost:11434, puedes definir peticiones a /api/generate, /api/chat o /api/embeddings, ajustar parámetros como temperatura o max_tokens y ver la respuesta estructurada de forma amigable.

Al trabajar con modelos de razonamiento más complejos (DeepSeek R1, por ejemplo), es especialmente útil que el cliente de pruebas fusione y muestre de forma clara el contenido transmitido, facilitando seguir el “proceso de pensamiento” del modelo cuando se habilita streaming. Esto hace mucho más llevadero depurar prompts, comprobar cómo influyen distintos parámetros y comparar salidas entre modelos.

Además, al integrar Ollama en aplicaciones mediante código (Python, Node, Go, etc.), puedes usar este tipo de herramientas para probar la API fuera de la app, simular casos límite, validar manejo de errores y medir tiempos de respuesta antes de desplegar en entornos de producción o de pruebas automatizadas.

Consejos prácticos de rendimiento y errores frecuentes

Para que la experiencia con LLMs locales no se convierta en un suplicio, conviene aplicar ciertos patrones de configuración. El primero es ajustar el tamaño de modelo a tu máquina: mejor un 7B bien afinado que un 34B que se arrastra. Compensa más que lo que ganas en capacidad teórica.

Casi siempre sale a cuenta usar modelos cuantizados en Q4_K_M o similares, salvo que tengas una GPU monstruosa y quieras exprimir al máximo la calidad. Verás una diferencia notable en VRAM y RAM consumida, y el salto en rendimiento suele ser de varias veces. También es recomendable limitar el tamaño de contexto a lo que realmente necesitas: pasar de 4K a 128K tokens dispara el consumo de memoria y no siempre aporta valor.

Cuando combines CPU y GPU, ten en cuenta que si el modelo no cabe entero en VRAM habrá que hacer offload a RAM y la ventaja de la GPU se reduce. En algunos escenarios, una CPU moderna con buena memoria unificada puede superar en fluidez a una GPU limitada de 4 GB obligada a hacer malabares.

En cuanto a errores habituales, uno de los grandes clásicos es intentar ejecutar modelos demasiado grandes para la RAM disponible, lo que lleva a bloqueos o mensajes de “out of memory”. Otro es olvidar revisar los permisos de la carpeta de modelos y encontrarse con descargas fallidas sin entender por qué. En Linux, revisar los logs del servicio y los permisos de /usr/share/ollama/.ollama/models suele aclarar rápido la causa.

Finalmente, no hay que confiarse con la privacidad: que el modelo corra en local no significa que esté exento de riesgos. Las inyecciones de prompt siguen existiendo, y si combinas el LLM con datos internos en un sistema más grande, puedes acabar exfiltrando información sensible por culpa de un prompt mal diseñado o de no filtrar bien la entrada.

Con todo lo visto, se puede decir que hoy en día montar un entorno con LLMs locales usando Ollama Desktop, LM Studio o Jan está al alcance de cualquiera con un equipo medio decente y un poco de paciencia en la configuración inicial. La combinación de privacidad, ahorro de costes y control que ofrecen estas herramientas hace que merezca la pena el esfuerzo, sobre todo si trabajas con datos sensibles o quieres experimentar sin mirar el contador de tokens. A partir de instalar Ollama, bajar un modelo tipo llama3.2:8b o mistral y apuntar tus proyectos a localhost:11434, tienes un punto de partida muy sólido para integrar la IA generativa en tu flujo de trabajo sin depender por completo de las grandes plataformas cloud.