Si alguna vez intentaste «simplemente añadir otra GPU» y esperaste que la gráfica subiera sin más, ya has conocido al villano de esta historia:
el mundo real. El multi‑GPU en los juegos de consumo —NVIDIA SLI y AMD CrossFire— parecía pura justicia de ingeniería: paralelismo,
más silicio, más frames, listo.
Luego lo lanzaste. Los tiempos de fotograma se convirtieron en una valla. La pila de controladores pasó a ser una negociación entre el motor del juego, el planificador de GPU, PCIe
y el timing del monitor que creías entender. Tu costosa segunda tarjeta a menudo se convirtió en un radiador con currículum.
La promesa: escalar añadiendo GPUs
El multi‑GPU, tal como se vendía a los jugadores, era un cuento operativo: tu juego está limitado por la GPU, por lo tanto otra GPU significa casi el doble de rendimiento.
Ese es el argumento. También es la primera suposición equivocada. Los sistemas no escalan porque una diapositiva de marketing diga «2×»; los sistemas escalan cuando la parte más lenta
del pipeline deja de ser la más lenta.
Un frame moderno de un juego es una línea de ensamblaje desordenada: simulación de CPU, envío de draw calls, renderizado por GPU, post‑procesado, composición, presentación,
y un contrato de sincronización con tu pantalla. SLI/CrossFire intentó ocultar la complejidad multi‑GPU detrás de controladores, perfiles y un puente. Ese ocultamiento es
exactamente lo que lo condenó.
El sueño del multi‑GPU murió porque chocó contra la física (latencia y sincronización), la economía del software (los desarrolladores no prueban configuraciones raras) y
los cambios de plataforma (DX12/Vulkan trasladaron la responsabilidad del driver al motor). Y porque el «FPS medio» resultó ser una omisión: lo que perciben tus ojos es la consistencia de los tiempos de fotograma, no la media.
Cómo funcionaba realmente SLI/CrossFire
Multi‑GPU gestionado por el controlador: perfiles hasta el fondo
En la era clásica, SLI/CrossFire dependía de heurísticas del controlador y perfiles por juego. El controlador decidía cómo repartir el renderizado entre las GPUs
sin que el juego lo supiera explícitamente. Eso suena conveniente. También es una pesadilla operativa: ahora tienes un sistema distribuido donde un nodo
(el juego) no sabe que está distribuido.
Los perfiles importaban porque la mayoría de los juegos no estaban escritos para paralelizarse de forma segura entre GPUs. El controlador necesitaba «pistas» específicas del juego para evitar
peligros como leer datos que aún no se habían producido, o aplicar post‑procesados que asumen un historial completo de frames.
Los modos principales: AFR, SFR y «por favor no hagan eso»
Alternate Frame Rendering (AFR) fue el caballo de batalla. GPU0 renderiza el frame N, GPU1 renderiza el frame N+1, repetir. En papel: fantástico.
En la práctica: AFR es una máquina de latencia y pacing. Si el frame N tarda 8 ms y el frame N+1 tarda 22 ms, tu «FPS medio» puede parecer correcto mientras tus
ojos reciben un pase de diapositivas con pasos extra.
Split Frame Rendering (SFR) divide un solo frame en regiones. Esto exige un balanceo de carga cuidadoso: una mitad de la pantalla puede
contener una explosión, sombreado de pelo, volumétricos y tus remordimientos; la otra mitad es una pared. Adivina qué GPU termina primero y se queda en espera.
También hubo modos híbridos y trucos específicos de cada proveedor. Cuantos más trucos necesites, menos general será tu solución. En algún punto ya no estás
ofreciendo «soporte multi‑GPU»; estás escribiendo respuesta a incidentes por título dentro del controlador.
Puentes, PCIe y por qué el interconector nunca fue el héroe
Los puentes SLI (y los puentes CrossFire en eras anteriores) ofrecían un camino de mayor ancho de banda y menor latencia para ciertas operaciones de sincronización y compartición de buffers
que PCIe por sí solo. Pero el puente no fusionaba mágicamente la VRAM. Cada GPU seguía teniendo su propia memoria. En AFR, cada GPU típicamente necesitaba su
propia copia de las mismas texturas y geometría. Así que tus «dos tarjetas de 8 GB» no se convertían en «16 GB». Se convertían en «8 GB, dos veces».
Cuando los desarrolladores comenzaron a apoyarse más en técnicas temporales—TAA, reflexiones en espacio de pantalla con buffers históricos, escaladores temporales—AFR se volvió
cada vez más incompatible. No puedes renderizar fácilmente el frame N+1 en GPU1 si necesita historial del frame N que vive en GPU0, a menos que añadas
sincronización y transferencia de datos que borran la ganancia de rendimiento.
Una idea parafraseada, ampliamente atribuida en espíritu al pensamiento de confiabilidad de sistemas (y a menudo mencionada por ingenieros en el órbita SRE de Google): Idea parafraseada: la esperanza no es una estrategia.
Encaja perfectamente con el multi‑GPU. SLI/CrossFire te pedía esperar que el pipeline de renderizado de tu juego se alineara con las suposiciones del controlador.
Por qué falló: la muerte por mil casos límite
1) El pacing de frames mató el «se siente rápido»
AFR puede entregar un alto FPS medio mientras produce tiempos de fotograma desiguales (microstutter). Los humanos notan la varianza. Tu overlay de monitor puede mostrar
«120 FPS», mientras tu cerebro registra «inconsistente». Este fue el fallo central de experiencia de usuario: SLI/CrossFire podía ganar en benchmarks y perder
frente a los ojos.
El pacing de frames no es solo «un poco de jitter». Interactúa con VSync, VRR (G‑SYNC/FreeSync), profundidad de cola de renderizado y la planificación de la CPU. Si el controlador
encola frames demasiado agresivamente, obtienes latencia de entrada. Si encola muy poco, obtienes burbujas y stutter.
Broma #1: El multi‑GPU es como tener dos becarios que escriben páginas alternadas del mismo informe: rápido, hasta que notas que discrepan en la trama.
2) Espejado de VRAM: pagaste por memoria que no podías usar
En el consumo, el multi‑GPU casi siempre espejaba activos en la memoria de cada GPU. Eso permitió escalado sin tratar la memoria como un pool coherente compartido,
pero también significó que texturas de alta resolución, geometría grande y estructuras de aceleración de trazado moderno quedaron limitadas por la menor
VRAM en una sola tarjeta.
A medida que los juegos demandaban más VRAM, el plan de «añadir una segunda GPU» empeoró: tu cuello de botella se trasladó del cómputo a la capacidad de memoria, y el multi‑GPU
no ayudó. Peor aún, una segunda GPU aumentó consumo eléctrico, calor y necesidad de flujo de aire en el chasis mientras entregaba el mismo límite de VRAM que una sola tarjeta.
3) La CPU se convirtió en coordinadora, y tampoco escaló
Multi‑GPU no es solo «dos GPUs». Es trabajo extra del controlador, gestión adicional de command buffers, más sincronización y a menudo más overhead de draw calls.
Muchos motores ya estaban limitados por la CPU en el hilo de render. Añadir una segunda GPU puede desplazar el cuello de botella hacia arriba y convertir a la CPU en el limitante.
En términos productivos: añadiste capacidad a un servicio downstream sin aumentar el throughput upstream. Felicitaciones, inventaste una nueva cola.
4) El modelo de perfiles del controlador no sobrevivió a la cadena de suministro de software
SLI/CrossFire gestionado por controlador requería que los proveedores mantuvieran el ritmo con nuevos lanzamientos de juegos, parches, actualizaciones de motores y nuevas técnicas de render.
Los estudios publicaban actualizaciones semanales. Los vendedores de GPU sacaban controladores en una cadencia más lenta y tenían que probar miles de combinaciones.
Un perfil multi‑GPU que funciona en la versión 1.0 puede romperse en la 1.0.3 porque cambió el orden de un pase de post‑procesado, o porque un nuevo filtro temporal ahora
lee un buffer del frame anterior. El «optimizar» del controlador a ciegas puede volverse aquello que corrompe el frame.
5) VRR (frecuencia variable) y multi‑GPU se hicieron la vida imposible
La frecuencia de refresco variable es una de las mejores mejoras de calidad de vida en el juego de PC. También complica el pacing multi‑GPU: la pantalla se adapta al
ritmo de entrega de frames, así que si AFR crea ráfagas y huecos, VRR no puede «suavizarlos»; mostrará fielmente la desigualdad.
Muchos usuarios actualizaron a monitores VRR y descubrieron que su configuración multi‑GPU previamente «aceptable» ahora se veía peor. No es culpa del monitor.
Es que por fin estás viendo la verdad.
6) Llegó el multi‑GPU explícito, y la industria no quiso pagar la factura
DX12 y Vulkan hicieron posible el multi‑adaptador explícito: el motor puede controlar múltiples GPUs directamente. Eso es técnicamente más limpio que la magia del controlador.
También es trabajo de ingeniería costoso que beneficia a una fracción minúscula de clientes.
Los estudios priorizaron características que se enviaban a todos: mejores escaladores temporales, mejor antialiasing, mejores pipelines de contenido, mejor paridad con consolas.
El multi‑GPU era una carga de soporte con bajo ROI. Murió como muchas funciones empresariales: en silencio, porque nadie financió la rotación de on‑call.
7) Energía, térmicas y limitaciones de caja: la capa física se defendió
Dos GPUs de gama alta demandan un margen serio de PSU, buen flujo de aire y a menudo una placa base que pueda proveer suficientes líneas PCIe sin estrangulamiento. La
«caja de consumo + dos GPUs tope de gama» es un proyecto de ingeniería térmica. Y la mayoría de la gente quería un ordenador, no un hobby que queme polvo.
8) Seguridad y estabilidad: la pila de controladores se volvió un radio de explosión mayor
Cuanto más compleja sea la lógica de planificación del controlador y la sincronización entre GPUs, más modos de fallo: pantallas negras, TDRs (timeout detection and recovery),
corrupciones extrañas, crashes específicos por juego. En términos operativos, aumentaste la complejidad del sistema y redujiste el tiempo medio hasta la inocencia.
Broma #2: SLI prometía «dos GPUs», pero a veces entregaba «el doble de resolución de problemas», lo cual no es una característica que nadie mida en benchmarks.
Contexto histórico: hechos que la gente olvida
- Hecho 1: El nombre original «SLI» vino de Scan‑Line Interleave de 3dfx a finales de los 90; NVIDIA reutilizó el acrónimo más tarde con un enfoque técnico diferente.
- Hecho 2: El multi‑GPU de consumo temprano a menudo se apoyó mucho en AFR porque era la manera más fácil de escalar sin reescribir motores.
- Hecho 3: El escalado multi‑GPU fue notoriamente inconsistente: algunos títulos vieron ganancias casi lineales, otros cero, y algunos se volvieron más lentos por overhead de CPU/controlador.
- Hecho 4: «Microstutter» se convirtió en una queja general a principios de los 2010s cuando los analistas comenzaron a medir tiempos de fotograma en lugar del FPS medio.
- Hecho 5: AMD invirtió en mejoras de pacing de frames en controladores tras críticas generalizadas; ayudó, pero no cambió las limitaciones subyacentes de AFR.
- Hecho 6: Muchos motores utilizaron cada vez más buffers de historial temporal (TAA, escalado temporal, vectores de movimiento), que son inherentemente incómodos para AFR.
- Hecho 7: El ancho de banda de PCIe subió con las generaciones, pero la latencia y el overhead de sincronización siguieron siendo problemas centrales para dependencias frame‑a‑frame.
- Hecho 8: El multi‑GPU explícito de DX12/Vulkan puso el control en la aplicación; la mayoría de los estudios optó por no implementarlo porque la matriz de pruebas explotaba.
- Hecho 9: NVIDIA restringió/cambió gradualmente el soporte SLI en generaciones posteriores, enfocándose en segmentos de gama alta y casos de uso específicos en vez de soporte amplio por título.
Qué lo reemplazó (más o menos): multi‑GPU explícito y alternativas modernas
Multi‑GPU explícito: mejor arquitectura, peor economía
El multi‑GPU explícito (multi‑adaptador de DX12, device groups de Vulkan) es como lo diseñarías si estuvieras sobrio: el motor sabe qué cargas pueden ejecutarse en
qué GPU, qué datos necesitan compartirse y cuándo sincronizar. Esto elimina mucha suposición del controlador.
También exige que el motor esté estructurado para paralelismo entre dispositivos: duplicación de recursos, barreras entre dispositivos, manejo cuidadoso de efectos temporales,
y estrategias diferentes para distintas combinaciones de GPU. Eso no es «soportar SLI». Es construir un segundo renderizador.
Algunos títulos lo experimentaron. La mayoría de los estudios hizo las cuentas y compró otra cosa: escaladores temporales, mejor threading de CPU y optimizaciones de contenido que ayudan a todos los usuarios.
El «multi‑GPU» moderno que realmente funciona: especialización
El multi‑GPU sigue vivo donde la carga es naturalmente paralela y no requiere coherencia estricta frame a frame:
- Renderizado offline / path tracing: Puedes dividir muestras o teselas entre GPUs y fusionar resultados.
- Cómputo / entrenamiento ML: Paralelismo de datos con frameworks explícitos, aunque todavía con dolores de sincronización.
- Pipelines de codificación de vídeo: GPUs separadas pueden manejar flujos o etapas separadas.
Para el juego en tiempo real, la estrategia ganadora fue: una GPU potente, mejor programación, mejor escalado y mejores técnicas de generación de frames. No
porque sea «cool», sino porque es operacionalmente sensato.
Guía rápida de diagnóstico
Cuando alguien dice «mi segunda GPU no hace nada» o «SLI lo empeoró», no empieces con palancas místicas del controlador. Trátalo como un incidente.
Establece qué está limitado y luego aisla.
Primero: confirma que el sistema ve ambas GPUs y que el enlace está sano
- ¿Ambos dispositivos aparecen en PCIe?
- ¿Funcionan a la generación/anchura PCIe esperada?
- ¿Está instalado el puente correcto (si se requiere)?
- ¿Los conectores de alimentación son correctos y estables?
Segundo: confirma que la ruta de software es realmente multi‑GPU
- ¿Se sabe que el juego soporta SLI/CrossFire para tu generación de GPU?
- ¿El perfil del controlador está presente/habilitado?
- ¿La vía de la API (DX11 vs DX12 vs Vulkan) es compatible con el modo multi‑GPU del proveedor?
Tercero: mide los tiempos de fotograma e identifica el recurso limitante
- Utilización por GPU (no solo «total»).
- Saturación del hilo de render de la CPU.
- Uso de VRAM y comportamiento de paginación.
- Pacing de frames (percentil 99 del tiempo de fotograma), no solo FPS medio.
Cuarto: elimina variables hasta que el comportamiento sea explicable
- Desactiva VRR/VSync temporalmente para observar el pacing bruto.
- Prueba un título/benchmark conocido con escalado documentado.
- Prueba cada GPU individualmente para descartar una tarjeta marginal.
Tareas prácticas: comandos, salidas y decisiones
Estas asumen una estación Linux usada para pruebas/CI, reproducción en laboratorio, o simplemente porque disfrutas del dolor de forma reproducible. El punto no es
que Linux sea donde el SLI para juegos alcanzó su cúspide; es que Linux te da observabilidad sin una búsqueda del tesoro en GUI.
Tarea 1: Listar GPUs y confirmar la topología PCIe
cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|display'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06]
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06]
Qué significa: Dos GPUs se enumeran en el bus PCIe. Si solo ves una, detente: tienes un problema de hardware/firmware.
Decisión: Si falta una GPU, vuelca, revisa cables de alimentación, ajustes BIOS (Above 4G decoding, configuración de slots PCIe), y vuelve a probar.
Tarea 2: Verificar ancho y generación del enlace PCIe para cada GPU
cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 8GT/s, Width x16
LnkSta: Speed 8GT/s, Width x16
Qué significa: La GPU está negociando PCIe Gen3 x16 como se espera. Si ves x8 o Gen1, has encontrado un cuello de botella o fallback.
Decisión: Si el enlace está degradado, revisa el cableado de slots, el reparto de líneas de la placa base (M.2 que roba líneas), BIOS PCIe, risers y la integridad de la señal.
Tarea 3: Confirmar que el controlador NVIDIA ve ambas GPUs e informa utilización
cr0x@server:~$ nvidia-smi -L
GPU 0: GeForce GTX 1080 Ti (UUID: GPU-aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee)
GPU 1: GeForce GTX 1080 Ti (UUID: GPU-ffffffff-1111-2222-3333-444444444444)
Qué significa: La capa del controlador ve ambos dispositivos. Si uno falta aquí pero aparece en lspci, probablemente tienes un problema de binding del controlador o incompatibilidad de firmware.
Decisión: Si falta, revisa dmesg en busca de errores de GPU, verifica módulos del kernel y confirma que ambas GPUs son soportadas por el driver instalado.
Tarea 4: Observar utilización y memoria por GPU durante carga
cr0x@server:~$ nvidia-smi dmon -s pucvmet
# gpu pwr gtemp mtemp sm mem enc dec mclk pclk pviol rxpci txpci
0 210 78 - 92 55 0 0 5500 1582 0 120 110
1 95 64 - 18 52 0 0 5500 1582 0 40 35
Qué significa: GPU0 está realizando trabajo real; GPU1 está mayormente inactiva pero aún mantiene VRAM similar (espejado de activos). Ese es el comportamiento clásico de «segunda GPU no utilizada».
Decisión: Si GPU1 permanece inactiva, verifica que la vía de la aplicación soporte multi‑GPU; de lo contrario, deja de intentar arreglar una no‑característica.
Tarea 5: Confirmar detalles de sesión Xorg/Wayland (para evitar sorpresas del compositor)
cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland
Qué significa: Estás en Wayland. Algunas herramientas y ciertas rutas legacy de multi‑GPU se comportan diferente bajo Wayland vs Xorg.
Decisión: Si depuras problemas de render/presentación, reproduce bajo Xorg como control para aislar efectos de timing del compositor.
Tarea 6: Revisar logs del kernel por errores PCIe y resets de GPU
cr0x@server:~$ sudo dmesg -T | egrep -i 'pcie|aer|nvrm|gpu|xid' | tail -n 12
[Mon Jan 13 10:19:22 2026] NVRM: Xid (PCI:0000:02:00): 79, GPU has fallen off the bus.
[Mon Jan 13 10:19:22 2026] pcieport 0000:00:03.1: AER: Corrected error received: 0000:02:00.0
Qué significa: «Fallen off the bus» a menudo indica inestabilidad de alimentación/temperaturas, riser defectuoso, slot inestable o problemas de integridad de señal—el multi‑GPU hace esto más probable.
Decisión: Trátalo como fiabilidad de hardware: reduce el límite de potencia, mejora la refrigeración, vuelve a montar, intercambia slots, elimina risers, actualiza BIOS y prueba estabilidad antes de culpar al driver.
Tarea 7: Comprobar indicadores de cuello de botella de CPU (carga, cola de ejecución, throttling)
cr0x@server:~$ uptime
10:22:11 up 3 days, 6:41, 1 user, load average: 14.82, 13.97, 12.10
Qué significa: Un load average alto puede indicar saturación de CPU o hilos ejecutables acumulándose. Los juegos pueden estar limitados por la CPU en un solo hilo de render incluso si la CPU total no está «al 100%».
Decisión: Si la carga es alta y la utilización GPU es baja, deja de perseguir ajustes SLI. Reduce ajustes pesados de CPU (distancia de visión, densidad de población), o acepta que estás limitado por la CPU.
Tarea 8: Inspeccionar uso por núcleo para detectar un hilo de render pegado
cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (server) 01/13/2026 _x86_64_ (16 CPU)
10:22:18 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
10:22:19 AM all 42.0 0.0 8.0 0.2 0.0 0.5 0.0 0.0 0.0 49.3
10:22:19 AM 3 98.5 0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.5
Qué significa: Un núcleo (CPU3) está saturado. Ese es tu cuello de botella de render/juego. Dos GPUs no ayudarán si el frame no puede ser alimentado.
Decisión: Reduce ajustes limitados por CPU, o cambia a una CPU/plataforma con mejor rendimiento de hilo único. Multi‑GPU no arreglará un tubo estrecho upstream.
Tarea 9: Verificar presión de memoria (la paginación puede hacerse pasar por «stutter de GPU»)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 32Gi 30Gi 500Mi 1.2Gi 1.5Gi 1.0Gi
Swap: 16Gi 10Gi 6.0Gi
Qué significa: Estás haciendo mucho swap. Eso destruirá los tiempos de fotograma sin importar cuántas GPUs apiles.
Decisión: Arregla la presión de memoria primero: cierra apps en segundo plano, reduce ajustes de textura, añade RAM y vuelve a probar. Trata el uso de swap como alarma roja para el pacing.
Tarea 10: Confirmar frecuencia de CPU y estado de throttling
cr0x@server:~$ lscpu | egrep -i 'model name|cpu mhz'
Model name: AMD Ryzen 9 5950X 16-Core Processor
CPU MHz: 3599.998
Qué significa: La frecuencia actual se muestra, pero no si está haciendo throttling bajo carga sostenida.
Decisión: Si los relojes bajan bajo carga de juego, arregla la refrigeración o los límites de potencia. Multi‑GPU aumenta el calor en la caja, lo que puede reducir silenciosamente el boost de la CPU.
Tarea 11: Revisar flags de capping / throttling de potencia en NVIDIA
cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | egrep -i 'Power Limit|Clocks Throttle Reasons' -A3
Power Limit : 250.00 W
Clocks Throttle Reasons
Idle : Not Active
Applications Clocks Setting : Not Active
SW Power Cap : Active
Qué significa: La GPU está alcanzando un tope de potencia por software. En multi‑GPU, PSUs y térmicas de VRM pueden forzar límites conservadores.
Decisión: Si el tope de potencia está activo y el rendimiento es inconsistente, considera bajar el objetivo de FPS, mejorar el flujo de aire o ejecutar una sola GPU a relojes sostenidos más altos.
Tarea 12: Comprobar pistas de compartición de líneas PCIe desde el estado NVLink/bridge (cuando esté disponible)
cr0x@server:~$ nvidia-smi topo -m
GPU0 GPU1 CPU Affinity
GPU0 X PHB 0-7
GPU1 PHB X 8-15
Qué significa: PHB indica que la comunicación pasa por el puente host PCIe; no es un camino peer‑to‑peer estrecho. Eso puede perjudicar cualquier carga que necesite tráfico entre GPUs.
Decisión: Si la topología es pobre, deja de esperar que la colaboración entre GPUs sea barata. Prefiere renderizado en una sola GPU o particionado explícito de la carga que evite compartir.
Tarea 13: Confirmar visibilidad de dispositivos en Vulkan (para experimentos multi‑GPU explícitos)
cr0x@server:~$ vulkaninfo --summary | egrep -i 'GPU id|deviceName' -A1
GPU id : 0 (GeForce GTX 1080 Ti)
deviceName = GeForce GTX 1080 Ti
GPU id : 1 (GeForce GTX 1080 Ti)
deviceName = GeForce GTX 1080 Ti
Qué significa: Vulkan ve ambos dispositivos. Eso es un prerrequisito para apps multi‑GPU explícitas, no una garantía de que algún juego lo soporte.
Decisión: Si solo aparece uno, arregla la instalación del driver/runtime. Si ambos aparecen, pasa a las comprobaciones a nivel de aplicación.
Tarea 14: Validar latencia de almacenamiento (sí, puede parecer «stutter de GPU»)
cr0x@server:~$ iostat -xz 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
38.12 0.00 6.21 8.93 0.00 46.74
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await aqu-sz %util
nvme0n1 210.0 38400.0 0.0 0.00 3.10 182.86 75.0 10240.0 9.80 2.10 78.00
Qué significa: Alto iowait y await elevado pueden causar hitches en el streaming. Multi‑GPU no arreglará compilaciones de shaders ni latencia de streaming de activos.
Decisión: Si el almacenamiento está saturado, reduce IO en segundo plano, mueve el juego a almacenamiento más rápido y arregla el comportamiento de caché de shaders. Arregla el cuello de botella real.
Errores comunes (síntomas → causa raíz → solución)
1) «La segunda GPU muestra 0–10% de utilización»
Síntomas: Una GPU se calienta, la otra está inactiva; FPS sin cambios respecto a una sola GPU.
Causa raíz: La vía del juego/API no soporta multi‑GPU gestionado por el controlador, o el perfil del controlador está ausente/deshabilitado.
Solución: Valida el soporte del título para tu generación de GPU y modo de API. Si el juego es DX12/Vulkan y no implementa multi‑GPU explícito, acepta una sola GPU.
2) «Mayor FPS medio, pero se siente peor»
Síntomas: El benchmark dice más rápido; la jugabilidad se siente con stutter; VRR lo hace más evidente.
Causa raíz: Varianza de tiempos de fotograma por AFR (microstutter), encolamiento o carga por frame inconsistente.
Solución: Mide los tiempos de fotograma y limita FPS para estabilizar el pacing, o desactiva multi‑GPU. Prioriza 1% low / percentil 99 del tiempo de fotograma sobre medias.
3) «Las texturas aparecen de golpe y el hitching se vuelve brutal en 4K»
Síntomas: Picos repentinos, especialmente al girar rápido o entrar en áreas nuevas.
Causa raíz: El límite de VRAM es por GPU; el espejado significa que no ganaste capacidad. Estás paginando activos y bloqueando.
Solución: Baja la resolución de texturas, reduce ajustes de RT, o cambia a una sola GPU con más VRAM.
4) «Pantallas negras aleatorias / GPU desapareció»
Síntomas: Reseteos del controlador, una GPU desaparece del bus, problemas de estabilidad intermitentes.
Causa raíz: Inestabilidad en la entrega de potencia, estrés térmico, integridad marginal de PCIe o un overclock que era «estable» en una tarjeta.
Solución: Vuelve a relojes de stock, reduce el límite de potencia, mejora la refrigeración, verifica el cableado, evita risers, actualiza BIOS y prueba cada GPU sola.
5) «Funciona en una versión de driver, falla en la siguiente»
Síntomas: El escalado desaparece o aparecen artefactos después de actualizar controladores.
Causa raíz: Cambios en perfiles, cambios de scheduling o regresión en caminos de código multi‑GPU (ahora de baja prioridad).
Solución: Fija versiones de controladores para tu caso de uso, documenta combinaciones conocidas buenas y no trates «último controlador» como inherentemente mejor para multi‑GPU.
6) «Dos GPUs, pero el uso de CPU se ve bajo—aún limitado por CPU»
Síntomas: Utilización de GPU baja, FPS topeado, CPU total por debajo del 50%.
Causa raíz: Uno o dos hilos calientes (render thread, game thread). La CPU total oculta saturación por núcleo.
Solución: Observa uso por núcleo. Reduce ajustes pesados de CPU; busca tiempos de fotograma estables; considera actualizar plataforma en lugar de añadir GPUs.
7) «PCIe x8/x4 inesperado, escalado pobre»
Síntomas: Escalado peor del esperado; stutter alto durante el streaming; topo muestra rutas PHB.
Causa raíz: Compartición de líneas con M.2/otros dispositivos, elección de slot incorrecta o limitaciones del uplink del chipset.
Solución: Usa los slots correctos, reduce consumidores de líneas o elige una plataforma con más líneas de CPU si insistes en configuraciones multi‑dispositivo.
Tres micro‑historias corporativas desde el terreno
Micro‑historia 1: El incidente causado por una suposición errónea
Un estudio pequeño tenía un «laboratorio de rendimiento» con unas pocas máquinas de pruebas de gama alta. Alguien había montado una máquina monstruo: dos GPUs tope, mucho RGB y una
hoja de cálculo de números de benchmark que alegraba a la dirección. El estudio la usó para aprobar presupuestos de rendimiento para un nuevo nivel cargado de contenido.
La suposición errónea fue sutil: asumieron que el escalado era representativo. Su máquina de aprobación ejecutaba AFR con un perfil de controlador que casualmente funcionaba bien para esa build específica. Produjo un gran FPS medio en el laboratorio. No produjo buenos tiempos de fotograma en la mayoría de las máquinas de los usuarios, y definitivamente no representó la línea base de una sola GPU que poseía la mayoría.
Llegó la semana de lanzamiento. Las redes se llenaron de quejas de «stutter en el nuevo nivel». Internamente, la máquina del laboratorio parecía «bien». Los ingenieros comenzaron
a perseguir bugs fantasma en animación y física porque los gráficos de GPU no parecían saturados.
El verdadero culpable fue el streaming de activos más un nuevo efecto temporal. En la máquina del laboratorio, AFR enmascaró parte del tiempo de GPU solapando trabajo, mientras empeoraba el pacing de una forma que el estudio no medía. En las máquinas de los consumidores con una sola GPU, el mismo efecto empujó la VRAM al límite y desencadenó paginación y thrash de caché de shaders. El estudio había optimizado para la realidad equivocada.
La solución no fue un ajuste mágico de multi‑GPU. Reconstruyeron su gate de rendimiento: una sola GPU, medición basada en tiempos de fotograma, con umbrales de presión de memoria. La máquina dual se quedó en el laboratorio, pero dejó de ser la fuente de la verdad. El incidente terminó cuando dejaron de confiar en un benchmark que no coincidía con la población de usuarios.
Micro‑historia 2: La optimización que se volvió en contra
Un equipo de visualización empresarial (pensemos: escenas CAD grandes, walkthroughs en tiempo real) intentó «obtener rendimiento gratis» activando AFR en un entorno controlado. Sus escenas
dependían mucho de acumulación temporal: anti‑aliasing, denoise y mucha lógica de «usar el frame anterior». Alguien argumentó que, dado que las GPUs eran idénticas, los resultados deberían ser consistentes.
Obtuvieron mayor throughput medio con cámara estática. Gran demo. Luego enviaron una beta a algunos stakeholders internos. En cuanto movías la cámara, la estabilidad de imagen se degradó: ghosting, shimmer y filtros temporales inconsistentes. Peor aún, la latencia interactiva se sintió peor porque la profundidad de cola aumentó bajo AFR.
El retroceso fue arquitectónico: el pipeline temporal del renderer asumía un historial de frames coherente. AFR dividió ese historial entre dispositivos. El equipo agregó puntos de sincronización y transferencias entre GPUs para «arreglarlo», lo que destruyó la ganancia de rendimiento e introdujo nuevos stalls. Ahora tenían complejidad y sin aumento de velocidad.
Eventualmente eliminaron AFR e invirtieron en un conjunto aburrido pero efectivo de mejoras: culling en CPU, simplificación de shaders y reglas de LOD de contenido. El sistema final fue más rápido en una sola GPU que la build AFR en dos. La optimización falló porque optimizó la capa equivocada: intentó paralelizar algo que era fundamentalmente serial en términos de dependencia temporal.
Micro‑historia 3: La práctica aburrida pero correcta que salvó el día
Un grupo de validación de hardware en una empresa mediana mantenía una flota de nodos de prueba GPU. No jugaban en ellos; ejecutaban regresiones de render y compute y ocasionalmente reproducían bugs de clientes. Los nodos incluían cajas multi‑GPU porque los clientes las usaban para cómputo, no porque fuera divertido.
Su arma secreta no era un scheduler ingenioso. Era un changelog. Cada nodo tenía una versión de driver fijada, una baseline de firmware fijada y una matriz simple de «conocido‑bueno». Las actualizaciones se desplegaban por etapas: un nodo canario primero, luego un lote pequeño y luego el resto. Sin excepciones. A nadie le gustaba. Parecía lento.
Una semana, un driver nuevo introdujo errores correctables PCIe en una revisión específica de placa base cuando ambas GPUs estaban bajo carga mixta. En el workstation de un desarrollador parecía crash aleatorio de aplicaciones. En la flota, el nodo canario empezó a emitir logs AER en horas.
Porque el grupo tenía disciplina aburrida, correlacionaron la línea de tiempo, revertieron el canario y bloquearon el despliegue. No hubo inestabilidad en la flota, no hubo reimaging masivo, no hubo scramble. Abrieron un ticket con el proveedor con logs reproducibles y una receta de reproducción precisa.
La «salvación» no fue depuración heroica. Fue la práctica operacional de despliegues por etapas y fijado de versiones. Los sistemas multi‑GPU amplifican problemas marginales; la única respuesta sensata es tratar los cambios como cambios de producción, no como experimentos de fin de semana.
Listas de verificación / plan paso a paso
Paso a paso: decidir si vale la pena tocar multi‑GPU
- Define el objetivo. ¿Es mayor FPS medio, mejores 1% lows o una carga de cómputo/render específica?
- Identifica el tipo de carga. ¿Tiempo real con efectos temporales? Asume «no». ¿Render offline/cómputo? Quizá «sí».
- Comprueba la realidad de soporte. Si la app no implementa multi‑GPU explícito y el proveedor ya no soporta perfiles de controlador, para aquí.
- Mide la baseline. Una sola GPU, driver estable, tiempos de fotograma, uso de VRAM, CPU por núcleo.
- Añade la segunda GPU. Verifica ancho de enlace PCIe, potencia, térmicas y topología.
- Re‑mide. Busca mejoras en el percentil 99 del tiempo de fotograma y throughput, no solo en el FPS medio.
- Decide. Si las ganancias son pequeñas o el pacing empeora, retíralo. El impuesto de complejidad es real.
Paso a paso: estabilizar una máquina multi‑GPU (cuando debes mantenerla)
- Arranca con relojes de stock. Los overclocks que son «estables» en una GPU pueden fallar en condiciones térmicas de doble GPU.
- Valida el presupuesto de potencia. Asegura margen de PSU; evita cables de alimentación PCIe en cadena para consumos altos.
- Bloquea versiones. Fija driver/firmware; despliega actualizaciones como en producción.
- Instrumenta. Loggea dmesg, eventos AER, razones de throttling de GPU, temperaturas y utilización.
- Fija expectativas. Para gaming, estás optimizando para estabilidad y pacing, no para capturas de benchmark.
Preguntas frecuentes
1) ¿SLI/CrossFire funcionó alguna vez de verdad?
Sí—a veces. En títulos bien perfilados con DX11, pipelines amigables con AFR y dependencias temporales mínimas, el escalado podía ser fuerte. El problema es que «a veces» no es una estrategia de producto.
2) ¿Por qué la VRAM no se sumaba entre GPUs en los juegos?
Porque cada GPU necesita acceso local a texturas y geometría a máxima velocidad, y el multi‑GPU de consumo típicamente espeja recursos por tarjeta. Sin un modelo de memoria unificada, no puedes tratar dos pools de VRAM como uno sin pagar costos elevados de sincronización y transferencia.
3) ¿Qué es el microstutter, operativamente hablando?
Es varianza de latencia. Entregas frames en intervalos inconsistentes—ráfagas y huecos—por lo que el movimiento se ve desigual. Es la razón por la que el «FPS medio» es una métrica peligrosamente incompleta.
4) ¿Por qué DX12/Vulkan hicieron que el multi‑GPU fuera más raro en lugar de más común?
Lo hicieron explícito. Eso es arquitectónicamente honesto pero traslada el trabajo al equipo del motor: gestión de recursos, sincronización, pruebas a través de combinaciones de GPU y cobertura de QA. La mayoría de los estudios no quiso financiar eso para una base de usuarios pequeña.
5) ¿Pueden dos GPUs diferentes trabajar juntas para juegos ahora?
No en la forma antigua de «el controlador lo hace por ti». El multi‑adaptador explícito puede, en teoría, usar GPUs heterogéneas, pero el soporte en el mundo real es raro y generalmente especializado. Para juegos típicos: asume que no.
6) ¿Y NVLink—lo arregla?
NVLink ayuda en ciertos escenarios peer‑to‑peer de ancho de banda y es valioso en cómputo. No resuelve automáticamente el pacing de frames, las dependencias temporales o el problema económico de software. Los interconectores no arreglan la arquitectura.
7) Si ya tengo dos GPUs, ¿qué debería hacer?
Para juegos: usa una GPU y vende la otra, o repúrposeala para cómputo/codificación. Para cómputo: usa frameworks que soporten explícitamente multi‑GPU y mide el escalado con tamaños de lotes realistas y el overhead de sincronización.
8) ¿Qué métricas debería confiar al probar multi‑GPU?
Percentiles de tiempo de fotograma (como el 99.º), sensación de latencia de entrada (difícil de medir, fácil de notar), utilización por GPU, margen de VRAM y logs de estabilidad.
El FPS medio es una métrica de vanidad en este contexto.
9) ¿Está el multi‑GPU completamente muerto?
No de forma general—solo en el gaming en tiempo real de consumo como vía de aceleración por defecto. El multi‑GPU prospera donde la carga se puede particionar limpiamente: render offline, cómputo científico, ML y algunos pipelines de visualización profesional.
Próximos pasos que realmente puedes tomar
Si estás pensando en multi‑GPU para juegos en 2026, aquí va un consejo directo: no. Compra la mejor GPU única que puedas justificar, luego optimiza para tiempos de fotograma, margen de VRAM y una pila de controladores estable. Obtendrás un sistema que se comporta de forma predecible, que es lo que quieres cuando eres quien tiene que depurarlo.
Si debes ejecutar multi‑GPU—porque tu carga es cómputo, render offline o visualización especializada—trátalo como infraestructura de producción:
fija versiones, despliega por etapas, instrumenta todo y asume que la segunda GPU aumenta la superficie de fallo más que el rendimiento.
Pasos prácticos:
- Cambia tu mentalidad de pruebas de «FPS medio» a percentiles de tiempo de fotograma y ejecuciones reproducibles.
- Valida ancho de enlace PCIe, topología y estabilidad de potencia antes de tocar controladores.
- Decide por adelantado si tu aplicación usa multi‑GPU explícito; si no, deja de invertir tiempo.
- Mantén una baseline de controladores conocida y trata las actualizaciones como despliegues controlados.