LLM locales para programar: cómo correr un modelo de código en tu propia máquina (2026)
Podés correr un modelo de código capaz completamente en tu propia máquina — sin clave de API, sin nube, sin que tu código salga de la computadora. Una laptop con 8 GB de VRAM corre un buen modelo de código 7B; una GPU o una Mac de 24–32 GB corren algo cercano a un asistente alojado. Esta guía explica qué puede hacer de verdad un LLM de código local, cómo elegir uno para tu hardware, cómo instalar un runtime y cómo conectarle un agente de código real.
En resumen: elegí un runtime (Ollama es el más fácil), descargá un modelo de código dimensionado a tu VRAM y apuntá un editor o agente agnóstico al endpoint local. La inferencia pasa entonces en tu CPU/GPU y nada se envía a un proveedor. La única restricción real es la memoria — decide qué tan grande, y por lo tanto qué tan bueno, puede ser el modelo.
Qué puede (y qué no) hacer un modelo de código local
Un LLM de código local es un modelo que corre en tu propio hardware en lugar de en los servidores de un proveedor. En 2026 la distancia con los modelos alojados se redujo mucho para el trabajo diario:
- Bueno para: autocompletado, escribir funciones y tests, explicar código, refactors chicos, boilerplate, fragmentos de shell y config, y ser el cerebro de un agente en una tarea bien acotada.
- Más flojo en: razonamiento multiarchivo muy amplio, los frameworks más nuevos y corridas autónomas largas — donde los modelos alojados más grandes todavía llevan ventaja.
El trade-off es simple. Los modelos alojados son más grandes y no requieren instalación, pero tu prompt y seguido los archivos cercanos salen de tu máquina (mirá ¿Las herramientas de programación con IA envían tu código a la nube?). Un modelo local es más chico pero privado, gratis de correr y funciona sin conexión. Para código propietario, de clientes o regulado, el trade-off suele valer la pena.
Paso 1 — Ajustá el modelo a tu VRAM
La memoria es el factor decisivo. Los pesos de un modelo ocupan aproximadamente:
GB de pesos ≈ (parámetros en miles de millones × bits por peso) ÷ 8
La mayoría usa cuantización de 4 bits (las versiones Q4_K_M), que mantiene alta la calidad reduciendo el tamaño ~4×. Un modelo 7B en Q4 ocupa solo ~4–5 GB de pesos. Dejá margen por encima para la ventana de contexto (el caché KV) y la sobrecarga del runtime — si un modelo queda justo en el límite de tu VRAM, se desborda a la RAM del sistema y se vuelve lentísimo.
Tramos prácticos para programar (Q4_K_M), como punto de partida:
| Tu hardware | Tamaño del modelo | Buenas opciones 2026 |
|---|---|---|
| 8 GB VRAM / Mac 16 GB | 7–8B | Qwen2.5-Coder 7B; 1.5B solo para autocompletado |
| 12–16 GB VRAM | 13–14B | Qwen2.5-Coder 14B, Codestral 22B (justo) |
| 24–32 GB VRAM / Mac 32 GB | 27–32B | Qwen3-Coder 30B (MoE, rápido), Devstral Small 2 (agéntico) |
Dos aclaraciones. Apple Silicon usa memoria unificada, así que estos números de VRAM no se traducen uno a uno — una Mac de 32 GB corre cómoda un modelo 27–32B. Y la gama de modelos cambia rápido: tomá los nombres de arriba como punto de partida y revisá los tags actuales en la biblioteca de Ollama o en Hugging Face antes de comprometerte. Los puntajes de los benchmarks suelen declararlos los propios creadores — probá dos o tres con tu propio código y juzgá vos.
Paso 2 — Instalá un runtime
Un runtime carga el modelo y lo expone mediante una API local. Cuatro opciones comunes, de la más fácil:
- Ollama — un comando para descargar y correr; expone un endpoint compatible con OpenAI en
http://localhost:11434. La mejor opción por defecto. - LM Studio — una GUI con navegador de modelos y servidor local con un clic; ideal si preferís evitar la terminal.
- llama.cpp — el motor de bajo nivel sobre el que se construyen la mayoría de las herramientas; máximo control sobre hilos, contexto y descarga a GPU.
- vLLM — serving de alto rendimiento para una workstation o una máquina compartida con una GPU grande.
Instalá y corré un modelo de código con Ollama:
# instalación (macOS/Linux); Windows tiene un instalador en ollama.com
curl -fsSL https://ollama.com/install.sh | sh
# descargá un modelo de código dimensionado a tu máquina
ollama pull qwen2.5-coder:7b # 8-16 GB
# ollama pull qwen2.5-coder:14b # 16 GB+
# ollama pull qwen3-coder:30b # 24-32 GB
# corrélo — esto también levanta la API local en :11434
ollama run qwen2.5-coder:7b
Ampliá la ventana de contexto. Ollama usa por defecto un contexto demasiado corto para código real. Definí uno más grande por corrida o incluilo en un Modelfile:
# puntual: contexto más grande para esta sesión
OLLAMA_CONTEXT_LENGTH=16384 ollama serve
# o un Modelfile reutilizable
printf 'FROM qwen2.5-coder:7b\nPARAMETER num_ctx 16384\n' > Modelfile
ollama create qwen-coder-16k -f Modelfile
Verificá que el endpoint responde — habla la API de OpenAI, así que cualquier herramienta agnóstica puede usarlo:
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"qwen2.5-coder:7b","messages":[{"role":"user","content":"Write a Python function that reverses a string."}]}'
Paso 3 — Apuntá un agente al modelo local
Un modelo crudo en una terminal es solo chat. El valor llega con un agente o editor de código agnóstico capaz de leer tus archivos, correr comandos y aplicar cambios — apuntado a tu endpoint local en lugar de a una clave en la nube. Como el endpoint es compatible con OpenAI, la configuración suele ser de tres campos:
- URL base:
http://localhost:11434/v1 - Clave de API: cualquier cosa (los runtimes locales la ignoran)
- Modelo: el tag descargado, p. ej.
qwen2.5-coder:7b
Ese es todo el cableado. Ahora el razonamiento del agente corre en tu GPU y tu código nunca sale de la máquina. Tené un modelo local grande para tareas pesadas y uno chico para autocompletado en línea — muchas configuraciones usan ambos.
Dónde encaja NoTrack Coder
NoTrack Coder es un agente de código autónomo y local-first para Windows, hecho justo para esta configuración: apuntalo a un runtime local — Ollama, LM Studio, llama.cpp o vLLM — y ejecuta herramientas reales, shell y ediciones de archivos en tu máquina mientras el modelo queda local, con cero telemetría y redacción de secretos para que los archivos .env, tokens y claves nunca viajen en un prompt. Es agnóstico al modelo por diseño: todo local para el trabajo privado, o cambiá a un endpoint alojado por tarea, sin lock-in. Es un ejemplo honesto del enfoque local — mirá cómo se compara en las páginas de comparación, leé la documentación o mirá los precios.
¿Querés que tu código se quede en tu máquina? Descargalo para Windows.
Preguntas frecuentes
¿Cuál es el mejor LLM de código local en 2026?
Para la mayoría de las máquinas, un modelo de código de la familia Qwen es la opción constante: Qwen2.5-Coder 7B en 8–16 GB, y Qwen3-Coder 30B o Devstral Small 2 en una GPU de 24–32 GB o una Mac de 32 GB. Los benchmarks suelen ser autodeclarados, así que probá dos o tres con tu propio código antes de decidir.
¿Cuánta VRAM necesito para correr un modelo de código en local?
A grandes rasgos: 8 GB para un modelo 7–8B a 4 bits, 16 GB para un 13–14B y 24 GB+ para un 27–32B — siempre en cuantización Q4_K_M y dejando margen para la ventana de contexto. La memoria unificada de Apple Silicon rinde más de lo que sugieren los números en crudo.
¿Puedo usar un LLM de código local totalmente sin conexión?
Sí. Una vez descargado el modelo, un runtime como Ollama o llama.cpp lo corre sin red alguna — la inferencia pasa en tu CPU/GPU, así que funciona en un avión o en una máquina aislada.
¿Cómo conecto un modelo local a mi editor o agente?
La mayoría de los runtimes exponen un endpoint compatible con OpenAI (Ollama en http://localhost:11434/v1). En un editor o agente agnóstico, poné la URL base en esa dirección, cualquier texto como clave de API y elegí el tag del modelo descargado.
¿Son los modelos de código locales tan buenos como ChatGPT o Claude?
No del todo en la cima — los modelos alojados más grandes todavía llevan ventaja en el gran razonamiento multiarchivo y en corridas autónomas largas. Pero para autocompletado, funciones, tests, explicaciones y tareas de agente acotadas, un modelo local de 14–32B en 2026 está lo bastante cerca para el día a día, y es privado y gratis de correr.
¿La cuantización va a perjudicar la calidad del código?
Apenas, en Q4_K_M. La cuantización de 4 bits es el trade-off estándar para uso local: reduce un modelo ~4× con un pequeño costo de calidad que casi nadie nota en tareas de código. Bajá de 4 bits solo en hardware muy ajustado.