GPU on KnightLi Blog

Cómo elegir una GPU en abril de 2026: qué modelos evitar y cuáles vale más la pena considerar

Mon, 27 Apr 2026 08:51:10 +0800

Si te estás preparando para construir una PC, la GPU es la única parte en la que realmente no debes fijarte únicamente en si una tarjeta es nueva. En abril de 2026, algunos modelos ya son mucho más difíciles de justificar, mientras que otros no son perfectos, pero aún así parecen notablemente más razonables que las alternativas del mismo precio.

Así que este artículo se salta la teoría y va directamente a modelos específicos.

Modelos que no priorizaría

1. `RTX 5060 Ti 8GB`

El mayor problema de esta tarjeta no es que sea inutilizable. El problema es que “8GB” ya se siente atrapado en un incómodo término medio en este momento.

Si juegas principalmente a juegos en línea más livianos en configuraciones 1080p de media a alta, aún puede funcionar. Pero una vez que ingresa a cualquiera de estas áreas, la limitación aparece rápidamente:

Juegos AAA más nuevos
Configuraciones de textura más altas
1440p
Uso mixto con inferencia de IA, edición o trabajo de productividad

Si ya está considerando la “RTX 5060 Ti”, la decisión más segura suele ser ir directamente a la versión de “16 GB” en lugar de ahorrar un poco de presupuesto optando por la de “8 GB”.

En resumen:

RTX 5060 Ti 8GB: no recomendado
RTX 5060 Ti 16GB: claramente más vale la pena considerar

2. Tarjetas antiguas y caras, especialmente `RTX 3080 10GB` y `RTX 3070 Ti` cuando todavía tienen un precio elevado

El problema con estas tarjetas no es que el rendimiento sea completamente malo. El problema es que, en el mercado actual, comprarlos a menudo te pone en una situación incómoda:

El consumo de energía no es bajo
Ya no son nuevos
La VRAM no es especialmente generosa
Las fuentes del mercado de segunda mano suelen ser confusas

RTX 3080 10GB es el ejemplo más claro. Si todavía tiene un precio alto, rápidamente se convierte en una tarjeta que parece sólida en el papel pero que se siente menos equilibrada en el uso real.

RTX 3070 Ti sigue la misma lógica. No es absolutamente imposible de comprar, pero si la diferencia de precio no es significativa, normalmente será mejor que busques algo más nuevo, algo con una VRAM más cómoda o algo más equilibrado en potencia y térmica.

3. Insignias más antiguas con un historial poco claro, como `RTX 3090` y `RTX 3080 Ti`

Es fácil querer estas dos cartas por razones obvias:

Los nombres todavía suenan fuertes
El rendimiento del papel no es débil
Son muy visibles en el mercado de segunda mano.

Lo que realmente hay que tener en cuenta es de dónde vienen.

Si estás comprando:

Una tarjeta extraída
Una tarjeta reparada
Una tarjeta usada con un historial poco claro.

entonces el riesgo suele ser mucho mayor que con una tarjeta minorista normal. Una tarjeta como la “RTX 3090” parece atractiva debido a la VRAM de “24 GB”, pero el calor, la entrega de energía, el estado del silicio y el historial de uso pasado se convierten en preocupaciones mayores de las que serían en una tarjeta nueva y sencilla.

Si aún no sabe exactamente lo que está comprando y no planea dedicar tiempo a revisar la tarjeta con atención, estos buques insignia más antiguos generalmente no son algo que tocaría casualmente.

4. `RTX 5070` cuando el precio no es el adecuado

RTX 5070 no es una tarjeta que sea automáticamente mala. El problema es que el precio tiene que tener sentido.

Su incomodidad aparece cuando la brecha entre este y el RTX 5070 Ti no es lo suficientemente grande. En ese caso, muchos compradores acaban sintiéndose extrañamente insatisfechos.

El patrón suele verse así:

Compra el 5070: sigues pensando que con un poco más te habrías comprado el 5070 Ti
No estires el presupuesto: aún sabes que compraste la tarjeta “casi”

Por lo tanto, “RTX 5070” no es algo que deba ignorarse por completo, pero vale la pena considerarlo solo cuando el precio es claramente correcto. Si el precio se sitúa en una zona intermedia incómoda, rápidamente se convierte en una tarjeta que tiene sentido teórico pero que no se siente muy bien en la práctica.

Modelos que tienen más sentido

1. `RTX 5060 Ti 16GB`

Si ya está comprando en el rango medio, esta tarjeta suele ser la opción más segura en comparación con la versión de “8 GB”.

Las razones son simples:

Más espacio libre dentro de la misma familia de productos
Es menos probable que VRAM lo bloquee en los próximos años.
Es más fácil vivir con él si combinas juegos y productividad

Puede que no sea la tarjeta más explosiva por su precio, pero al menos es el tipo de tarjeta de la que es menos probable que te arrepientas inmediatamente.

2. `RTX 5070 Ti`

Si su presupuesto puede estirarse, esta suele ser una respuesta más completa que el RTX 5070.

Su valor no es que domine todos los escenarios. Su valor es que se siente más como una tarjeta que puede equilibrar los juegos, la resolución y el uso a largo plazo, todo al mismo tiempo.

Tiene sentido para las personas que:

Quiere configuraciones altas de 1440p
Quiere que el sistema dure años
No quiero empezar a pensar en actualizaciones demasiado pronto.

Si ya está atrapado entre el 5070 y el 5070 Ti, y la brecha no es absurdamente grande, ir directamente al 5070 Ti suele ser la decisión menos molesta.

3. Las tarjetas nuevas con un precio adecuado suelen ser una mejor primera opción que las tarjetas más antiguas de alta gama

Si no eres un cazador veterano de GPU usadas, una regla simple y efectiva es la siguiente:

Priorizar las nuevas tarjetas minoristas normales
Tenga cuidado con las tarjetas antiguas de alta gama que tienen orígenes complicados

En este punto, el enfoque más práctico suele ser:

Presupuesto de gama media: comience con RTX 5060 Ti 16GB
Un nivel superior: céntrese en RTX 5070 Ti
Considere RTX 5070 solo cuando el precio sea claramente favorable

Este suele ser un mejor camino que apostar con cartas más antiguas que suenan más fuertes pero que vienen con más equipaje.

Si solo quieres la versión corta

Puedes recordarlo así:

Realmente no recomendado: RTX 5060 Ti 8GB
No recomendado a menos que tenga un buen precio: RTX 5070
Tenga cuidado con: RTX 3080 10GB, RTX 3070 Ti y RTX 3090/RTX 3080 Ti de fuente poco clara
Más que vale la pena considerar: RTX 5060 Ti 16GB
Selección más fácil a largo plazo si el presupuesto lo permite: RTX 5070 Ti

Línea final

A estas alturas del mercado el verdadero error suele ser no gastar un poco más. Se trata de comprar una tarjeta que parece aceptable en papel pero que siempre se siente un poco comprometida en el uso real.

