Llama.cpp on KnightLi Blog

Cómo medir el rendimiento multi-GPU en llama.cpp: ¿2x V100 16GB son más rápidas que una sola GPU de 32GB?

Sat, 09 May 2026 15:05:41 +0800

La conclusión rápida: el multi-GPU offload de llama.cpp no significa rendimiento gratis por añadir una segunda tarjeta. Si el modelo ya cabe completo en una GPU de 32GB, 2x V100 16GB suele ser menos cómodo que una sola tarjeta de 32GB, e incluso puede ser más lento. Si el modelo no cabe en una sola tarjeta de 16GB, el valor principal de usar dos GPU es mantener el modelo en GPU, y ahí la mejora sí puede ser clara.

Primero, separa los split mode

El uso multi-GPU en llama.cpp gira principalmente alrededor de --split-mode y --tensor-split. Para hablar de rendimiento, conviene distinguir primero estos modos:

layer: divide capas entre distintas GPU. Suele ser el punto de partida más compatible.
tensor: divide el cálculo de tensores entre varias GPU. Se acerca más al paralelismo real, pero depende mucho del ancho de banda entre GPU y del soporte del backend.
row: un modo antiguo de división por filas. Todavía aparece en algunas configuraciones, pero normalmente no es la primera opción para despliegues nuevos.

En términos simples, layer es como poner diferentes pisos en diferentes tarjetas. Durante la generación de un solo token, no siempre mantiene ambas GPU completamente ocupadas. tensor se parece más a hacer que ambas tarjetas trabajen juntas en la misma capa. Tiene más paralelismo teórico, pero la comunicación entre GPU puede convertirse en el cuello de botella.

Si una GPU de 32GB puede cargar el modelo, dos de 16GB no siempre son más rápidas

Si el modelo y la KV cache caben completos en una GPU de 32GB, una sola tarjeta suele ser más estable y a menudo más rápida. En hardware de la misma generación, como 1x V100 32GB frente a 2x V100 16GB, la configuración de dos tarjetas no tiene por qué ganar.

Una expectativa conservadora es que 2x V100 16GB pueda ser entre un 10% y un 40% más lenta que una sola V100 32GB, sobre todo en chat de un solo usuario, Continue Agent y preguntas de código, donde una petición suele generar una sola respuesta.

La razón es sencilla: multi-GPU no convierte la VRAM en un único gran bloque rápido. Con división por capas, la inferencia pasa entre GPU y una tarjeta puede esperar a la otra durante la generación. Con división por tensores, ambas tarjetas pueden calcular juntas, pero los resultados intermedios necesitan sincronización entre GPU, y el ancho de banda y la latencia afectan directamente el throughput.

Así que si tus opciones son:

1x V100 32GB
2x V100 16GB

y el modelo objetivo ya cabe completo en una sola tarjeta de 32GB, la GPU única de 32GB suele ser la opción más cómoda.

Si una GPU de 16GB no puede cargar el modelo, dos tarjetas sí aportan mucho

La situación cambia por completo cuando el modelo no cabe en una GPU de 16GB, pero sí cabe repartido entre dos tarjetas de 16GB.

En ese caso, el valor de dos GPU es directo:

Una tarjeta de 16GB: puede requerir mucho CPU offload, con una caída clara de velocidad.
2x 16GB: los pesos pueden quedarse en gran parte en GPU, lo que puede ser mucho más rápido que una ejecución mixta CPU/GPU.

En este escenario, 2x V100 16GB no garantiza superar a una sola tarjeta de 32GB, pero puede ser varias veces más rápida que una sola 16GB con mucho offload a memoria del sistema. Es decir, el primer valor de dos tarjetas no es acelerar; es evitar que los pesos del modelo caigan en una RAM del sistema mucho más lenta.

V100 PCIe y V100 SXM2 son muy diferentes

Lo que más se pasa por alto en inferencia multi-GPU es el interconnect.

Si tienes V100 SXM2 con NVLink, el ancho de banda entre GPU es mucho mayor. La documentación de NVIDIA para V100 indica que NVLink puede llegar hasta 300GB/s de ancho de banda de interconexión. En ese entorno, tensor o cargas con batch más alto tienen más posibilidades de acercarse o incluso superar el rendimiento de una sola tarjeta.

Si tienes V100 PCIe, conviene ser mucho más conservador. V100 PCIe usa principalmente PCIe Gen3, y el interconnect bandwidth indicado es 32GB/s. No está en la misma categoría que NVLink, por eso dos tarjetas PCIe a menudo dan VRAM suficiente, pero no duplican la velocidad.

