Llama.cpp on KnightLi Blog

Actualización llama.cpp b9196: los binarios precompilados para Windows soportan CUDA 13.1, Vulkan, HIP y SYCL

Mon, 18 May 2026 23:20:00 +0800

La versión reciente de llama.cpp para Windows es más amigable para usuarios de LLM locales. Antes, ejecutar modelos GGUF en Windows solía atascarse por problemas de entorno: versiones de CUDA incompatibles, DLL faltantes, drivers no compatibles, fallos de compilación con CMake, variables de entorno incorrectas o configuración complicada de Vulkan / HIP / SYCL.

Ahora la página oficial de Release ofrece varios paquetes precompilados para Windows. En muchos casos ya no hace falta compilar desde código fuente. Descargas la versión correcta, la descomprimes, colocas el archivo del modelo y puedes arrancar directamente un servicio local de inferencia.

Para qué sirve llama.cpp

llama.cpp es uno de los frameworks más usados para inferencia local con modelos GGUF. Es ligero, multiplataforma, puede usar CPU o GPU, y alrededor de GGUF ya existe un ecosistema amplio de modelos.

Familias de modelos comunes:

Qwen
Llama
DeepSeek
Gemma
Mistral
Mixtral
Hermes

A medida que los modelos cuantizados en GGUF se popularizan, muchos modelos open source publican versiones GGUF aptas para despliegue local. Para usuarios normales, el valor de llama.cpp está en que no necesitas montar un stack de inferencia complejo para correr un servicio de chat usable en tu propia máquina.

Cómo elegir una versión precompilada para Windows

Los usuarios de Windows pueden elegir distintos builds según su hardware:

Windows x64 CPU
Windows x64 CUDA 12.4
Windows x64 CUDA 13.1
Windows x64 Vulkan
Windows x64 HIP Radeon
Windows x64 SYCL
Windows ARM64 CPU

Si usas una GPU NVIDIA, normalmente conviene priorizar la versión CUDA. Tarjetas como RTX 3060, 4060, 4070, 4080 y 4090 encajan mejor con la ruta CUDA.

Si usas una GPU AMD, puedes probar HIP o Vulkan. En la práctica, Vulkan a veces resulta más sencillo que HIP, sobre todo si no quieres montar un entorno ROCm completo.

Si usas gráficos integrados Intel o una GPU Arc, puedes probar SYCL o Vulkan. El rendimiento suele quedar por detrás de NVIDIA CUDA, pero ya basta para probar muchos modelos GGUF pequeños y medianos.

La versión CPU sirve para usuarios sin GPU dedicada o para quienes solo quieren verificar un modelo o correr modelos pequeños. No será rápida, pero es la ruta más simple.

Arrancar un modelo GGUF normal

Supongamos que ya descargaste el paquete precompilado de llama.cpp para Windows y colocaste el modelo en el directorio models. Entra en la carpeta descomprimida de llama.cpp y ejecuta:

`1`	`llama-server.exe -m models\your-model.gguf -ngl 999`

Aquí -m apunta al archivo GGUF, y -ngl 999 intenta cargar la mayor cantidad posible de capas en la GPU. Cuántas se cargan realmente depende de la VRAM, el tamaño del modelo y el formato de cuantización.

Cuando arranque correctamente, abre en el navegador:

`1`	`http://127.0.0.1:8080`

Entrarás en la interfaz web local de chat.

Si la VRAM no alcanza, cambia a un modelo más pequeño o a una cuantización más baja, como archivos GGUF Q4 o Q5. No mires solo el número de parámetros; revisa también el formato de cuantización y la longitud de contexto.

Arrancar un modelo visual multimodal

Los modelos visuales multimodales normalmente necesitan algo más que el archivo principal. También necesitan un archivo de proyección visual mmproj. Al arrancar, especifica ambos:

`1`	`llama-server.exe -m "models\main-model.gguf" --mmproj "models\mmproj-model.gguf" -ngl 999`

Usos comunes:

Reconocimiento OCR
Comprensión de capturas de pantalla
Análisis de capturas de páginas web
Preguntas y respuestas sobre imágenes
Juicio simple de contenido visual

Por ejemplo, modelos como Qwen2-VL / Qwen2.5-VL son útiles para entender capturas en chino, OCR y preguntas sobre imágenes. Asegúrate de que el modelo principal y el archivo mmproj correspondan entre sí; una versión no compatible puede causar fallos de carga o resultados extraños.

Gestionar varios modelos con un script bat