Si desea minimizar el arrepentimiento, RTX 5060 Ti 16GB y RTX 5070 Ti son generalmente más seguras que muchas tarjetas que parecen “suficientemente buenas”, mientras que RTX 5060 Ti 8GB, RTX 5070 de mal precio y tarjetas de gama alta más antiguas con un historial poco claro suelen ser las primeras en tachar.

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.

C贸mo solucionar que Ollama use CPU en lugar de GPU

Fri, 24 Apr 2026 18:30:00 +0800

Al ejecutar LLMs locales, uno de los problemas más frustrantes es este: tu máquina claramente tiene una GPU, sin embargo, Ollama sigue apoyándose en gran medida en la CPU, y el rendimiento es dolorosamente lento.

La versión corta es que esto generalmente no se debe a un único problema. Las causas más comunes son:

Ollama no está detectando ninguna GPU utilizable
El driver, el entorno ROCm o CUDA no están configurados correctamente
El servicio Ollama se inició sin las variables de entorno adecuadas
El modelo es demasiado grande y ha recurrido a la CPU o tiene una carga mixta de CPU/GPU
En plataformas AMD, puede haber problemas de compatibilidad adicionales, como una incompatibilidad de versión de ROCm, ajustes gfx, o problemas de visibilidad del dispositivo

La forma más rápida de solucionar el problema es seguir las comprobaciones a continuación en orden.

false

1. Primero, confirma si Ollama realmente no está usando la GPU

La comprobación más directa es:

`1`	`ollama ps`

Concéntrate en la columna PROCESSOR.

100% GPU: el modelo se está ejecutando completamente en la GPU
100% CPU: la GPU no se está usando en absoluto
Resultados como 48%/52% CPU/GPU: parte del modelo está en VRAM, y parte se ha volcado a la memoria del sistema

Si ves 100% CPU, el siguiente paso es centrarse en la configuración del entorno y del servicio. Si ves una carga mixta, eso no significa necesariamente que la GPU esté rota. En muchos casos, simplemente significa que la VRAM no es suficiente.

false

2. Descartar primero el malentendido más común: el modelo no cabe en VRAM

Mucha gente asume que una vez que se instala una GPU, Ollama siempre funcionará completamente en ella. Eso no es así.

Si el modelo es demasiado grande, el contexto es demasiado largo, o algún otro modelo cargado ya está ocupando VRAM, Ollama puede recurrir a:

GPU parcial + CPU parcial
100% CPU completo

En este punto, las dos pruebas más sencillas son:

Intentar un modelo más pequeño primero Por ejemplo, pruébalo con un modelo 4B o 7B antes de saltar directamente a modelos mucho más grandes.
Descargar otros modelos activos y probar de nuevo Ejecuta ollama ps primero y asegúrate de que nada más esté ocupando VRAM.

Si los modelos más pequeños usan la GPU, pero los más grandes no, el problema real suele ser la capacidad de VRAM, y no el driver.

false

3. Comprobar si el driver de la GPU y el runtime de bajo nivel están funcionando realmente

Si incluso modelos pequeños se ejecutan solo en CPU, el siguiente paso es revisar el entorno subyacente.

NVIDIA

Primero, confirma que el driver está funcionando y que el sistema puede ver la GPU. Una comprobación común es:

`1`	`nvidia-smi`

Si esto ya falla, es muy poco probable que Ollama use la GPU correctamente.

AMD / ROCm

Si estás usando una AMD GPU, especialmente con ROCm, empieza con:

1
2

rocminfo
rocm-smi

Si estas herramientas no pueden listar el dispositivo correctamente, el problema sigue estando por debajo de Ollama, por lo que no tiene sentido depurar la capa de la aplicación todavía.

En AMD, el problema más común no es simplemente ¿está instalado el driver?, sino más bien:

La versión de ROCm no coincide con la versión del OS
La arquitectura actual de la GPU tiene soporte incompleto
El dispositivo existe, pero el runtime no se está exponiendo correctamente a Ollama

false

4. Reinicia el servicio de Ollama, no solo tu terminal

Esta es una trampa muy común.

Muchas personas instalan drivers, cambian variables de entorno, arreglan ROCm, y luego simplemente abren una nueva terminal y continúan con ollama run. Pero si Ollama se está ejecutando como un servicio en segundo plano, aún puede estar usando el entorno antiguo.

Por lo tanto, el enfoque más seguro es:

Reiniciar completamente el servicio Ollama
Reiniciar la máquina si es necesario

Si lo estás ejecutando como un servicio en Linux, asegúrate de que el proceso del servicio fue realmente reiniciado en lugar de reutilizar el antiguo.

false

5. Comprobar si las variables de entorno están llegando realmente al servicio

Esto es especialmente importante en sistemas AMD ROCm.

Algunas máquinas funcionan bien cuando se ejecutan comandos manualmente en un shell, pero el servicio Ollama sigue usando solo CPU. En ese caso, la razón habitual es que el proceso del servicio nunca recibió las variables que estableciste en tu shell.

Las variables comunes a revisar incluyen:

1
2

ROCR_VISIBLE_DEVICES
HSA_OVERRIDE_GFX_VERSION

Específicamente:

ROCR_VISIBLE_DEVICES limita o selecciona qué GPUs puede ver ROCm
HSA_OVERRIDE_GFX_VERSION se usa a menudo como solución de compatibilidad en algunas plataformas AMD

Si solo exportas estas variables en la terminal actual, pero Ollama es iniciado por systemd, un servicio de fondo de escritorio u otro demonio, es posible que no surtan efecto.

En otras palabras, que “parece estar establecido en mi terminal” no significa que Ollama lo esté usando realmente.

false

6. En plataformas AMD, céntrate en la compatibilidad de ROCm

Según los metadatos de la página pública, el video original sobre este tema está vinculado a AMD Max+ 395, strix halo, y AMD ROCm. En configuraciones como estas, que Ollama no logre usar la GPU a menudo depende más de la coincidencia de versiones que de los sistemas NVIDIA.

Empieza revisando lo siguiente:

Si la versión instalada de ROCm es compatible con el OS y la GPU actuales
Si la GPU pertenece a una arquitectura con soporte sólido de ROCm
Si necesitas establecer HSA_OVERRIDE_GFX_VERSION
Si una versión anterior de Ollama o un runtime de inferencia antiguo está causando problemas de compatibilidad

Si rocminfo funciona y la GPU es visible para el sistema, pero Ollama sigue ejecutándose solo en CPU, el problema a menudo radica en la combinación de versiones en lugar de en los parámetros del modelo.

false

7. En Docker, WSL o entornos remotos, comprueba también el mapeo de dispositivos

Si no estás ejecutando en hardware físico (bare metal) sino dentro de:

Docker
WSL
Contenedores remotos (Remote containers)
Entornos virtualizados

entonces necesitas comprobar una capa más: si el dispositivo GPU realmente se está exponiendo dentro de ese entorno.

Un síntoma típico se ve así:

La máquina anfitriona (host machine) puede ver la GPU
Ollama dentro del contenedor o subsistema sigue usando solo CPU

