Modelos LLM locales en Linux con Ollama — guía e integración con el IDE (2026)

Ejecutar tu propio modelo de lenguaje de forma local ofrece tres cosas que la nube no da: privacidad (el código nunca sale de la máquina), ausencia de costes por token e independencia de los límites del proveedor. El camino más sencillo en Linux es Ollama, una herramienta que descarga, cuantiza y sirve modelos con un solo comando, exponiendo de paso una API compatible con OpenAI. Este artículo recorre todo el proceso: desde la instalación, pasando por la elección del modelo adecuado para tu GPU, hasta el uso del modelo como agente para escribir código. Dedico una sección aparte, bastante extensa, a qué IDE funciona realmente bien con un modelo local, con un repaso concreto de VS Code, PyCharm, Antigravity, Cursor y Zed.

Para anclar la teoría en cifras, en varios puntos utilizo el ejemplo de un portátil de desarrollo moderno: NVIDIA RTX PRO 500 (Blackwell), 6 GB de VRAM, 64 GB de RAM. Es una buena ilustración de una situación habitual: poca VRAM junto con una gran cantidad de RAM del sistema.

Qué es Ollama y cómo funciona

Ollama es un runtime ligero para ejecutar modelos LLM de forma local. Descarga modelos ya cuantizados desde su propio registro, detecta automáticamente la GPU (NVIDIA/AMD) y sirve el modelo mediante un servidor HTTP local en el puerto 11434. Lo más importante: expone un endpoint compatible con la API de OpenAI en http://localhost:11434/v1, gracias a lo cual la mayoría de las herramientas que "hablan OpenAI" pueden apuntarse a un modelo local.

Por debajo, Ollama se apoya en llama.cpp, el formato GGUF y la cuantización: una compresión de los pesos del modelo que reduce drásticamente los requisitos de memoria a cambio de una pequeña pérdida de calidad. Gracias a ella, modelos del orden de 30B caben en tarjetas de consumo.

Instalación en Linux

El instalador oficial detecta la distribución y configura un servicio systemd:

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

Tras la instalación, Ollama funciona como un servicio en segundo plano. Comprueba su estado y versión:

systemctl status ollama
ollama --version

Controladores de GPU

• NVIDIA — necesitas tener instalados los controladores y CUDA. Ollama detectará la tarjeta automáticamente. Verificación: nvidia-smi debería mostrar la tarjeta.
• AMD — Ollama admite ROCm para las tarjetas Radeon compatibles.
• Solo CPU — Ollama funcionará sin GPU, pero lentamente (solo tiene sentido para los modelos más pequeños).

Tras arrancar un modelo, puedes comprobar si realmente está calculando en la GPU:

ollama ps   # the PROCESSOR column shows the GPU-vs-CPU split

Una trampa con las tarjetas más recientes. Las generaciones más nuevas de GPU NVIDIA (Blackwell y posteriores) requieren módulos de kernel abiertos; en Ubuntu es el paquete nvidia-driver-<versión>-open en lugar del clásico nvidia-driver-<versión>. Instalar la variante cerrada hace que la tarjeta directamente no se inicialice: en los registros del kernel aparece RmInitAdapter failed junto con un mensaje de que "requires use of the NVIDIA open kernel modules", y nvidia-smi no reporta ningún dispositivo. La solución es cambiar a la variante -open y reiniciar. En el portátil con RTX PRO 500 (Blackwell) esto era una condición imprescindible para que Ollama calculara en la GPU y no en la CPU.

Comandos básicos

ollama pull qwen2.5-coder:7b     # download a model
ollama run qwen2.5-coder:7b      # download (if needed) and run interactively
ollama list                      # list downloaded models
ollama ps                        # models currently loaded into memory
ollama rm qwen2.5-coder:7b       # remove a model
ollama show qwen2.5-coder:7b     # parameters, template, license

En el modo interactivo son útiles los comandos que empiezan por /, por ejemplo /bye termina la sesión, y /set parameter num_ctx 8192 cambia la longitud del contexto sobre la marcha.

Cuantización y VRAM — la base para elegir el modelo