Por eso, para decidir si 2x V100 16GB merece la pena, no basta con sumar VRAM y decir que son 32GB. También hay que comprobar si son tarjetas PCIe o SXM2/NVLink.

Cómo elegir de forma práctica

Si el modelo cabe en una sola GPU de 32GB, prioriza una sola tarjeta. Su latencia, estabilidad y coste de ajuste suelen ser mejores.

Si el modelo no cabe en una GPU de 16GB, pero sí en dos de 16GB, merece la pena usar dos tarjetas. En ese caso, el objetivo es mantener los pesos en GPU tanto como sea posible, no esperar una mejora lineal de rendimiento.

Si tienes dos V100 PCIe, empieza con --split-mode layer y busca ejecución estable con menos caída a CPU.

Si tienes V100 SXM2/NVLink, vale más la pena probar modos relacionados con tensor, especialmente en prefill, batch más grande o servicio concurrente.

Cuándo comprar 2x16GB y cuándo comprar 1x32GB

Si solo atiendes a un usuario y trabajas sobre todo con chat, completado de código, Continue Agent o preguntas con contexto largo, y el modelo objetivo cabe en 32GB, 1x32GB suele ser mejor. Evita la planificación entre GPU, ofrece latencia más estable y simplifica la depuración.

Si ya tienes una tarjeta de 16GB y quieres una forma más barata de ejecutar modelos de 30B, 32B o cuantizaciones más grandes, 2x16GB tiene sentido. No necesariamente duplicará los token/s, pero puede mantener en GPU pesos que de otro modo tendrían que ir a CPU offload.

Si vas a comprar desde cero, puedes priorizar así:

Un solo modelo, un solo usuario, latencia importante: preferir 1x32GB.
El modelo no cabe en una sola tarjeta y el presupuesto es limitado: considerar 2x16GB.
Hay una máquina con NVLink o SXM2: 2x16GB es mucho más interesante que dos tarjetas PCIe comunes.
Quieres usar contextos más largos en el futuro: no mires solo el tamaño de los pesos; reserva VRAM para KV cache.

Consejos prácticos para layer split y tensor split

La regla práctica es: empieza con layer y luego mide tensor.

layer es un buen punto de partida. Divide el modelo por capas, tiene mejor compatibilidad y funciona mejor en sistemas PCIe de dos tarjetas. Su desventaja es que la generación puede comportarse como una tubería: en algunos momentos una tarjeta está ocupada mientras la otra espera.

tensor encaja mejor en máquinas con buena interconexión, como V100 SXM2/NVLink. Divide parte del cálculo de una misma capa entre varias GPU, así que tiene más paralelismo teórico, pero también sincroniza más a menudo entre tarjetas. En dos GPU PCIe, el coste de comunicación puede comerse la ganancia.

Puedes empezar con estas pruebas:

1
2
3

llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,0

El tercer comando no es para uso permanente. Sirve como referencia de una sola tarjeta, para saber si dos GPU realmente son más rápidas o solo están repartiendo la presión de VRAM.

Por qué prefill y decode se comportan distinto

El rendimiento de un LLM local suele dividirse en dos fases:

prefill: procesa el prompt de entrada. Una métrica típica es el throughput de prompt processing, como pp512.
decode: genera la respuesta token por token. Una métrica típica es el throughput de token generation, como tg128.

prefill se parece más a cálculo matricial con batch grande. Con batch más alto es más fácil mantener las GPU ocupadas y obtener beneficio del paralelismo multi-GPU. decode genera un token tras otro. El batch es pequeño y la sincronización es frecuente, así que la comunicación entre tarjetas y la latencia de planificación se notan más.

Por eso puedes ver que dos GPU mejoran pp512, pero tg128 apenas mejora o incluso empeora. Para chat y agentes, la experiencia del usuario se parece más a tg128. Para ingestión de documentos largos, prefill por lotes o servicio concurrente, pp512 también importa.

¿Puede KV cache convertirse en el segundo cuello de botella de VRAM?

Sí. Muchas personas solo calculan los pesos del modelo y olvidan la KV cache.

Los pesos determinan si el modelo puede cargarse. La KV cache determina si puedes usar la longitud de contexto que quieres. Cuanto más largo sea el contexto, mayor la concurrencia y más grande el batch, más visible será el consumo de KV cache. Puede pasar que el modelo base quepa en 32GB, pero al abrir 32K o 64K de contexto vuelva a faltar VRAM.

