CapordiaReunir un informe de partida compacto pero reconstruible
Conserva las versiones del sistema, de la aplicación y de sus dependencias, el procedimiento de lanzamiento y un pequeño conjunto representativo. Añade las rutas esperadas, los permisos y la forma de verificar las salidas. Este manifiesto describe una referencia conocida. Para un cambio, crea una versión candidata junto a esa referencia; los secretos permanecen en tu sistema de gestión de accesos. Nombra los elementos que faltan y su responsable en lugar de ocultarlos tras una mención «entorno listo».
Designa a una persona para la recepción y a otra para la decisión de cambio cuando tu organización lo requiera. Deben conocer los criterios antes de que el nuevo procesamiento se convierta en una dependencia para el resto del equipo. La preferencia Ubuntu, PyTorch, Blender o personalizada elegida en el pedido orienta la preparación; no sustituye al inventario preciso de tu aplicación.
Verificar los recursos realmente visibles
Al recibir el servicio, compara el modelo detectado, el número de tarjetas y su memoria con el alcance esperado. Anota también los elementos necesarios para el proyecto que no describe el propio GPU: sistema, espacio de trabajo, permisos y acceso a los destinos. Una discrepancia se convierte en una pregunta concreta que hay que resolver, sin dar por supuesta una capacidad de CPU, red o disco que no figure en la ficha.
En un entorno NVIDIA que disponga de nvidia-smi, el comando propuesto lee el nombre, la memoria total que anuncia la herramienta y el controlador. No determina el rendimiento ni todas las dependencias de CUDA. Para AMD, usa la documentación correspondiente al hardware y a la combinación de ROCm elegida; evita trasladar una comprobación de NVIDIA como prueba de funcionamiento de una MI300X.
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csvHacer una pasada completa con criterios separados
Comprueba sucesivamente el acceso, la configuración, la carga de datos, la ejecución y la exportación. Para cada etapa, anota una observación y una decisión. Un programa que termina sin errores no necesariamente ha producido todos los archivos esperados. A la inversa, una visualización correcta de la tarjeta no prueba que el software use el GPU elegido.
Fija el resultado aceptable antes de la prueba. Puede tratarse de un número exacto de carpetas, de una imagen controlada visualmente o de un criterio numérico. PyTorch recuerda que no se garantiza una reproducibilidad completa entre versiones y plataformas. Elige, por tanto, la tolerancia adecuada al trabajo junto con su responsable; no la amplíes a posteriori solo para que pase la prueba.
| Etapa | Observación esperada | Decisión si falla |
|---|---|---|
| Acceso | La persona autorizada llega al entorno correcto | Corregir el acceso antes de la importación |
| Carga | Todas las entradas del conjunto de prueba son legibles | Corregir el paquete o sus permisos |
| Ejecución | El procesamiento usa los recursos previstos y finaliza | Identificar la dependencia o el ajuste |
| Resultado | El contenido cumple los criterios escritos | Suspender la ampliación de la campaña |
| Exportación | El resultado es utilizable desde su destino | Corregir la salida antes del cambio |
Ejemplo práctico: cien carpetas recibidas, noventa y nueve resultados
En este caso ficticio, un equipo sustituye la versión A de un preprocesamiento por una versión B. Su manifiesto indica el código, las dependencias y el formato de salida antes y después; el conjunto de recepción sigue compuesto por las mismas 100 carpetas identificadas del 001 al 100. La versión A produce 100 resultados. La versión B termina pero exporta 99 identificadores distintos: falta la carpeta 057. El criterio escrito exige 100 resultados sin duplicados. Por tanto, el cambio se rechaza en esta fase.
Falta una dependencia necesaria para la carpeta 057 en el paquete candidato. El equipo la restablece en una nueva versión del manifiesto, verifica esa carpeta y vuelve a ejecutar las 100 entradas sobre el candidato corregido. Recupera 100 identificadores distintos y abre el paquete desde el destino final. La prueba completa verifica que la corrección no solo ha reparado el caso aislado. Este resultado resuelve la discrepancia descrita; todavía no demuestra el funcionamiento con un volumen superior ni con carga continua.
Comparar el manifiesto antes y después, y decidir la adopción
La ficha de cambio cabe en unas pocas líneas: motivo, elemento modificado, elementos mantenidos, criterios y responsable. Conserva una copia utilizable de la configuración de referencia. Si cambias a la vez el controlador, el framework y el formato de los datos, multiplicas las posibles causas de una discrepancia. Fracciona cuando sea posible; de lo contrario, trata explícitamente este conjunto como un cambio más amplio.
Tras la corrección, haz que el propietario del resultado valide la nueva referencia. La tabla siguiente organiza esta decisión; no constituye un inventario de programas suministrados. Una versión aceptada se convierte en la referencia solo después de los controles acordados. Fecha la adopción e indica las tareas a las que se aplica, para que dos personas no lancen en silencio dos variantes de la misma campaña.
| Elemento | Antes | Candidato retenido tras corrección |
|---|---|---|
| Aplicación | Versión A | Versión B, con correctivo de dependencia incluido |
| Entradas de recepción | 100 expedientes fijados | Los mismos 100 expedientes |
| Resultados exigidos | 100 identificadores distintos | 100 identificadores distintos, formato aceptado |
| Publicación | Referencia utilizada por el equipo | Adopción con fecha tras la aprobación del responsable |
Mantener una posibilidad de retorno sin mezclar los resultados
Antes de adoptar, verifica que la referencia anterior aún pueda leer sus entradas y retomar su estado. Distingue las salidas del candidato, evita una publicación duplicada y define quién puede decidir el retorno. Si el nuevo software modifica archivos de trabajo de forma irreversible, conservar el programa antiguo no basta: también hace falta un estado de datos compatible. La guía de migración aborda el cambio entre entornos; aquí, la decisión se refiere al cambio de software cualificado.
La confirmación del pago y la puesta a disposición siguen siendo distintas de estos controles técnicos. El botón «He pagado» señala un pago; no valida ni el acceso ni el cambio de software. Realiza las pruebas cuando el entorno sea realmente accesible y luego vincula su resultado a tu referencia de pedido en el expediente interno.
Terminar con un equipo capaz de explotar y de salir
La salida esperada es un expediente breve: entorno relevado, conjunto de recepción, controles aceptados, desviaciones pendientes y persona que decide lo que sigue. Haz que alguien que no preparó la instalación revise el procedimiento de lanzamiento. Si esa persona tiene que preguntar por una ruta o un ajuste esencial, completa el expediente antes de transferirle la explotación.
Planifica también la recuperación final y su control. Los errores frecuentes son ampliar la carga antes de la recepción, cambiar varias versiones durante el diagnóstico y descubrir la exportación solo al llegar el plazo. En 3, 7 o 30 días, reserva tiempo para estas etapas dentro del periodo elegido, sin tratarlas como operaciones necesariamente instantáneas.
Preguntas para decidir
¿Basta con detectar una tarjeta para aceptar el despliegue?
No. La detección verifica una parte del alcance de hardware. Queda cargar las entradas, ejecutar el software, verificar sus resultados y recuperarlos desde su destino. Cada control debe tener un criterio distinto.
¿Se necesitan salidas exactamente idénticas tras cambiar de GPU?
Depende de tu procesamiento. Define qué debe permanecer estrictamente idéntico y qué entra dentro de una tolerancia justificada. Documenta las versiones y los parámetros; no debe suponerse una identidad perfecta para todo software y todo entorno.
¿Quién decide que una desviación es aceptable?
El responsable designado para el criterio en cuestión, junto con el decisor del cambio cuando la desviación afecte al servicio. La persona que lanza la prueba describe la observación; no sustituye automáticamente al responsable de negocio o al de datos.