En ese caso, el problema puede no ser Ollama en sí. El contenedor o subsistema simplemente puede no tener acceso a la GPU.

false

8. Revisar los registros al final, pero revisarlos por la razón correcta

Si ya has pasado por los pasos anteriores, el siguiente movimiento más efectivo no es reinstalar sin parar, sino mirar directamente los registros de inicio y tiempo de ejecución de Ollama.

Concéntrate en dos tipos de mensajes:

Si se detectó una GPU
Si hay errores de controlador, carga de bibliotecas o inicialización de dispositivos

Si los registros dicen claramente algo como “no compatible GPU found” o “failed to initialize ROCm/CUDA”, la dirección de la solución de problemas se vuelve mucho más clara de inmediato.

false

Orden de Solución de Problemas

Si solo quieres el camino más corto, usa este orden:

Ejecuta ollama ps y confirma si está usando GPU, CPU o carga mixta.
Intenta con un modelo más pequeño para descartar límites de VRAM.
Utiliza nvidia-smi, rocminfo y rocm-smi para verificar primero el entorno de bajo nivel.
Reinicia completamente el servicio Ollama.
Revisa las variables de entorno del servicio, especialmente ROCR_VISIBLE_DEVICES y HSA_OVERRIDE_GFX_VERSION en AMD.
Si estás en Docker o WSL, verifica el mapeo de dispositivos.
Finalmente, inspecciona los logs para encontrar el error exacto.

false

Conclusión

Cuando Ollama utiliza CPU en lugar de GPU, la causa raíz generalmente cae en uno de tres grupos:

La GPU no está siendo detectada en absoluto
La GPU es detectable, pero el entorno de ejecución no está alcanzando a Ollama
La GPU está funcionando, pero el modelo es demasiado grande y retrocede a CPU o memoria mixta

Una vez que se separan esos tres casos, la solución de problemas se vuelve mucho más rápida. Si estás en una plataforma AMD, presta especial atención a la coincidencia de versiones de ROCm, la visibilidad del dispositivo y las variables de compatibilidad, en lugar de centrarte solo en el comando Ollama en sí.

Original video: https://www.bilibili.com/video/BV1cHoYBqE8k/ false

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

Cómo comprobar si una Tesla V100 tiene errores ECC

Thu, 23 Apr 2026 11:50:21 +0800

Si tienes una Tesla V100 y quieres hacer primero una revisión básica de salud, el estado ECC es una de las cosas más útiles que mirar.

El método más directo es inspeccionar la información detallada de la tarjeta con nvidia-smi.

1
2
3

nvidia-smi -q
# Query GPU 0
nvidia-smi -q -i 0

Concéntrate en la sección ECC Errors.

En una tarjeta en estado normal, los cuatro grupos comunes de contadores bajo ECC Errors deberían ser 0 o N/A. Si alguno ya muestra un valor distinto de cero, significa que la tarjeta ha visto ese tipo de anomalía ECC antes, y deberías evaluar con más detalle si sigue siendo adecuada para uso continuo.

Salida de referencia:

nvidia-smi -q
    ECC Mode
        Current                          : Enabled
        Pending                          : Enabled
    ECC Errors
        Volatile
            Single Bit
                Device Memory            : 0
                Register File            : 0
                L1 Cache                 : 0
                L2 Cache                 : 0
                Texture Memory           : N/A
                Texture Shared           : N/A
                CBU                      : N/A
                Total                    : 0
            Double Bit
                Device Memory            : 0
                Register File            : 0
                L1 Cache                 : 0
                L2 Cache                 : 0
                Texture Memory           : N/A
                Texture Shared           : N/A
                CBU                      : 0
                Total                    : 0
        Aggregate
            Single Bit
                Device Memory            : 0
                Register File            : 0
                L1 Cache                 : 0
                L2 Cache                 : 0
                Texture Memory           : N/A
                Texture Shared           : N/A
                CBU                      : N/A
                Total                    : 0
            Double Bit
                Device Memory            : 0
                Register File            : 0
                L1 Cache                 : 0
                L2 Cache                 : 0
                Texture Memory           : N/A
                Texture Shared           : N/A
                CBU                      : 0
                Total                    : 0
    Retired Pages

Puedes pensarlo así:

Volatile es el conteo de errores del ciclo de encendido actual
Aggregate es el conteo acumulado durante la vida de la tarjeta
Single Bit significa errores corregibles
Double Bit significa errores no corregibles, más serios

Si solo quieres una regla rápida de cribado:

La mayoría de elementos deberían ser 0
N/A es normal en entradas no aplicables
Si Double Bit o el total no es 0, no te fíes solo de la descripción verbal del vendedor; conviene seguir con stress tests y comprobaciones de estabilidad

Esto no reemplaza una inspección completa, pero basta para una primera revisión cuando llega una V100.

¿Sigue valiendo la pena comprar una Tesla V100? ECC, mods de refrigeración y trampas DIY

Thu, 23 Apr 2026 11:15:10 +0800

Si has estado mirando tarjetas Tesla V100 usadas, probablemente viste dos opiniones muy distintas:

un lado dice que la tarjeta sigue siendo fuerte y ofrece gran valor
el otro dice que el mercado está lleno de trampas y que los usuarios DIY pueden quemarse fácilmente

Ambas son ciertas.

El punto no es que V100 sea incomprable. El punto es que no puedes comprarla como comprarías una GPU de consumo normal. No importa solo si arranca, ni si el vendedor dice “como nueva” o “retirada de servidor original”. Importa si fue manipulada, cómo se ve su estado ECC y si el setup de refrigeración y alimentación es realmente fiable.

Este artículo reúne los controles más útiles para comprar y usar una en la práctica.

Resumen rápido

Si solo quieres la versión corta:

V100 se produjo aproximadamente de 2017 a 2021, y las tarjetas 16G de 2021 son poco comunes
mirar solo “ECC cero” u “original pull” no basta, porque tanto datos como estado físico pueden alterarse
el mayor riesgo no suele ser comprar una tarjeta vieja, sino una que fue desmontada, reflasheada o usada con mala refrigeración
para usuarios DIY, el problema real suele estar en la placa adaptadora, alimentación, temperatura hotspot y refrigeración de backplate

1. Empieza por fecha de producción y pistas de lote

Un método práctico es revisar primero la fecha del chip y luego ver si las fechas de componentes cercanos encajan.

Por ejemplo, si la superficie del chip muestra 1828, normalmente significa:

18 = año 2018
28 = semana 28

Ese chip se produjo en la semana 28 de 2018.

Además del encapsulado del chip, los inductores cercanos suelen tener marcas relacionadas con fecha. Si la fecha del chip y la de los inductores están muy separadas, por ejemplo:

chip de 2017
inductores que apuntan a 2020

conviene tener cuidado. No prueba automáticamente que la tarjeta sea mala, pero sugiere que ya no está en estado muy original.

Si las fechas encajan de forma amplia, como un chip 2018 con componentes 2018, o un chip de finales de 2019 con componentes 2020, eso es mucho más normal.

2. No mires solo el chip: revisa inductores, resortes y marco