Antes de elegir un modelo, recuerda la regla que lo decide todo: el modelo debe caber por completo en la VRAM. Un modelo cargado íntegramente en la GPU funciona entre 5 y 10 veces más rápido que uno que se "desborda" hacia la RAM del sistema. Un ejemplo real: un modelo de 32B que va a ~60 t/s en VRAM cae a ~1–2 t/s en el momento en que empieza a usar RAM.

La cuantización es la palanca con la que ajustas el modelo a tu tarjeta:

La opción por defecto en la práctica es Q4_K_M. Recurre a Q5/Q8 solo cuando te sobre VRAM, tanto para los pesos como para el contexto adicional (caché KV). Regla general: un modelo más pequeño que quepa en memoria suele superar a uno más grande que se desborda.

La excepción: modelos MoE y descarga a RAM

Vale la pena matizar la regla de "todo en VRAM" con los modelos MoE (Mixture of Experts), que tienen un gran número de parámetros pero solo activan una fracción de ellos por token. Por ejemplo, qwen3-coder:30b tiene 30 000 millones de parámetros, de los cuales solo ~3 000 millones están activos. Estos modelos toleran mucho mejor la descarga a RAM que los modelos densos, porque por el bus de memoria, en cada token, solo pasa una pequeña porción activa de los pesos.

Esto abre una puerta en máquinas con poca VRAM pero mucha RAM. En el portátil mencionado (6 GB de VRAM + 64 GB de RAM):

• qwen2.5-coder:7b (~4,7 GB en Q4) cabe por completo en 6 GB de VRAM: funciona rápido, totalmente en la GPU.
• qwen3-coder:30b (~19 GB) no cabe en 6 GB, pero gracias a los 64 GB de RAM se puede ejecutar con descarga, y la arquitectura MoE (3B activos) hace que la velocidad se mantenga aceptable.

Conclusión: a la hora de comprar o evaluar hardware, una gran cantidad de RAM del sistema es un complemento sensato para una VRAM modesta, ya que permite acceder a modelos MoE cuyo equivalente denso sería inmanejable.

Elegir el modelo según la clase de hardware

En lugar de un único modelo "mejor", ajústalo a la cantidad de VRAM disponible. Los siguientes umbrales son puntos de partida prácticos para trabajar con código.

Clase "pequeña" (≤ 8 GB de VRAM, incluidos portátiles)

Objetivo: probar todo el flujo de trabajo y tareas ligeras del día a día.

• 6–8 GB de VRAM — qwen2.5-coder:7b (~4,7 GB en Q4). El mejor modelo pequeño de código en este presupuesto; supera a los antiguos CodeLlama y DeepSeek-Coder en autocompletado de código.
• Solo CPU / poca RAM — qwen2.5-coder:1.5b o :3b. Será lento, pero permite probar las integraciones.

ollama run qwen2.5-coder:7b

En esta etapa conviene verificar: si el modelo responde con sentido, si funciona en la GPU (ollama ps), cuál es la velocidad de generación y si se puede conectar al editor.

Clase "media" (12–16 GB de VRAM)

Un rango cómodo para trabajo real con código:

• qwen2.5-coder:14b (~10 GB en Q4) — sólido para el trabajo diario.
• devstral:24b — modelo agéntico local de Mistral, requiere ≥16 GB de VRAM, bueno para tareas de agente.
• deepseek-coder-v2:16b (lite) — variante económica para tarjetas de ~12 GB.

ollama run qwen2.5-coder:14b

Clase "grande" (24 GB+ de VRAM)

El nivel en el que un modelo local empieza a sustituir de verdad a la nube para la escritura de código de forma agéntica. El líder es qwen3-coder:30b:

• arquitectura MoE 30B-A3B (de 30 000 millones de parámetros, solo ~3 000 millones están activos por token),
• ~16,5–18 GB en Q4_K_M: cabe en una tarjeta de 24 GB con margen para el contexto,
• contexto nativo de 256K (ampliable), entrenado para tareas agénticas y con llamada nativa a herramientas (tool calling), algo clave para funcionar como agente.

ollama run qwen3-coder:30b

Variantes según la tarjeta:

