Falsificaciones y reacondicionados: Cómo evitar una GPU fantasma

octubre 24, 2025 • febrero 3, 2026 • Lectura: 26 min • Views: 0

¿Te fue útil?

Compraste “una tarjeta de clase A100” a través de un intermediario porque los plazos de entrega eran pésimos y finanzas peor aún. Llega en una caja que parece haber sobrevivido a una pequeña guerra, la colocas en el rack y entonces… tus trabajos de ML corren como si hicieran cálculos en una tostadora.

Bienvenido a la GPU fantasma: hardware que “aparece” en el inventario y más o menos funciona, hasta que no. Falsificaciones, reacondicionados, firmware desajustado, desgaste por minería, impostores virtualizados y revendedores bienintencionados que difuminan la línea entre “probado” y “encendido una vez”. Si gestionas sistemas de producción, la postura correcta es el escepticismo respaldado por comprobaciones repetibles.

Qué es realmente una “GPU fantasma” (y por qué ocurre)

Una GPU fantasma no es una sola cosa. Es una categoría de sorpresas desagradables donde el dispositivo se enumera y parece legítimo, pero su identidad, estado o capacidad no son lo que pagaste. El tema es expectativas desajustadas:

Fallo de identidad: Esperabas el Modelo X con 80GB; recibiste el Modelo Y con un vBIOS que miente, o una placa con funciones deshabilitadas.
Fallo de estado: “Nuevo” es en realidad reacondicionado; “reacondicionado” es en realidad procedente de minería o de un centro de datos cripto con vida dura.
Fallo de capacidad: Es el silicio correcto, pero la refrigeración, el enlace PCIe, la alimentación o la estabilidad de memoria están comprometidos.
Fallo de entorno: La GPU es real, pero tu controlador, kernel, firmware, topología PCIe o capa de virtualización la hacen comportarse como una falsa.

Las GPUs modernas son una pila: identificadores de dispositivo PCIe, vBIOS, campos VPD, ID de placa, números de serie, fusibles, telemetría ECC y un controlador que traduce el marketing en realidad. Atacantes, revendedores turbios y accidentes honestos apuntan al mismo punto débil: confiar en la etiqueta más que en la telemetría.

Mi sesgo: trata cada GPU como un dispositivo de almacenamiento. No desplegarías un SSD usado al azar en un clúster de bases de datos sin leer SMART, comprobar el firmware y ejecutar un burn-in. Igual aquí—salvo que las GPUs fallan de formas más creativas.

Broma #1: Una “GPU ligeramente usada para minería” es como un “paracaídas ligeramente usado”. Puede estar bien, pero no quieres descubrir la verdad a mitad de vuelo.

Algunos datos e historia que explican el desorden actual

Un poco de contexto hace que el mercado actual parezca menos caos y más entropía predecible.

Las falsificaciones de GPUs son anteriores a la IA. Mucho antes de los LLMs, los falsificadores reflasheaban tarjetas de consumo de menor gama para que parecieran modelos superiores para gamers y compradores profesionales.
Flashear vBIOS ha sido un hobby durante décadas. Los entusiastas lo usaban para desbloquear funciones, cambiar curvas de ventilador o exprimir rendimiento—creando herramientas y conocimientos que los falsificadores luego aprovecharon.
El boom cripto de 2017–2018 normalizó “flotas de GPU”. Esa ola produjo grandes volúmenes de tarjetas muy usadas que luego reentraron al mercado de reventa, a menudo cosmetizadas.
Las GPUs de centro de datos se convirtieron en objetivo de la cadena de suministro cuando escasearon. Cuando los tiempos de entrega se dispararon, aparecieron brokers de la noche a la mañana. Algunos son legítimos; otros son básicamente servicios de enrutamiento de residuos electrónicos.
La topología PCIe importa más ahora. Los servidores modernos tienen enrutado complejo de líneas, bifurcación, retimers y múltiples root complexes—por lo que “va lento” puede ser tu plataforma, no la tarjeta.
La telemetría ECC cambió el juego. Muchas GPUs de centro de datos exponen contadores de errores corregibles/no corregibles. Eso es un regalo—si realmente lo miras.
MIG y SR-IOV complican la identidad. La partición y virtualización pueden hacer que una GPU legítima parezca “incorrecta” si no sabes en qué modo está.
Los materiales térmicos envejecen más rápido de lo que admite el marketing. Las almohadillas y pastas se degradan; los ventiladores se desgastan; los componentes VRM derivan. Un reacondicionado que “arranca” puede estar a un ciclo térmico de empezar a estrangularse.