La inspección visual conviene dividirla en varios controles.

1. Toca primero los inductores

Presiona o toca suavemente los inductores. En condiciones normales, ninguno debería sentirse suelto.

Si alguno se mueve, suele significar:

la soldadura no está sana
el problema puede empeorar con el uso

Aunque la tarjeta funcione ahora, no es una buena señal.

2. Revisa si el resorte de retención fue retirado antes

Hay una lógica útil:

si el vendedor insiste en que es una “original server pull”
entonces el resorte de retención normalmente no debería haberse retirado casualmente

En un entorno normal de servidor de fábrica, la gente no retira ese resorte sin razón.

Si el resorte sale muy fácil, probablemente la tarjeta fue abierta antes. Si el vendedor además dice que nunca fue tocada, esa afirmación merece escepticismo.

3. Si el marco se separa demasiado fácil, también sospecha

Una vez retirado el marco medio, si toda la estructura se separa casi sin esfuerzo, suele significar que la tarjeta ya fue desmontada varias veces.

En V100 usadas, reflasheos, modificaciones y reparaciones suelen dejar exactamente ese tipo de trazas.

3. Si el backplate se separa demasiado fácil, sospecha reflasheo o manipulación previa

Un detalle importante es que hay una placa metálica bajo el PCB. No solo protege; también ayuda a disipar calor.

En estado original normal, este backplate no suele ser fácil de retirar por:

adhesivo
ajuste estructural estrecho
diseño no pensado para desmontajes repetidos

Si el backplate se separa del PCB con poca fuerza, sospecha:

fue abierta antes
pudo tener VBIOS reflasheado
pudo sufrir modificaciones secundarias

No la vuelve automáticamente inutilizable, pero contradice claramente “original e intacta”.

4. Cómo leer `ECC`: importa más si crece que si es cero

ECC es una de las primeras cosas que se miran en una V100, y hay que interpretarlo con cuidado.

Un método común es usar nvidia-smi en modo detallado y revisar ECC Errors.

1. Los errores en tiempo real son los más peligrosos

La sección superior puede entenderse como errores en tiempo real.

Si esos números siguen aumentando mientras la tarjeta corre, normalmente significa que ya está en estado inestable.

En simple:

una tarjeta que corre sin nuevos errores importa más que una lectura estática de cero
una tarjeta cuyos errores aumentan bajo estrés preocupa mucho más que una con solo conteos históricos acumulados

2. Los errores acumulados de por vida no siempre son terroríficos

Otra sección muestra errores acumulados de vida útil.

Si esos valores son:

de un solo dígito
o quizá decenas bajas

no es automáticamente desastre.

Si los errores en tiempo real no siguen aumentando durante uso real, la tarjeta puede seguir siendo perfectamente usable.

3. La sección de page retirement merece más atención

La sección de page retirement es aún más importante, porque indica bloques de memoria retirados tras errores no corregibles.

Una forma práctica de verlo:

categorías single-bit y double-bit pueden tener bloques retirados
si el total supera 10, entras en una zona donde conviene cautela

No siempre significa que la tarjeta sea inutilizable, pero sugiere menor memoria efectiva y menor confianza a largo plazo.

5. No veneres “zero ECC”: los datos pueden manipularse

Advertencia práctica:

los números ECC no son sagrados por sí mismos.

Si una tarjeta tiene:

datos extremadamente limpios
señales obvias de desmontaje
estructura claramente trabajada

no confíes en “zero ECC” por sí solo.

La analogía útil es un coche viejo que de pronto muestra 0 kilometraje y casi nada de desgaste. Cuesta no sospechar del odómetro.

Con V100 aplica igual:

números demasiado perfectos no siempre son buena noticia
importa que datos, estado físico y comportamiento bajo estrés tengan sentido juntos

6. El stress test es necesario, pero no basta probar el core

Puedes usar herramientas como gpu-burn durante varios minutos o más y observar:

si permanece estable
si la tarjeta desaparece
si aparecen nuevos errores ECC

Pero probar solo el core no demuestra que toda la tarjeta esté sana.

Muchos fallos de V100 no empiezan en el core, sino en:

sobrecalentamiento de alimentación
refrigeración insuficiente del backplate
temperaturas hotspot excesivas
adaptadores y refrigeración operando demasiado al límite

El stress test solo prueba que “la tarjeta corre ahora”. No prueba que “este setup DIY sobrevivirá a largo plazo”.

7. Para DIY, el punto débil suele ser refrigeración y alimentación

Esta quizá sea la parte más importante.

Para usuarios DIY, combinar una base adaptadora cualquiera con un cooler genérico no es un plan robusto.

V100 no es una tarjeta de consumo normal. Es un acelerador de servidor con:

alto consumo
alta densidad térmica
distribución de calor complicada

El chip no es lo único que genera calor. Backplate, zona de alimentación y conectores también se calientan, a veces mucho.

1. No mires solo temperatura promedio de GPU

Muchas herramientas muestran temperatura promedio, pero el número peligroso suele ser el hot spot.

Puede pasar que:

la temperatura visible esté en 60 y pico Celsius
mientras hotspots locales ya superen 100C

Por eso algunos builds DIY de V100 parecen “bien” en papel y luego mueren de repente.

2. La refrigeración de backplate debe considerarse

No puedes ignorar backplate y zona de alimentación.

Si solo enfrías el core, pero:

descuidas la zona MOS
el backplate no recibe ayuda térmica
la parte trasera carece de diseño térmico adecuado

el setup sigue incompleto.

3. Los water-cooling improvisados baratos son riesgosos

Cuidado con setups tipo “adaptador aleatorio + AIO barato”.

El problema no es que fallen siempre de inmediato. Es que a menudo tienen:

cobertura desigual de canales de agua
refrigeración incompleta de alimentación
control pobre de zonas hotspot reales
vida útil impredecible

8. Si aún quieres DIY, vigila al menos esto

Recomendaciones prácticas:

prefiere adaptadores más maduros y con historial
no te centres solo en el core; alimentación trasera y backplate también necesitan atención térmica
el bloque de agua necesita cobertura real y manejo uniforme del calor
tras stress test, sigue observando temperaturas, hotspots y comportamiento a largo plazo
la calidad de PSU también afecta coil whine y estabilidad

Lo difícil de un build V100 DIY no es “hacer que arranque”. Es “mantenerlo vivo y estable después”.

9. Coil whine y variación de adaptadores también son problemas reales

Dos puntos se pasan por alto.

1. El coil whine quizá no se elimine del todo

Depende de la tarjeta concreta, inductores, capacitores y entorno de alimentación. No siempre se arregla con un cable o accesorio.

2. La variación entre adaptadores es enorme

Por eso algunos vendedores, incluso vendiendo tarjeta desnuda, enfatizan:

probarla en banco primero
registrar número de serie
hacer stress tests
documentar el proceso

Muchos conflictos no vienen del silicio, sino del adaptador y la refrigeración usados después.

Cierre

¿Sigue valiendo la pena comprar Tesla V100? Sí, pero solo si entiendes qué compras y cómo planeas usarla.