Como mínimo, deja margen de VRAM para:

KV cache
CUDA graph o sobrecarga del runtime del backend
prompt batch y ubatch
escritorio, driver y otros procesos

Si usas 2x16GB, la VRAM no es un pool único de 32GB completamente equivalente. Algunos buffers, KV cache o tensores intermedios todavía pueden quedar limitados por la memoria restante en una sola tarjeta. Para probar contexto largo, usa directamente el --ctx-size objetivo y la concurrencia objetivo, no solo compruebes si el modelo arranca.

Cómo medir tus dos tarjetas con llama-bench

llama-bench es mejor que chatear directamente para comparar hardware, porque separa prompt processing y token generation en métricas comparables. El ejemplo básico del README oficial es:

`1`	`llama-bench -m model.gguf`

Para dos V100, al menos mide estos grupos:

# Single-card baseline
CUDA_VISIBLE_DEVICES=0 llama-bench -m model.gguf -ngl 99

# Dual-card layer split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1

# Dual-card tensor split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1

Fíjate sobre todo en dos columnas:

pp512: prompt processing, más relevante para entradas largas y prefill por lotes.
tg128: token generation, más relevante para chat de un solo usuario y respuesta de agentes.

Mantén fijos el modelo, la cuantización, el contexto, batch, versión del driver y versión de llama.cpp. Ejecuta cada grupo varias veces y compara medianas, no un único resultado. Por último, prueba también tu flujo real, como Continue Agent, un OpenAI-compatible server o tus propias peticiones RAG, porque un benchmark bonito no siempre significa una mejor experiencia interactiva.

Conclusión en una frase

La ventaja principal de 2x V100 16GB es la capacidad de VRAM, no una velocidad de generación garantizada. Si el modelo cabe en una sola tarjeta, una GPU de 32GB suele ser más rápida y estable. Si el modelo no cabe en una sola 16GB, dos tarjetas de 16GB valen mucho porque evitan gran parte del CPU offload. Que sean más rápidas o no depende del split mode, batch, tamaño del modelo y de si las dos V100 están conectadas por PCIe o NVLink.

Referencias:

Modelos LLM locales recomendados para una GPU RTX 3060

Fri, 08 May 2026 09:25:24 +0800

La versión más común de la RTX 3060 tiene 12GB de VRAM. No es una GPU de IA de gama alta, pero funciona muy bien para LLM locales, especialmente modelos de 7B, 8B, 9B y 12B.

Si solo quieres una regla rápida:

En una RTX 3060 12GB, prioriza modelos de alrededor de 8B en cuantización Q4_K_M o Q5_K_M. Elige Q4 para más estabilidad y prueba Q5 si quieres mejor calidad.

No empieces persiguiendo modelos de 32B o 70B. Aunque puedan ejecutarse con cuantización muy baja y CPU offload, la velocidad y la experiencia normalmente no son adecuadas para uso diario.

Primero mira el límite de VRAM

Al ejecutar LLM locales en una RTX 3060 12GB, el límite real es la VRAM.

Tamaño del modelo	Cuantización recomendada	Experiencia en RTX 3060 12GB
3B / 4B	Q4, Q5, Q8	Muy fácil, rápido
7B / 8B / 9B	Q4_K_M, Q5_K_M	Lo más recomendado; buen equilibrio
12B / 14B	Q4_K_M	Se puede probar, cuidado con contexto grande
30B+	Q2 / Q3 o offload parcial	Se puede experimentar, no diario
70B+	Cuantización extrema o mucha CPU/RAM	Más bien experimental

Un LLM local no solo consume VRAM por el archivo del modelo. También consumen contexto, KV cache, batch size, framework de inferencia y drivers.

Por eso 12GB de VRAM no significa cargar sin más un archivo de modelo de 12GB. Es mejor dejar margen para el sistema y el contexto.

Recomendación 1: Qwen3 8B

Si usas principalmente chino, Qwen3 8B es uno de los primeros modelos que vale la pena probar en una RTX 3060.

Sirve para:

Preguntas y respuestas en chino.
Resumen y reescritura.
Asistente diario de conocimiento.
Explicación simple de código.
RAG local.
Flujos Agent ligeros.

Elección recomendada:

1
2
3

Qwen3 8B GGUF
Q4_K_M: primera opción
Q5_K_M: mejor calidad, más presión de VRAM

La familia Qwen suele funcionar bien con chino. Para escritura diaria, organización de información y comprensión de instrucciones en chino, Qwen3 8B es un buen punto de partida.

