Modelos locales para programar en una RTX 3060 de 12 GB con un planificador de modelos

Varios modelos locales en una sola GPU de 12 GB

Hoy es fácil poner en marcha un LLM en local. Lo interesante empieza cuando quieres tener disponibles varios modelos especializados para programar, razonar y trabajar con agentes en una sola tarjeta de 12 GB.

Imagina una máquina de desarrollo bastante normal: una RTX 3060 con 12 GB de VRAM, un Ryzen 7 5800, 64 GB de RAM y Ubuntu. El objetivo no es una ventana de chat local. Se trata de modelos locales con los que puedan trabajar de verdad agentes de programación como OpenCode y otras herramientas compatibles con OpenAI. Eso pone en la lista la capacidad de programar, la llamada a herramientas, el tamaño de contexto y la latencia, y una cosa más: cambiar de modelo sin vigilar a mano la memoria de la GPU.

Lo que dan de sí 12 GB

Los modelos modernos de 7.000 a 12.000 millones de parámetros, sobre todo si están bien cuantizados, son realmente útiles para programar en una tarjeta de 12 GB. La trampa es optimizar para el modelo más grande que llega a cargar. Los pesos no son lo único que consume VRAM. El contexto, la caché KV, los búferes del runtime y otros procesos de la GPU también quieren su parte.

Los agentes de programación lo empeoran, porque una sola petición puede llevar el prompt de sistema, las definiciones de herramientas, el contexto del repositorio, archivos de código y toda la conversación previa, todo apilado.

Una regla mejor es ejecutar el modelo más potente que quepa con holgura, no el más grande que técnicamente carga.

En hardware limitado, GGUF con llama.cpp suele ser la mejor opción, porque la cuantización y la descarga a CPU y RAM dan mucho margen de maniobra. En equipos con GPU más grandes, donde cuenta el rendimiento, SafeTensors con vLLM resulta atractivo. Y de ahí sale el siguiente quebradero de cabeza, porque puede que quieras ambos.

El verdadero problema es el cambio

Un flujo de trabajo realista necesita más de un modelo: uno afinado para programar, otro para razonar, otro con la llamada a herramientas verificada, un modelo de embeddings y algunos experimentales en evaluación. Una 3060 no puede tenerlos todos en VRAM. Tampoco hace falta, siempre que esté cargado el adecuado cuando llega una petición. El comportamiento deseado es más o menos este:

Request → Model B

Y detrás, un flujo de decisión parecido a este:

Model B running?
      │
      No
      ↓
Drain Model A
      ↓
Unload Model A
      ↓
Free VRAM
      ↓
Load Model B
      ↓
Health check
      ↓
Serve request

Dicho de otro modo, la petición decide qué modelo ocupa la GPU. En ese momento el trabajo deja de ser de inferencia y pasa a ser de planificación.

Por qué Ollama o LM Studio no lo cubren

Los dos son muy buenos. Ollama es una de las formas más sencillas de descargar un modelo y empezar a usarlo, y LM Studio es estupendo para encontrar, configurar y probar modelos locales. Además, ambos tienen una gestión de modelos cada vez más capaz.

Aquí el requisito es algo distinto: varias aplicaciones deben tratar toda la colección de modelos locales como infraestructura compartida. Sin eso acabas con un montón de puertos sueltos:

Coding model       → localhost:8081
Reasoning model    → localhost:8082
Experimental model → localhost:8083
vLLM               → localhost:8000

Lo que preferirías es que todos los clientes hablaran con un único endpoint:

OpenCode ────┐
AI Agents ───┤
Python SDK ──┼──→ One OpenAI-compatible API
Node SDK ────┤
Apps ────────┘
                    │
                    ▼
              Model Scheduler
                /        \
               /          \
          llama.cpp       vLLM
              │             │
             GGUF      SafeTensors

Los clientes no deberían tener que saber qué runtime los atiende. Piden un modelo y la infraestructura decide cómo ejecutarlo.

GGUF Switchboard

De esa idea nació GGUF Switchboard, un planificador de modelos de código abierto para entornos de IA locales. Expone un único endpoint compatible con OpenAI y gestiona por debajo el ciclo de vida de los modelos. El lema es breve: un endpoint, varios modelos locales, y la infraestructura gestiona la GPU.

Ahora mismo se centra en cuatro cosas.

Descubrimiento de modelos según el hardware. Una búsqueda como esta no debería limitarse a listar todos los modelos Qwen:

ggs models search "qwen"

Debería indicar qué variantes tienen sentido para la RAM y la VRAM que tiene de verdad la máquina.

Cambio según la petición. Cuando una petición necesita otro modelo, Switchboard deja terminar la carga actual, descarga el modelo cargado, carga el solicitado y le dirige el tráfico.

Varios backends de inferencia. Cada formato de modelo corresponde a su propio runtime:

GGUF → llama.cpp
SafeTensors → vLLM

Los clientes no necesitan una configuración distinta para cada runtime.

Pruebas de conformidad con herramientas. Un modelo que escribe buen código no es automáticamente fiable dentro de un agente. La selección de herramientas, los argumentos estructurados y el comportamiento en ejecución deben comprobarse antes de confiarle flujos de trabajo con agentes.

La diferencia en una frase

Ollama y LM Studio facilitan ejecutar un modelo local. GGUF Switchboard aspira a que operar todo un conjunto de modelos locales resulte aburrido. En una GPU de 12 GB, una infraestructura aburrida es justo el objetivo.

Dónde encontrarlo

El proyecto es de código abierto y se está probando en equipos de consumo y en máquinas con varias GPU. El repositorio está en https://github.com/pradeepgudipati/gguf-switchboard.

Si usas tarjetas de consumo de 8 a 16 GB, las preguntas abiertas interesantes son cómo gestionas hoy varios modelos (un modelo para todo, cambio manual, la gestión de modelos de Ollama, llama.cpp directamente, otro planificador) y qué modelos se han mostrado fiables en la llamada a herramientas con OpenCode, Cline, Cursor o agentes parecidos. Si alguna combinación de hardware y modelo da problemas, lo más útil es abrir un issue en el repositorio con los detalles, porque son las configuraciones reales las que impulsan las mejoras del proyecto.