Si tienes varios modelos locales, puedes escribir un .bat sencillo para alternarlos con un menú. Este ejemplo requiere cambiar ruta y nombres de modelos por los tuyos:

@echo off
chcp 65001 >nul
cd /d C:\path\to\llama-b9196-bin-win-cuda-13.1-x64

echo 请选择模型：
echo 1. Gemma
echo 2. Qwen VL 多模态
echo 3. DeepSeek

set /p choice=输入数字：

if "%choice%"=="1" llama-server.exe -m "models\gemma.gguf" -ngl 999
if "%choice%"=="2" llama-server.exe -m "models\qwen-vl.gguf" --mmproj "models\mmproj.gguf" -ngl 999
if "%choice%"=="3" llama-server.exe -m "models\deepseek.gguf" -ngl 999

pause

Guárdalo en UTF-8 y luego cambia la extensión a .bat. Al hacer doble clic, podrás elegir distintos modelos por número.

Tres cosas que mirar al elegir modelos

Primero, el hardware. Cuanta más VRAM tengas, modelos más grandes podrás correr. Si la VRAM es limitada, no fuerces un modelo grande; empieza con 7B, 8B o una cuantización más baja.

Segundo, el uso. Para preguntas diarias, resúmenes y reescritura, un modelo pequeño o una cuantización media suele bastar. Para código, análisis de documentos largos o comprensión multimodal, necesitas modelos más fuertes y más VRAM.

Tercero, licencias y límites de seguridad. En internet hay muchos modelos modificados por la comunidad, con capacidades, restricciones y licencias distintas. Antes de descargar, confirma origen, licencia, escenario de uso y riesgos. No conviene entregar tareas de producción directamente a modelos de origen poco claro.

Problemas comunes

Si al arrancar aparece un error de DLL faltante, primero confirma que el paquete descargado corresponde a tu ruta de GPU. Los usuarios de NVIDIA no deberían descargar por error la versión HIP, y los usuarios de AMD no deberían descargar la versión CUDA.

Si el modelo carga muy lento, puede ser demasiado grande, el disco puede ser lento, o parte de las capas puede estar cayendo a CPU por falta de VRAM.

Si la página web no abre, revisa primero si el servicio arrancó correctamente en la consola y confirma que el puerto sea 8080. Si el puerto está ocupado, consulta los parámetros de llama-server para cambiarlo.

Si un modelo multimodal da resultados raros, revisa primero si el archivo mmproj corresponde al modelo principal, antes de limitarte a cambiar prompts.

Resumen

El valor de estos paquetes precompilados para Windows está en bajar la barrera de entrada a la IA local. Antes muchos usuarios se quedaban atrapados en compilación y dependencias; ahora pueden llegar más rápido a descargar modelos, arrancar un servicio y probar resultados.

Para usuarios de Windows, la ruta puede resumirse así:

NVIDIA: prioriza CUDA.
AMD: prueba primero Vulkan, luego HIP.
Intel: prueba SYCL o Vulkan.
Sin GPU dedicada: usa la versión CPU para modelos pequeños.

Antes de usarlo en serio, confirma origen del modelo, licencia, requisitos de VRAM y resultados reales. La IA local ofrece control, uso offline y baja latencia, pero no significa coste cero: gestión de modelos, recursos de hardware y calidad de salida siguen siendo responsabilidad tuya.

Fuente: https://www.freedidi.com/24211.html

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

Cómo ajustar llama.cpp con 8GB de VRAM: por qué 32K es más seguro y 64K necesita cuantización de KV Cache

Thu, 23 Apr 2026 12:13:04 +0800

Si 8GB de VRAM bastan para ejecutar LLMs locales con fluidez, especialmente con contextos largos, es una de las preguntas más comunes al usar llama.cpp.

Tres conclusiones clave:

Con 8GB de VRAM, contexto 32K suele ser el equilibrio más seguro
Si realmente quieres 64K, la cuantización de KV Cache suele ser esencial
En inferencia full-GPU, subir a ciegas el número de hilos CPU puede empeorar el rendimiento

1. Qué significan 32K, 64K y KV Cache

32K y 64K se refieren a longitud de contexto, es decir, cuántos tokens puede procesar el modelo a la vez. K significa miles: 32K son unos 32000 tokens, y 64K unos 64000 tokens. Cuanto más largo el contexto, más contenido previo puede ver el modelo.