Recomendación 2: Llama 3.1 8B Instruct

Llama 3.1 8B Instruct es un modelo general estable, con buena capacidad en inglés y ecosistema maduro.

Sirve para:

Preguntas en inglés.
Ayuda ligera con código.
Chat general.
Resumen de documentos.
Pruebas de prompts.
Comparar herramientas de inferencia.

Elección recomendada:

1
2
3

Llama 3.1 8B Instruct GGUF
Q4_K_M: mejor velocidad y estabilidad de VRAM
Q5_K_M: mejor calidad de respuesta

Si procesas sobre todo material en inglés, o quieres un modelo con muchos tutoriales y buena compatibilidad, Llama 3.1 8B sigue siendo una buena base.

Recomendación 3: Gemma 3 12B

Gemma 3 12B está más cerca del límite práctico de una RTX 3060 12GB.

Consume más VRAM que los modelos 8B, pero con cuantización Q4 todavía puede funcionar en una tarjeta de 12GB. Es una opción para quien quiera probar un modelo algo mayor en una sola GPU.

Sirve para:

Preguntas generales de mayor calidad.
Procesamiento de contenido en inglés.
Resúmenes y análisis algo más complejos.
Probar una mejora sobre modelos 8B.

Elección recomendada:

1
2
3

Gemma 3 12B GGUF
Q4_K_M u oficial QAT Q4
No abras demasiado el contexto

Si falta VRAM, reduce primero la longitud de contexto o vuelve a un modelo 8B. Para una 3060, 12B es “probable”, no una recomendación automática.

Recomendación 4: DeepSeek R1 Distill Qwen 8B

Si quieres probar modelos locales con estilo de razonamiento, puedes usar modelos como DeepSeek R1 Distill Qwen 8B.

Sirve para:

Problemas simples de razonamiento.
Análisis por pasos.
Aprender el estilo de salida de modelos de razonamiento.
Experimentos locales de bajo costo.

Elección recomendada:

1
2

DeepSeek R1 Distill Qwen 8B GGUF
Q4_K_M

Estos modelos a veces generan procesos de razonamiento más largos, así que la velocidad y el uso de contexto pueden sentirse más pesados que en modelos instruct normales. Para chat diario no siempre son más cómodos que Qwen3 8B, pero sirven bien para experimentar.

Recomendación 5: Phi / MiniCPM / modelos pequeños

Si tu 3060 es de 8GB, o tu RAM también es limitada, considera primero modelos de 3B o 4B.

Sirven para:

Preguntas rápidas.
Resúmenes simples.
Integración en pequeñas herramientas locales.
Chat de baja latencia.
Pruebas en equipos antiguos.

No siempre igualan la calidad de 8B o 12B, pero son ligeros, rápidos y fáciles de desplegar.

Cómo elegir cuantización

El formato local común es GGUF, con cuantizaciones como Q4, Q5, Q6 y Q8.

Cuantización	Características	Mejor para
Q4_K_M	Pequeña, rápida, calidad suficiente	Primera opción en 3060
Q5_K_M	Mejor calidad, más consumo	Probar con modelos 8B
Q6 / Q8	Más cerca de calidad original, más grande	Modelos pequeños o más VRAM
Q2 / Q3	Ahorra VRAM, baja calidad notable	Experimentar con modelos grandes

Para RTX 3060 12GB, lo más práctico es:

1
2
3

Modelos 8B: Q4_K_M o Q5_K_M
Modelos 12B: primero Q4_K_M
Modelos mayores: no recomendados como uso diario

Qué herramienta usar

Los principiantes pueden empezar con Ollama, porque instalar y ejecutar modelos es sencillo.

Comandos comunes:

1
2

ollama run qwen3:8b
ollama run llama3.1:8b

Si quieres controlar mejor archivos GGUF, GPU layers y longitud de contexto, usa llama.cpp o herramientas gráficas basadas en llama.cpp.

Opciones comunes:

Ollama: lo más simple, ideal para empezar.
LM Studio: interfaz gráfica amigable, útil para descargar y cambiar modelos.
llama.cpp: control más fino, bueno para ajustar rendimiento.
text-generation-webui: muchas funciones, útil para probar backends.

Para chat local y preguntas simples, Ollama o LM Studio bastan.

No abras demasiado el contexto

Muchos modelos anuncian soporte de contexto largo, pero en una RTX 3060 no conviene usar siempre el máximo.

Cuanto más largo el contexto, más KV cache se usa y mayor presión de VRAM. Incluso si el modelo carga, un contexto largo puede reducir la velocidad.

