LM Studio on KnightLi Blog

Una GPU de 16GB aún puede ejecutar modelos 35B: estrategias de compresión VRAM para modelos MoE en LM Studio

Wed, 22 Apr 2026 21:47:34 +0800

Mucha gente piensa que 16GB de VRAM es el punto donde el despliegue local de LLMs se queda más o menos en modelos 12B a 14B, y que cualquier cosa más grande se vuelve demasiado dolorosa incluso con cuantización. Esa visión es comprensible, pero no es el techo real de una GPU de 16GB.

Si eliges bien el modelo y configuras bien los parámetros, una GPU de 16GB no tiene por qué limitarse a modelos pequeños. Un enfoque representativo es usar modelos MoE dentro de LM Studio con una estrategia sensata de descarga, de modo que modelos de clase 35B sigan funcionando a una velocidad realmente usable.

01 Por qué una GPU de 16GB no necesariamente se limita a 12B-14B

La idea central es simple: el tamaño de VRAM importa, pero la arquitectura del modelo importa igual.

Si intentas meter un modelo dense estándar en una GPU de 16GB, chocarás con el límite rápidamente. Estos modelos suelen involucrar todos los parámetros durante inferencia, así que la presión de VRAM y ancho de banda sube de inmediato.

Pero los modelos MoE son distintos. Su número total de parámetros puede ser grande, mientras solo una parte de los parámetros expertos se activa en cada paso de inferencia. Tomando como ejemplo un modelo de clase 35B: aunque el total de parámetros es alto, el número real que participa en cada paso es mucho menor, así que su requisito real de VRAM no es tan extremo como muchos asumen.

Por eso una GPU de 16GB todavía deja cierto margen de trabajo.

02 Conclusión práctica clave: los modelos MoE 35B pueden correr sorprendentemente rápido

Un caso representativo es un modelo MoE cuantizado como Qwen 3.5 35B A3B. Con una GPU de 16GB y los ajustes correctos en LM Studio, la cuantización Q6 puede superar los 30 tokens/s, y Q4 a veces prueba incluso más alto.

Ese resultado importa no solo porque el modelo “corre”, sino porque la velocidad ya está en un rango claramente usable.

En comparación, modelos grandes de escala similar que no son MoE suelen sufrir overflow de VRAM y caídas bruscas de velocidad en una GPU de 16GB. En otras palabras, el resultado no se determina solo por el número de parámetros. Importa cómo se usan esos parámetros durante inferencia.

03 En LM Studio, la clave no es un solo parámetro

Si quieres que este tipo de modelo corra con fluidez en una GPU de 16GB, el truco real no es suerte. Es ajustar correctamente dos parámetros:

GPU Offload
el ajuste que fuerza parte de las capas expertas a memoria CPU

El primero es fácil de entender. GPU Offload básicamente se empuja lo más alto posible para que el modelo priorice cálculo en GPU.

El segundo es la clave. No es el enfoque tradicional de “tomar prestada memoria del sistema cuando se desborda la VRAM”. En su lugar, coloca proactivamente parte de las capas expertas en memoria CPU para reducir uso de VRAM desde el inicio. Como los modelos MoE no activan todos los expertos en cada paso, mover algunos expertos a memoria no perjudica la velocidad global tanto como muchos esperarían.

Una forma más segura de ajustarlo es empezar en un rango y luego afinar gradualmente según tu máquina:

empezar con valores relacionados entre 20 y 35
luego ajustar según uso de VRAM y presión de memoria

En el fondo, este método usa memoria del sistema para recuperar margen de VRAM.

04 Puede seguir funcionando a 128K de contexto, y contextos menores reducen más la VRAM

Otro punto interesante es que incluso con longitud de contexto en 128K, un modelo MoE de clase 35B puede mantener una velocidad relativamente alta.

Eso dice algo importante: el cuello de botella de una GPU de 16GB no es tan rígido como muchos imaginan. Especialmente en una herramienta local como LM Studio, la pregunta real no suele ser simplemente si corre o no, sino:

si aceptas intercambiar más memoria del sistema por menos uso de VRAM
si aceptas acortar la longitud de contexto
si aceptas distintos compromisos de capacidad entre niveles de cuantización

Si reduces el contexto de 128K a 64K o 32K, la presión de VRAM baja aún más. Eso significa que algunos modelos MoE de clase 35B podrían incluso correr, con dificultad, en GPUs con menos VRAM, aunque velocidad y presión de memoria tendrán que reequilibrarse.

05 El coste: mucha más demanda de RAM y memoria virtual

Este setup no es rendimiento gratis.

Lo que debes vigilar es que, al comprimir más la presión de VRAM, el uso de RAM del sistema sube notablemente, y también la presión de memoria virtual. En otras palabras, no eliminas el coste: lo desplazas desde la GPU hacia RAM y swap en disco.

Si quieres probarlo, revisa primero:

si tu RAM del sistema es suficiente
si tu asignación de memoria virtual es suficiente
si demasiadas apps de fondo ya consumen recursos

Si esas condiciones no están, quizá no obtengas “35B corriendo rápido”, sino una máquina lenta en todo.

06 Una cuantización más agresiva no siempre es mejor

Hay otro compromiso práctico. La cuantización de menos bits suele ahorrar más VRAM, pero eso no la convierte automáticamente en la mejor opción.

La conclusión práctica es que algunos modelos corren más rápido en Q4, pero su capacidad original también puede degradarse más. En comparación, Q6 tiende a equilibrar mejor velocidad y retención de capacidad. Así que la elección correcta depende de qué te importe más:

máxima velocidad y encajar en VRAM
o preservar más capacidad original del modelo

Esas dos prioridades no siempre llevan a la misma cuantización.

07 Qué modelos vale la pena probar

Desde este ángulo, lo mejor no es perseguir ciegamente más parámetros, sino buscar primero modelos que encajen con esta estrategia:

modelos construidos sobre arquitectura MoE
modelos bien soportados en LM Studio y con variantes cuantizadas completas
modelos con ventajas claras en contexto largo o seguimiento de instrucciones

La idea no se detiene en un único modelo MoE 35B. También se extiende a modelos experimentales con memoria de contexto largo más fuerte, mejor seguimiento de instrucciones o variantes cuantizadas más ligeras con gran velocidad.

La lógica es consistente: primero encuentra modelos cuya arquitectura encaje con la estrategia de intercambiar memoria por VRAM, y luego habla de tuning. No empieces solo por número de parámetros.

08 Conclusión breve

Si tienes una GPU de 16GB y asumes que los LLMs locales se detienen en 12B-14B, vale la pena actualizar esa suposición.

Una forma más precisa de decirlo:

una GPU de 16GB no queda automáticamente descartada para modelos más grandes
modelos dense y modelos MoE deben considerarse por separado
GPU Offload y transferencia de capas expertas a memoria CPU en LM Studio pueden cambiar significativamente el uso de VRAM
en la práctica, intercambias mayor presión de memoria por más escala de modelo y mejor velocidad usable

Este enfoque no encaja con todas las máquinas, pero muestra algo importante: en despliegue local de LLMs, la VRAM no es el único límite. La arquitectura del modelo y la configuración de inferencia importan igual.

Gemma 4 en Raspberry Pi 5: viable, pero con respuestas lentas

Wed, 08 Apr 2026 18:42:00 +0800

Un intento un poco extremo: ejecutar Gemma 4 en una Raspberry Pi 5 (8GB RAM). El objetivo no fue una versión grande del modelo, sino el modelo más pequeño E2B.

La conclusión primero: puede ejecutarse y es usable, pero encaja mejor en escenarios con poca interacción. No es ideal para una experiencia conversacional con alta exigencia de tiempo real.

Entorno de prueba

Dispositivo: Raspberry Pi 5 (CPU de 4 núcleos, 8GB RAM)
Sistema: Ubuntu Server (sin interfaz gráfica)
Acceso: SSH
Forma de ejecución del modelo: LM Studio CLI (solo modo línea de comandos)
Modelo: Gemma 4 E2B (aprox. 4.5GB)

Paso 1: instalar e iniciar LM Studio CLI

Instala la versión CLI de LM Studio, inicia el servicio y consulta los comandos disponibles.

Como es un entorno puro de línea de comandos, este método de despliegue solo por CLI encaja muy bien con Raspberry Pi.

Paso 2: mover el almacenamiento de modelos a un SSD

Para evitar lecturas y escrituras frecuentes en la tarjeta SD, moví el directorio de descarga de modelos a un SSD externo.

La experiencia de conectar un SSD a Raspberry Pi 5 es claramente más práctica que en modelos anteriores. Para ejecutar modelos locales durante mucho tiempo, conviene priorizar SSD.

Paso 3: descargar y cargar Gemma 4 E2B

Después de la descarga, el modelo puede cargarse correctamente en memoria.

Según la información oficial, la serie Gemma 4 cuenta con:

Capacidad de tool calling orientada a escenarios Agent (function calling)
Capacidades multimodales (incluyendo imagen/video; los modelos pequeños también tienen capacidades relacionadas con voz)
Ventana de contexto 128K
Licencia Apache 2.0 (usable comercialmente)

Viendo las condiciones de hardware de Raspberry Pi, la variante E2B es la más adecuada para empezar a probar.

Paso 4: iniciar la API y abrir acceso en la red local

Después de cargar el modelo, primero inicié la API en el puerto local (4000) y confirmé mediante una petición HTTP que la lista de modelos podía devolverse.

El problema es que, por defecto, solo escucha en la propia máquina, así que otros dispositivos de la LAN no pueden acceder directamente.

Como los parámetros de inicio no permitían configurar directamente el host, usé socat para hacer reenvío de puerto: las peticiones al puerto externo de la Raspberry Pi se puentean al puerto interno de LM Studio, permitiendo acceso por LAN.

El resultado fue viable: desde un MacBook en la misma red local pude hacer la petición y obtener correctamente la lista de modelos.

Paso 5: integración con editor (Zed)

El servicio local de LM Studio es compatible con la forma de la OpenAI API, por lo que la mayoría de herramientas que soportan base_url personalizado pueden conectarse directamente.

En Zed añadí un nuevo LLM provider apuntando a la instancia de Gemma 4 en la Raspberry Pi, y después la prueba de chat dentro del editor funcionó.

Juicio de usabilidad real

Esta solución encaja con:

Scripts locales de automatización
Tareas auxiliares de baja concurrencia y baja exigencia de tiempo real
Aprendizaje personal y experimentos en dispositivos edge

No encaja tanto con:

Chat interactivo de alta frecuencia
Escenarios de colaboración de desarrollo sensibles a la latencia

Conclusión

Ejecutar Gemma 4 (E2B) en Raspberry Pi 5 es viable, y el resultado real fue mejor de lo esperado.

Si tu objetivo es “poder ejecutarlo offline, conectarlo a herramientas y completar tareas ligeras o medias”, esta ruta merece probarse. Si el objetivo es interacción fluida en tiempo real, sigue siendo recomendable usar hardware más potente.