Explicar las expectativas antes de buscar una GPU más potente.

Describir el problema con un resultado y una ventana

Sustituye «la GPU no trabaja» por una observación verificable: el primer resultado llega tarde, las etapas presentan pausas o el número de salidas aceptadas disminuye. Indica el conjunto de entradas, la versión de la aplicación, los ajustes y el periodo observado. Un primer lanzamiento puede incluir fases distintas de una ejecución ya preparada; no las mezcles sin indicarlo.

Divide el recorrido en apertura de archivos, preparación de la CPU, transferencia, cálculo en la GPU, escritura y validación. Estas fases pueden solaparse: el dibujo constituye una hipótesis que hay que confrontar con las trazas. Anota los límites con la misma zona horaria y una precisión suficiente. Un gráfico del hardware tomado después de la pausa no permite explicar la pausa, aunque su valor parezca inusual.

Leer correctamente los porcentajes y las memorias

En NVIDIA SMI, la utilización de la GPU indica la parte del intervalo de muestreo durante la cual se ejecutaba al menos un núcleo. No es una nota de rendimiento de todos los componentes. La utilización de la memoria describe su actividad de lectura o escritura; no debe confundirse con la cantidad de memoria ocupada. La documentación precisa además que algunos campos pueden no estar disponibles según el entorno.

Conserva, por tanto, el nombre exacto de la métrica y su unidad. Una cantidad de memoria elevada puede corresponder a datos conservados en espera; una baja actividad puede aparecer durante una fase normal de preparación. A la inversa, una actividad elevada no establece que el programa realice un trabajo útil. Hay que mirar las salidas y la progresión de la aplicación al mismo tiempo que el hardware.

Recoger un registro correlacionado y lo bastante corto

Elige una secuencia representativa y limita la recolección a esa secuencia. Registra las horas, el identificador de la GPU, la actividad, la memoria ocupada y las fases de la aplicación. En paralelo, usa las herramientas disponibles en tu sistema para observar el proceso de CPU, sus esperas, sus lecturas y escrituras. Un promedio sobre todos los núcleos puede ocultar un solo hilo saturado; observa también los procesos implicados.

El comando de lectura que aparece a continuación se propone para un objetivo NVIDIA autorizado que ya disponga de NVIDIA SMI. No se ha ejecutado para esta guía. Conserva las unidades en el CSV y muestra una observación por segundo hasta su interrupción. Verifica los campos admitidos por tu versión y detén la recolección al final del escenario. Un campo N/A sigue siendo desconocido: no lo conviertas en cero.

El registro mínimo relaciona un identificador de trabajo, una hora con zona horaria, la fase actual, una entrada o un lote identificable, el progreso y el error eventual. No debe contener ni secretos ni contenido de negocio innecesario para el diagnóstico. Si falta la telemetría, verifica primero su dispositivo de recolección y el progreso de la aplicación: una curva vacía no prueba que un proceso esté detenido. Marca el periodo sin observación en lugar de reconstruirlo de memoria.

nvidia-smi --version
nvidia-smi --query-gpu=timestamp,uuid,utilization.gpu,memory.used,memory.total --format=csv --loop=1

Diferenciar una pista de una conclusión

Si la actividad de la GPU baja mientras la aplicación espera sus entradas, examina la ruta de los archivos. Si baja durante una preparación de CPU larga, examina esa fase y su paralelismo real. Si los dispositivos esperan a los demás participantes de un trabajo distribuido, verifica el equilibrio de cargas y las comunicaciones. Varios síntomas pueden producirse a la vez; su correlación aún no es una prueba de causalidad.

Escribe una hipótesis breve y una modificación que permita distinguirla. Por ejemplo, comparar las mismas entradas ya preparadas con su preparación habitual puede aislar una etapa, siempre que los resultados sigan siendo idénticos. No cambies simultáneamente el tamaño del lote, la precisión, el número de procesos y la ubicación de los archivos: una mejora sería difícil de atribuir.

Ejemplo ficticio: analizar un bucle de cien segundos

El equipo ficticio «Revisión de maquetas» describe un bucle sin solapamiento: sesenta segundos de preparación de CPU, veinte de cálculo de GPU y luego veinte de exportación. El total es 100 segundos y la fracción temporal atribuida al cálculo de GPU vale 20/100, es decir, el 20 %. Este cálculo pedagógico no predice el porcentaje de una herramienta de muestreo y no corresponde a ninguna medición de una GPU del catálogo.

Supongamos que la preparación puede reducirse a treinta segundos, sin cambiar el cálculo ni las salidas. El bucle haría entonces 30 + 20 + 20 = 70 segundos: treinta segundos menos, con una fracción de GPU de 20/70, es decir, aproximadamente el 28,6 %. A la inversa, dividir hipotéticamente solo el cálculo de GPU por dos daría 60 + 10 + 20 = 90 segundos. El escenario explica por qué abordar la espera más larga puede pesar más que cambiar de tarjeta.

Profundizar en una fase con un perfilador

Si la observación general localiza una zona lenta sin explicarla, utiliza el generador de perfiles adecuado para la aplicación en una ventana corta. PyTorch Profiler puede recopilar eventos de CPU y CUDA y organizar ventanas de recolección. La documentación señala una sobrecarga cuando se activa el registro de formas o de pilas. Por lo tanto, una traza detallada es un instrumento de diagnóstico; su tiempo total no debe presentarse sin reservas como el tiempo normal del programa.

Mantén los nombres de las fases lo bastante explícitos para vincular una operación técnica con tu trabajo: preparación de un grupo de archivos, transferencia, etapa de la aplicación o publicación de salida. Comienza con el nivel de detalle necesario para la hipótesis. Tras la modificación, repite una observación comparable y después una ejecución sin instrumentación pesada. Esta segunda comprobación permite verificar que el beneficio también existe en las condiciones habituales.

Evitar correcciones que oculten el problema

Aumentar la concurrencia puede llenar la GPU a la vez que sobrecarga el disco, la memoria del host o las salidas. Incrementar el tamaño de los lotes puede cambiar la latencia y la memoria necesaria. Reducir la precisión puede modificar el resultado. Estas decisiones no están prohibidas, pero deben evaluarse sobre el mismo objetivo de negocio, con sus efectos secundarios, en lugar de adoptarse porque aumente el porcentaje mostrado.

No reinicies un dispositivo ni modifiques sus parámetros de hardware para diagnosticar una simple caída de actividad. Empieza por la lectura y, después, haz que el responsable autorizado examine los errores explícitos. Evita también publicar trazas sin procesar que contengan rutas privadas, parámetros confidenciales o datos de entrada. Prepara un extracto útil para el diagnóstico y conserva la prueba completa dentro del ámbito autorizado del equipo.

Cerrar el diagnóstico con una prueba útil para la decisión

El informe final debe indicar el síntoma, la hipótesis adoptada, el cambio probado, sus condiciones y el resultado observado. Conserva al menos una comparación antes/después sobre el mismo conjunto de entradas, la misma calidad y la misma definición de fin. Si el resultado no es concluyente, escribe lo que se descartó y la próxima observación necesaria. Una pista rechazada y documentada evita que otra persona vuelva a empezar al azar.

Una baja actividad normal no siempre requiere una corrección. Si la tarea cumple su plazo, su calidad y su presupuesto, reducir una complejidad puede ser preferible a una optimización frágil. Si se plantea una nueva configuración, transmite las restricciones demostradas al expediente de recepción. Ningún registro aislado clasifica el catálogo y ningún valor de este ejemplo constituye un rendimiento prometido.