No basta revisar:

si enciende
si ECC está todo en cero
si el vendedor dice “original pull”

Es más útil verificar:

si fechas y pistas de lote encajan
si hay señales sospechosas de desmontaje
si backplate y estructura fueron abiertos
si los errores aumentan bajo stress test
si tu refrigeración y alimentación son confiables

Especialmente para usuarios DIY, la parte más peligrosa de V100 no suele ser comprar una tarjeta vieja, sino subestimar lo exigentes que son en refrigeración, alimentación y calidad de modificación.

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.

Guía práctica de formatos tensoriales comunes en LLMs: FP32, FP16, BF16, TF32 y FP8

Wed, 22 Apr 2026 22:40:00 +0800

En cuanto empiezas a trabajar con entrenamiento, inferencia o despliegue de modelos grandes, aparece un conjunto familiar de abreviaturas: FP32, FP16, BF16, TF32 y FP8. Parecen pequeñas etiquetas en una página de modelo, pero su impacto es mucho mayor que una diferencia de nombre.

Estos formatos determinan cómo se almacenan los números en memoria y cómo se representan durante el cálculo. Afectan directamente la estabilidad del entrenamiento, la velocidad de inferencia e incluso qué tamaño de modelo puede manejar realmente una GPU.

Así que si quieres entender los tradeoffs de precisión en modelos grandes, uno de los mejores puntos de partida no es una tabla de benchmarks de un modelo concreto, sino una imagen clara de qué son estos formatos tensoriales y por qué se diseñaron así.

Qué determinan realmente los formatos tensoriales

En esencia, un modelo grande es un conjunto masivo de operaciones matriciales sobre enormes cantidades de parámetros, y el formato tensorial es cómo esos números se almacenan en memoria y se representan durante el cálculo.

El tradeoff suele girar alrededor de tres dimensiones:

precisión
uso de VRAM
velocidad de cómputo

Se parece bastante a los formatos de imagen. Los formatos sin pérdida preservan más detalle, pero ocupan más espacio y cargan más lento. Los formatos comprimidos descartan información menos perceptible a cambio de menor tamaño y manejo más rápido. Los modelos grandes aceptan tradeoffs similares porque, en conjuntos enormes de parámetros, muchos cambios numéricos diminutos no afectan significativamente la salida final.

Por eso el mundo de modelos desarrolló toda una familia de formatos de precisión.

Cómo se representa un número

Antes de entrar en formatos, conviene recordar una estructura básica. Un número de punto flotante suele tener tres partes:

bit de signo: determina positivo o negativo
bits de exponente: determinan rango numérico
bits de mantisa: determinan detalle numérico

En modelos grandes, la precisión de mantisa importa, pero muchos modelos son incluso más sensibles a un rango numérico insuficiente, es decir, muy pocos bits de exponente y mayor riesgo de overflow o entrenamiento inestable. Mucho del diseño de formatos tensoriales consiste en redistribuir un número limitado de bits entre rango y detalle.

El diagrama siguiente da una vista general:

FP32: el más estable, pero caro

FP32 es el formato tradicional de punto flotante de precisión simple. Usa 32 bits en total, o 4 bytes.

Sus fortalezas son claras:

rango numérico amplio
alta precisión
comportamiento de entrenamiento más estable

La desventaja es igual de clara: consume mucha VRAM.

Una estimación muy aproximada:

`1`	`VRAM usage ~= parameter count * bytes per parameter`

Si un modelo 27B guarda pesos enteramente en FP32, solo los pesos ocupan aproximadamente:

`1`	`27B * 4 bytes ~= 108GB`

Y eso no incluye activaciones, KV cache, estado del optimizador u otros overheads. Por eso, en entrenamiento e inferencia modernos, FP32 ya no es tanto el formato predeterminado como la línea base más estable.

FP16: mitad de tamaño, pero menos estable

FP16 comprime cada parámetro a 2 bytes, reduciendo memoria aproximadamente a la mitad frente a FP32.

Para el mismo modelo 27B, mirando solo tamaño de pesos:

`1`	`27B * 2 bytes ~= 54GB`

Eso ya explica por qué muchas guías colocan un modelo 27B alrededor de 50GB de VRAM.

Ventajas de FP16:

mucha menos presión de VRAM
mayor throughput
uso amplio en entrenamiento mixed-precision temprano

Su debilidad es el rango de exponente relativamente pequeño. En entrenamiento de modelos grandes, eso hace más probable el overflow y suele requerir técnicas extra como loss scaling, añadiendo complejidad de ingeniería.

Así que FP16 sigue siendo común, pero en muchos escenarios ya no es la opción más cómoda.

BF16: una half precision más práctica para la era de modelos grandes

BF16 también usa 2 bytes, pero hace un tradeoff distinto a FP16.

Mantiene un rango de exponente mucho mayor, acercando su rango dinámico a FP32, mientras sacrifica algo de precisión de mantisa. Ese tradeoff funciona especialmente bien en modelos grandes, porque suelen ser más sensibles al rango que a perder unos pocos bits de mantisa.

Por eso muchos frameworks de entrenamiento, papers de modelos grandes y setups reales prefieren BF16.

Una forma simple de pensarlo:

coste de VRAM cercano a FP16
estabilidad más cercana a FP32

Si una guía de despliegue 27B pide alrededor de 50GB de VRAM y otra optimizada se acerca a 30GB, la primera suele vivir aún en la capa FP16/BF16, mientras la segunda normalmente avanzó hacia menor precisión o cuantización.

TF32: no ahorra VRAM, acelera flujos FP32

TF32 es fácil de confundir con otro formato de ahorro de memoria, pero su rol es distinto.

En términos comunes, puedes pensarlo como un formato de cómputo que mantiene un rango de exponente grande y acorta la precisión de mantisa.

Pero es importante notar que TF32 se parece más a un formato interno de cálculo usado en la ruta Tensor Core, no algo usado principalmente para almacenar pesos como FP16 o BF16.

Es sobre todo un modo de cómputo que NVIDIA ofrece en GPUs nuevas. El objetivo no es reducir VRAM, sino hacer que flujos originalmente basados en FP32 corran más rápido sin grandes cambios de código.

Su rol se resume así:

externamente sigue pareciendo un flujo FP32
internamente ejecuta math matricial aproximada más rápida

Así que TF32 resuelve principalmente que FP32 es demasiado lento, no que use demasiada memoria. Si tu pregunta es por qué el mismo modelo puede tener requisitos de VRAM muy distintos, TF32 no es la respuesta principal.

FP8: más compresión, pero exige mucha más ingeniería

Un paso más lleva a FP8. Comprime cada valor en aún menos bits, reduciendo más el ancho de banda de memoria y el coste de almacenamiento.

Normalmente no aparece como un único formato, sino como dos variantes comunes: E4M3 y E5M2.

Pero FP8 tiene un coste obvio: con tan pocos bits, es muy difícil preservar rango y precisión al mismo tiempo. En la práctica, distintas variantes se usan en distintas etapas para equilibrar forward pass, backward pass y gradientes.

