GTX 1060 con Qwen 35B: optimizar llama.cpp de 3 tok/s a 17 tok/s

¿Puede una GTX 1060 con 6GB de VRAM ejecutar un modelo grande de clase 35B?

Con la lógica habitual, la primera respuesta suele ser “no parece muy realista”. Un modelo de 35B es enorme, 6GB de VRAM es poco, e incluso con cuantización es fácil encontrar generación lenta, falta de memoria, contexto limitado o inestabilidad después de un rato.

Pero si el modelo usa arquitectura MoE y se combina con descarga por capas en llama.cpp, memoria de CPU y ajuste de parámetros, la situación cambia. No se va a convertir en una experiencia de GPU de gama alta, pero puede pasar de “apenas funciona” a “usable para pruebas locales”.

Esta guía está organizada como una práctica de optimización. El objetivo no es exagerar lo que puede hacer una GTX 1060, sino explicar dónde mirar, qué ajustar y cómo identificar cuellos de botella al ejecutar modelos tipo Qwen 35B en hardware con poca VRAM.

Primero, la conclusión

Cuando una GPU con poca VRAM ejecuta un modelo de 35B, la clave no es meterlo todo en la VRAM. La idea es dejar que la GPU procese las partes donde la aceleración realmente compensa.

El flujo general es:

1
2
3
4
5
6
7


Primero hacer que funcione
-> Entender por qué la velocidad por defecto es baja
-> Ajustar la descarga a GPU
-> Usar las características de MoE para reducir carga innecesaria
-> Corregir cuellos de botella de memoria y caché
-> Aumentar el contexto después
-> Finalmente revisar estabilidad

Si al principio solo te preguntas “cómo lo meto en la VRAM”, es fácil optimizar en la dirección equivocada. El objetivo más práctico es coordinar VRAM, memoria del sistema, CPU, disco y caché de contexto.

Preparar el entorno

Antes de probar este enfoque, conviene tener:

Una GPU NVIDIA con alrededor de 6GB de VRAM, por ejemplo una GTX 1060 6GB;
Suficiente RAM del sistema, porque con poca RAM aparecen más fácilmente swap u OOM;
Una compilación de llama.cpp con soporte CUDA;
Un modelo cuantizado adecuado para pruebas con poca VRAM;
Expectativas realistas: no será tan rápido como una API en la nube;
Capacidad para observar VRAM, RAM y uso de procesos.

Primero comprueba el entorno:

1
2
3


nvidia-smi
free -h
./llama-cli --help

Si nvidia-smi no ve la GPU, o tu llama.cpp no tiene soporte CUDA, ajustar parámetros no dará el resultado esperado.

Paso 1: hacer que el modelo arranque

No busques 17 tok/s desde el primer minuto. El primer objetivo es simple: ¿el modelo carga y genera texto?

Un comando básico suele verse así:

1
2
3
4


./llama-cli \
  -m /path/to/model.gguf \
  -p "用三句话解释什么是 MoE 模型" \
  -n 128

Si esto falla, no añadas todavía parámetros de GPU. Revisa primero:

Si la ruta del modelo es correcta;
Si el formato de cuantización está soportado por tu versión de llama.cpp;
Si hay suficiente RAM del sistema;
Si descargaste la variante correcta del modelo;
Si el binario soporta la arquitectura del modelo.

Cuando el modelo ya funciona, empieza a optimizar velocidad.

Por qué la velocidad por defecto puede ser solo 3 tok/s

En entornos con poca VRAM, una configuración por defecto lenta rara vez tiene una sola causa.

Estos son cuellos de botella frecuentes:

Cuello de botella	Síntoma	Dirección
Muy poca descarga a GPU	La GPU está ociosa y la CPU ocupada	Aumentar GPU offload dentro del límite
Descarga demasiado agresiva	La VRAM se llena o aparecen errores	Reducir capas descargadas
Ancho de banda de memoria insuficiente	CPU alta pero pocos tokens	Reducir sobrecarga, probar otra cuantización
Contexto demasiado grande	Inicio lento o RAM que sube mucho	Probar primero con contexto pequeño
Uso de swap	El sistema se siente bloqueado	Añadir RAM o bajar parámetros
Batch inadecuado	Procesamiento lento del prompt	Ajustar parámetros de batch

