CUDA on KnightLi Blog

Actualizaciones de hardware y GPU Ubuntu 26.04 LTS: CUDA, ROCm, DPC++ y más cambios de plataforma

Sun, 26 Apr 2026 19:35:57 +0800

Si el artículo anterior funcionó como una descripción general centrada en el escritorio de Ubuntu 26.04 LTS, es mejor leer este como su seguimiento del hardware y la computación. En este ciclo 26.04, Ubuntu impulsó una serie de cambios en IA, computación GPU y compatibilidad de plataforma en el archivo principal o alcance de soporte formal.

La versión corta es esta: la parte más importante de esta ronda no son solo las actualizaciones de escritorio y kernel, sino que Ubuntu está incorporando pilas de computación de GPU Intel, NVIDIA y AMD a la distribución de una manera más sistemática.

1. Intel DPC++ y componentes relacionados ahora están en Ubuntu Archive

A partir de 26.04, el compilador de código abierto oneAPI DPC++ de Intel está disponible directamente desde Ubuntu Archive para crear código SYCL. Su tiempo de ejecución también incluye adaptadores para GPU Intel.

Ahora también están disponibles dos componentes relacionados en los repositorios de Ubuntu:

oneDPL, la biblioteca DPC++, que proporciona API de desarrollador de mayor productividad
oneDNN, creado con dpclang-6, que puede ejecutarse en GPU Intel

Eso significa que si ya está trabajando con SYCL, computación heterogénea o cargas de trabajo de IA en GPU Intel, Ubuntu ahora ofrece una ruta más directa en lugar de obligarlo a mantener una pila externa separada para todo.

Ubuntu también señala un requisito práctico: los usuarios deben estar en el grupo “renderizar” para utilizar realmente estas capacidades relacionadas con la GPU Intel.

2. El kit de herramientas NVIDIA CUDA ahora se puede instalar directamente con `apt`

Para muchos desarrolladores y operadores, este puede ser uno de los cambios más útiles de inmediato en las notas.

A partir de 26.04, el kit de herramientas NVIDIA CUDA ahora se puede instalar directamente desde Ubuntu Archive:

`1`	`sudo apt install cuda-toolkit`

El valor aquí es mayor que simplemente guardar algunos pasos de configuración.

Para los desarrolladores que envían software en Ubuntu, este nuevo modelo significa que pueden simplemente declarar una dependencia del “tiempo de ejecución CUDA”, mientras que Ubuntu gestiona la instalación y la compatibilidad a nivel de distribución. Eso hace que CUDA se sienta más como una capacidad nativa del sistema en Ubuntu, en lugar de una capa de software adicional que siempre debe mantenerse por separado.

3. AMD ROCm 7.1.0 ya está en Universe

Por el lado de AMD, Ubuntu Universe ahora incluye ROCm 7.1.0.

Estas bibliotecas proporcionan principalmente:

infraestructura backend para entrenamiento e inferencia de IA en GPU AMD
fundamentos de software para el aprendizaje automático y la informática de alto rendimiento

Canonical también señala que los componentes relacionados con ROCm se prueban continuamente en su canal de CI/CD. Más allá de “autopkgtests”, eso incluye varias aplicaciones de espacio de usuario como:

-llama.cpp -pytorch

licuadora
Servidor de limonada

Ese detalle es importante, porque muestra que Ubuntu no se limita a colocar paquetes en el archivo. Está validando ROCm como una pila de software mantenible.

4. La historia más importante es que los tres ecosistemas de GPU están aterrizando

Es más fácil ver la dirección de 26.04 cuando DPC++, CUDA y ROCm se ven juntos:

Intel: incorporando componentes SYCL/oneAPI a repositorios oficiales
NVIDIA: dando al kit de herramientas CUDA una ruta de instalación administrada por distribución
AMD: lanzando ROCm 7.1.0 en Universe con pruebas en curso

Si trabaja con este tipo de cargas de trabajo en Ubuntu, esta versión probablemente le resultará más relevante:

inferencia local LLM
Entrenamiento o ajuste acelerado por GPU
Blender, informática científica y HPC.
entornos de desarrollo que necesitan moverse a través de diferentes plataformas GPU

En otras palabras, Ubuntu ya no es sólo “un sistema donde puedes instalar un controlador de GPU”. Está comenzando a tener una pila de software de espacio de usuario más completa para computación con IA y GPU.

5. NVIDIA Dynamic Boost está habilitado de forma predeterminada

Desde el “25.04”, “Dynamic Boost” se ha habilitado de forma predeterminada en las computadoras portátiles NVIDIA compatibles.

La idea es sencilla: dependiendo de la carga del sistema, la energía se puede cambiar dinámicamente entre la CPU y la GPU. En escenarios de juegos, eso generalmente significa darle más potencia a la GPU cuando sea necesario para extraer más rendimiento.

Sólo se aplica bajo dos condiciones:

la computadora portátil está conectada a la alimentación de CA
la carga de la GPU es lo suficientemente alta

No se activa mientras el sistema está funcionando con batería.

6. La compatibilidad con las nuevas GPU Intel integradas y discretas sigue avanzando

Ubuntu también continúa ampliando el soporte para nuevas GPU Intel, que incluyen:

Integrado:

-Intel Core Ultra Xe2 -Intel Core Ultra Xe3

Discreto:

Intel Arco 5 B570 -Intel Arc 5 B580 -Intel Arc Pro B50 -Intel Arc Pro B60 -Intel Arc Pro B65 -Intel Arc Pro B70

Ubuntu también destaca varias características que ya están disponibles en estos dispositivos:

rendimiento mejorado del trazado de rayos de GPU y CPU a través de Intel Embree, beneficiando aplicaciones como Blender 4.2+
codificación de vídeo por hardware para AVC, JPEG, HEVC y AV1 en dispositivos “Battlemage”
una nueva optimización CCS en Intel Compute Runtime
soporte de depuración habilitado para GPU Intel Xe

Si está viendo las versiones de seguimiento, “25.10” también continúa incorporando más capacidades, que incluyen:

soporte inicial para la plataforma de cliente de próxima generación de Intel con nombre en código Panther Lake hasta Linux kernel 6.17
IOMMU mejorado, subsistema PCIe y compatibilidad con múltiples GPU
Mesa 25.2.3 habilitando VK_KHR_shader_bfloat16 para Battlemage y Panther Lake
intel-media-driver 25.3.0 agrega soporte de decodificación Panther Lake y codificación VP9
intel-compute-runtime 25.31 ajusta el comportamiento de asignación de eventos de memoria del dispositivo local y del grupo USM de nivel cero
level-zero 1.24 y level-zero-raytracing 1.1.0 brindan compatibilidad con especificaciones más amplias y extensión RTAS

7. Suspender y reanudar también es más estable en las computadoras de escritorio Nvidia

A partir de 25.10, Ubuntu habilita el soporte de suspensión y reanudación en el controlador propietario Nvidia para reducir la corrupción y la congelación al activar un sistema de escritorio.

Este no es el tipo de cambio más visible, pero es muy importante en el uso diario, especialmente en computadoras de escritorio que permanecen encendidas durante períodos prolongados y que se suspenden y reanudan con frecuencia.

8. ARM, Raspberry Pi, RISC-V e IBM Z también reciben cambios más difíciles a nivel de plataforma

Más allá de la pila de software de GPU, las notas de la versión también incluyen varios cambios a nivel de plataforma que vale la pena mencionar por separado.

Plataformas de escritorio ARM64

A partir de 25.10, el kernel linux-generic ARM64 proporciona una compatibilidad de escritorio más amplia para las plataformas de escritorio ARM64 que arrancan a través de UEFI.

Un nuevo diseño de arranque de Raspberry Pi

Un cambio introducido en 25.10 y refinado en 26.04 es un nuevo diseño de partición de arranque para sistemas Raspberry Pi. Su objetivo es mejorar la confiabilidad del arranque: los recursos de arranque recién escritos primero se “prueban” antes de confirmarlos como el nuevo conjunto “bueno conocido”.

Los requisitos de fecha del firmware son la parte que la mayoría de los usuarios querrán recordar:

Pi 3 / 3+ / CM3+ / Zero 2W: no se requiere ninguna acción adicional, el firmware de arranque está en la propia imagen
Pi 4/400/CM4: el firmware de arranque no debe tener una fecha anterior a 2022-11-25
Pi 5/500/CM5: el firmware de arranque no debe tener una fecha anterior a 2025-02-11

Puedes comprobarlo con:

`1`	`sudo rpi-eeprom-update`

Si el firmware es demasiado antiguo y está utilizando “Ubuntu 24.04 LTS” o más reciente, puede actualizarlo de esta manera:

1
2

sudo rpi-eeprom-update -a
sudo reboot

Las imágenes de escritorio de Raspberry Pi ahora usan escritorio mínimo

Desde “25.10”, las imágenes de escritorio de Ubuntu para Raspberry Pi se basan en “desktop-minimal” en lugar de en la semilla de “escritorio” completa.

Ubuntu ofrece aquí un beneficio muy concreto: el conjunto de aplicaciones predeterminado es más pequeño, lo que ahorra alrededor de “777 MB” en la imagen sin comprimir y en los sistemas instalados.

Si desea eliminar esa aplicación predeterminada configurada de forma masiva después de la actualización, puede usar:

`1`	`sudo apt purge ubuntu-desktop --autoremove`

Si desea conservar algunas de esas aplicaciones, primero márquelas como instaladas manualmente con “apt”.

El intercambio en Raspberry Pi ahora lo maneja cloud-init

Desde “25.10”, la creación de archivos de intercambio en imágenes de escritorio de Raspberry Pi se maneja mediante “cloud-init”.
Si desea personalizar el tamaño del intercambio antes del primer inicio, puede editar los “datos de usuario” directamente en la partición de inicio.

Los requisitos de RISC-V han aumentado

A partir de 25.10, la compilación RISC-V de Ubuntu 26.04 LTS requiere hardware que implemente el perfil ISA RVA23S64.

Los sistemas que no cumplan con ese requisito ya no podrán ejecutar “Ubuntu 26.04 LTS”. Si todavía tiene placas basadas en núcleos de procesador “RVA20” anteriores, debe permanecer en la línea de soporte proporcionada por “Ubuntu 24.04 LTS”.