Modelo de amenazas: cómo te engañan GPUs falsas y reacondicionadas

1) “Se enumera, por tanto es real” es una trampa

La enumeración PCIe demuestra que tienes un dispositivo. No prueba que sea el dispositivo correcto, el tamaño de memoria correcto o el bin de rendimiento correcto. Los falsificadores pueden suplantar nombres en capas visibles por software. Y los reacondicionados simples pueden llevar firmware desajustado que reporta identificadores confusos.

2) Los tres patrones comunes de fraude

Reflashear un modelo inferior como uno superior: A menudo falla bajo carga, muestra tamaño de memoria extraño o tiene IDs de dispositivo inconsistentes entre herramientas.
Vender placas reparadas como “nuevas”: Componentes re-soldados, chips de memoria reemplazados o GPUs “reballed”. A veces estables, a veces no. Las fallas pueden ser intermitentes y dependientes del calor.
Vender ex-flotas/ex-minería como “reacondicionadas”: El silicio puede ser correcto. El problema es el consumo de vida útil: ventiladores, VRAM y VRMs. Las cargas de minería son brutales: carga constante, calor constante y experimentación frecuente con undervolting/overclocking.

3) La falla poco glamorosa: ambigüedad en compras

El incidente más común de “GPU falsa” en empresas no es un anillo de falsificadores de Hollywood. Es una orden de compra que dice “equivalente A100” y un proceso de recepción de activos que solo comprueba “nvidia-smi muestra algo”. Las fantasmas prosperan en las brechas entre equipos: compras, operaciones de centro de datos, ingeniería de plataforma y finanzas.

4) Mentalidad de fiabilidad, parafraseada

Cita (idea parafraseada): La idea de John Allspaw es que la fiabilidad es resultado del pensamiento sistémico—las suposiciones son el enemigo y los bucles de retroalimentación la cura.

Guía de diagnóstico rápido (primera/segunda/tercera comprobación)

Tienes una GPU que “parece rara”. Tal vez el rendimiento es terrible, tal vez desaparece, tal vez sospechas que no es lo que indica la etiqueta. Aquí tienes cómo encontrar el cuello de botella sin convertir tu día en un hobby forense.

Primero: prueba identidad básica y topología

¿El kernel la ve consistentemente? Revisa la enumeración PCI y los registros del kernel.
¿Está de acuerdo el controlador? Compara lspci vs nvidia-smi (o herramientas ROCm) en busca de consistencia.
¿El enlace PCIe está sano? Velocidad y ancho del enlace. Una tarjeta x16 funcionando a x4 es una “fantasma” en la práctica.

Segundo: prueba que las capacidades coinciden con lo esperado

Tamaño de memoria y estado ECC. ¿Reporta la VRAM esperada? ¿ECC activado/desactivado coincide con la norma del SKU?
Frecuencias y límites de potencia. ¿Está limitada por potencia? ¿Atrapada en un P-state bajo?
Termal bajo carga. ¿Empieza a estrangularse de inmediato?

Tercero: prueba de estabilidad con un burn-in corto

Ejecuta una prueba de carga controlada. Observa errores Xid, picos de ECC, reinicios.
Comprueba persistencia tras reinicios. Algunos fraudes solo aparecen después de un arranque en frío o un ciclo de energía.
Compara con una línea base conocida buena. Mismo tipo de host, mismo controlador, misma prueba.

El objetivo es separar: “tarjeta mala” vs “plataforma mala” vs “configuración mala” en menos de una hora. Si no puedes, no tienes un problema de diagnóstico—tienes una brecha de observabilidad.

Pruebas de aceptación con comandos: demuestra lo que compraste

A continuación hay tareas prácticas que puedes ejecutar en hosts Linux. Cada una incluye: un comando, qué significa la salida típica y qué decisión tomar después. Están escritas para herramientas de NVIDIA porque son comunes en producción, pero la postura aplica en todas partes: verifica desde múltiples capas.

Task 1: Confirmar identidad del dispositivo PCIe y proveedor

cr0x@server:~$ sudo lspci -nn | egrep -i 'vga|3d|nvidia|amd'
01:00.0 3D controller [0302]: NVIDIA Corporation GA100 [A100 PCIe 80GB] [10de:20b5] (rev a1)

Qué significa: Obtienes el par vendor/device ID ([10de:20b5]) y un nombre legible. El ID es más difícil de falsificar que un nombre comercial.