No mires solo el número de tok/s. Mantén abiertos:

1
2


watch -n 1 nvidia-smi
htop

Observa juntos el uso de VRAM, utilización de GPU, carga de CPU y memoria del sistema.

Paso 2: ajustar la descarga a GPU

La forma más común de acelerar llama.cpp es descargar parte del modelo a la GPU.

Un parámetro típico es:

1

-ngl 20

O con un comando más completo:

1
2
3
4
5


./llama-cli \
  -m /path/to/model.gguf \
  -p "写一个本地大模型调优 checklist" \
  -n 256 \
  -ngl 20

El valor 20 no es una respuesta universal. En una GPU con poca VRAM, prueba poco a poco:

1
2
3
4


-ngl 10
-ngl 15
-ngl 20
-ngl 25

Después de cada cambio, revisa tres cosas:

Si el proceso arranca correctamente;
Si la VRAM está cerca del límite;
Si tok/s realmente mejora.

Si la VRAM ya está llena, subir más -ngl normalmente reduce estabilidad en vez de aumentar velocidad.

Paso 3: entender por qué MoE importa

Los modelos MoE son diferentes de los modelos dense tradicionales.

La idea clave es que el número total de parámetros es grande, pero no todos los expertos se activan en cada token. Es decir, que un modelo se anuncie como 35B no significa que cada token ejecute todo el cálculo de 35B.

Esa es una de las razones por las que una GPU con poca VRAM puede intentar ejecutar estos modelos.

Pero hay dos advertencias:

MoE no es magia gratis; el archivo del modelo sigue siendo grande;
Cuando falta VRAM, la memoria de CPU sigue cargando muchos datos.

Por eso, al optimizar modelos MoE, el objetivo es pasar a la GPU las partes de alto valor y usar la VRAM donde más aporta.

Paso 4: tratar los cuellos de botella de memoria

Mucha gente piensa que si un modelo no va bien con poca VRAM, el problema es solo la VRAM. En la práctica, VRAM, RAM y caché suelen atascarse juntas.

Si la memoria del sistema se acerca al límite, o si swap empieza a usarse mucho, la velocidad cae claramente. Puedes comprobarlo con:

1

free -h

O con:

1

vmstat 1

Busca actividad frecuente de swap.

Direcciones útiles:

Usar una versión cuantizada más pequeña;
Reducir la longitud de contexto;
Reducir batch;
Cerrar tareas en paralelo;
Cerrar procesos de fondo innecesarios;
Poner el modelo en un SSD rápido;
Dejar margen suficiente de RAM.

Si la RAM del sistema es demasiado pequeña, una GPU de 6GB no basta para que todo sea fluido.

Paso 5: no empezar con el contexto al máximo

Muchos modelos anuncian soporte de contexto largo, pero una máquina con poca VRAM no debería empezar por ahí.

Empieza con un contexto más pequeño:

1

-c 4096

Si es estable, prueba:

1

-c 8192

Al seguir subiendo, observa memoria y velocidad.

Cuanto más largo sea el contexto, mayor será la presión sobre KV cache. En dispositivos con poca VRAM, el contexto largo suele exponer problemas antes que la generación de respuestas cortas.

Si tu objetivo es Q&A local, explicar fragmentos de código o resumir textos cortos, no necesitas buscar un contexto enorme desde el inicio.

Paso 6: vigilar los parámetros de batch

Los parámetros de batch en llama.cpp afectan el procesamiento del prompt y la generación. Los nombres pueden variar entre versiones, así que mira primero la ayuda:

1

./llama-cli --help

Ideas generales:

Si el prompt es largo, ajustar batch puede mejorar el procesamiento;
Si la VRAM está justa, un batch demasiado grande puede reducir estabilidad;
No copies valores de otra persona sin probarlos en tu equipo.

Cambia solo un parámetro cada vez.

Por ejemplo, fija primero el modelo, el contexto y -ngl, y después prueba batch. Si cambias todo a la vez, no sabrás qué ajuste ayudó.