KV Cache es una caché de resultados intermedios que el modelo mantiene para acelerar la generación autoregresiva. Una vez que el modelo leyó parte del contexto, no necesita recalcular todo desde cero cada vez. Guarda información intermedia y la reutiliza. K y V vienen de Key y Value en Transformers.

Estos términos aparecen juntos porque:

32K y 64K definen cuánto contenido quieres recordar
KV Cache determina cuánta VRAM extra hace falta para mantener esa memoria
cuanto más largo el contexto, más grande suele ser la KV Cache

Cuando la inferencia de contexto largo se ralentiza, el problema raíz suele ser que la caché creció hasta presionar el límite de VRAM.

2. Por qué 32K y 64K se comportan tan distinto

Usando unas 30000 letras chinas de The Three-Body Problem como stress test, la comparación entre 32K y 64K puede verse dramática: con tamaño de documento similar, 64K puede volverse mucho más lento.

La razón no es que el modelo empeore de repente. El problema real es tocar el límite de VRAM.

En 32K, pesos del modelo más caché quizá aún caben en 8GB, así que la mayoría del tráfico se queda en la memoria de la GPU. Al pasar a 64K, la caché crece, el uso total se acerca o supera el techo de VRAM, y parte de los datos se empuja a memoria compartida o del sistema.

En ese punto no colapsa el cómputo bruto, sino el ancho de banda.

Lo que parece “el contexto se duplicó y el rendimiento se hundió” suele ser que la ruta de datos salió de VRAM hacia memoria mucho más lenta.

3. Para 64K, la cuantización de KV Cache importa mucho

Para usuarios de 8GB de VRAM, una conclusión importante es que cuantizar KV Cache importa muchísimo.

Sin cambiar el modelo, cuantizar solo la caché reduce directamente el uso de memoria en contexto largo. Eso permite que parte de los datos que antes salían de VRAM vuelvan a caber. 64K seguirá siendo más pesado que 32K, pero es menos probable que caiga en la zona más lenta.

En simple:

32K es el rango predeterminado más práctico para 8GB
64K no es imposible
pero sin cuantización de caché, puede pasar de usable a difícil de usar

Prioridad habitual:

Revisar si la VRAM ya está cerca del techo
Decidir si activar cuantización de KV Cache
Solo después experimentar con ajustes de throughput

4. Baja utilización GPU no significa que esté inactiva

Este punto rompe la intuición.

Cuando Task Manager muestra 20% o 30% de GPU, mucha gente asume:

los parámetros están mal
el modelo no corre realmente en GPU
la GPU no se usa completa

Pero en inferencia llama.cpp, lo más probable es que el cuello de botella no sea cómputo del core, sino lecturas y escrituras de memoria.

Los cores GPU pueden terminar rápido un lote de cálculo y pasar el resto del tiempo esperando el siguiente lote de pesos o datos cacheados.

Por eso:

la utilización de cores no parece alta
pero la velocidad end-to-end no mejora

No es una GPU perezosa. Es una ruta de datos estrecha.

5. Aumentar parámetros de throughput ayuda solo si la VRAM aguanta

Si los cores GPU no están saturados, aumentar parámetros relacionados con throughput puede hacer que la GPU procese más datos a la vez y use mejor el paralelismo.

Puede mejorar velocidad, pero con una condición: debe quedar margen de VRAM.

Si ya estás en 64K, con una caché grande y VRAM casi agotada, subir esos parámetros puede terminar en:

crash
fallback a memoria compartida mucho más lenta

La secuencia más segura:

proteger primero el límite de VRAM
luego probar optimizaciones de throughput
tras cada cambio, revisar velocidad y estabilidad

6. Más hilos CPU no siempre son mejores

Es una trampa fácil.

Parece natural pensar que más hilos dan más velocidad. Pero si el modelo ya corre casi todo en GPU, forzar más hilos CPU puede empeorar claramente el rendimiento.

En inferencia full-GPU, la CPU es más scheduler y ayudante de preprocesamiento que motor principal. Demasiados hilos aumentan contención, overhead de scheduling y cambios de contexto, interrumpiendo el flujo de datos.

Resultado:

la CPU parece más ocupada
la velocidad general baja

En este setup, valores predeterminados o hilos más bajos suelen ser más fiables que maximizar todo.

7. Enfoque práctico para 8GB de VRAM

1. Trata 32K como objetivo predeterminado

Con una GPU de 8GB, no persigas 64K de inmediato. 32K suele equilibrar mejor velocidad, estabilidad y memoria.

2. Si quieres 64K, resuelve primero la caché

Confirma si KV Cache está cuantizada y si la VRAM ya está al límite.