Según Ubuntu, a partir de “abril de 2026”, todavía no hay hardware “RVA23S64” real disponible. Por lo tanto, la única plataforma actualmente compatible es efectivamente un entorno virtualizado “QEMU” configurado con “-cpu rva23s64”.

IBM Z ahora requiere z15 como mínimo

A partir de 26.04, el requisito mínimo para la arquitectura s390x pasó a z15.

Eso significa:

z14 / LinuxONE II y sistemas más antiguos ya no pueden instalar Ubuntu 26.04 LTS
z15 / LinuxONE III y los sistemas más nuevos deberían tener un mejor rendimiento

9. ¿Quién debería leer esto primero?

Este artículo es más útil que la descripción general del escritorio si se encuentra en alguno de estos casos:

usas Ubuntu para CUDA, ROCm, SYCL o inferencia de IA local
realiza trabajos de desarrollo o computación en GPU Intel, NVIDIA o AMD
mantiene Raspberry Pi, ARM64, RISC-V, IBM Z u otras plataformas x86 no estándar
eres especialmente sensible a la disponibilidad del repositorio, el comportamiento del controlador, los tiempos de ejecución y los requisitos de la plataforma después de una actualización

10. Comida para llevar de una línea

El punto clave de “Ubuntu 26.04 LTS” en el lado del hardware y la pila de IA no es que un proveedor de GPU haya obtenido una actualización destacada. Es que DPC++ de Intel, CUDA de NVIDIA y ROCm de AMD están ingresando al ecosistema Ubuntu de una manera más oficial, en repositorio y mantenible. Si solía pensar en Ubuntu como “primero el sistema, luego yo mismo ensamblo el entorno de GPU”, 26.04 comienza a parecerse más a una distribución que está dispuesta a transportar activamente IA y cargas de trabajo informáticas heterogéneas.

Qu茅 es NVIDIA nvbandwidth: c贸mo usar esta herramienta de prueba de ancho de banda de GPU

Fri, 24 Apr 2026 14:41:35 +0800

Si recientemente has estado solucionando problemas del rendimiento de la interconexión entre múltiples NVIDIA GPUs, o si deseas verificar el ancho de banda real entre PCIe, NVLink, la memoria host y la VRAM, NVIDIA/nvbandwidth es una herramienta pequeña que vale la pena conocer.

No es una utilidad de benchmark general, ni es un comando oculto dentro de un framework de modelo grande. Es una herramienta de código abierto de NVIDIA diseñada específicamente para medir el ancho de banda y la latencia para copias de memoria relacionadas con la GPU. En lugar de solo mirar el ancho de banda teórico, nvbandwidth es mejor para responder a una pregunta práctica: ¿cuánto ancho de banda puede entregar esta máquina y sus interconexiones GPU actuales en este momento?

false

1. ¿Qué hace `nvbandwidth`

Según el README oficial, nvbandwidth es una herramienta de línea de comandos para medir el ancho de banda en las NVIDIA GPU.

Se enfoca principalmente en el rendimiento de transferencia a través de diferentes patrones de memcpy, tales como:

GPU -> GPU
CPU -> GPU
GPU -> CPU
Transferencias entre GPUs a través de múltiples nodos

Estas pruebas son especialmente útiles en escenarios como:

Solucionar problemas de cuellos de botella de interconexión en el entrenamiento o la inferencia multi-GPU
Verificar el comportamiento real de enlaces como NVLink, PCIe y C2C
Comparar diferencias de transferencia entre servidores, topologías, drivers o versiones de CUDA
Realizar validación de hardware de referencia antes del despliegue del clúster

En resumen, nvbandwidth no se trata del rendimiento del modelo (model throughput). Se trata de la capacidad de bajo nivel para mover datos.

false

2. No produce solo una puntuación simple

Mucha gente considera una prueba de ancho de banda como algo que termina con un solo número, pero nvbandwidth proporciona una salida más detallada que eso.

Informa los resultados como matrices para cada tipo de prueba. Por ejemplo, en una prueba como device_to_device_memcpy_write_ce, muestra el ancho de banda entre cada par de GPUs por fila y columna. Eso significa que puedes ver más que solo una estimación aproximada de la velocidad a nivel de todo el sistema. También puedes detectar:

Qué pares de GPUs son especialmente rápidos
Qué rutas están claramente limitadas por PCIe
Si ciertos pares de GPUs muestran un ancho de banda anormalmente bajo
Si la topología multi-GPU coincide con tus expectativas

Si estás trabajando con un servidor de 8 GPUs, una plataforma dual-socket o un sistema multinodo, esta salida de estilo matriz suele ser más útil que un único número promedio.

false

3. Cómo entender las copias `CE` y `SM`

La documentación oficial divide las pruebas en dos categorías:

CE: transferencias del motor de copia basadas en las APIs memcpy
SM: transferencias basadas en el kernel

Estos dos tipos de resultados no están garantizados a coincidir exactamente, porque representan diferentes rutas de copia. Si principalmente quieres entender el comportamiento regular de transferencia de dispositivo a dispositivo, generalmente mirarás CE primero. Si quieres estudiar los detalles de ejecución más de cerca, entonces SM también vale la pena revisar.

