Inference Optimization 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.

Explicación de la cuantificación de LLM: cómo elegir FP16, Q8, Q5, Q4 o Q2

Sun, 05 Apr 2026 22:09:11 +0800

El objetivo principal de la cuantificación es simple: intercambiar una pequeña cantidad de precisión por un tamaño de modelo más pequeño, un menor uso de VRAM y una inferencia más rápida.
Para la implementación local, elegir el formato de cuantificación correcto suele ser más importante que buscar un recuento de parámetros mayor.

¿Qué es la cuantización?

La cuantización significa comprimir los parámetros del modelo desde formatos de mayor precisión (como “FP16”) a formatos de bits más bajos (como “Q8” y “Q4”).

Una analogía simple:

Modelo original: como una foto de alta calidad, clara pero grande.
Modelo cuantificado: como una foto comprimida, ligeramente menos detallada pero más ligera y rápida.

Formatos de cuantificación comunes

Cuantización	Precisión/Ancho de broca	Tamaño	Pérdida de calidad	Uso recomendado
FP16	flotante de 16 bits	Más grande	Casi ninguno	Investigación, evaluación, máxima calidad
Q8_0	Entero de 8 bits	Más grande	Casi ninguno	PC de alta gama, calidad + rendimiento
Q5_K_M	5 bits mixto	Medio	Ligero	Conductor diario, elección equilibrada
Q4_K_M	Mixto de 4 bits	Más pequeño	Aceptable	Valor predeterminado general, valor fuerte
Q3_K_M	Mezclado de 3 bits	Muy pequeño	Notable	Dispositivos de baja especificación, ejecutar primero
Q2_K	Mixto de 2 bits	Más pequeño	Significativo	Límites extremos de recursos, respaldo

Reglas de denominación de cuantificación

Tome gemma-4:4b-q4_k_m como ejemplo:

gemma-4:4b: nombre del modelo y escala de parámetros.
q4: cuantificación de 4 bits.
k: K-quants (un método de cuantificación mejorado).
m: nivel medio (las opciones comunes también incluyen s/small y l/large).

Selección rápida por VRAM

RAM/VRAM	Cuantización recomendada
4 GB	Q3_K_M / Q2_K
8 GB	Q4_K_M
16 GB	Q5_K_M / Q8_0
32GB+	FP16 / T8_0

Comience con una versión que se ejecute de manera estable en su máquina, luego avance con precisión paso a paso en lugar de saltar directamente al modelo más grande.

Consejos prácticos

Comience con Q4_K_M de forma predeterminada y pruebe primero las tareas reales.
Si la calidad de la respuesta no es suficiente, suba a Q5_K_M o Q8_0.
Si la VRAM o la velocidad son el principal cuello de botella, baje a Q3_K_M.
Utilice el mismo conjunto de prueba cada vez que cambie de formato de cuantificación.

Conclusión

Calidad primero: FP16 o Q8_0.
Saldo primero: Q5_K_M.
Valor predeterminado general: Q4_K_M.
Reserva de baja especificación: Q3_K_M o Q2_K.

La clave no es “cuanto más grande, mejor”, sino “el resultado más estable y utilizable bajo los límites de su hardware”.

Publicaciones relacionadas

Comparación y selección de modelos Gemma 4
Desinstalar completamente Ollama en Linux
Ruta de almacenamiento y migración del modelo Ollama
Cómo comprobar si Ollama usa GPU