Desarrollo e IA Guía
Modelos locales para programar: Qwen, Devstral y gpt-oss con Ollama
Programar con IA sin enviar el código a la nube es posible con un portátil potente o una estación de trabajo. Qué modelos abiertos merecen la pena, cuánta memoria necesitan y cómo conectarlos a tu editor o agente con Ollama y LM Studio.
Hay tres motivos habituales para querer un modelo de IA local para programar: confidencialidad (código de clientes que no puede salir de la empresa), coste (sin tarifas por token) y disponibilidad (funciona sin conexión y sin límites de uso). A cambio, se renuncia a parte de la calidad de los modelos de frontera y hay que dedicar hardware. En 2026 esa renuncia es menor que nunca: varios modelos abiertos están pensados específicamente para trabajar como agentes de programación y caben en un ordenador de gama alta.
Esta guía repasa qué modelos usar, qué necesitan y cómo conectarlos a tus herramientas mediante Ollama y LM Studio, los dos servidores locales más extendidos.
¿Qué modelos abiertos son mejores para programar?
Estos son los que recomendamos probar primero, con los datos que publica la biblioteca de Ollama:
Qwen3-Coder (30B)
El modelo de programación de Alibaba en versión «asequible»: 30.000 millones de parámetros, de los que solo se activan unos 3.300 millones por token gracias a su arquitectura de mezcla de expertos (MoE). Ocupa 19 GB, tiene una ventana de contexto nativa de 256.000 tokens y está pensado para tareas agénticas y para entender repositorios grandes. Su hermano mayor de 480B necesita al menos 250 GB de memoria, así que en la práctica solo es viable en servidores o en la nube.
Qwen3-Coder-Next
Basado en Qwen3-Next, tiene 80.000 millones de parámetros con 3.000 millones activos y 256.000 tokens de contexto. La versión cuantizada a 4 bits ocupa 52 GB, por lo que encaja en equipos con mucha memoria unificada. Funciona solo en modo sin razonamiento explícito, lo que lo hace más rápido para el bucle de editar y probar.
Devstral Small 2 (24B)
El modelo de Mistral para agentes de programación: 24.000 millones de parámetros, 15 GB de descarga, ventana de 384.000 tokens, entrada de imagen y licencia Apache 2.0. Según la ficha del modelo, Mistral le atribuye un 65,8% en SWE-bench Verified, frente al 72,2% de Devstral 2 (123B). Son cifras del fabricante y conviene leerlas con cautela, pero es de los modelos que mejor rinden por gigabyte.
gpt-oss (20B y 120B)
Los modelos de pesos abiertos de OpenAI, con licencia Apache 2.0 y contexto de 128.000 tokens. La versión de 20B ocupa 14 GB y puede funcionar en sistemas con 16 GB de memoria; la de 120B ocupa 65 GB y cabe en una sola GPU de 80 GB. Es buena opción generalista si además del código quieres un asistente para documentación o análisis.
Qwen3.6 (27B y 35B)
No es un modelo exclusivo de código, pero admite herramientas, razonamiento e imágenes, y la versión 35B-A3B (MoE) es la que usa uno de los ingenieros de Zed en su día a día, según contaba el propio equipo del editor. Ocupa entre 18 y 24 GB según la variante.
¿Y DeepSeek? Sus modelos más recientes en la biblioteca de Ollama (V4 Pro y V4.1 Flash) aparecen solo como modelos en la nube, sin descarga local. Las versiones descargables específicas de código, como deepseek-coder-v2, pertenecen a generaciones anteriores y son anteriores a las opciones citadas.
Lee también: Hermes Agent estrena la versión 0.22 tras levantar 90 millones
¿Cuánta memoria necesito?
Como regla práctica, necesitas la memoria de la descarga más margen para el contexto, que en agentes de programación es grande. Orientativamente:
- 16 GB: gpt-oss 20B con contexto moderado. Suficiente para autocompletado y preguntas puntuales.
- 24-32 GB: Devstral Small 2, Qwen3-Coder 30B o Qwen3.6. Ya permite trabajo agéntico real.
- 64 GB o más (memoria unificada en Mac o estación con varias GPU): Qwen3-Coder-Next o gpt-oss 120B.
Los modelos MoE, que activan pocos parámetros por token, funcionan especialmente bien en chips con memoria unificada como los Apple M o AMD Strix Halo.
¿Cómo usar un modelo local con Ollama?
Instalado Ollama, descargar y probar un modelo es una línea:
ollama run qwen3-coder:30bEl paso que casi todo el mundo olvida es el contexto. Ollama asigna por defecto una ventana según la memoria de vídeo: 4.000 tokens con menos de 24 GiB, 32.000 entre 24 y 48 GiB y 256.000 a partir de 48 GiB. Su documentación indica que los agentes y herramientas de programación necesitan al menos 64.000 tokens. Con 4.000, el agente olvidará el fichero que acaba de leer. Se ajusta al arrancar el servidor:
OLLAMA_CONTEXT_LENGTH=64000 ollama serveDespués, comprueba con ollama ps que la columna PROCESSOR indica «100% GPU». Si aparece un reparto con la CPU, el modelo o el contexto no caben y el rendimiento caerá en picado.
Para conectar el modelo a un agente, Ollama incluye el comando ollama launch, que configura automáticamente herramientas como Claude Code u OpenCode:
ollama launch claude --model qwen3-coder
ollama launch opencode --model devstral-small-2Ollama expone además una API local en http://localhost:11434 que puedes usar desde cualquier cliente compatible.
¿Y con LM Studio?
LM Studio ofrece interfaz gráfica para descargar modelos y ver si caben en tu GPU, y un servidor local compatible con las API de OpenAI y, desde la versión 0.4.1, con la de Anthropic (/v1/messages). Para usarlo con un agente de terminal:
lms server start --port 1234
export ANTHROPIC_BASE_URL=http://localhost:1234
export ANTHROPIC_AUTH_TOKEN=lmstudio
claude --model openai/gpt-oss-20bLM Studio recomienda un contexto superior a unos 25.000 tokens para este uso y, si activas la autenticación, usar un token propio en lugar del valor genérico.
¿Qué editores admiten modelos locales?
Zed integra de serie LM Studio, Ollama y llama.cpp: basta con arrancar el servidor local para que los modelos descargados aparezcan en el selector del agente. En VS Code, Ollama ofrece su propia extensión. Para el resto de editores y agentes, lo más práctico es tirar de la API compatible con OpenAI o Anthropic que exponen ambos servidores y comprobar en la documentación de cada herramienta si permite configurar una URL base propia.
Consejos para que funcione en el día a día
- Tareas acotadas: los modelos locales rinden mejor con instrucciones concretas que con «implementa el módulo de facturación».
- Corrige editando, no añadiendo: si el modelo se equivoca, edita tu mensaje anterior en lugar de enviar una corrección; así no llenas el contexto de respuestas erróneas.
- Combina: modelo local para el grueso del trabajo con código sensible y modelo de frontera en la nube para tareas complejas sobre código no confidencial.
- Mide con tus propias tareas: las cifras de SWE-bench de los fabricantes no sustituyen probar con issues reales de tus repositorios.
Para una agencia con código de clientes sujeto a acuerdos de confidencialidad, un equipo con 32 GB y Devstral Small 2 o Qwen3-Coder ya permite un flujo de trabajo útil sin que una sola línea salga de la oficina.