El README también explica que los resultados de ancho de banda utilizan la mediana a través de múltiples ejecuciones de prueba por defecto. Las versiones más nuevas incluyen además estadísticas de variabilidad, lo que facilita juzgar cuán estables son los números.

false

4. ¿Qué entorno requiere

nvbandwidth no es una utilidad binaria pura que simplemente descargues y ejecutes. Espera un entorno de desarrollo CUDA estándar.

El README actual enumera estos requisitos básicos:

CUDA Toolkit 11.x o más reciente
Un compilador con soporte para C++17
CMake 3.20+, siendo 3.24+ recomendado
Boost program_options
Un dispositivo CUDA utilizable y un controlador compatible

Los requisitos son más altos si deseas la versión multinode. El README actual indica explícitamente:

Las compilaciones multinode requieren CUDA Toolkit 12.3
El controlador debe ser 550 o más reciente
Se requiere MPI
El servicio nvidia-imex debe estar configurado

Por lo tanto, esta es mucho más una herramienta de ingeniería para servidores y clusters de GPU en Linux que algo destinado a un uso de escritorio casual.

false

5. Cómo construir y ejecutar la versión de nodo único

El proceso de construcción de nodo único es sencillo:

1
2

cmake .
make

En Ubuntu / Debian, el proyecto también proporciona un script debian_install.sh que instala dependencias comunes y construye el proyecto.

Después de construir, puedes verificar primero la salida de ayuda:

`1`	`./nvbandwidth -h`

Algunas opciones comúnmente utilizadas incluyen:

-l: listar pruebas disponibles
-t: ejecutar una prueba específica por nombre o índice
-p: ejecutar pruebas por prefijo
-b: establecer el tamaño del búfer de memcpy, predeterminado 512 MiB
-i: establecer el número de iteraciones de benchmark
-j: salida JSON
-H: habilitar huge pages para la asignación de memoria del host

Si solo deseas ejecutar la suite de pruebas predeterminada una vez, usa:

`1`	`./nvbandwidth`

Si solo quieres probar un elemento específico, como una copia de dispositivo a dispositivo:

`1`	`./nvbandwidth -t device_to_device_memcpy_read_ce`

false

6. El soporte multinodo es una de sus características más destacadas

nvbandwidth no es solo para pruebas multi-GPU en un solo nodo. También admite escenarios multinodo.

Según el README, la compilación multinodo se realiza de esta manera:

1
2

cmake -DMULTINODE=1 .
make

En tiempo de ejecución, normalmente se utiliza junto con mpirun, con un proceso lanzado por GPU. La documentación también requiere que todos los ranks participantes pertenezcan al mismo clúster multinodo, y recomienda ejecutar las pruebas principalmente con el prefijo multinode bajo MPI.

Esto acerca su posicionamiento a la informática de alto rendimiento (high-performance computing) y a los sistemas GPU grandes que a las comprobaciones básicas de una estación de trabajo.

Si estás trabajando con implementaciones multinodo de NVLink o plataformas más complejas como GB200 / Grace Hopper, el valor de nvbandwidth es mucho mayor de lo que sería en una configuración típica de GPU de consumo.

false

7. Qué cambió en v0.9

A partir del 24 de abril de 2026, la página de GitHub Releases muestra que la última versión de nvbandwidth es v0.9, lanzada el 8 de abril de 2026.

Las actualizaciones más destacadas en este lanzamiento incluyen:

Se agregaron estadísticas de variabilidad a la salida de ancho de banda
Se agregó soporte para páginas grandes (huge page) para la memoria anfitriona (excluyendo Windows)
Se agregó muestreo de pares (pair sampling) para pruebas de dispositivo a dispositivo
Se agregó una guía de solución de problemas
Se unificaron los caminos de ejecución de nodo único y multinodo

También vale la pena señalar dos cambios orientados a la ingeniería:

Mejora en la detección de la arquitectura CUDA sin depender tanto del acceso directo a la GPU
Se eliminó el soporte para Volta (sm_70 / sm_72) en entornos de CUDA Toolkit 13.0+

Por lo tanto, si solo mirabas las versiones anteriores, v0.9 ya no es solo un probador básico de ancho de banda. Claramente se está moviendo hacia una mejor automatización, solución de problemas y validación de sistemas a gran escala.

false

8. ¿Cuándo es una buena opción?