Esta familia representa una estrategia más agresiva:

renunciar a más precisión
ganar menor coste de almacenamiento y mayor throughput
depender de hardware y frameworks más maduros

Tiene mucho potencial, pero para la mayoría de usuarios las divisiones prácticas principales siguen siendo FP32, FP16 y BF16.

Por qué importa entender estos formatos

Mucha gente primero trata estas abreviaturas como detalles de implementación en una página de descarga. Pero en la práctica cambian cómo piensas sobre entrenamiento y despliegue.

Por ejemplo, ayudan a explicar:

por qué algunos setups de entrenamiento se preocupan tanto por la estabilidad numérica
por qué algunas stacks de inferencia priorizan cuantización y baja precisión
por qué modelos con conteos de parámetros similares pueden tener requisitos de despliegue muy distintos
por qué algunos formatos son mejores para almacenar pesos y otros tienen más sentido como rutas de cómputo

Si sigues desarmando esas preguntas, vuelves al mismo punto: cómo eliges intercambiar precisión, rango, memoria y velocidad.

Por eso entender FP32, FP16, BF16, TF32 y FP8 no es solo decodificar un glosario. Es entender qué se está intercambiando realmente al leer una config de entrenamiento, elegir un motor de inferencia o comparar opciones de despliegue.

Un modelo mental práctico

Si no quieres memorizar todos los detalles de inmediato, ayuda recordarlos así:

FP32: más estable, más caro
FP16: menos uso de VRAM, pero menor rango
BF16: coste de VRAM similar a FP16, pero estabilidad más adecuada para modelos grandes
TF32: resuelve principalmente lentitud de FP32, no uso de VRAM
FP8: ruta más agresiva de compresión y aceleración

Después, cuando veas fp16, bf16 o fp8 en una página de modelo, o cuando distintas guías den umbrales de VRAM muy diferentes, ya no parecerá una diferencia de palabras. Esas etiquetas reflejan presupuestos de precisión y elecciones de ingeniería muy distintos.

Cierre

Los formatos tensoriales en modelos grandes parecen una discusión sobre anchos de bits, pero debajo son una discusión sobre tradeoffs de ingeniería.

FP32, FP16, BF16, TF32 y FP8 no son simplemente mejores o peores entre sí. Cada uno se ubica en un punto diferente de la curva entre estabilidad, rango, precisión, memoria y velocidad.

Cuando entiendes claramente esa capa, resulta mucho más fácil leer papers de entrenamiento, ajustar inferencia y comparar estrategias de despliegue con el modelo mental correcto.

Una GPU de 16GB aún puede ejecutar modelos 35B: estrategias de compresión VRAM para modelos MoE en LM Studio

Wed, 22 Apr 2026 21:47:34 +0800

Mucha gente piensa que 16GB de VRAM es el punto donde el despliegue local de LLMs se queda más o menos en modelos 12B a 14B, y que cualquier cosa más grande se vuelve demasiado dolorosa incluso con cuantización. Esa visión es comprensible, pero no es el techo real de una GPU de 16GB.

Si eliges bien el modelo y configuras bien los parámetros, una GPU de 16GB no tiene por qué limitarse a modelos pequeños. Un enfoque representativo es usar modelos MoE dentro de LM Studio con una estrategia sensata de descarga, de modo que modelos de clase 35B sigan funcionando a una velocidad realmente usable.

01 Por qué una GPU de 16GB no necesariamente se limita a 12B-14B

La idea central es simple: el tamaño de VRAM importa, pero la arquitectura del modelo importa igual.

Si intentas meter un modelo dense estándar en una GPU de 16GB, chocarás con el límite rápidamente. Estos modelos suelen involucrar todos los parámetros durante inferencia, así que la presión de VRAM y ancho de banda sube de inmediato.

Pero los modelos MoE son distintos. Su número total de parámetros puede ser grande, mientras solo una parte de los parámetros expertos se activa en cada paso de inferencia. Tomando como ejemplo un modelo de clase 35B: aunque el total de parámetros es alto, el número real que participa en cada paso es mucho menor, así que su requisito real de VRAM no es tan extremo como muchos asumen.

Por eso una GPU de 16GB todavía deja cierto margen de trabajo.

02 Conclusión práctica clave: los modelos MoE 35B pueden correr sorprendentemente rápido

Un caso representativo es un modelo MoE cuantizado como Qwen 3.5 35B A3B. Con una GPU de 16GB y los ajustes correctos en LM Studio, la cuantización Q6 puede superar los 30 tokens/s, y Q4 a veces prueba incluso más alto.

Ese resultado importa no solo porque el modelo “corre”, sino porque la velocidad ya está en un rango claramente usable.

En comparación, modelos grandes de escala similar que no son MoE suelen sufrir overflow de VRAM y caídas bruscas de velocidad en una GPU de 16GB. En otras palabras, el resultado no se determina solo por el número de parámetros. Importa cómo se usan esos parámetros durante inferencia.

03 En LM Studio, la clave no es un solo parámetro

Si quieres que este tipo de modelo corra con fluidez en una GPU de 16GB, el truco real no es suerte. Es ajustar correctamente dos parámetros:

GPU Offload
el ajuste que fuerza parte de las capas expertas a memoria CPU

El primero es fácil de entender. GPU Offload básicamente se empuja lo más alto posible para que el modelo priorice cálculo en GPU.

El segundo es la clave. No es el enfoque tradicional de “tomar prestada memoria del sistema cuando se desborda la VRAM”. En su lugar, coloca proactivamente parte de las capas expertas en memoria CPU para reducir uso de VRAM desde el inicio. Como los modelos MoE no activan todos los expertos en cada paso, mover algunos expertos a memoria no perjudica la velocidad global tanto como muchos esperarían.

Una forma más segura de ajustarlo es empezar en un rango y luego afinar gradualmente según tu máquina:

empezar con valores relacionados entre 20 y 35
luego ajustar según uso de VRAM y presión de memoria

En el fondo, este método usa memoria del sistema para recuperar margen de VRAM.

04 Puede seguir funcionando a 128K de contexto, y contextos menores reducen más la VRAM

Otro punto interesante es que incluso con longitud de contexto en 128K, un modelo MoE de clase 35B puede mantener una velocidad relativamente alta.

Eso dice algo importante: el cuello de botella de una GPU de 16GB no es tan rígido como muchos imaginan. Especialmente en una herramienta local como LM Studio, la pregunta real no suele ser simplemente si corre o no, sino:

si aceptas intercambiar más memoria del sistema por menos uso de VRAM
si aceptas acortar la longitud de contexto
si aceptas distintos compromisos de capacidad entre niveles de cuantización

Si reduces el contexto de 128K a 64K o 32K, la presión de VRAM baja aún más. Eso significa que algunos modelos MoE de clase 35B podrían incluso correr, con dificultad, en GPUs con menos VRAM, aunque velocidad y presión de memoria tendrán que reequilibrarse.

05 El coste: mucha más demanda de RAM y memoria virtual

