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:

V100 on KnightLi Blog