Sugerencia:

1
2
3

Chat normal: 4K a 8K
Resumen de documentos: 8K a 16K
RAG de documentos largos: divide primero; no pegues todo de una vez

La 3060 funciona mejor con “contexto medio + buen modelo + buena recuperación” que intentando meter cientos de miles de tokens.

Elegir según uso

Si escribes principalmente en chino:

1
2

Primero: Qwen3 8B Q4_K_M
Alternativa: DeepSeek R1 Distill Qwen 8B

Si escribes principalmente en inglés:

1
2

Primero: Llama 3.1 8B Instruct Q4_K_M
Alternativa: Gemma 3 12B Q4_K_M

Si quieres velocidad:

1
2
3

Modelos 3B / 4B
8B Q4_K_M
Contexto entre 4K y 8K

Si quieres más calidad:

1
2
3

8B Q5_K_M
12B Q4_K_M
Acepta menor velocidad

Si quieres ayuda con código:

1
2

Modelos de código 8B sirven para explicar y pequeños cambios
Para ingeniería compleja, usa modelos cloud más fuertes

Los modelos locales en 3060 son útiles para explicar código, completar funciones, generar scripts pequeños y ayudar sin conexión. Para grandes refactors, bugs complejos y tareas Agent entre archivos, no esperes rendimiento al nivel de Claude Sonnet o GPT-5.

Expectativas razonables

La RTX 3060 12GB puede convertir los LLM locales de “juguete” en herramienta diaria, pero no replica modelos cloud de primera línea en casa.

Ventajas:

Bajo costo.
Más VRAM que tarjetas de 8GB.
Buena experiencia con modelos 8B.
Uso offline.
Procesamiento local de datos sensibles.

Límites:

Modelos grandes no van fluidos.
Contexto largo consume VRAM.
Menor velocidad que tarjetas de gama alta.
Modelos locales pequeños tienen razonamiento complejo limitado.
Multimodalidad y flujos Agent consumen más recursos.

La ruta estable es: usar 8B como asistente local diario, probar 12B para mejor calidad y dejar tareas complejas a modelos cloud.

Resumen

Modelos locales recomendados para RTX 3060 12GB:

Chino general: Qwen3 8B Q4_K_M
Inglés general: Llama 3.1 8B Instruct Q4_K_M
Prueba de más calidad: Gemma 3 12B Q4_K_M
Experimento de razonamiento: DeepSeek R1 Distill Qwen 8B Q4_K_M
Experiencia rápida con poca VRAM: modelos pequeños 3B / 4B

Elige primero Q4_K_M; en modelos 8B puedes probar Q5_K_M. Empieza con Ollama o LM Studio.

No trates la 3060 como un servidor de grandes modelos. Úsala como asistente local de conocimiento, procesador privado de documentos, ayuda ligera de código y tarjeta de experimentación, y encajará mejor con sus capacidades reales.

Referencias

Qwen3 8B GGUF: https://huggingface.co/Qwen/Qwen3-8B-GGUF
Llama 3.1 8B GGUF: https://huggingface.co/macandchiz/Llama-3.1-8B-Instruct-GGUF
Gemma 3 12B GGUF: https://huggingface.co/unsloth/gemma-3-12b-it-GGUF
llama.cpp: https://github.com/ggml-org/llama.cpp
Ollama: https://ollama.com

Hermes + Qwen3.6: una solucion barata para desplegar un Agent local

Mon, 04 May 2026 06:40:30 +0800

La idea es ejecutar el modelo Qwen3.6 GGUF con llama.cpp dentro de WSL2 y conectar Hermes Agent a una API local compatible con OpenAI. Asi puedes tener un asistente de IA local siempre disponible en tu propio ordenador, sin depender de cuotas de tokens de servicios online.

Esta solucion encaja con usuarios que quieren probar un AI Agent local y, al mismo tiempo, conservar privacidad de datos y control a largo plazo. Puede servir para preguntas diarias, escritura, ayuda con codigo, organizacion de informacion y automatizacion simple. Hay que tener en cuenta que cuanto mayor sea el modelo, mas VRAM necesitara; el ejemplo original usa Qwen3.6-27B y va mas estable con 24GB de VRAM. Si tienes menos VRAM, conviene elegir un modelo mas pequeno o una cuantizacion mas baja.

Estructura de la solucion

La cadena completa es sencilla:

Instalar WSL2 y Ubuntu 24.04 en Windows.
Instalar CUDA Toolkit y compilar llama.cpp dentro de WSL2.
Descargar el modelo Qwen3.6 GGUF.
Iniciar el servicio local con llama-server.
Instalar Hermes Agent y configurarlo hacia http://localhost:8080/v1.
Opcional: escribir un script de inicio para arrancar el servicio del modelo al abrir WSL2.

Hermes aporta la capacidad de Agent, y Qwen3.6 aporta el LLM local. Combinados, convierten el ordenador en un asistente de IA local y privado.

Instalar WSL2 y Ubuntu

En una ventana de Windows PowerShell como administrador:

1
2

wsl --install
wsl --set-default-version 2

Despues de reiniciar, instala Ubuntu 24.04:

`1`	`wsl --install -d Ubuntu-24.04`

Al terminar, Ubuntu pedira usuario y contrasena. Ya dentro de Ubuntu, comprueba primero si la GPU NVIDIA se reconoce correctamente en WSL2:

`1`	`nvidia-smi`

Si no se reconoce la GPU, normalmente hay que actualizar primero el driver NVIDIA en Windows. WSL2 hereda el driver de Windows, pero CUDA Toolkit debe instalarse por separado dentro de WSL2.

Instalar Python y herramientas basicas

`1`	`sudo apt update && sudo apt install -y python3-pip python3-venv`

Tambien hacen falta herramientas de compilacion, Git y CMake:

`1`	`sudo apt install -y cmake build-essential git`

Compilar llama.cpp

Clona primero el codigo:

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

Si WSL2 ya tiene un entorno CUDA utilizable, compila directamente:

1
2

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=89 es adecuado para GPU Ada, por ejemplo la serie RTX 40. En otras tarjetas debes ajustarlo segun la arquitectura real.

Si al compilar aparece que falta CUDA Toolkit, instalalo primero dentro de WSL2:

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

Despues configura variables de entorno:

export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
echo 'export PATH=/usr/local/cuda-12.8/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

Y compila de nuevo:

cd ~/llama.cpp
rm -rf build
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

Descargar el modelo Qwen3.6 GGUF

El ejemplo original usa Qwen3.6-27B-UD-Q4_K_XL.gguf de unsloth/Qwen3.6-27B-GGUF:

1
2
3

hf download unsloth/Qwen3.6-27B-GGUF \
Qwen3.6-27B-UD-Q4_K_XL.gguf \
--local-dir ~/models/

El archivo ronda los 17GB. Si Hugging Face descarga lento, puedes cambiar a espejos como ModelScope. Si no tienes suficiente VRAM, no fuerces 27B; usa un modelo mas pequeno o una cuantizacion mas baja.

Iniciar el servicio local del modelo

Arranca llama-server segun el nombre real de tu archivo de modelo:

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080

Tras iniciar correctamente, abre en el navegador de Windows:

`1`	`http://localhost:8080`

Para que Hermes Agent u otros clientes compatibles con OpenAI lo llamen, la direccion de API suele ser:

`1`	`http://localhost:8080/v1`

Elegir Thinking mode

Qwen3.6 puede activar Thinking mode por defecto. Es util para razonamiento complejo, problemas de codigo complicados y analisis de varios pasos, pero sera mas lento.

Si quieres desactivarlo, detén el servicio y agrega --chat-template-kwargs:

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--chat-template-kwargs '{"enable_thinking":false}' \
--port 8080

Sin Thinking, las preguntas simples, escritura, autocompletado de codigo y explicacion de codigo iran mas rapido; para algoritmos complejos, Debug dificil y analisis de arquitectura, sigue siendo recomendable activarlo.

Instalar Hermes Agent

Mantén llama-server en ejecucion y abre otra terminal WSL2 para instalar Hermes Agent:

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

El script instala dependencias como Python, Node.js, ripgrep y ffmpeg. Al configurar el endpoint del modelo, elige endpoint personalizado:

1
2
3

URL: http://localhost:8080/v1
API Key: 12345678
Model: autodetect

Para el llama-server local, la API Key puede ser cualquier valor de relleno. Tras configurarlo, puedes conectar Telegram, WeChat, QQ, Discord y otros canales para que Hermes Agent use el modelo local y ejecute tareas.

Arrancar automaticamente el servicio del modelo

Puedes escribir un script para iniciar el servicio al abrir la terminal WSL2.

Crea el script:

cat > ~/start-llm.sh << 'EOF'
#!/bin/bash
echo "Starting Qwen3.6-27B llama-server..."
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 65536 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080 \
--host 0.0.0.0 &
echo "llama-server started, PID: $!"
echo "API: http://localhost:8080/v1"
echo "Chat UI: http://localhost:8080"
EOF
chmod +x ~/start-llm.sh