Decisión: Si el ID de dispositivo no coincide con el SKU que compraste, detente. No “veas si funciona”. Abre un ticket de recepción y pon el hardware en cuarentena.

Task 2: Inspeccionar capacidades PCIe extendidas y estado del enlace

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
LnkSta: Speed 16GT/s (ok), Width x16 (ok)

Qué significa: LnkCap es lo que el hardware soporta; LnkSta es lo que realmente negociaron. “(ok)” es tu amigo.

Decisión: Si el ancho es x8/x4 o la velocidad es 8GT/s cuando esperas 16GT/s, investiga la plataforma: colocación, elección de slot, ajustes del BIOS, bifurcación, retimers. Una queja de “GPU falsa” suele ser un error de “slot equivocado” disfrazado.

Task 3: Revisar registros del kernel por errores relacionados con la GPU

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|xid|pcie|aer' | tail -n 25
[Mon Jan 21 09:13:42 2026] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  550.54.14  Tue Dec 17 20:41:24 UTC 2025
[Mon Jan 21 09:14:03 2026] pcieport 0000:00:03.0: AER: Corrected error received: 0000:01:00.0
[Mon Jan 21 09:14:03 2026] nvidia 0000:01:00.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer

Qué significa: Errores AER corregidos pueden ser “más o menos aceptables” o signo de integridad de señal marginal. Errores no corregidos son más graves. Los códigos Xid son fallos a nivel de driver que conviene correlacionar.

Decisión: Si ves spam frecuente de AER bajo carga, sospecha risers, retimers, problemas de slot o hardware borderline. Mueve la GPU a otro host/slot antes de declarar la tarjeta fraudulenta.

Task 4: Confirmar que el controlador ve las mismas GPU(s)

cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA A100-PCIE-80GB (UUID: GPU-3b2c1c39-1d1a-2f0a-8f1a-1f5c8f5c2a11)

Qué significa: La pila de controladores enumera la GPU y expone un UUID. Este es el identificador de inventario que debes rastrear en el CMDB, no “slot 1”.

Decisión: Si lspci muestra la GPU pero nvidia-smi no, sospecha incompatibilidad de controlador, fallo de carga del módulo del kernel, problemas de Secure Boot o una GPU que falla en la inicialización.

Task 5: Capturar campos de inventario completos para comparaciones posteriores

cr0x@server:~$ nvidia-smi -q | egrep -i 'Product Name|Product Brand|VBIOS Version|Serial Number|GPU UUID|Board Part Number|FRU Part Number' -A0
Product Name                    : NVIDIA A100-PCIE-80GB
Product Brand                   : NVIDIA
VBIOS Version                   : 94.00.9F.00.02
Serial Number                   : 0324XXXXXXXXXX
GPU UUID                        : GPU-3b2c1c39-1d1a-2f0a-8f1a-1f5c8f5c2a11
Board Part Number               : 699-2G133-0200-000
FRU Part Number                 : 900-2G133-0200-000

Qué significa: Estos campos ayudan a detectar “lotes mixtos” y cadenas de reacondicionado sospechosas. Si faltan seriales, están duplicados o son inconsistentes entre herramientas, es una señal de alarma.

Decisión: Registra esta salida en la recepción. Si luego hay RMA o auditorías, querrás prueba de lo que realmente recibiste y desplegaste.

Task 6: Comprobar tamaño de memoria, modo ECC y contadores de errores ECC

cr0x@server:~$ nvidia-smi --query-gpu=name,memory.total,ecc.mode.current,ecc.errors.corrected.volatile.total,ecc.errors.uncorrected.volatile.total --format=csv
name, memory.total [MiB], ecc.mode.current, ecc.errors.corrected.volatile.total, ecc.errors.uncorrected.volatile.total
NVIDIA A100-PCIE-80GB, 81920 MiB, Enabled, 0, 0

Qué significa: VRAM y ECC son comprobaciones de cordura. Errores corregibles que aumentan con poco uso pueden indicar memoria envejecida o dañada.

Decisión: Si la VRAM es incorrecta, detente. Si los correctables de ECC aumentan durante el burn-in, pon la tarjeta en cuarentena: no es apta para entrenamiento de producción o inferencia con SLA.

Task 7: Verificar límites de potencia y razones de estrangulamiento

cr0x@server:~$ nvidia-smi --query-gpu=power.draw,power.limit,clocks.current.sm,clocks_throttle_reasons.active --format=csv
power.draw [W], power.limit [W], clocks.current.sm [MHz], clocks_throttle_reasons.active
45.12 W, 250.00 W, 210 MHz, Not Active