3. No juzgues todo por utilización GPU

Baja utilización no implica ajustes incorrectos. Puede indicar que el cuello de botella es memoria.

4. Optimiza throughput sin cruzar el límite de VRAM

Estos parámetros pueden ayudar, pero solo con margen suficiente.

5. Sé conservador con hilos CPU

Si el modelo corre principalmente en GPU, más hilos CPU no son automáticamente mejores.

Conclusión

El valor de esta discusión no son solo números de benchmark, sino una verdad fácil de olvidar:

ajustar LLMs locales no consiste en poner cada valor al máximo. Consiste en entender si tu cuello de botella real es cómputo, capacidad de VRAM, ancho de banda de memoria o scheduling de CPU.

Para usuarios de 8GB, la estrategia más segura suele ser proteger primero el límite de VRAM y solo entonces decidir cuánto más empujar.

Si recuerdas una frase:

32K suele ser el rango de trabajo más estable para 8GB de VRAM; 64K es posible, pero solo si ya controlaste KV Cache y uso de VRAM.

Ranking de rendimiento GPU en llama.cpp: cómo leer los scoreboards CUDA, ROCm y Vulkan con pp512 / tg128 / FA

Thu, 23 Apr 2026 10:22:04 +0800

Los scoreboards de llama.cpp son muy útiles, pero también son fáciles de malinterpretar si solo miras una cifra. En esas tablas suelen aparecer CUDA, ROCm, Vulkan, Q4_0, pp512, tg128, FA y t/s, y cada uno describe una dimensión diferente del benchmark.

Este artículo resume cómo leer esas tablas y qué conclusiones prácticas conviene sacar antes de comparar GPUs.

Entender primero las métricas

Qué es Q4_0

Q4_0 es un formato de cuantización de 4 bits. No significa que el modelo sea más fuerte. Significa que el modelo es más pequeño, usa menos VRAM y cabe en más dispositivos.

La mayoría de estos scoreboards estandarizan sobre Llama 2 7B, Q4_0 para que la comparación entre GPUs sea más sencilla.

Qué es pp512

pp512 suele significar prompt processing 512 tokens, es decir, el throughput al procesar 512 tokens de entrada.

pp = prompt processing
512 = la entrada tiene 512 tokens
t/s = tokens por segundo

Esto se acerca más a la velocidad de ingestión del prompt, por eso suele ser mucho más alto que la velocidad de generación.

Qué es tg128

tg128 suele significar text generation 128 tokens, es decir, la velocidad al generar 128 tokens de forma continua.

tg = text generation
128 = generar 128 tokens seguidos
t/s = tokens por segundo

Esta métrica suele estar más cerca de la velocidad que el usuario percibe en uso interactivo.

Qué es FA

FA significa Flash Attention.

with FA significa que Flash Attention está activado
no FA significa que Flash Attention está desactivado

En muchas GPUs, FA mejora pp512 con más claridad que tg128, pero la ganancia no es idéntica entre backends, drivers y arquitecturas GPU.

Cómo leer t/s

t/s significa tokens per second. La regla clave es comparar el mismo tipo de prueba con los mismos ajustes.

No compares pp512 y tg128 como si fueran lo mismo.
No mezcles resultados no FA con with FA.
No asumas que CUDA, ROCm y Vulkan son directamente intercambiables.

Conclusiones rápidas

CUDA sigue siendo la ruta más fuerte en conjunto para benchmarks GPU de llama.cpp, especialmente en GPUs Nvidia de gama alta.
ROCm ya ofrece resultados fuertes en GPUs AMD de gama alta y aceleradores Instinct.
Vulkan tiene la cobertura de hardware más amplia, incluyendo Nvidia, AMD, Intel, GPUs antiguas y algunos setups Apple / Asahi.
tg128 se acerca más a la velocidad percibida en uso diario, mientras pp512 es mejor para juzgar throughput de prompt.

Cómo usar las tablas

1. Decide si te importa más tg128 o pp512

Para chat y uso interactivo, tg128 suele importar más. Para prompts largos, batch processing o workloads de ingestión, pp512 pesa más.

2. Compara el backend que realmente usas

Usuarios Nvidia deberían priorizar CUDA. Usuarios AMD deberían comparar primero ROCm y Vulkan. Si necesitas compatibilidad amplia o hardware mixto, presta atención a Vulkan.

3. Mira FA al final

En muchas GPUs, activar FA mejora más pp512 que tg128, así que una sola cifra destacada puede ser engañosa.

