Cómo usar LLM locales para programación con agentes
(blog.alexewerlof.com)- En medio del fuerte aumento de precios de los modelos insignia en la nube, se presenta una guía para aprovechar modelos locales y seguir programando sin una carga de costos
- Los modelos locales no alcanzan el rendimiento de los modelos SOTA, pero con una buena relación precio/rendimiento y refuerzo mediante un harness determinista (deterministic harness), la calidad puede mejorar hasta 6 veces
- Para programación, Gemma 4 ofrece un buen equilibrio entre trabajo general y generación de código, y su soporte para Tools Use, Vision y Reasoning lo hace adecuado para integrarlo con VS Code
- Se incluye el procedimiento completo para levantar un servidor de modelos con LM Studio y conectarlo a endpoints personalizados de VS Code Copilot y Pi
- Si el hardware no alcanza, se pueden usar como alternativa los modelos gratuitos de OpenRouter, aunque los modelos locales siguen teniendo ventaja en funcionamiento offline y privacidad
Contexto del aumento de precios
- GitHub Copilot pasó de un modelo por créditos a facturación por uso, y los modelos que antes eran gratuitos ya no lo son
- Como GitHub actúa como revendedor de tokens, el impacto del aumento se siente más. Los modelos insignia se están lanzando sin que la mejora de rendimiento siga el ritmo del aumento de precio
- Google Flash 3.5 cuesta 3 veces más que Flash 2.5
- GPT 5.5 cuesta 3 veces más que GPT 5
- Claude, que ya era demasiado caro, terminó bajando de precio
La realidad y las fortalezas de los modelos locales
- Los modelos locales no igualan el rendimiento SOTA de modelos como Claude, GPT o Gemini, pero hay varios matices (nuance)
- Relación precio/rendimiento: en los modelos en la nube, el costo crece de forma exponencial frente a las mejoras de rendimiento
- Harness determinista: con mejor tooling e instrucciones, la calidad de un modelo débil puede mejorar hasta 6 veces
- La trampa de los benchmarks: es difícil reducir un modelo a una sola cifra, y cada laboratorio de IA se enfoca en benchmarks que lo favorecen, así que conviene evaluarlos directamente con tu propia carga de trabajo
- Efecto geopolítico: lo que los laboratorios de EE. UU. publican gratis no es lo mejor que tienen.
gpt-oss-20bya está demasiado viejo y Anthropic no publica open weights. Gemma 4 es el único modelo realmente serio, y vale la pena prestar atención a modelos competentes publicados por laboratorios chinos como Qwen, Kimi y GLM
- Desde la perspectiva del fenómeno de "brain rot", un modelo más débil obliga al usuario a intervenir más, así que puede ser mejor para la salud mental
- Es como andar en bicicleta: más lento, pero mejor para la salud. En el trabajo del conocimiento, "slow is fast"
- El objetivo no es maximizar la automatización delegando el pensamiento a la máquina. No sacrifiques tu relevancia personal (relevance) futura por velocidad a corto plazo
- Las técnicas para manejar modelos débiles también sirven con modelos grandes. Manejar modelos débiles es como jugar en modo difícil: si lo dominas, luego puedes aprovechar mejor herramientas más poderosas
Elección del modelo — Gemma 4
- Para programación, los modelos chinos dominan la parte alta del leaderboard de Huggingface, con opciones como Qwen, DeepSeek, Kimi, Llama y Gemma
- Gemma 4 está compuesto por varias versiones
- E2B: la "E" significa edge. Con 2B parámetros puede correr en la mayoría del hardware, pero hay alto riesgo de alucinaciones o de no completar tareas
- E4B: el doble de tamaño que E2B. Es barato de descargar y configurar, así que se recomienda para empezar
- 12B: entiende imágenes de forma nativa sin decoder, por lo que es más rápido para frontend y programación visual. También soporta audio nativamente, aunque eso importa poco en cargas de trabajo de código
- 26B A4B: arquitectura MoE (mixture of experts) donde, de 26B parámetros, solo se activan 4B. Es más inteligente que E4B y encaja bien en GPUs con 8~12GB de VRAM (es el modelo preferido del autor)
- 31B: el mayor modelo open weight de Google. No es MoE y requiere mucha VRAM. En una AMD APU corre a 1~2 TPS, un nivel prácticamente inutilizable
- Las variantes QAT (por ejemplo, E4B QAT) usan menos memoria y mantienen casi la misma calidad. Unsloth está haciendo optimizaciones adicionales
Componentes necesarios para ejecutar un modelo local
- Para ejecutar un modelo local se necesita un harness, un modelo, un runtime y un gestor de modelos
- Harness: VS Code Copilot, Copilot CLI, Pi, etc. Es el componente determinista (código tradicional) que envuelve al modelo, que es probabilístico
- Modelo: archivo de pesos de una red neuronal profunda. La cuantización (quantization) (
Q8,Q4, etc.) es un concepto parecido a la resolución de imagen, y los formatos incluyen GGUF y MLX
-
Runtime (motor de inferencia)
- Llama.cpp: el runtime open source más popular, capaz de cargar GGUF y MLX. No tiene relación con los modelos Llama de Meta, y LM Studio lo usa internamente
- MLX: runtime de Apple para Mac con M1, M2, etc.
- ONNX Runtime: basado en
transformers.js, permite ejecución en navegador mediante WebGPU y también soporta móviles iOS y Android - vLLM: open source surgido en UC Berkeley, orientado sobre todo a servidores de alto rendimiento, con una configuración más compleja
-
Gestor de modelos
- Ollama: comenzó como CLI de terminal y luego añadió una GUI ligera. Es un wrapper en Go sobre Llama.cpp. Es open source
- LM Studio: gratuito, pero no es open source. Ofrece SDK (Python/TypeScript) y REST API, y permite controlar funciones propias de modelos locales como la carga dinámica
- Jan: alternativa similar a LM Studio, gratuita y open source, aunque con menos funciones
- El soporte para API compatible con OpenAI es clave, porque muchas aplicaciones de IA funcionan con este estándar de facto
Configuración del servidor en LM Studio
- Desde el botón "Developer" se puede iniciar el servidor con un toggle. Si se ejecuta en otra máquina o en un contenedor, hay que activar Serve on Local Network; para acceso desde apps web, Enable CORS
- LM Studio usa carga JIT (Just In Time), es decir, carga el modelo al momento de la solicitud. El TTL permite controlar cuánto tiempo se mantiene en memoria
- Cold start: si el modelo no está cargado, la primera solicitud tarda unos 10~30 segundos extra, parecido al cold start de AWS Lambda. Esto afecta la métrica TTFT (Time To First Token)
- Ventana de contexto corta: con la configuración por defecto, la ventana de contexto puede ser de solo 4k, por lo que hay que aumentarla manualmente. La mayoría de los modelos de VS Code Copilot tienen entre 200~400k
-
Longitud de contexto y configuración de memoria
- Requisitos de VRAM según la longitud de contexto: 262144 (máximo) = 25.74GB, 4096 (por defecto) = 18.16GB, 150000 (preferencia del autor) = 22.45GB
- Para programación, el prompt del sistema puede ocupar entre 20~40k tokens, así que hace falta cargar al menos 100k tokens
- Si el contexto es demasiado grande, baja la velocidad de generación de tokens. Lo ideal es encontrar el punto donde el harness comprime automáticamente el contexto
- Lo ideal es ejecutar todas las capas del modelo en la GPU, así que se recomienda llevar al máximo el slider de "GPU Offload". Ejecutar capas en CPU, salvo en Apple Silicon (UMA), implica copiar datos entre CPU y GPU
-
Truco de cuantización de KV cache
- Configura K Cache Quantization Type en
Q8_0y V Cache Quantization Type enQ4_0 - La idea es mantener las claves a mayor resolución que los valores. Con esto, la memoria requerida en GPU baja de 28.75GB a 22.45GB
- Es imprescindible guardar la configuración. Si no se guarda, al cargar el siguiente modelo vuelve a los valores por defecto
- VS Code Copilot no tiene un concepto de solicitud de ventana de contexto personalizada, así que LM Studio debe recordar esta configuración al recibir la llamada REST API
- Configura K Cache Quantization Type en
- Si el TPS es menor de 10, resulta difícil de tolerar para programar, porque se pasa más tiempo esperando al modelo
Conectar Copilot a un endpoint personalizado
- Se necesita una versión reciente de VS Code (1.122.1 al momento de escribir esto). Para agregarlo: selector de modelos → engrane → "Add Models" → "Custom Endpoint"
- Asigna un nombre (por ejemplo, "Local LM Studio"), ingresa la API Key (o presiona Enter si no configuraste una) y elige el tipo de API de inferencia
- De los tres tipos de API, solo Chat Completions funciona bien
- En la configuración JSON hay que definir manualmente
url,maxInputTokens,maxOutputTokens, etc.- Configura correctamente la opción
thinking(Gemma 4 la soporta) - El arreglo
supportsReasoningEffortvaría según el modelo, y la versión 26B ofrece control más fino que E4B - Para 4B:
maxInputTokens64000 /maxOutputTokens16000; para 26B MoE: 100000 / 50000
- Configura correctamente la opción
- En el primer prompt, Copilot envía un prompt de sistema enorme junto con definiciones de herramientas, lo que provoca un retraso inicial de 2~5 minutos en la primera interacción. Cargar el modelo toma 30 segundos, y procesar el prompt de entrada unos 5 minutos
- Solo ocurre una vez por sesión, porque LM Studio aplica prompt caching. Pi no tiene este problema porque su prompt del sistema es pequeño
-
Prueba rápida y entorno
- Sin
AGENTS.mdni SKILL, se genera un juego de Snake con un prompt de una sola vez para demostrar el rendimiento de Gemma 4 26B A4B - Entorno usado: Lenovo Thinkpad L16 Gen 2, AMD Ryzen 7 PRO 250 APU, 64GB DDR5 (5,600MT/s), Aurora Linux. El autor considera que 32GB también serían suficientes
- Sin
Configuración de Pi
- Conectarlo al servidor local de LM Studio es sencillo, y la configuración de
contextWindowencaja mejor con la forma en que LM Studio maneja esto - Define
baseUrlcomohttp://host.containers.internal:1234/v1yapicomoopenai-completions- Para 4B, configura
contextWindow64000 /maxTokens16000; para 26B MoE, 150000 / 50000, además de mapearthinkingLevelMap
- Para 4B, configura
Resumen de ventajas y desventajas de los modelos locales
- Ventajas: funcionamiento offline, alta privacidad y respuestas rápidas según hardware, flujo de trabajo, modelo y configuración
- Desventajas
- Los modelos open weight no son tan inteligentes como los modelos insignia cerrados, pero con un harness con guardrails adecuados (
lint, tests,AGENTS.md) se puede mejorar mucho la precisión al programar - Ejecutar el LLM en la misma máquina provoca ralentización por carga de hardware
- Cold start, procesamiento del primer prompt de entrada (cache miss) y alto costo inicial de hardware
- Los modelos open weight no son tan inteligentes como los modelos insignia cerrados, pero con un harness con guardrails adecuados (
- Una vez que te acostumbras a LM Studio, puedes usar Llama.cpp directamente sin GUI. La mayoría de los harnesses soportan endpoints personalizados, así que pueden integrarse con LLM locales
Alternativa: modelos gratuitos de OpenRouter
- OpenRouter es un servicio de API y routing unificado que expone cientos de modelos con un solo endpoint y una sola cuenta
- Copilot, Zed y Pi tienen soporte nativo para OpenRouter, así que basta con emitir un token de API y conectarlo
- Para evitar que los costos se disparen, se recomienda crear un guardrail personalizado con tope de $1/mes y añadir a la allowlist solo modelos gratuitos
- Al crear una nueva API key, se recomienda configurar el max credit en 0
- Desventajas: los prompts y datos pueden usarse para entrenamiento (hay configuración ZDR), se necesita conexión a internet y OpenRouter podría dejar de ofrecer modelos gratuitos
- Ventajas: no hace falta descargar ni configurar nada localmente, y la computadora no se vuelve más lenta mientras se usa
-
Actualización 2026-06-09
- Se adopta Deepseek V4 Pro. Su rendimiento es casi comparable a Claude Opus 4.8, con una ventana de contexto 5 veces mayor y un precio unas 17~86 veces menor
- Había una diferencia de precio de unas 3 veces entre Pi y OpenRouter, y la causa fue que OpenRouter enviaba las solicitudes a un endpoint más caro (GMICloud)
- Para tareas complejas, el autor abrió directamente una cuenta de Deepseek. Para tareas simples, comprensión de funcionamiento o situaciones donde importa la privacidad, los modelos locales siguen siendo la primera opción
3 comentarios
Al final, la conclusión fue que terminé usando DeepSeek V4 Pro después de haber estado usando modelos locales.
Como tampoco es fácil ir cambiando de modelo cada vez que trabajo, también se me hizo difícil mantener la idea de usar lo local para tareas simples.
No hace falta que sea necesariamente local; hay muchas alternativas de suscripción económicas como opencode, ollama y cursor.
En la era de los grandes LLM, yo uso un plugin que hice. Incluso lo presenté una vez en GN SHOW; creo que otra opción es hacer algo así a la medida de tus necesidades.
https://github.com/hang-in/tunaLlama