Qué significa: Las frecuencias en reposo deberían ser bajas; bajo carga deberías ver cómo suben las frecuencias y la potencia se aproxima al límite. Las razones de estrangulamiento indican si estás limitado por potencia/temperatura.

Decisión: Si hay estrangulamiento activo con cargas modestas, revisa la refrigeración, el cableado de alimentación y las líneas PSU. Si el límite de potencia es extrañamente bajo y está bloqueado, sospecha políticas de firmware o restricciones típicas de algunos reacondicionados.

Task 8: Confirmar la generación PCIe desde la perspectiva del controlador

cr0x@server:~$ nvidia-smi -q | egrep -i 'PCIe Generation|Link Width' -A2
PCIe Generation
    Max                         : 4
    Current                     : 4
Link Width
    Max                         : 16x
    Current                     : 16x

Qué significa: Cruzar esto con lspci. Si discrepan, tienes un problema de reporte de plataforma o un enlace negociado que cambia con el estado de energía.

Decisión: Si Current está por debajo de Max en estado estable bajo carga, puede que estés atascado en un estado de baja energía por ajustes del BIOS o peculiaridades de ASPM.

Task 9: Comprobar temperatura, ventilador y comportamiento de estrangulamiento inmediato

cr0x@server:~$ nvidia-smi --query-gpu=temperature.gpu,temperature.memory,fan.speed,pstate --format=csv
temperature.gpu, temperature.memory, fan.speed [%], pstate
36, 40, 30 %, P8

Qué significa: Las temperaturas en reposo deben ser razonables. Bajo carga, observa las temperaturas de memoria; la memoria puede estrangularse antes que el núcleo.

Decisión: Si la temperatura de la memoria es alta en reposo o se dispara rápidamente, sospecha mala conductividad térmica (común tras un reacondicionado descuidado) o flujo de aire bloqueado.

Task 10: Validar funcionalidad de cómputo con un sample CUDA mínimo

cr0x@server:~$ /usr/local/cuda/samples/1_Utilities/deviceQuery/deviceQuery | egrep -i 'Device 0|CUDA Capability|Total amount of global memory|Result'
Device 0: "NVIDIA A100-PCIE-80GB"
  CUDA Capability Major/Minor version number:    8.0
  Total amount of global memory:                 81161 MBytes (85014073344 bytes)
Result = PASS

Qué significa: Confirma que el runtime ve la capacidad de cómputo y la memoria esperadas. Es una comprobación barata para despistar desaciertos obvios.

Decisión: Si la capacidad de cómputo no coincide con lo esperado, tu “A100” puede ser otra arquitectura, o tu stack de contenedores/controladores está mintiendo mediante bibliotecas incompatibles.

Task 11: Ejecutar un burn-in corto y vigilar eventos Xid/ECC

cr0x@server:~$ sudo gpu-burn -d 60
Burning for 60 seconds.
GPU 0: 0.0%  (0/1024 MB)
GPU 0: 100.0%  (1024/1024 MB)
Tested 1 GPUs:
  GPU 0: OK

Qué significa: Un burn-in rápido no es prueba de salud a largo plazo, pero saca a la luz inestabilidades inmediatas: chips de VRAM malos, alimentación marginal, sobrecalentamiento.

Decisión: Si la prueba hace caer el controlador, desencadena Xid o picos de ECC, pon en cuarentena y vuelve a probar en otro host. Si el problema persiste con la tarjeta, es de la tarjeta.

Task 12: Comprobar comportamiento de reset de la GPU (útil para reacondicionados inestables)

cr0x@server:~$ sudo nvidia-smi --gpu-reset -i 0
GPU 00000000:01:00.0 was reset.

Qué significa: Que el reset funcione es señal de que la GPU responde de forma sensata a controles de gestión.

Decisión: Si el reset falla repetidamente, o la GPU desaparece tras el reset hasta un ciclo completo de energía del host, es una señal de inestabilidad. No la envíes a un pool de nodos Kubernetes confiando en la suerte.

Task 13: Verificar agrupamiento IOMMU para sanity de passthrough / aislamiento