``nvbandwidth` es especialmente adecuado cuando:

Quieres verificar el ancho de banda de interconexión real entre múltiples NVIDIA GPUs
Sospechas que una GPU está instalada en una ranura PCIe con ancho de banda limitado
Quieres comparar rutas NVLink frente a rutas no NVLink
Estás desplegando un clúster de GPU multinode y necesitas validar los enlaces
Quieres los resultados de las pruebas en JSON para pipelines de automatización

Pero si tu objetivo es solo responder preguntas como “¿qué tan rápido es el entrenamiento?” o “¿cuántos tokens por segundo puede alcanzar la inferencia?”, esta herramienta no es la respuesta completa. En ese caso, todavía necesitas pruebas a nivel de carga de trabajo (workload-level testing) con tu framework de entrenamiento, motor de inferencia o aplicación real.

false

9. Cómo pensar sobre su valor

Muchos problemas de rendimiento de GPU no son causados realmente por una capacidad de cómputo insuficiente. Ocurren porque la ruta de datos no está funcionando como se espera.

Por ejemplo:

Las GPUs no están utilizando la ruta de interconexión prevista
El acceso Cross-NUMA está reduciendo la velocidad
Ciertos pares de GPU tienen un ancho de banda anormal
La comunicación multinode está solo parcialmente configurada

Estos problemas a menudo son difíciles de diagnosticar si solo se observa nvidia-smi o el rendimiento del modelo. Una herramienta de nivel más bajo y orientada a matrices, como nvbandwidth, es útil precisamente porque expone lo que está sucediendo en la capa de interconexión.

Así que una forma sencilla de pensarlo es: nvbandwidth es una herramienta de verificación de salud en línea de comandos para el ancho de banda en sistemas NVIDIA GPU.

Enlaces relacionados

Proyecto GitHub: https://github.com/NVIDIA/nvbandwidth
Lanzamientos: https://github.com/NVIDIA/nvbandwidth/releases false

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.

Notas de Ollama Multi-GPU: agrupación de VRAM, selección de GPU y malentendidos comunes

Sun, 19 Apr 2026 00:18:00 +0800

Al ejecutar la inferencia local con Ollama, surgen rápidamente algunas preguntas: si ya tengo una GPU y mi placa base todavía tiene ranuras PCIe vacías, ¿ayuda agregar más GPU? ¿Es necesario que las GPU sean idénticas? ¿Se puede combinar VRAM? ¿Acelerará la inferencia como un marco de entrenamiento de múltiples GPU?

Esta nota resume cómo se comporta Ollama con múltiples GPU. La versión corta:

Ollama admite múltiples GPU.
El valor principal de varias GPU generalmente es adaptar modelos más grandes a la VRAM disponible, sin obtener un escalado lineal de tokens.
De forma predeterminada, si un modelo cabe completamente en una GPU, Ollama tiende a cargarlo en una sola GPU.
Si un modelo no cabe en una GPU, Ollama puede distribuirlo entre las GPU disponibles.
Ollama puede ver modelos de GPU mixtos, pero el rendimiento y la ubicación pueden no ser los ideales.
SLI/NVLink no es necesario para el uso de múltiples GPU.
Para limitar qué GPU puede usar Ollama, use CUDA_VISIBLE_DEVICES, ROCR_VISIBLE_DEVICES o GGML_VK_VISIBLE_DEVICES.

Comportamiento oficial: GPU única primero, GPU múltiple cuando sea necesario

Las preguntas frecuentes de Ollama describen directamente la lógica de carga de múltiples GPU: al cargar un nuevo modelo, Ollama estima la VRAM requerida y la compara con la memoria de GPU disponible actualmente. Si el modelo cabe completamente en una GPU, carga el modelo en esa GPU. Si no cabe en una sola GPU, el modelo se distribuye entre todas las GPU disponibles.

La razón es el rendimiento. Mantener un modelo en una GPU generalmente reduce las transferencias de datos a través del bus PCIe durante la inferencia, por lo que suele ser más rápido.

Así que no pienses en Ollama multi-GPU como si “más tarjetas significan automáticamente varias veces más rápido”. Un modelo más preciso es:

El modelo pequeño cabe en una GPU: normalmente funciona con una GPU.
El modelo grande no cabe en una GPU: se divide en varias GPU.
Todavía no hay suficiente VRAM: parte del modelo vuelve a la memoria del sistema y la velocidad cae notablemente.

Utilice este comando para ver dónde está cargado el modelo:

`1`	`ollama ps`

La columna “PROCESADOR” puede mostrar algo como:

1
2
3

100% GPU
48%/52% CPU/GPU
100% CPU

Si ve “48%/52% CPU/GPU”, parte del modelo ya está en la memoria del sistema. En ese caso, agregar más memoria GPU o usar una GPU con VRAM más grande suele ser más útil que seguir dependiendo de la CPU/RAM.

Multi-GPU no es un simple apilamiento informático

La inferencia LLM local no es lo mismo que SLI en los juegos. Con Ollama en múltiples GPU, el patrón común es que se colocan diferentes capas o tensores en diferentes dispositivos. Esto puede hacer que un modelo más grande encaje en la VRAM disponible combinada, pero es posible que aún sea necesario que los datos se muevan entre dispositivos durante la inferencia.

Por lo tanto, los beneficios de múltiples GPU generalmente se dividen en dos categorías:

Beneficio de VRAM: los modelos más grandes encajan más fácilmente, o menos parte del modelo recurre a CPU/RAM.
Beneficio de rendimiento: generalmente es más obvio cuando un modelo no cabría en una GPU o se extendería en gran medida a la CPU.

Si un modelo 8B o 14B ya cabe por completo en un solo RTX 3090, forzarlo en dos GPU puede no ser más rápido. Incluso puede ralentizarse debido a la sobrecarga de transferencia entre GPU. La estrategia predeterminada de Ollama de “usar una GPU cuando sea necesario” evita ese costo innecesario de PCIe.

No se requiere SLI o NVLink

Ollama multi-GPU no depende de SLI. Se pueden programar varias GPU PCIe normales siempre que el controlador y Ollama puedan detectarlas. NVLink o un ancho de banda PCIe superior puede ayudar en algunos escenarios entre GPU, pero no es un requisito. Muchos servidores y estaciones de trabajo GPU usados pueden ejecutar varias GPU a través de PCIe normal.

A lo que debes prestar atención es al ancho de banda PCIe. La diferencia entre x1, x4, x8 y x16 afecta la rapidez con la que se carga un modelo en VRAM. Si cambia con frecuencia de modelo grande, el ancho de banda PCIe se vuelve más importante. Después de cargar un modelo, PCIe generalmente importa menos durante la generación, pero la división entre GPU aún puede agregar gastos generales.

Reglas más seguras:

Prefiere las bandas x16/x8 a las bandas x1 estilo minería.
El ancho de banda PCIe es más importante cuando se cambian modelos grandes con frecuencia.
Si un modelo permanece residente en VRAM durante mucho tiempo, el ancho de banda PCIe es menos visible.
Para máquinas con múltiples GPU, verifique la topología PCIe de la placa base y los carriles conectados a la CPU.

Limite las GPU NVIDIA que utiliza Ollama

En sistemas NVIDIA con múltiples GPU, use CUDA_VISIBLE_DEVICES para controlar qué GPU puede ver Ollama.

Ejecución temporal:

`1`	`CUDA_VISIBLE_DEVICES=0,1 ollama serve`

Utilice sólo la segunda GPU:

`1`	`CUDA_VISIBLE_DEVICES=1 ollama serve`

Obligar a Ollama a no utilizar GPU NVIDIA:

`1`	`CUDA_VISIBLE_DEVICES=-1 ollama serve`

Los documentos oficiales señalan que los ID numéricos pueden cambiar de orden, por lo que los UUID de GPU son más confiables. Primero verifique los UUID:

`1`	`nvidia-smi -L`

Salida de ejemplo:

1
2

GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
GPU 1: NVIDIA GeForce RTX 3070 (UUID: GPU-yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy)

Luego especifique el UUID:

`1`	`CUDA_VISIBLE_DEVICES=GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ollama serve`

Si Ollama está instalado como un servicio systemd de Linux, coloque la variable en el entorno del servicio:

`1`	`sudo systemctl edit ollama.service`

Agregar:

1
2

[Service]
Environment="CUDA_VISIBLE_DEVICES=0,1"

Recargar y reiniciar:

1
2

sudo systemctl daemon-reload
sudo systemctl restart ollama

Selección de dispositivos AMD y Vulkan

Para AMD ROCm, use ROCR_VISIBLE_DEVICES para controlar las GPU visibles:

`1`	`ROCR_VISIBLE_DEVICES=0,1 ollama serve`

Para obligar a Ollama a no usar GPU ROCm, use una identificación no válida:

`1`	`ROCR_VISIBLE_DEVICES=-1 ollama serve`

Los documentos de GPU de Ollama también mencionan el soporte experimental de Vulkan. Para GPU Vulkan, use GGML_VK_VISIBLE_DEVICES:

`1`	`OLLAMA_VULKAN=1 GGML_VK_VISIBLE_DEVICES=0 ollama serve`

Si los dispositivos Vulkan causan problemas, desactívelos:

`1`	`GGML_VK_VISIBLE_DEVICES=-1 ollama serve`

Es más probable que las configuraciones de múltiples GPU de AMD tengan problemas de compatibilidad con el controlador, la versión ROCm y la versión GFX. Los documentos oficiales también mencionan los requisitos del controlador ROCm de Linux y las anulaciones de compatibilidad, como HSA_OVERRIDE_GFX_VERSION. Si combina diferentes generaciones de GPU AMD, primero verifique que cada tarjeta funcione por sí sola antes de probar con varias GPU.

Exponer varias GPU en Docker

Si ejecuta Ollama en Docker, las configuraciones de NVIDIA generalmente requieren nvidia-container-toolkit y luego --gpus para exponer los dispositivos.

Exponga todas las GPU:

docker run -d \
  --gpus=all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

Exponer GPU específicas:

docker run -d \
  --gpus '"device=0,1"' \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

También puedes combinar esto con variables de entorno:

docker run -d \
  --gpus=all \
  -e CUDA_VISIBLE_DEVICES=0,1 \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

Si nvidia-smi no puede ver las GPU dentro del contenedor, Ollama tampoco puede usarlas. Primero solucione los problemas de transferencia de GPU de Docker y luego Ollama.

¿Qué es `OLLAMA_SCHED_SPREAD`?

En algunas discusiones sobre configuración de múltiples GPU, es posible que vea OLLAMA_SCHED_SPREAD=1 o OLLAMA_SCHED_SPREAD=true. Está relacionado con el programador de Ollama y se usa a menudo cuando las personas desean que los modelos o solicitudes se distribuyan más ampliamente entre las GPU.

Ejemplo:

`1`	`OLLAMA_SCHED_SPREAD=1 ollama serve`

O con systemd:

1
2

[Service]
Environment="OLLAMA_SCHED_SPREAD=true"

Pero no es un cambio mágico. Habilitarlo no implica un escalado lineal de tokens y aún puede ejecutarse en OOM cuando se cargan varios modelos, las estimaciones de VRAM son ajustadas, la longitud del contexto aumenta o la caché KV se expande. El comportamiento principal de las preguntas frecuentes todavía se aplica: si una GPU puede contener completamente el modelo, una GPU suele ser más eficiente; Si una GPU no puede contenerlo, entonces resulta útil la división entre varias GPU. Trate OLLAMA_SCHED_SPREAD como un experimento de programación avanzada, no como una configuración multi-GPU requerida. Primero, comprenda el comportamiento predeterminado y luego ajústelo según ollama ps, registros y nvidia-smi.

Cómo comprobar si se están utilizando varias GPU

Comandos útiles:

`1`	`ollama ps`

`1`	`watch -n 0.5 nvidia-smi`

Ver los registros del servicio de Ollama:

`1`	`journalctl -u ollama -f`

Si usa Docker:

`1`	`docker logs -f ollama`

Esté atento a:

Si Ollama descubre GPU compatibles.
Si el modelo muestra “100% GPU” o una división CPU/GPU.
Si cada GPU tiene VRAM asignada.
Si la VRAM crece en varias GPU durante la carga del modelo.
Si los tokens de generación mejoran en comparación con el desbordamiento de CPU/RAM.
Si la descarga de OOM o de modelos ocurre con frecuencia.

La utilización de la GPU por sí sola puede resultar engañosa. La inferencia LLM no siempre mantiene las GPU completamente cargadas, especialmente con varias GPU, tamaños de lote bajos, contextos pequeños, CPU lentas o enlaces PCIe lentos.

Malentendidos comunes

Malentendido 1: Dos GPU de 12 GB equivalen a una GPU de 24 GB

No exactamente. Varias GPU pueden colocar un modelo en varios dispositivos, pero el acceso entre dispositivos tiene una sobrecarga. Resuelve el problema de “no encaja”, pero no es equivalente a la velocidad y estabilidad de una GPU de gran VRAM.

Malentendido 2: No se pueden mezclar diferentes modelos de GPU

No necesariamente. Si el controlador, la capacidad informática y las bibliotecas de tiempo de ejecución son compatibles con las tarjetas, Ollama puede ver varias GPU. Pero las configuraciones mixtas suelen estar limitadas por una tarjeta más lenta, una VRAM más pequeña y una topología PCIe. La configuración más predecible sigue siendo el mismo modelo, el mismo tamaño de VRAM y controladores de la misma generación con buen soporte.

Malentendido 3: La GPU múltiple siempre es más rápida que la GPU única

No siempre. Si el modelo se adapta completamente a una GPU rápida, una GPU única puede ser más rápida. La GPU múltiple es útil principalmente para modelos grandes, contextos prolongados o VRAM de GPU única insuficiente.

Malentendido 4: Se requiere NVLink / SLI

No. Ollama puede utilizar sistemas PCIe múltiples-GPU ordinarios. NVLink no es un requisito previo.

Malentendido 5: Agregar una GPU no requiere reiniciar los servicios

No siempre es cierto. Es posible que sea necesario reiniciar los servicios systemd de Linux, las aplicaciones en segundo plano de Windows y los contenedores Docker antes de que redescubran dispositivos y variables de entorno.

Sugerencias de selección de GPU

Para la inferencia local de Ollama, la prioridad aproximada es:

La VRAM de una sola GPU más grande suele ser más fácil de administrar.
Las GPU idénticas son más fáciles de solucionar que las GPU mixtas.
Los carriles PCIe más completos facilitan la carga de modelos grandes.
Primero se debe verificar la capacidad de computación CUDA o la compatibilidad con ROCm en las tarjetas más antiguas.
La alimentación, la refrigeración y el flujo de aire del chasis de varias GPU deben planificarse con antelación.

Para plataformas económicas de segunda mano:

Dual RTX 3090 sigue siendo una opción común de alta VRAM.
Las tarjetas Tesla más antiguas, como la P40/M40, tienen una gran VRAM, pero la potencia, la refrigeración, la compatibilidad con el controlador y el rendimiento necesitan compensaciones.
Las tarjetas como RTX 4070/4070 Ti tienen buena eficiencia, pero la VRAM de una sola tarjeta puede ser limitante.
Puede ser divertido experimentar con varias tarjetas antiguas de 8 GB, pero no son ideales para ejecutar modelos grandes a largo plazo.

Resumen

La compatibilidad con múltiples GPU de Ollama se entiende mejor como “primero la expansión de VRAM y luego la aceleración del rendimiento”. Si el modelo cabe completamente en una GPU, la ruta predeterminada de una sola GPU suele ser más rápida. Si una GPU no puede contenerlo, varias GPU pueden distribuir el modelo entre dispositivos y evitar un gran desbordamiento de CPU/RAM, lo que hace que se puedan utilizar modelos más grandes.

En la práctica, use ollama ps para verificar dónde está cargado el modelo, luego use las herramientas nvidia-smi o ROCm para observar la asignación de VRAM. Para la selección de GPU, use CUDA_VISIBLE_DEVICES en NVIDIA, ROCR_VISIBLE_DEVICES en AMD ROCm y GGML_VK_VISIBLE_DEVICES para Vulkan. Si se ejecuta en Docker, primero asegúrese de que el contenedor pueda ver las GPU.

La multi-GPU no es mágica. Puede ayudar a adaptar modelos más grandes, pero no garantiza una aceleración lineal. La ruta estable sigue siendo preferir GPU únicas con gran VRAM o configuraciones idénticas de múltiples GPU, considerando al mismo tiempo la compatibilidad con controladores, PCIe, alimentación, refrigeración y cuantificación de modelos.

Referencias

Preguntas frecuentes de Ollama: ¿Cómo carga Ollama modelos en múltiples GPU?: https://github.com/ollama/ollama/blob/main/docs/faq.mdx
Documentos de Ollama GPU: soporte de hardware/selección de GPU: https://github.com/ollama/ollama/blob/main/docs/gpu.mdx
Centro Docker de Ollama: https://hub.docker.com/r/ollama/ollama
Kit de herramientas de contenedor NVIDIA: https://github.com/NVIDIA/nvidia-container-toolkit

CUDA on KnightLi Blog

Actualizaciones de hardware y GPU Ubuntu 26.04 LTS: CUDA, ROCm, DPC++ y más cambios de plataforma

1. Intel DPC++ y componentes relacionados ahora están en Ubuntu Archive

2. El kit de herramientas NVIDIA CUDA ahora se puede instalar directamente con apt

3. AMD ROCm 7.1.0 ya está en Universe

4. La historia más importante es que los tres ecosistemas de GPU están aterrizando

5. NVIDIA Dynamic Boost está habilitado de forma predeterminada

6. La compatibilidad con las nuevas GPU Intel integradas y discretas sigue avanzando

7. Suspender y reanudar también es más estable en las computadoras de escritorio Nvidia

8. ARM, Raspberry Pi, RISC-V e IBM Z también reciben cambios más difíciles a nivel de plataforma

Plataformas de escritorio ARM64

Un nuevo diseño de arranque de Raspberry Pi

Las imágenes de escritorio de Raspberry Pi ahora usan escritorio mínimo

El intercambio en Raspberry Pi ahora lo maneja cloud-init

Los requisitos de RISC-V han aumentado

IBM Z ahora requiere z15 como mínimo

9. ¿Quién debería leer esto primero?

10. Comida para llevar de una línea

Qu茅 es NVIDIA nvbandwidth: c贸mo usar esta herramienta de prueba de ancho de banda de GPU

1. ¿Qué hace nvbandwidth

2. No produce solo una puntuación simple

3. Cómo entender las copias CE y SM

4. ¿Qué entorno requiere

5. Cómo construir y ejecutar la versión de nodo único

6. El soporte multinodo es una de sus características más destacadas

7. Qué cambió en v0.9

8. ¿Cuándo es una buena opción?

9. Cómo pensar sobre su valor

Enlaces relacionados

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

Entender primero las métricas

Qué es Q4_0

Qué es pp512

Qué es tg128

Qué es FA

Cómo leer t/s

Conclusiones rápidas

Cómo usar las tablas

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

2. Compara el backend que realmente usas

3. Mira FA al final

4. No compares generaciones solo por memoria

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

Qué muestran en general los scoreboards

Resumen en una frase

Fuentes

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

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

Qué significa FA: Flash Attention

Qué significa no FA

Qué significa Q4_0: un formato de cuantización

Qué significa pp512 t/s

Qué significa tg128 t/s

Por qué pp512 y tg128 difieren tanto

Cómo pensar sobre t/s

En qué fijarse primero al leer un scoreboard

1. Qué modelo se está probando

2. Si las optimizaciones clave están activadas

3. Si la métrica mide entrada o salida

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

Una forma práctica de recordarlo

Cierre

Notas de Ollama Multi-GPU: agrupación de VRAM, selección de GPU y malentendidos comunes

Comportamiento oficial: GPU única primero, GPU múltiple cuando sea necesario

Multi-GPU no es un simple apilamiento informático

No se requiere SLI o NVLink

Limite las GPU NVIDIA que utiliza Ollama

Selección de dispositivos AMD y Vulkan

Exponer varias GPU en Docker

¿Qué es OLLAMA_SCHED_SPREAD?

Cómo comprobar si se están utilizando varias GPU

Malentendidos comunes

Malentendido 1: Dos GPU de 12 GB equivalen a una GPU de 24 GB

Malentendido 2: No se pueden mezclar diferentes modelos de GPU

Malentendido 3: La GPU múltiple siempre es más rápida que la GPU única

Malentendido 4: Se requiere NVLink / SLI

Malentendido 5: Agregar una GPU no requiere reiniciar los servicios

Sugerencias de selección de GPU

Resumen

Referencias

2. El kit de herramientas NVIDIA CUDA ahora se puede instalar directamente con `apt`

1. ¿Qué hace `nvbandwidth`

3. Cómo entender las copias `CE` y `SM`

¿Qué es `OLLAMA_SCHED_SPREAD`?