Paso 7: registrar cinco parámetros clave

Lo peor de la inferencia local con poca VRAM es conseguir que funcione hoy y olvidar mañana qué parámetros usaste.

Registra estos datos en cada prueba:

Parámetro	Qué registrar
Archivo de modelo	Nombre, cuantización y tamaño
Descarga a GPU	`-ngl` u opciones relacionadas
Longitud de contexto	Valor de `-c`
Batch	batch / ubatch y ajustes relacionados
Resultado	tok/s, VRAM, RAM, estabilidad

Una nota simple puede ser:

1
2
3
4
5
6
7


model: Qwen-xx-35B-xxx.gguf
gpu: GTX 1060 6GB
ngl: 20
ctx: 4096
batch: default
speed: about 17 tok/s
status: stable for short text, long context needs more testing

Así, cuando cambies de modelo o de máquina, tendrás una base para comparar.

Un flujo de prueba más estable

Recomiendo este orden:

Ejecutar sin descarga a GPU para confirmar que el modelo carga;
Añadir un -ngl bajo y confirmar que genera;
Subir -ngl gradualmente para encontrar el límite de VRAM;
Fijar -ngl y ajustar longitud de contexto;
Fijar contexto y probar batch;
Comparar tok/s con el mismo prompt;
Ejecutar 10 a 20 minutos para observar estabilidad;
Registrar los parámetros finales.

No cambies el prompt en cada prueba de velocidad. Con prompts distintos, los resultados no son comparables.

Puedes preparar un prompt fijo:

1

請用 800 字解釋 MoE 模型為什麼適合低顯存推理，並給出三個注意事項。

Usar siempre el mismo prompt facilita saber si la optimización realmente funcionó.

Intentos fallidos comunes

Al ajustar modelos grandes en hardware con poca VRAM, estos errores suelen hacer perder tiempo.

1. Subir GPU offload a ciegas

Ves que -ngl mejora la velocidad y sigues subiendo.

El problema es que una GTX 1060 solo tiene 6GB de VRAM. Al cruzar el límite, el programa puede fallar directamente o iniciar pero volverse inestable.

2. Empezar con contexto muy largo

El contexto largo presiona mucho la memoria y KV cache. Es mejor estabilizar el modelo con contexto corto y después ampliarlo.

3. Mirar solo el tok/s promedio

tok/s es importante, pero no es la única métrica.

También conviene mirar:

Latencia del primer token;
Velocidad de procesamiento del prompt;
Si la VRAM se desborda;
Si la ejecución larga sigue estable;
Si el sistema queda demasiado lento para otras tareas.

4. No registrar parámetros

La optimización de inferencia local requiere muchas pruebas. Sin notas, es fácil olvidar qué configuración funcionaba.

Qué esperar de una GTX 1060

¿Para qué sirve una GPU antigua como la GTX 1060?

Sirve para:

Aprender llama.cpp;
Probar modelos GGUF;
Ejecutar Q&A local corto;
Experimentar con parámetros de modelos locales;
Probar inferencia MoE con pocos recursos;
Decidir si un modelo merece desplegarse en mejor hardware.

No es ideal para:

Servicios de alta concurrencia;
Uso intensivo de contexto muy largo;
Varios usuarios a la vez;
RAG de producción a gran escala;
Aplicaciones en tiempo real sensibles a latencia.

Si tratas la GTX 1060 como una máquina de experimentos, tiene mucho valor. Si la tratas como servidor LLM de producción, es fácil decepcionarse.

Resumen en una frase

Ejecutar modelos tipo Qwen 35B con 6GB de VRAM no consiste en meterlo todo a la fuerza en la GPU. Consiste en coordinar la descarga a GPU de llama.cpp, el comportamiento MoE, la memoria del sistema, la longitud de contexto y los parámetros de batch.

Si tienes una GTX 1060 antigua, prueba este orden:

1

Hacer que arranque -> Ajustar -ngl -> Mirar VRAM -> Controlar contexto -> Revisar RAM -> Probar batch -> Registrar tok/s

Pasar de 3 tok/s a 17 tok/s no es magia. Es separar los cuellos de botella uno por uno.