Este setup no es rendimiento gratis.

Lo que debes vigilar es que, al comprimir más la presión de VRAM, el uso de RAM del sistema sube notablemente, y también la presión de memoria virtual. En otras palabras, no eliminas el coste: lo desplazas desde la GPU hacia RAM y swap en disco.

Si quieres probarlo, revisa primero:

si tu RAM del sistema es suficiente
si tu asignación de memoria virtual es suficiente
si demasiadas apps de fondo ya consumen recursos

Si esas condiciones no están, quizá no obtengas “35B corriendo rápido”, sino una máquina lenta en todo.

06 Una cuantización más agresiva no siempre es mejor

Hay otro compromiso práctico. La cuantización de menos bits suele ahorrar más VRAM, pero eso no la convierte automáticamente en la mejor opción.

La conclusión práctica es que algunos modelos corren más rápido en Q4, pero su capacidad original también puede degradarse más. En comparación, Q6 tiende a equilibrar mejor velocidad y retención de capacidad. Así que la elección correcta depende de qué te importe más:

máxima velocidad y encajar en VRAM
o preservar más capacidad original del modelo

Esas dos prioridades no siempre llevan a la misma cuantización.

07 Qué modelos vale la pena probar

Desde este ángulo, lo mejor no es perseguir ciegamente más parámetros, sino buscar primero modelos que encajen con esta estrategia:

modelos construidos sobre arquitectura MoE
modelos bien soportados en LM Studio y con variantes cuantizadas completas
modelos con ventajas claras en contexto largo o seguimiento de instrucciones

La idea no se detiene en un único modelo MoE 35B. También se extiende a modelos experimentales con memoria de contexto largo más fuerte, mejor seguimiento de instrucciones o variantes cuantizadas más ligeras con gran velocidad.

La lógica es consistente: primero encuentra modelos cuya arquitectura encaje con la estrategia de intercambiar memoria por VRAM, y luego habla de tuning. No empieces solo por número de parámetros.

08 Conclusión breve

Si tienes una GPU de 16GB y asumes que los LLMs locales se detienen en 12B-14B, vale la pena actualizar esa suposición.

Una forma más precisa de decirlo:

una GPU de 16GB no queda automáticamente descartada para modelos más grandes
modelos dense y modelos MoE deben considerarse por separado
GPU Offload y transferencia de capas expertas a memoria CPU en LM Studio pueden cambiar significativamente el uso de VRAM
en la práctica, intercambias mayor presión de memoria por más escala de modelo y mejor velocidad usable

Este enfoque no encaja con todas las máquinas, pero muestra algo importante: en despliegue local de LLMs, la VRAM no es el único límite. La arquitectura del modelo y la configuración de inferencia importan igual.

12V-2x6 frente a 12VHPWR: notas sobre las diferencias en el conector de alimentación de 16 pines de la GPU

Sun, 19 Apr 2026 23:21:17 +0800

Entre las GPU de gama alta recientes, el conector de alimentación del que se habla con más frecuencia es probablemente el “12VHPWR” y el más nuevo “12V-2x6”. Ambos parecen conectores de 16 pines, con un diseño “12 + 4”, pero no son exactamente la misma interfaz.

En términos simples, “12V-2x6” puede entenderse como una revisión del diseño anterior “12VHPWR” bajo “ATX 3.1” y “PCIe CEM 5.1”. Mantiene la capacidad de salida de alta potencia, pero utiliza un diseño más conservador para la detección de inserción y la estructura del terminal. El objetivo es reducir el riesgo de que el conector siga soportando carga cuando no está completamente asentado.

01 Las diferencias de cables son pequeñas

La primera pregunta que preocupa a mucha gente es si los cables modulares “12V-2x6” y “12VHPWR” se pueden utilizar indistintamente.

Si nos fijamos únicamente en el cable en sí, la diferencia no suele ser grande. El verdadero cambio está principalmente en el conector del lado de la placa, como el zócalo de la GPU o el zócalo de la placa posterior de la fuente de alimentación modular. Tanto los cables modulares “12V-2x6” más nuevos como los cables modulares “12VHPWR” más antiguos todavía están destinados a la entrega de energía de GPU de 16 pines.

Por lo tanto, la compatibilidad no debe juzgarse únicamente por la longitud, el calibre o la apariencia del cable. Las especificaciones del socket del lado de la GPU y de la PSU, la calidad del terminal y la declaración de compatibilidad oficial del proveedor de la fuente de alimentación son más importantes.

02 Cambios mecánicos clave

El objetivo de 12V-2x6 no es cambiar completamente la forma exterior del conector, sino ajustar la estructura de los pines.

Sus 12 pines de alimentación principales son más largos y hacen contacto antes, mientras que los 4 pines de señal SENSE son más cortos y hacen contacto más tarde. La lógica es sencilla: sólo cuando el conector se inserta lo suficientemente profundo los pines SENSE deben conducir correctamente, permitiendo a la GPU identificar la capacidad de energía deseada.

Este cambio apunta a un problema típico expuesto por los primeros conectores “12VHPWR”: el enchufe puede parecer insertado, pero en realidad puede no estar completamente asentado. Bajo cargas elevadas, un contacto insuficiente puede generar calor y, en casos graves, puede quemar el enchufe o el enchufe.

03 Lógica SENTIDA más conservadora

SENTIDO0	SENTIDO1	Encendido inicial (encendido)	Potencia máxima sostenida
Terreno	Terreno	375 W	600 vatios
Abrir	Terreno	225 W	450 vatios
Terreno	Abrir	150W	300W
Corto	Corto	100 vatios	150W
Abrir	Abrir	0W	0W

La mejora de seguridad en 12V-2x6 se centra en la lógica SENSE.

En la definición más reciente, si “SENSE0” y “SENSE1” están en el estado flotante “Abierto”, la GPU no se encenderá normalmente o no entrará en el estado de entrada de alta potencia correspondiente. En otras palabras, cuando el conector no está colocado correctamente, el sistema es más propenso a impedir el funcionamiento en lugar de dejar que la GPU siga consumiendo energía.

Esto es más conservador que los primeros “12VHPWR”. En diseños más antiguos, incluso si el estado SENSE no fuera ideal, algunos casos aún podrían permitir un cierto nivel de entrada de energía. Para las GPU de alta potencia, esa tolerancia puede convertirse en un riesgo.

Acortar los pines SENSE es esencialmente una forma de hacer que “completamente insertados” sea un requisito previo más estricto.

04 Qué significa H++

Los conectores “12V-2x6” más nuevos suelen llevar una marca “H++”. Indica que los terminales del conector admiten una capacidad de corriente 9.2A o superior, lo que los distingue de los conectores 12VHPWR anteriores marcados como H+.

Vale la pena señalar que “H++” no significa que el límite de potencia del conector supere los 600 W. Ya sea nuevo o antiguo, el límite superior común para este esquema de energía de GPU de 16 pines sigue siendo “600W”. H++ se entiende mejor como especificación de terminal e identificación de versión de conector, no simplemente como “mayor potencia”.

