Mejor LLM local para código: de 8 a 24 GB de VRAM

El mejor LLM local para programar ahora mismo: Qwen3 Coder 30B A3B en una tarjeta de 24 GB, Qwen2.5 Coder 14B en Q4 con 12–16 GB y Qwen2.5 Coder 7B en Q4 con 8 GB. Todos corren 100 % offline, autocompletan y refactorizan código real, y no cuestan nada por token. Si tu GPU tiene menos VRAM de la que necesita el modelo, baja un escalón el quant antes de bajar el tamaño del modelo. Esta guía empareja modelos con tramos de VRAM, compara las dos familias de código que la gente discute de verdad y termina con comandos ejecutables para que estés generando código en local en unos cinco minutos.

¿Qué LLM local usar para programar según tu GPU?

Elige primero por VRAM, el modelo después — el modelo solo entra si los pesos más el contexto caben en memoria. Esta es la lista corta que sigue ganando en los benchmarks comunitarios de 2026 y en el uso diario:

VRAM	Modelo	Quant	Pesos en disco	Por qué gana este tramo
8 GB	Qwen2.5 Coder 7B Instruct	Q4_K_M	~4.7 GB	Mejor relación tokens-por-segundo/calidad para autocompletar y refactors pequeños
12 GB	Qwen2.5 Coder 14B Instruct	Q4_K_M	~9.0 GB	Las ediciones de archivo completo caben en contexto; aún 30+ tok/s en una tarjeta clase 3060
16 GB	Qwen3 14B o gpt-oss-20b	Q4_K_M	~9–12 GB	Mejor razonamiento con especificaciones ambiguas; las tarjetas clase 4090 lo mantienen rápido
24 GB	Qwen3 Coder 30B A3B	Q4_K_M	~18.6 GB	MoE: solo ~3B de parámetros activos por token, así la velocidad se mantiene usable

Dos reglas hacen que esta tabla funcione en la práctica:

Deja 1–2 GB de VRAM de margen para la caché KV. Un modelo 14B en Q4 más un contexto de 8K tokens no caben en un presupuesto de 10 GB — el contexto cuenta dentro del total.
Baja un quant antes de bajar un tamaño de modelo. Los quants Q5/Q4 cuestan un porcentaje pequeño de calidad; pasar de un 14B a un 7B cuesta bastante más que eso.

¿Cuánta VRAM necesitas para un LLM local de programación?

La regla honesta de dedo: VRAM necesaria ≈ pesos cuantizados + 0.125 GB por cada 1K tokens de contexto con caché KV a 8 bits. En números planos:

8 GB corre modelos 7B–8B en Q4 con comodidad. Espera respuestas de largo de autocompletado, contexto de 4K–8K.
12 GB es el punto dulce para un 14B en Q4 — espacio de sobra para el modelo más un contexto de código realista de 8K–16K.
16 GB abre los modelos densos clase 20B y Qwen3 14B con contexto más largo.
24 GB corre el Qwen3 Coder 30B A3B MoE en Q4, lo más parecido a un modelo de código de calidad de nube que puedes hospedar tú mismo.

¿Solo CPU? Funciona — llama.cpp corre un 7B en Q4 sin queja en la CPU de una laptop a 5–10 tok/s — pero trátalo como ejercicio de paciencia, no como caballo de batalla diario. Para la parte de herramientas — qué runtime instalar — la comparación Ollama vs LM Studio cubre qué programa ponerle debajo a tus modelos.

Qwen3 Coder vs DeepSeek: ¿cuál es mejor para programar?

Este es el enfrentamiento que las barras de autocompletado preguntan de verdad, y la respuesta se divide con limpieza:

Qwen3 Coder (30B A3B) está construido para el bucle de edición: sigue las convenciones de formato de instrucciones para tool calling, produce diffs consistentes y — la parte decisiva — su diseño MoE activa solo ~3B de parámetros por token, así que una sola tarjeta de 24 GB obtiene 40–60 tok/s. Para uso estilo IDE, la capacidad de respuesta es calidad.
La línea DeepSeek V3/R1 razona a un nivel más alto: decisiones de arquitectura, algoritmos tramposos, razonamiento de varios pasos. Pero el buque insignia tiene 600B+ de parámetros; en local solo lo corres fuertemente cuantizado en rigs multi-GPU o de memoria unificada de Mac, y escribe prosa sobre código más rápido de lo que escribe código.

Elección local: Qwen3 Coder como caballo de batalla diario, DeepSeek solo si tienes el hardware para hospedarlos casi a precisión completa. Con 8–16 GB el debate es música de fondo — los modelos Qwen2.5/3 Coder son lo más fuerte que cabe.

¿Cómo ejecutar el mejor LLM local para programar con Ollama?

Cinco comandos, de la nada a una API compatible con OpenAI que tu editor puede usar:

# 1. Instala Ollama (Linux)
curl -fsSL https://ollama.com/install.sh | sh

# 2. Descarga el modelo que cabe en tu tramo de VRAM (tarjeta de 8 GB)
ollama pull qwen2.5-coder:7b

# 3. Conversa con él de forma interactiva
ollama run qwen2.5-coder:7b

# 4. Úsalo como API compatible con OpenAI desde cualquier herramienta
curl http://localhost:11434/v1/chat/completions \
  -d '{
    "model": "qwen2.5-coder:7b",
    "messages": [{"role": "user", "content": "Refactor this fn to be async: add(a,b){return a+b}"}]
  }'

# 5. Apunta hacia él las herramientas que esperan OPENAI_BASE_URL
export OPENAI_BASE_URL=http://localhost:11434/v1

Sin API key, sin límite de peticiones, sin factura por token. En Linux el instalador registra una unidad de systemd, así que si el servidor se porta mal alguna vez, journalctl te dice por qué — la chuleta de journalctl tiene los filtros exactos para depurar servicios.

¿Basta un LLM local para trabajo de programación real?

Sí para el bucle de edición, no para los problemas difíciles — y esa división es exactamente como debes usarlo. Un modelo local de 14B–30B maneja refactors, boilerplate, andamiaje de tests, regex y «explícame esta función legado» más rápido de lo que la mayoría de las APIs de nube completa el viaje de ida y vuelta. Donde pierde contra los grandes modelos hospedados es en razonamiento largo de varios archivos y en trivia oscura de frameworks — un modelo 30B simplemente sabe menos que un modelo frontera.

El flujo que funciona: ten un modelo local corriendo para el 90 % de tus pulsaciones y recurre a un modelo frontera hospedado solo para las preguntas de diseño espinosas. Tu código nunca sale de la máquina para el trabajo rutinario — algo que importa con código de clientes — y la VRAM que ya posees reemplaza en silencio una suscripción.