cr0x@server:~$ for d in /sys/kernel/iommu_groups/*/devices/*; do echo "$d"; done | egrep '01:00.0|01:00.1'
/sys/kernel/iommu_groups/42/devices/0000:01:00.0
/sys/kernel/iommu_groups/42/devices/0000:01:00.1

Qué significa: Si haces passthrough, el comportamiento “misterioso” de una GPU puede deberse a IOMMU y ACS. Una GPU legítima puede parecer embrujada cuando está agrupada con otros dispositivos.

Decisión: Si la GPU comparte grupo con almacenamiento o NICs, quizá necesites ajustes de BIOS ACS o cambiar de slot.

Task 14: Confirmar modo de persistencia y políticas de modo de cómputo

cr0x@server:~$ sudo nvidia-smi -pm 1
Enabled persistence mode for GPU 00000000:01:00.0.

Qué significa: La persistencia puede reducir el churn de reinicializaciones y mejorar la estabilidad para algunas cargas. No arregla hardware malo, pero reduce el “ruido” de arranque en frío del driver durante pruebas.

Decisión: Si al activar persistencia aparecen errores, probablemente haya desajuste driver/hardware. Investiga antes del despliegue de cargas.

Task 15: Detectar virtualización/MIG que cambia lo que “ves”

cr0x@server:~$ nvidia-smi -q | egrep -i 'MIG Mode' -A2
MIG Mode
    Current                     : Enabled
    Pending                     : Enabled

Qué significa: Con MIG activado, puede que no veas “una GPU grande” en el scheduler como esperas. La gente diagnostica esto erróneamente como “reacondicionado con VRAM incorrecta” constantemente.

Decisión: Si esperas asignación full-GPU, desactiva MIG (con ventana de mantenimiento) o adapta tu lógica de programación e inventario a instancias MIG.

Task 16: Cruzar errores PCIe en vivo mientras estresas

cr0x@server:~$ sudo journalctl -k -f | egrep -i 'aer|xid|nvrm'
Jan 21 09:22:41 server kernel: NVRM: Xid (PCI:0000:01:00): 13, Graphics SM Warp Exception
Jan 21 09:22:41 server kernel: pcieport 0000:00:03.0: AER: Uncorrected (Non-Fatal) error received: 0000:01:00.0

Qué significa: Correlación en vivo durante estrés es como separas “lento” de “roto”. Xid 13 suele ser relacionado con cómputo; la línea AER apunta a problemas de enlace.

Decisión: Si aparecen errores AER solo en un chasis/slot, arregla la plataforma. Si te siguen a la GPU, hay riesgo de hardware—trátalo en consecuencia.

Broma #2: La GPU más cara es la que pasa la compra y falla en la primera rotación de on-call.

Tres micro-relatos corporativos desde el frente

Micro-relato 1: El incidente causado por una suposición equivocada

Una empresa SaaS de tamaño medio decidió traer la inferencia internamente. Compraron un pequeño lote de “GPUs de clase centro de datos” a través de un broker porque el distribuidor aprobado tenía lista de espera. La comprobación de recepción fue simple: montar el nodo, ejecutar nvidia-smi, confirmar una cadena de nombre y entregarlo al equipo de plataforma.

Todo parecía bien durante una semana. Luego la latencia del servicio de modelos empezó a aumentar de forma que no coincidía con el tráfico. El autoescalado añadió nodos, lo que ayudó brevemente y luego no. El SRE de guardia notó un patrón: los nodos del nuevo lote eran consistentemente más lentos, pero solo bajo carga máxima. Los dashboards culparon a “variación del modelo”. El negocio culpó a “los datos”. Clásico.

La falla real fue una suposición equivocada: “Si nvidia-smi dice A40, es una A40.” Los dispositivos eran placas NVIDIA reales, pero negociaron un ancho PCIe inferior debido a un desajuste de slot/riser en esa generación de chasis. Bajo carga ligera nadie lo notó. Bajo carga pesada, el cuello de botella PCIe hacía las transferencias host-dispositivo dolorosamente lentas, y la lógica de colocación del scheduler seguía poniendo modelos de alto throughput en esos nodos.

La solución fue vergonzantemente simple: mover las GPUs a los slots correctos y bloquear ajustes del BIOS para evitar bifurcación accidental. La lección no fue “los brokers son malvados”. La lección fue que las comprobaciones de identidad deben incluir comprobaciones de topología. Una GPU fantasma puede ser creada por tu propio layout de rack.

Micro-relato 2: La optimización que salió mal

Un equipo ML empresarial quería mayor utilización. Activaron MIG en una flota para que varios equipos compartieran GPUs de forma segura. La idea era buena: aislar cargas, aumentar la equidad, reducir inactividad. Finanzas adoró la proyección.

Entonces los trabajos de entrenamiento empezaron a fallar de formas raras: out-of-memory en tamaños que “deberían caber”, rendimiento inconsistente y algunos contenedores reportando VRAM menor de la esperada. El equipo sospechó de hardware falsificado porque los síntomas coincidían con la leyenda urbana: “la tarjeta miente sobre la memoria”. Escalaron a compras, que escaló a legal, que subió la presión sanguínea de todos.

La causa raíz fue una optimización que salió mal por comunicación incompleta. MIG se había activado, pero el scheduler y la documentación interna aún asumían asignación full-GPU. Algunos equipos lanzaban trabajos grandes en slices MIG y luego se sorprendían cuando el slice se comportaba como un slice. Peor aún, el monitoreo agregaba memoria GPU a nivel de host y hacía parecer que la memoria “desaparecía” durante el día.

La solución fue operativa: etiquetado explícito de perfiles MIG, control de admisión para evitar trabajos full-GPU en dispositivos sliceados y un endpoint de “identidad GPU” que reporte modo MIG y tamaños de instancia. El hardware era inocente; la capa de abstracción fue el bromista.

Micro-relato 3: La práctica aburrida pero correcta que salvó el día

Una fintech con control de cambios estricto trató las GPUs como cualquier otro componente crítico. Cada tarjeta entrante pasaba por un arnés de recepción: registrar IDs PCI, versiones de vBIOS, ejecutar un test de estrés de 30 minutos, registrar contadores ECC antes y después y almacenar resultados en una base de activos indexada por UUID de GPU.

Un trimestre compraron un lote mixto: algunas nuevas, algunas reacondicionadas por el proveedor, todas de canales legítimos. Un subconjunto pasó la funcionalidad inicial pero mostró una pequeña subida en errores correctables ECC durante el estrés. No suficiente para caer. Suficiente para sospechar. El arnés de recepción las marcó automáticamente porque la política era “movimiento de ECC durante burn-in = cuarentena”. Regla aburrida, aplicada consistentemente.

Dos semanas después, otro equipo de la industria reportó una oleada de fallas de memoria en GPUs tras desplegar lotes reacondicionados similares en producción. Esta empresa no participó en esa diversión. Sus GPUs en cuarentena fueron devueltas bajo términos del proveedor y la flota de producción se mantuvo limpia.

La práctica no fue ingeniosa. No requirió acceso especial ni secretos de proveedor. Fue solo disciplina: capturar telemetría de base, compararla y tomar decisiones de aceptación antes de que el hardware se encuentre con tus clientes.

Errores comunes: síntoma → causa raíz → solución

Esta sección está diseñada para triage. Si tu situación GPU parece “embrujada”, mapea el síntoma a una causa probable y aplica la solución que realmente cambia el resultado.

1) Síntoma: “La GPU se detecta, pero el rendimiento es la mitad de lo esperado”

Causa raíz: Enlace PCIe negociado a menor ancho/velocidad (x4/x8, Gen3 en lugar de Gen4), a menudo por slot equivocado, problemas de riser o bifurcación BIOS.

Solución: Verifica LnkSta vía lspci -vv y nvidia-smi -q. Mueve a un slot x16 conocido bueno. Desactiva bifurcación inesperada. Reemplaza riser/retimer si los errores persisten.

2) Síntoma: “nvidia-smi muestra el nombre correcto, pero el tamaño de memoria es incorrecto”

Causa raíz: MIG activado, o estás mirando una instancia de GPU y no la GPU completa. Alternativamente, incompatibilidad de firmware o un reflash fraudulento.

Solución: Revisa el modo MIG. Si MIG está desactivado y la memoria sigue siendo incorrecta, compara IDs PCI y campos vBIOS; pon la tarjeta en cuarentena y verifica en un host conocido bueno.

3) Síntoma: “La GPU desaparece tras reinicio o bajo carga”

Causa raíz: Inestabilidad en la alimentación, VRMs sobrecalentados, integridad de señal PCIe marginal o compatibilidad driver/kernel. Los reacondicionados con componentes de alimentación fatigados pueden hacer esto cuando se calientan.

Solución: Revisa dmesg por errores AER y Xid. Asegura cableado de alimentación adecuado. Valida flujo de aire del chasis y curvas de ventilador. Re-test en otro nodo para aislar tarjeta vs plataforma.

4) Síntoma: “Errores ECC corregibles aumentan durante estrés”

Causa raíz: Degradación de VRAM o uso intenso previo. A veces inducido por sobrecalentamiento de la memoria debido a malas almohadillas.

Solución: Poner en cuarentena para uso en producción. Inspeccionar termales; re-asentar y verificar refrigeración. Si sigue aumentando, devolver/RMA.

5) Síntoma: “Las frecuencias están bloqueadas bajas; la GPU nunca acelera”

Causa raíz: Límite de potencia bloqueado bajo, tope térmico, persistencia/configuración o ejecución en modo restringido en entorno compartido.

Solución: Revisa razones de throttle y límite de potencia. Confirma que no hay políticas admin (gestión de centro de datos, ajustes de nvidia) que limiten. Arregla flujo de aire; confirma drivers correctos.

6) Síntoma: “El driver carga, pero el sample CUDA falla”

Causa raíz: Versiones de driver/runtime incompatibles, misconfiguración del runtime de contenedores o fallos de hardware que solo aparecen bajo cómputo.

Solución: Alinea driver y runtime CUDA. Ejecuta deviceQuery primero en el host y luego en el contenedor. Si falla en el host, es problema de hardware/driver; si solo falla en el contenedor, arregla el stack del contenedor.

7) Síntoma: “Muchos errores PCIe corregidos, pero las cargas funcionan mayormente”

Causa raíz: Problemas de integridad de señal: riser, retimer, conector contaminado o marginalidad de la placa madre. A veces desencadenado por alto consumo de potencia y calor.

Solución: Mueve la GPU a otro slot o host. Limpia/inspecciona conectores. Actualiza BIOS/firmware. Si los errores siguen al slot, arregla la plataforma; si siguen a la GPU, trátala como riesgo.

8) Síntoma: “Dos GPUs reportan el mismo serial o serial faltante”

Causa raíz: Cadena de reacondicionado reprogramó campos VPD, o reporte roto de herramientas/firmware.

Solución: Indexa inventario por UUID de GPU y IDs PCI, no solo por serial. Si anomalías de serial correlacionan con otros comportamientos raros, pon el lote en cuarentena y reclama al proveedor.

Listas de verificación / plan paso a paso (compra a producción)

Step 0: Reglas de compra (antes de sacar dinero)

Escribe especificaciones de compra como un ingeniero, no como un comercial. Especifica modelo exacto, tamaño de memoria, factor de forma, interconexión (PCIe vs SXM) y estado de reacondicionado aceptable.
Exige procedencia y términos. Quieres confirmación por escrito del estado nuevo/reacondicionado, garantía y condiciones de devolución. Si no se comprometen, tú tampoco deberías.
Pide vBIOS y números de parte por adelantado. Los proveedores legítimos suelen poder proporcionar rangos típicos de vBIOS/PN o al menos reconocerlos.
Presupuesta tiempo para pruebas de recepción. Hardware sin pruebas de aceptación es solo aleatoriedad cara.

Step 1: Recepción física (la fase “no te impresiones con el shrink-wrap”)

Fotografía etiquetas, conectores y cualquier indicador de manipulación. No por drama—para poder probar la condición a la llegada.
Inspecciona el conector de borde PCIe por desgaste, residuos o señales de rework.
Inspecciona conectores de alimentación por decoloración por calor.
Revisa tornillos del disipador por marcas de herramientas; trabajo de reacondicionado intenso deja cicatrices.

Step 2: Inventario de software base (10 minutos por nodo)

Registra lspci -nn, lspci -vv estado de enlace y los campos de identidad de nvidia-smi -q.
Registra UUID de GPU, versión de vBIOS y números de parte de placa.
Asegura que las versiones de driver sean consistentes en la flota antes de juzgar rendimiento.

Step 3: Validación de plataforma (deja de culpar a la tarjeta por tu chasis)

Verifica ancho y generación PCIe en reposo y bajo carga.
Confirma ajustes de BIOS: Above 4G decoding, políticas Resizable BAR (si aplican), ASPM, bifurcación, expectativas SR-IOV/MIG.
Confirma potencia adecuada: cables apropiados, capacidad PSU y sin sorpresas de rail compartido.

Step 4: Política de burn-in y telemetría (haz difícil que hardware malo se cuele)

Stress por al menos 30 minutos para GPUs destinadas a producción; más tiempo si puedes permitírtelo.
Captura contadores ECC antes y después.
Captura registros del kernel durante estrés (AER, Xid).
Criterios de rechazo: cualquier ECC no corregible, cualquier aumento en ECC corregible durante burn-in, reinicios frecuentes Xid, AER persistente bajo carga.

Step 5: Despliegue a producción (gradual, etiquetado, reversible)

Rueda primero en un pool canario. Ejecuta cargas reales con radio de blast seguro.
Etiqueta nodos con UUIDs de GPU y estado de aceptación en el inventario del scheduler.
Configura alertas: deltas ECC, frecuencia de Xid, throttling térmico, tasas de error PCIe.
Tener una vía de escape: cordon/drain rápido de nodos GPU y flujo RMA claro.

FAQ

1) ¿Puede una GPU falsa realmente pasar `nvidia-smi`?

Sí, en el sentido de que las cadenas visibles por software pueden manipularse. Pero es difícil falsificarlo todo de forma consistente: IDs PCI, capacidad de cómputo, comportamiento de tamaño de memoria bajo carga, telemetría ECC y estabilidad. Por eso contrastas en múltiples frentes.

2) ¿Cuál es la mejor comprobación única de “autenticidad”?

No hay una sola. Si te obligan a elegir: empieza con los device IDs de lspci -nn más una prueba de estrés corta mientras observas ECC/Xid y el estado del enlace PCIe. Identidad sin estabilidad es un espejismo.

3) ¿Los reacondicionados son siempre mala idea?

No. Un reacondicionado puede estar bien si viene de un canal creíble con garantía y ejecutas pruebas de aceptación. El problema es usar “reacondicionado” como término amable para “historia desconocida”.

4) ¿Cómo fallan diferente las GPUs de minería?

Suele verse desgaste de ventiladores, interfaces térmicas degradadas e inestabilidad de memoria. Pueden “funcionar” hasta que alcanzan ciertos rangos de temperatura y empiezan a lanzar ECC corregible o reinicios de driver.

5) Si ECC está desactivado, ¿aún puedo detectar problemas de memoria?

Puedes, pero los detectarás más tarde y de forma más dolorosa. Sin telemetría ECC, dependes más de pruebas de estrés, errores de aplicación y caídas. Si puedes elegir para fiabilidad en producción, prefiere SKUs con ECC y con ECC activado.

6) ¿Por qué importa tanto el ancho PCIe si el cómputo está en la GPU?

Porque aún mueves datos: batches, pesos, activaciones, pre/post-procesado, checkpoints y comunicaciones multinodo. Una GPU con enlace PCIe mermado puede parecer “código de modelo lento” hasta que lo mides.

7) ¿Cuánto debe durar el burn-in?

Para recepción: 30 minutos detecta mucho. Para clústers de alto riesgo: 2–12 horas es mejor, especialmente para reacondicionados. El objetivo no es perfección; es surfacer fallos temprano y memoria marginal.

8) ¿Y si la GPU es real pero tiene una versión de vBIOS rara?

Raro no significa automáticamente falso. Puede ser firmware OEM, una actualización de reacondicionado o un desajuste. La respuesta correcta es comparar dentro del lote, comprobar comportamiento bajo carga y alinear con una matriz de firmware/controlador soportada.

9) ¿Puede la virtualización hacer que una GPU real parezca falsificada?

Absolutamente. MIG, vGPU, passthrough y desajustes de runtime de contenedor pueden cambiar la memoria reportada, el nombre del dispositivo e incluso la exposición de capacidades. Siempre verifica en el host desnudo antes de escalar a “fraude”.

10) ¿Qué guardo en mi base de activos para GPUs?

Como mínimo: UUID de GPU, IDs vendor/device PCI, números de parte de placa, versión de vBIOS, mapeo host/slot y resultados de pruebas de recepción (ECC antes/después, resultado de estrés, logs). Los números de serie ayudan, pero no apuestes tu auditoría solo a ellos.

Pasos prácticos siguientes

Si quieres menos GPUs fantasma en tu vida, haz tres cosas y hazlas consistentemente:

Deja de confiar en las cadenas de nombre. Contrasta IDs PCI, campos vBIOS y capacidades reportadas por el controlador. Regístralos en la recepción.
Mide la plataforma, no solo la tarjeta. Verifica ancho/velocidad PCIe y vigila errores AER bajo carga. Muchas “GPUs malas” son en realidad slots, risers o defaults del BIOS malos.
Adopta una política de rechazo que realmente aplicarás. Movimiento de ECC, tormentas Xid y throttling térmico durante burn-in no son “peculiaridades”. Son avisos tempranos.

El objetivo no es paranoia. Es higiene operacional. En producción, “probablemente bien” es cómo el hardware se convierte en folklore—y el folklore es cómo las interrupciones obtienen aprobación presupuestaria.