• 24 GB (RTX 3090/4090) — qwen3-coder:30b en Q4_K_M, ~22–24 t/s, ~6 GB de margen para la caché KV.
• 32 GB (RTX 5090) — el mismo modelo en Q4, o en el Q5_K_M de mayor calidad (~22 GB), con espacio para un contexto largo.
• 48 GB+ (2× RTX 3090, A6000) — qwen3-coder:30b en Q8, o modelos más pesados; el qwen3-coder:480b completo requiere, en la práctica, hardware de servidor o una versión alojada.

Mapa: VRAM → modelo de código recomendado

Nota sobre los nombres. En Ollama, la familia qwen3-coder existe únicamente como MoE de 30B y 480B; no hay variante de 7B. Para un modelo pequeño y rápido hay que usar la familia qwen2.5-coder (disponible en 0,5B / 1,5B / 3B / 7B / 14B / 32B). Esta confusión es una fuente frecuente del error pull model manifest: file does not exist.

Panorama de modelos de código (2026)

• qwen3-coder (30b / 480b) — el líder actual en programación local. La versión 30B-A3B es el modelo agéntico más potente que la mayoría de la gente puede ejecutar localmente. Tool calling, contexto de 256K.
• qwen2.5-coder (0,5b–32b) — la mejor familia de modelos pequeños y medianos para código. La variante :32b está cerca del nivel de GPT-4o en el benchmark de Aider. La opción cuando qwen3-coder:30b queda fuera del alcance del hardware.
• devstral:24b — modelo agéntico local de Mistral, con 128K de contexto.
• deepseek-r1 / deepseek-coder-v2 — buenos para razonar sobre errores difíciles, con una variante económica (16b lite) para tarjetas de 12 GB.

Ajuste y configuración de Ollama

El comportamiento del servidor se controla con variables de entorno (para el servicio systemd, se configuran en un archivo de override):

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"   # Listen on the network too (be careful!).
Environment="OLLAMA_ORIGINS=*"            # Allow CORS requests (needed by some plugins).
Environment="OLLAMA_KEEP_ALIVE=30m"       # How long a model stays in memory.
Environment="OLLAMA_NUM_PARALLEL=2"       # Number of parallel requests.
Environment="OLLAMA_FLASH_ATTENTION=1"    # Save KV-cache memory.
Environment="OLLAMA_MODELS=/data/ollama"  # Where downloaded models are stored.

Tras el cambio: sudo systemctl daemon-reload && sudo systemctl restart ollama.

El parámetro más importante para trabajar con código es la longitud del contexto (num_ctx). Por defecto suele ser baja, y un agente necesita una ventana grande; un contexto demasiado pequeño provoca que se corte el prompt del sistema y que el agente entre en "bucles". Puedes configurarla por sesión (/set parameter num_ctx 32768) o de forma permanente en tu propio Modelfile:

FROM qwen3-coder:30b
PARAMETER num_ctx 32768

ollama create qwen3-coder-32k -f ./Modelfile

También puedes sobrescribir un modelo existente con el mismo nombre (FROM qwen3-coder:30b + ollama create qwen3-coder:30b -f ./Modelfile); Ollama reutilizará las capas de pesos compartidas, así que no se vuelve a descargar nada.

Este cambio es permanente. El parámetro num_ctx queda grabado en la definición del modelo dentro del almacén de Ollama (~/.ollama/models), no en el archivo Modelfile, que solo hace falta en el momento de ollama create y se puede borrar después. El ajuste sobrevive a un reinicio del servicio o del sistema. Puedes consultarlo en cualquier momento con ollama show <model> --modelfile (verás una línea PARAMETER num_ctx ...).

Nota: un num_ctx más grande consume VRAM para la caché KV. En tarjetas con poca VRAM (p. ej. 6 GB), un compromiso razonable es 16384; con una ventana mayor, el modelo empezará a desbordarse hacia la RAM.

Qué IDE funciona bien con un modelo local

El nivel de soporte varía muchísimo entre editores. Primero un veredicto rápido, luego los detalles.

VS Code — el mejor soporte

VS Code tiene el ecosistema de extensiones más rico que se conectan a Ollama directamente, sin túneles ni enrutamiento a través de la nube:

• Continue — extensión agnóstica respecto al modelo, para chat, edición y autocompletado. Admite de forma nativa el proveedor ollama. La entrada más sencilla.
• Cline y Roo Code — extensiones orientadas a un flujo de trabajo agéntico (planificación, ejecución de cambios en archivos, uso de herramientas). Aprovechan mejor un modelo con tool calling, como qwen3-coder:30b. No olvides poner num_ctx ≥ 32k, o el prompt del sistema del agente se cortará.