Escribe en .bashrc:

echo '# Auto-start llama-server' >> ~/.bashrc
echo 'if ! pgrep -f "llama-server" > /dev/null 2>&1; then' >> ~/.bashrc
echo '    ~/start-llm.sh' >> ~/.bashrc
echo 'fi' >> ~/.bashrc

Asi, cada vez que abras WSL2, si llama-server no esta en ejecucion se iniciara automaticamente; si ya esta corriendo, se omitira para evitar duplicados.

Notas

El modelo 27B exige bastante VRAM; 24GB va mas estable. Con menos VRAM, usa un modelo mas pequeno.
--ctx-size 65536 aumenta mucho la presion de VRAM y RAM. Si no es estable, baja primero a 32768 o menos.
CUDA Toolkit dentro de WSL2 y el driver de Windows deben estar correctos; si falta uno, la compilacion o ejecucion CUDA puede fallar.
Cuando Hermes Agent se conecta al servicio local, en esencia llama a una API compatible con OpenAI. Lo clave es que http://localhost:8080/v1 responda bien.
Si quieres acceder desde el telefono u otros dispositivos, debes configurar firewall de Windows, direccion LAN y aislamiento de seguridad. No expongas el servicio local directamente a Internet.

Enlaces relacionados

Original: Hermes + Qwen3.6：本地最强 Agent 组合！零成本、无限 Token，太香了！
llama.cpp: ggerganov/llama.cpp
Hermes Agent: NousResearch/hermes-agent
Ejemplo Qwen3.6 GGUF: unsloth/Qwen3.6-27B-GGUF

¿Dónde guarda llama-cli -hf los modelos de caras abrazadas de forma predeterminada?

Fri, 17 Apr 2026 14:48:04 +0800

Si usa llama-cli para descargar y ejecutar un modelo directamente desde Hugging Face, por ejemplo:

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

esto utiliza el soporte de descarga de Hugging Face integrado en llama.cpp. Las compilaciones recientes de llama.cpp almacenan modelos descargados con -hf en el directorio de caché estándar de Hugging Face Hub.

Ubicaciones de caché predeterminadas

La ubicación del caché utilizada por llama-cli -hf se controla primero mediante la variable de entorno LLAMA_CACHE. Si LLAMA_CACHE no está configurado, llama.cpp verifica las variables de caché de Hugging Face como HF_HUB_CACHE, HUGGINGFACE_HUB_CACHE y HF_HOME.

Si no se establece ninguna de esas variables, las rutas predeterminadas comunes son:

Sistema	Directorio de caché predeterminado
Linux	`~/.cache/huggingface/hub`
MacOS	`~/.cache/huggingface/hub`
Ventanas	`%PERFIL DE USUARIO%\.cache\huggingface\hub`

En Windows, %USERPROFILE% normalmente se expande a:

`1`	`C:\Users\用户名`

Entonces el directorio de caché predeterminado es aproximadamente:

`1`	`C:\Users\用户名\.cache\huggingface\hub`

Cómo cambiar el directorio de caché llama-cli

Configure LLAMA_CACHE si desea almacenar los modelos descargados en un disco específico o en una carpeta específica. También puedes seguir la convención de Hugging Face y configurar HF_HOME; en ese caso, el directorio de caché del concentrador será $HF_HOME/hub.

Ejemplo de CMD temporal de Windows:

1
2

set LLAMA_CACHE=D:\models\llama-cache
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

Ejemplo de PowerShell temporal:

1
2

$env:LLAMA_CACHE="D:\models\llama-cache"
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

Ejemplo temporal de Linux/macOS:

1
2

export LLAMA_CACHE=/data/models/llama-cache
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

Resumen

llama-cli -hf ... usa la lógica de descarga de llama.cpp, pero las compilaciones recientes utilizan de forma predeterminada el caché de Hugging Face Hub.
Valor predeterminado de Linux/macOS: ~/.cache/huggingface/hub
Valor predeterminado de Windows: %USERPROFILE%\.cache\huggingface\hub
Para cambiar la ubicación, configure LLAMA_CACHE o configure HF_HOME / HF_HUB_CACHE

Cómo reparar el error de verificación del certificado SSL cuando llama-cli se descarga desde Hugging Face en Windows

Fri, 17 Apr 2026 14:20:29 +0800

Si ejecuta este comando en Windows:

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

y veo un error como este:

1
2