05 Qué significa para la construcción de PC

Para la construcción diaria de PC, el mayor valor de “12V-2x6” es reducir el riesgo relacionado con la inserción, pero no es un escudo mágico.

Al utilizar este tipo de conector, vale la pena prestar atención a algunas cosas:

Insertar completamente el enchufe; No confíe sólo en si “parece insertado”.
Evite doblar demasiado el cable justo al lado del conector de la GPU.
No deje que el panel lateral ejerza presión sobre el cable.
Prefiera cables originales, personalizados o adaptadores explícitamente admitidos por el proveedor de PSU o GPU.
Evite adaptadores baratos de origen desconocido en GPU de alta potencia.

Si la carcasa está apretada, un cable en forma de L de 90 grados o un cable personalizado certificado por el proveedor pueden reducir la presión de flexión. Aún así, la calidad del terminal, el calibre del cable y la certificación del proveedor son más importantes que la apariencia.

06 Resumen rápido

12V-2x6 no es un conector que sea “básicamente igual que 12VHPWR porque tiene el mismo aspecto”. Sus cambios reales están dentro de la estructura del conector y la lógica de detección.

Puedes pensarlo de esta manera:

La forma del cable es similar, pero el conector del lado de la placa y el diseño del terminal son más importantes.
Los pines de alimentación principales son más largos, mientras que los pines SENSE son más cortos.
Cuando el conector no está completamente asentado, es más probable que el nuevo diseño impida que la GPU entre en estado de funcionamiento.
La marca H++ identifica terminales con mayor capacidad de corriente.
El límite de potencia común de la GPU sigue siendo “600W”.

Si está construyendo un sistema con una GPU de alta potencia, “12V-2x6” es de hecho más tranquilizador que el anterior “12VHPWR”. Pero la seguridad final aún depende de si el enchufe está completamente colocado, la calidad del cable, el diseño de la fuente de alimentación y el espacio para la gestión de cables de la caja. Un mejor estándar de conector no hace que una instalación descuidada sea segura.

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

Cómo comprobar si un modelo de Ollama ya se cargó en la GPU

Mon, 06 Apr 2026 10:15:18 +0800

Si quieres confirmar si un modelo de Ollama se está ejecutando realmente en la GPU, el método más directo es revisar la información de uso de procesador de los modelos cargados actualmente.

Comando

`1`	`ollama ps`

Salida de ejemplo

1
2

NAME        ID            SIZE    PROCESSOR   UNTIL
llama3:70b  bcfb190ca3a7  42 GB   100% GPU    4 minutes from now

Cómo interpretar la columna `PROCESSOR`

100% GPU: el modelo está cargado por completo en la memoria de la GPU.
100% CPU: el modelo está cargado por completo en la memoria del sistema (no usa GPU para inferencia).
48%/52% CPU/GPU: una parte del modelo está en memoria del sistema y otra en memoria de GPU; es una carga mixta.

Consejos prácticos

Si esperas usar GPU pero ves 100% CPU, revisa primero el driver de la tarjeta gráfica, el entorno CUDA/ROCm y los parámetros de ejecución de Ollama.
Cuando el modelo es grande y la memoria de GPU no alcanza, suele aparecer una carga mixta CPU/GPU.
Al diagnosticar problemas de rendimiento, ejecuta primero ollama ps y luego mira los datos de velocidad; así podrás ubicar antes el cuello de botella.

Resumen

ollama ps es el primer paso para saber si un modelo está usando realmente la GPU. Basta con fijarse en la columna PROCESSOR para confirmar rápidamente dónde está cargado el modelo y decidir la siguiente dirección de optimización.

GPU on KnightLi Blog

Cómo elegir una GPU en abril de 2026: qué modelos evitar y cuáles vale más la pena considerar

Modelos que no priorizaría

1. RTX 5060 Ti 8GB

2. Tarjetas antiguas y caras, especialmente RTX 3080 10GB y RTX 3070 Ti cuando todavía tienen un precio elevado

3. Insignias más antiguas con un historial poco claro, como RTX 3090 y RTX 3080 Ti

4. RTX 5070 cuando el precio no es el adecuado

Modelos que tienen más sentido

1. RTX 5060 Ti 16GB

2. RTX 5070 Ti

3. Las tarjetas nuevas con un precio adecuado suelen ser una mejor primera opción que las tarjetas más antiguas de alta gama

Si solo quieres la versión corta

Línea final

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

C贸mo solucionar que Ollama use CPU en lugar de GPU

1. Primero, confirma si Ollama realmente no está usando la GPU

2. Descartar primero el malentendido más común: el modelo no cabe en VRAM

3. Comprobar si el driver de la GPU y el runtime de bajo nivel están funcionando realmente

NVIDIA

AMD / ROCm

4. Reinicia el servicio de Ollama, no solo tu terminal

5. Comprobar si las variables de entorno están llegando realmente al servicio

6. En plataformas AMD, céntrate en la compatibilidad de ROCm

7. En Docker, WSL o entornos remotos, comprueba también el mapeo de dispositivos

8. Revisar los registros al final, pero revisarlos por la razón correcta

Orden de Solución de Problemas

Conclusión

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

Cómo comprobar si una Tesla V100 tiene errores ECC

¿Sigue valiendo la pena comprar una Tesla V100? ECC, mods de refrigeración y trampas DIY

Resumen rápido

1. Empieza por fecha de producción y pistas de lote

2. No mires solo el chip: revisa inductores, resortes y marco

1. Toca primero los inductores

2. Revisa si el resorte de retención fue retirado antes

3. Si el marco se separa demasiado fácil, también sospecha

3. Si el backplate se separa demasiado fácil, sospecha reflasheo o manipulación previa

4. Cómo leer ECC: importa más si crece que si es cero

1. Los errores en tiempo real son los más peligrosos

2. Los errores acumulados de por vida no siempre son terroríficos

3. La sección de page retirement merece más atención

5. No veneres “zero ECC”: los datos pueden manipularse

6. El stress test es necesario, pero no basta probar el core

7. Para DIY, el punto débil suele ser refrigeración y alimentación

1. No mires solo temperatura promedio de GPU

2. La refrigeración de backplate debe considerarse

3. Los water-cooling improvisados baratos son riesgosos

8. Si aún quieres DIY, vigila al menos esto

9. Coil whine y variación de adaptadores también son problemas reales

1. El coil whine quizá no se elimine del todo

2. La variación entre adaptadores es enorme

Cierre

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

1. `RTX 5060 Ti 8GB`

2. Tarjetas antiguas y caras, especialmente `RTX 3080 10GB` y `RTX 3070 Ti` cuando todavía tienen un precio elevado

3. Insignias más antiguas con un historial poco claro, como `RTX 3090` y `RTX 3080 Ti`

4. `RTX 5070` cuando el precio no es el adecuado

1. `RTX 5060 Ti 16GB`

2. `RTX 5070 Ti`

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`

4. Cómo leer `ECC`: importa más si crece que si es cero

¿Qué es `OLLAMA_SCHED_SPREAD`?