Configuración de Continue (archivo ~/.continue/config.json; las versiones más nuevas usan config.yaml, y ambas funcionan):

{
  "models": [
    {
      "title": "Qwen2.5 Coder 7B",
      "provider": "ollama",
      "model": "qwen2.5-coder:7b",
      "apiBase": "http://localhost:11434"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Qwen2.5 Coder 1.5B",
    "provider": "ollama",
    "model": "qwen2.5-coder:1.5b",
    "apiBase": "http://localhost:11434"
  }
}

Se recomienda indicar siempre el apiBase de forma explícita; sin él, a veces se producen errores de conexión silenciosos. Una vez indicado el modelo, tienes chat, edición en línea (Ctrl+I) y autocompletado a partir del modelo local, totalmente sin conexión una vez descargado el modelo.

PyCharm / JetBrains — muy buen soporte

En el ecosistema de JetBrains hay tres vías sensatas:

• AI Assistant integrado — el asistente oficial de JetBrains admite modelos locales a través de Ollama. Al formar parte del IDE, siempre es compatible con la build actual. Configuración: Settings → Tools → AI Assistant → Providers & API keys → proveedor Ollama, URL http://localhost:11434 → Test Connection, y luego asignar el modelo en la sección Model Assignment. Limitación: con modelos locales, el AI Assistant no invoca herramientas (MCP), por lo que no sirve como un agente completo que edite archivos.
• ProxyAI (antes CodeGPT) — un plugin de código abierto con soporte para modelos locales (Ollama, LM Studio, llama.cpp) y un modo agéntico.
• Continue — tiene un plugin para JetBrains, y su configuración ~/.continue/config.json se comparte con VS Code.

Un matiz sobre la compatibilidad de los plugins con los IDE más recientes. El Marketplace oculta los plugins marcados como incompatibles con la build actual. En lanzamientos muy recientes (por ejemplo, PyCharm 2026.2, línea de build 262.*), el plugin Continue puede directamente no aparecer en la búsqueda del Marketplace hasta que sus autores amplíen el rango de compatibilidad. En ese caso, recurre al AI Assistant integrado o a ProxyAI (que suelen ponerse al día más rápido), usa la versión del canal EAP, instala el plugin "desde disco" tras ampliar el atributo until-build, o utiliza el equivalente en VS Code.

Modo agéntico en la terminal — Aider

Independientemente del editor, para tareas del tipo "hazme toda la tarea", la herramienta más fiable con modelos locales es Aider: un agente que funciona en la terminal (también dentro de la pestaña Terminal del propio IDE). A diferencia de los asistentes integrados en el editor, Aider encuentra y edita por sí mismo los archivos del repositorio git, y guarda cada cambio como un commit independiente (fácil de deshacer con /undo).

python -m pip install aider-install && aider-install

cd /path/to/your/git/repo
export OLLAMA_API_BASE=http://127.0.0.1:11434
aider --model ollama_chat/qwen2.5-coder:7b   # note the ollama_chat/ prefix, not ollama/

Los comandos más importantes dentro de una sesión:

Para modelos locales conviene construir de antemano una variante con un contexto mayor (ver la sección sobre num_ctx), por ejemplo qwen2.5-coder:7b-16k, e indicársela a Aider.

Antigravity — sin soporte nativo de modelos locales

Antigravity (el IDE de Google) utiliza una lista cerrada y curada de modelos servidos a través de Vertex Model Garden, entre ellos Gemini 3.x, Claude (Opus/Sonnet) y GPT-OSS-120B. En la práctica:

• no hay botón "Add Custom Model" ni BYOK (Bring Your Own Key),
• no hay configuración de un endpoint compatible con OpenAI ni forma de apuntar a localhost:11434,
• los modelos de la lista no se pueden añadir, quitar ni sustituir por otros propios.

En otras palabras: no puedes conectar una Ollama local a Antigravity de forma nativa. Las guías que circulan por internet describiendo cómo configurar Ollama mediante un "proveedor compatible con OpenAI" en Antigravity están, en su mayoría, desactualizadas o son incorrectas. Las soluciones alternativas vía MCP o proxy son extraoficiales y poco fiables.

Cursor — posible, pero con concesiones

Cursor no admite directamente modelos en localhost: enruta las peticiones a través de sus propios servidores, así que hay que exponer Ollama mediante un túnel HTTPS público (ngrok/Cloudflare Tunnel) e introducir la URL en Settings > Models > Override OpenAI Base URL (con el sufijo /v1 y cualquier clave de API no vacía). Además, Tab siempre funciona en la nube, y el modo Agent a veces tiene fallos. Se puede configurar así para el chat y Cmd+K, pero como agente local completo, Cursor no funciona bien.

Zed — una alternativa que vale la pena conocer

Zed es un editor nativo y rápido con soporte integrado para Ollama (un proveedor local en los ajustes). Ligero y eficiente, es una buena opción para trabajar con un modelo local sin instalar plugins.

Ruta recomendada, paso a paso

1. Instalación y prueba — instala Ollama, asegúrate de que la GPU es visible (nvidia-smi, ollama ps), ejecuta qwen2.5-coder:7b y pruébalo en la terminal, y después en VS Code + Continue o en PyCharm (AI Assistant/ProxyAI).
2. Trabajo con código — en tarjetas de 12–16 GB, pasa a qwen2.5-coder:14b o devstral:24b; activa el modo agéntico (Cline/Roo Code en VS Code, o Aider en la terminal).
3. Agente local definitivo — en tarjetas de 24 GB+, configura qwen3-coder:30b en Q4_K_M con un contexto ampliado; es el agente local de código más potente con tool calling. En máquinas con poca VRAM pero mucha RAM, puedes ejecutar el mismo modelo con descarga (los MoE lo toleran bien).
4. Elección de editor — para un agente local, apuesta por VS Code (el soporte más amplio) o PyCharm. Deja Antigravity para sus modelos en la nube, y considera Cursor solo si aceptas el túnel y sus limitaciones.

Resumen

Ollama en Linux es el camino más sencillo hacia los modelos locales: un comando instala el runtime, otro descarga y ejecuta el modelo, y una API compatible con OpenAI abre las integraciones. Empieza con qwen2.5-coder:7b para probar, pasa por :14b/devstral en una tarjeta de 16 GB, y en una de 24 GB+ configura qwen3-coder:30b como tu agente local definitivo: hoy es el modelo de código más potente que se puede ejecutar en hardware de consumo, con tool calling y un contexto de 256K. La regla de hardware: el modelo debe caber por completo en la VRAM (Q4_K_M como equilibrio por defecto), con los modelos MoE como excepción, ya que toleran sorprendentemente bien la descarga en máquinas con mucha RAM. En cuanto al editor: VS Code y PyCharm se conectan a Ollama de forma nativa (Continue/AI Assistant/ProxyAI, y para un agente, Cline/Roo Code o Aider). Antigravity no admite modelos locales (lista cerrada en la nube), y Cursor requiere túneles y tiene limitaciones.

Referencias

• Ollama — sitio oficial
• Ollama — biblioteca de modelos
• Ollama — repositorio en GitHub
• Best Ollama Models: Coding, RAG & Agents — junio de 2026 (Morph)
• Ollama Models Cheat Sheet 2026 (ComputingForGeeks)
• Best Ollama Coding Models by NVIDIA RTX GPU: VRAM Tier Guide (haimaker.ai)
• QwenLM/Qwen3-Coder — repositorio
• Run Qwen3-Coder 30B-A3B Locally — umbrales de VRAM (RunAIatHome)
• NVIDIA — Open GPU Kernel Modules (GitHub)
• Continue — documentación
• Continue — plugin de JetBrains (Marketplace)
• ProxyAI — plugin de JetBrains (Marketplace)
• Aider — sitio del proyecto
• Local AI Coding Assistant: VS Code + Ollama + Continue (SitePoint)
• Using Ollama with VS Code, IntelliJ, and Eclipse (Medium)
• Can You Use Local Models (Ollama) with Antigravity? (Agentpedia)
• Cursor Forum — How can I use a local LLM on my desktop/AI computer?
• Zed — documentación (AI / Ollama)