4. No compares generaciones solo por memoria

Una GPU con más VRAM no siempre gana en tg128. La generación token a token puede depender mucho de ancho de banda, caché, backend, kernel y optimizaciones del runtime.

5. Usa las tablas como orientación, no como garantía

Los scoreboards son aportes comunitarios. Pueden variar por commit, driver, sistema operativo, flags de compilación, versión de llama.cpp, temperatura y configuración de energía.

Qué muestran en general los scoreboards

En las tablas CUDA, las GPUs Nvidia modernas de gama alta, como RTX 5090, RTX PRO 6000 Blackwell, H100, A100, RTX 4090 y RTX 5080, ocupan los rangos superiores. El patrón general confirma que CUDA sigue siendo la ruta más madura para Nvidia.

En las tablas ROCm / HIP, aceleradores como MI300X y tarjetas AMD de gama alta como RX 7900 XTX muestran resultados fuertes. Esto confirma que ROCm ya es una ruta seria, aunque la experiencia puede depender mucho de soporte de driver y plataforma.

En las tablas Vulkan, el valor principal es la amplitud. Aparecen Nvidia, AMD, Intel, Apple vía MoltenVK / Asahi, GPUs antiguas y GPUs integradas. Vulkan no siempre es la ruta más rápida, pero suele ser la más flexible para comparar hardware diverso.

Resumen en una frase

En benchmarks de llama.cpp, pp512, tg128, Q4_0, FA y CUDA / ROCm / Vulkan describen dimensiones distintas. Cuando entiendes el contexto del benchmark, las tablas se vuelven mucho más fáciles de leer.

Fuentes

CUDA discussion #15013: https://github.com/ggml-org/llama.cpp/discussions/15013
Apple Silicon discussion #4167: https://github.com/ggml-org/llama.cpp/discussions/4167
ROCm discussion #15021: https://github.com/ggml-org/llama.cpp/discussions/15021
Vulkan discussion #10879: https://github.com/ggml-org/llama.cpp/discussions/10879

Qué significan realmente las métricas comunes de benchmark GPU: FA, pp512, tg128 y Q4_0

Thu, 23 Apr 2026 00:15:00 +0800

En cuanto empiezas a mirar benchmarks de LLM locales o inferencia GPU, aparece una pila de abreviaturas: FA, pp512, tg128 y Q4_0. Todas parecen métricas de rendimiento, pero sin contexto pueden ser sorprendentemente difíciles de interpretar.

Por ejemplo, puedes ver una línea como:

`1`	`CUDA Scoreboard for Llama 2 7B, Q4_0 (no FA)`

Y justo debajo:

1
2

pp512 t/s
tg128 t/s

Si no desarmas estos términos, cuesta entender qué mide realmente el benchmark o cómo comparar los resultados de dos GPUs distintas.

Este artículo no trata sobre qué GPU conviene comprar. Trata específicamente de explicar las métricas más comunes que aparecen en benchmarks de inferencia GPU.

Primero, qué dice realmente la línea del título

Una línea como CUDA Scoreboard for Llama 2 7B, Q4_0 (no FA) ya te cuenta casi todo el setup de prueba.

Como mínimo, contiene cuatro capas de información:

CUDA: el benchmark corre por la ruta NVIDIA CUDA
Llama 2 7B: el modelo probado es la versión 7B de Llama 2
Q4_0: el modelo usa un formato cuantizado de 4 bits
no FA: Flash Attention estuvo desactivado en esta prueba

En términos prácticos, este título suele significar:

“Un benchmark de un modelo grande cuantizado corriendo en una GPU NVIDIA, medido bajo una ruta de inferencia concreta.”

Qué significa FA: Flash Attention

Aquí, FA significa Flash Attention.

Es una de las técnicas de aceleración más importantes en entrenamiento e inferencia de modelos grandes, principalmente porque optimiza cómo se calcula la atención. En modelos Transformer, la atención ya es una de las partes más caras y más intensivas en ancho de banda de memoria.

Una implementación tradicional de atención suele sufrir:

lecturas y escrituras frecuentes de memoria
muchos resultados intermedios
movimiento repetido entre VRAM y caché on-chip
overhead que crece rápido al aumentar el contexto

Lo que hace Flash Attention, en términos simples, es:

reorganizar el orden de cálculo
reducir cuántas veces los resultados intermedios vuelven a VRAM
mantener más trabajo dentro de caché rápida

Eso le da tres ventajas típicas:

es más rápida
ahorra memoria
es matemáticamente equivalente a la atención estándar, no un atajo de menor precisión

Por eso muchos frameworks modernos de inferencia y entrenamiento la tratan como una optimización clave.

Qué significa no FA

Si FA significa Flash Attention, no FA simplemente significa que no se activó Flash Attention para esa prueba.

Es decir, el benchmark se midió usando una implementación de atención más tradicional.

Las tablas suelen marcar explícitamente no FA por varias razones:

mantener una línea base de comparación
soportar hardware o software donde FA no está disponible
evitar mezclar resultados de condiciones de optimización distintas

Así que cuando veas no FA, no lo leas como “esta GPU es débil”. Una lectura más precisa es:

“Esta puntuación se midió sin Flash Attention activado.”

Qué significa Q4_0: un formato de cuantización

Q4_0 se refiere a un formato de cuantización de 4 bits.

Los pesos del modelo original normalmente no se guardan con tan baja precisión. La cuantización comprime pesos de mayor precisión en una representación de menos bits para que el modelo sea más fácil de ejecutar en GPUs de consumo.

Una forma aproximada de pensarlo:

Q: Quantization
4: 4-bit
_0: identificador de un esquema concreto de cuantización

Su importancia práctica es directa:

menor tamaño de modelo
menos requisitos de VRAM
más probabilidad de caber en hardware de consumo

Así que Llama 2 7B, Q4_0 no significa solo “un modelo 7B normal”. Significa “un modelo 7B ya comprimido con un formato de cuantización de 4 bits.”

Qué significa pp512 t/s

pp512 suele significar:

Prompt Processing 512 tokens

Mide qué tan rápido el modelo procesa el prompt de entrada, normalmente en t/s, es decir, tokens per second.

Aquí, 512 significa que la longitud de prompt usada en la prueba fue de 512 tokens.

Esta métrica no mide velocidad de salida. Mide qué tan rápido el modelo codifica y calcula sobre la entrada antes de empezar a responder. Puedes pensarla como la velocidad de la etapa “leer primero el prompt”.

Una propiedad importante de esta etapa es que normalmente es mucho más paralelizable.

Como la secuencia de entrada puede procesarse en batches, la GPU puede mantener sus unidades de cómputo muy ocupadas. Por eso los números de pp512 pueden verse extremadamente altos.

Si ves algo como:

`1`	`pp512 ~= 14000 t/s`

no hay razón para preocuparse. Mide throughput de procesamiento de prompt, no velocidad de generación token por token.

Qué significa tg128 t/s

tg128 suele significar:

Text Generation 128 tokens

Mide la velocidad media de generar 128 tokens, también en t/s.

Esta métrica está mucho más cerca de lo que la gente quiere decir intuitivamente cuando pregunta si un modelo se siente rápido, porque mide directamente la etapa de salida.

La diferencia principal frente a pp512 es que la generación de texto suele ser autoregresiva.

Eso significa:

el modelo debe generar el primer token
luego usarlo para generar el segundo
y seguir así

Esta etapa no puede paralelizarse como el procesamiento de prompt, así que naturalmente es mucho más lenta.

Por eso es normal ver:

pp512 en decenas de miles de t/s
tg128 solo en cientos de t/s

No es un error de benchmark. Son workloads fundamentalmente distintos.

Por qué pp512 y tg128 difieren tanto

Esta suele ser la primera confusión al leer un scoreboard.

La explicación corta:

pp512 mide algo más cercano al throughput paralelo, mientras tg128 mide capacidad de generación token por token.

Más detalladamente:

la etapa de entrada es más fácil de paralelizar
la etapa de salida depende de generación secuencial
la generación suele ser más sensible a ancho de banda y caché
por eso la generación es mucho más lenta que el procesamiento de prompt

Esto también explica un patrón interesante:

una GPU puede ser más fuerte en pp512
otra puede terminar ligeramente más rápida en tg128

No es contradictorio. Una métrica se inclina más hacia throughput de cómputo pico; la otra refleja comportamiento de memoria y latencia en la ruta de generación.

Cómo pensar sobre t/s

Aquí, t/s significa tokens per second.

Indica cuántos tokens el modelo puede procesar o generar por segundo.

Pero hay una salvedad importante: un token no equivale exactamente a un carácter o una palabra. Es la unidad producida por el tokenizer del modelo, y su longitud real puede variar mucho entre modelos e idiomas.

En la práctica, t/s sirve sobre todo para:

comparar GPUs con el mismo modelo
comparar ajustes distintos en el mismo entorno
comparar un framework antes y después de activar una optimización concreta

Es mucho menos fiable como métrica absoluta universal entre modelos, frameworks y tokenizers distintos.

En qué fijarse primero al leer un scoreboard

Si no quieres enterrarte bajo abreviaturas, empieza por estas preguntas.

1. Qué modelo se está probando

¿Es Llama 2 7B? ¿Es la misma variante cuantizada, como Q4_0? Si cambia el modelo o el formato de cuantización, comparar directamente pierde sentido.

2. Si las optimizaciones clave están activadas

El ejemplo más común es FA. Si un benchmark usa Flash Attention y otro no, las puntuaciones no son directamente comparables.

3. Si la métrica mide entrada o salida

pp512 y tg128 miden etapas distintas. Una se acerca a velocidad de lectura de prompt; la otra a velocidad de generación de respuesta.

4. Si te importa throughput o sensación de uso

Si te importa procesar rápido un prompt largo, pp512 pesa más. Si te importa qué tan rápido se siente el modelo al responder, tg128 suele estar más cerca de la experiencia real.

Una forma práctica de recordarlo

Puedes resumirlo así:

Q4_0: el modelo está comprimido en una versión cuantizada de 4 bits
FA: si Flash Attention está activado
pp512: velocidad para procesar una entrada de 512 tokens
tg128: velocidad para generar una salida de 128 tokens
t/s: unidad de velocidad, tokens por segundo

Con esos cinco puntos claros, es mucho más fácil juzgar qué mide realmente un CUDA Scoreboard.

Cierre

Las tablas de benchmark GPU a menudo parecen más complicadas de lo que son, no porque las métricas sean misteriosas, sino porque identidad del modelo, cuantización, flags de optimización y etapas distintas de throughput se comprimen en abreviaturas cortas.

Cuando desarmas términos como FA, Q4_0, pp512 y tg128, estas tablas se vuelven mucho más legibles.

Lo importante no es recordar solo una puntuación, sino saber:

de qué configuración de modelo viene
si las optimizaciones clave estaban activadas
si midió entrada o salida
si refleja throughput de cómputo o algo más cercano a la sensación real de generación

Eso facilita juzgar qué significan realmente los resultados.

¿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.

Cómo usar llama-quantize para modelos GGUF

Sun, 12 Apr 2026 09:42:36 +0800

llama-quantize es la herramienta de cuantización de llama.cpp. Se usa para convertir modelos GGUF de alta precisión en versiones cuantizadas más pequeñas.

Su uso más común es convertir formatos como F32, BF16 o FP16 en versiones como Q4_K_M, Q5_K_M o Q8_0, que son más fáciles de ejecutar localmente. Después de la cuantización, los modelos suelen ser mucho más pequeños y a menudo más rápidos en inferencia, aunque se espera cierta pérdida de calidad.

Flujo básico

Un flujo típico consiste en preparar el modelo original, convertirlo a GGUF y luego ejecutar la cuantización.

# install Python dependencies
python3 -m pip install -r requirements.txt

# convert the model to ggml FP16 format
python3 convert_hf_to_gguf.py ./models/mymodel/

# quantize the model to 4-bits (using Q4_K_M method)
./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M

Después, puedes ejecutar el modelo cuantizado con llama-cli:

1
2

# start inference on a gguf model
./llama-cli -m ./models/mymodel/ggml-model-Q4_K_M.gguf -cnv -p "You are a helpful assistant"

Opciones comunes

--allow-requantize: permite volver a cuantizar un modelo ya cuantizado, algo que normalmente no es ideal para la calidad
--leave-output-tensor: deja la capa de salida sin cuantizar; aumenta el tamaño, pero a veces ayuda a la calidad
--pure: desactiva la cuantización mixta y usa un tipo de cuantización más uniforme
--imatrix: usa una matriz de importancia para mejorar la calidad de cuantización
--keep-split: conserva el diseño original por fragmentos en lugar de producir un único archivo combinado

Si solo quieres un punto de partida práctico, esto suele bastar:

`1`	`./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M`

Cómo elegir una cuantización

Puedes pensar en los niveles de cuantización como un compromiso entre tamaño, velocidad y calidad:

Q8_0: más grande, pero normalmente más seguro para la calidad
Q6_K / Q5_K_M: opciones equilibradas habituales
Q4_K_M: valor predeterminado muy común, con buen equilibrio entre tamaño y calidad
Q3 / Q2: útiles cuando el hardware es muy limitado, pero la pérdida de calidad es más visible