get_repo_commit: error: HTTPLIB failed: SSL server verification failed
error: failed to download model from Hugging Face

Por lo general, el problema no es CUDA ni llama.cpp. Más a menudo, el programa no puede acceder correctamente a la cadena de certificados del sistema en el entorno actual, por lo que falla la verificación HTTPS.

Desde el registro, ggml-rpc.dll y ggml-cpu-alderlake.dll se cargaron correctamente, lo que significa que el entorno de ejecución está prácticamente bien. El problema está principalmente en el paso de descarga del modelo.

La solución más sencilla: descargar el modelo manualmente

Si sólo desea que funcione rápidamente, descargar el modelo manualmente suele ser la opción más estable.

Abra la página del repositorio de Hugging Face correspondiente.
Descargue el archivo .gguf requerido desde Archivos y versiones.
Una vez finalizada la descarga, ejecútela con la ruta del archivo local:

`1`	`llama-cli -m C:\Users\knightli\Downloads\gemma-4-e4b-it.gguf`

Esto omite la verificación SSL durante el paso de descarga -hf y es útil cuando solo desea verificar que el modelo se puede ejecutar localmente.

Si aún deseas utilizar la descarga automática `-hf`

Puede especificar manualmente una ruta de archivo de certificado para que el programa pueda encontrar un paquete de CA utilizable en la sesión actual.

cacert.pem se puede obtener de la página de extracto de CA mantenida por el proyecto curl:

Página: https://curl.se/docs/caextract.html
Descarga directa: https://curl.se/ca/cacert.pem

Si lo descarga en un navegador, abra el enlace de descarga directa y guárdelo como cacert.pem. También puedes descargarlo a un directorio fijo con PowerShell:

1
2

New-Item -ItemType Directory -Force C:\certs
Invoke-WebRequest -Uri https://curl.se/ca/cacert.pem -OutFile C:\certs\cacert.pem

Una vez finalizada la descarga, configure estas variables en la línea de comando:

1
2

set SSL_CERT_FILE=C:\certs\cacert.pem
set CURL_CA_BUNDLE=C:\certs\cacert.pem

Luego ejecute el comando original nuevamente:

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

Si el problema realmente proviene de la cadena de certificados, esto generalmente lo soluciona directamente.

Llama.cpp on KnightLi Blog

Cómo medir el rendimiento multi-GPU en llama.cpp: ¿2x V100 16GB son más rápidas que una sola GPU de 32GB?

Primero, separa los split mode

Si una GPU de 32GB puede cargar el modelo, dos de 16GB no siempre son más rápidas

Si una GPU de 16GB no puede cargar el modelo, dos tarjetas sí aportan mucho

V100 PCIe y V100 SXM2 son muy diferentes

Cómo elegir de forma práctica

Cuándo comprar 2x16GB y cuándo comprar 1x32GB

Consejos prácticos para layer split y tensor split

Por qué prefill y decode se comportan distinto

¿Puede KV cache convertirse en el segundo cuello de botella de VRAM?

Cómo medir tus dos tarjetas con llama-bench

Conclusión en una frase

Modelos LLM locales recomendados para una GPU RTX 3060

Primero mira el límite de VRAM

Recomendación 1: Qwen3 8B

Recomendación 2: Llama 3.1 8B Instruct

Recomendación 3: Gemma 3 12B

Recomendación 4: DeepSeek R1 Distill Qwen 8B

Recomendación 5: Phi / MiniCPM / modelos pequeños

Cómo elegir cuantización

Qué herramienta usar

No abras demasiado el contexto

Elegir según uso

Expectativas razonables

Resumen

Referencias

Hermes + Qwen3.6: una solucion barata para desplegar un Agent local

Estructura de la solucion

Instalar WSL2 y Ubuntu

Instalar Python y herramientas basicas

Compilar llama.cpp

Descargar el modelo Qwen3.6 GGUF

Iniciar el servicio local del modelo

Elegir Thinking mode

Instalar Hermes Agent

Arrancar automaticamente el servicio del modelo

Notas

Enlaces relacionados

¿Dónde guarda llama-cli -hf los modelos de caras abrazadas de forma predeterminada?

Ubicaciones de caché predeterminadas

Cómo cambiar el directorio de caché llama-cli

Resumen

Cómo reparar el error de verificación del certificado SSL cuando llama-cli se descarga desde Hugging Face en Windows

La solución más sencilla: descargar el modelo manualmente

Si aún deseas utilizar la descarga automática -hf

Si aún deseas utilizar la descarga automática `-hf`