El objetivo práctico normalmente no es elegir la cuantización más grande que quepa, sino la que se ejecute de forma fiable en tu hardware manteniendo una calidad aceptable.

Conclusión práctica

empieza con Q4_K_M o Q5_K_M
sube a Q6_K o Q8_0 si la calidad importa más
baja a Q3 o Q2 si la memoria está ajustada
compara versiones con el mismo conjunto de prompts

En resumen, llama-quantize es útil porque hace que los modelos GGUF sean más fáciles de ejecutar en hardware local, no solo porque reduce el tamaño de los archivos.

Cómo obtener modelos GGUF desde Hugging Face con llama.cpp

Sun, 12 Apr 2026 09:31:38 +0800

llama.cpp puede trabajar directamente con modelos GGUF alojados en Hugging Face, así que no siempre necesitas descargar manualmente los archivos del modelo primero.

Si un repositorio de modelo ya ofrece archivos GGUF, puedes usar el argumento -hf en la CLI, por ejemplo:

`1`	`llama-cli -hf ggml-org/gemma-3-1b-it-GGUF`

De forma predeterminada, esto descarga desde Hugging Face.
Si usas otro servicio que expone una API compatible con Hugging Face, puedes cambiar el endpoint de descarga con la variable de entorno MODEL_ENDPOINT.

Un detalle importante es que llama.cpp solo puede usar directamente el formato GGUF.
Si tu modelo está en otro formato, primero necesitas convertirlo con los scripts convert_*.py incluidos en el repositorio.

Hugging Face también ofrece varias herramientas online relacionadas con llama.cpp, entre ellas:

convertir modelos a GGUF
cuantizar pesos para reducir tamaño
convertir adaptadores LoRA
editar metadatos GGUF en el navegador
alojar endpoints de inferencia llama.cpp

Si solo quieres la conclusión práctica, empieza por repositorios que ya ofrezcan GGUF y luego usa llama-cli -hf <user>/<model>. En la mayoría de casos, ese es el camino más simple.

Guía local de Gemma 4: de ejecutarlo con un comando a integrarlo en desarrollo

Fri, 10 Apr 2026 22:54:17 +0800

Si quieres ejecutar Gemma 4 en local, puedes elegir entre cuatro rutas prácticas según tu objetivo y tu hardware.

1) Inicio más rápido: Ollama (recomendado)

Es la opción con menos fricción para pruebas rápidas, chat diario y uso de API local.

`1`	`ollama run gemma4`

Puntos clave:

Funciona en Windows, macOS y Linux
Gestiona automáticamente la aceleración por hardware
Ofrece una API local compatible con el estilo de OpenAI

2) Flujo con interfaz gráfica: LM Studio / Unsloth Studio

Si prefieres una UI de escritorio en lugar de comandos de terminal:

LM Studio: permite buscar y ejecutar variantes cuantizadas de Gemma 4 desde Hugging Face, por ejemplo 4-bit u 8-bit, con visibilidad del uso de recursos.
Unsloth Studio: soporta inferencia y fine-tuning con poca VRAM, a menudo más cómodo para GPUs de 6GB-8GB.

3) Equipos modestos y máximo control: llama.cpp

Buena opción para hardware antiguo, escenarios centrados en CPU o usuarios que quieren controlar más parámetros de inferencia.

Con archivos de modelo .gguf y cuantización, Gemma 4 puede funcionar con presupuestos de hardware mucho más bajos.

4) Integración de desarrollo: Transformers / vLLM

Si necesitas integrar Gemma 4 en tu propia aplicación:

Transformers: integración directa en proyectos Python
vLLM: inferencia de alto rendimiento para entornos GPU más potentes

Selección rápida

Necesidad	Herramientas recomendadas	Requisito de hardware
Solo quiero ejecutarlo ya	Ollama	Bajo
Prefiero una interfaz tipo ChatGPT	LM Studio	Medio
Tengo VRAM limitada (6GB-8GB)	Unsloth / llama.cpp	Bajo
Estoy creando aplicaciones locales de AI	Ollama / Transformers / vLLM	Medio a alto
Necesito fine-tuning	Unsloth Studio	Medio a alto

Sugerencia de tamaño de modelo

Gemma 4 llega en varios tamaños, por ejemplo E2B, E4B y 31B.

En portátiles comunes, empieza por E2B/E4B cuantizados
Prueba variantes más grandes solo cuando tu flujo base ya sea estable