Recepcionar una configuración de GPU en equipo

Preparar la decisión antes de la puesta a disposición

Empieza por una unidad de trabajo terminada: una carpeta enriquecida y exportada, un lote de renderizados abierto por su destinatario o una evaluación acompañada de sus salidas. Escribe el criterio de negocio junto al criterio técnico. Un programa puede terminar sin errores y producir resultados inutilizables. A la inversa, un resultado correcto obtenido una sola vez todavía no demuestra que el equipo sepa relanzar el trabajo y recuperar sus archivos.

Conserva los parámetros que influyen en la carga: volumen de las entradas, precisión, tamaño de los lotes, concurrencia y dependencias. Distingue una cola de trabajos independientes, una tarea que reparte su cálculo entre varias tarjetas y un servicio que recibe solicitudes de forma continua. Estas tres organizaciones no tienen los mismos criterios de recepción. Una línea «GPU potente» no da a nadie un medio para decidir.

El responsable del proyecto fija los criterios antes de las pruebas. El operador prepara los accesos, el responsable de la aplicación proporciona el lanzamiento conocido y el destinatario valida las salidas. Una misma persona puede asumir varios roles; no obstante, cada rol debe tener un titular y un suplente. Reserva en el periodo elegido la instalación, las pruebas, una posible corrección y la exportación final, además del cálculo útil.

Separar fabricante, asignación y tarea real

La ficha de una GPU describe un hardware de referencia. La máquina asignada aporta otras propiedades: número de dispositivos visibles, accesos concedidos, versiones de software, volúmenes y rutas utilizables. La tarea patrón aporta un tercer nivel: el resultado obtenido con tus datos y tus ajustes. En la tabla, asigna cada fila a un solo nivel para evitar que una característica del fabricante se trate como una medida de tu servicio.

No deduzcas ni NVLink, ni una topología concreta, ni un caudal de disco del mero modelo de tarjeta. Si tu aplicación depende de estas propiedades, conviértelas en requisitos explícitos, haz que se precise el alcance y luego compruébalo en el destino. Si no son necesarias para tu carga, no las añadas como condiciones artificiales de recepción.

La memoria por GPU y el número de tarjetas siguen siendo dos columnas distintas. Un lote B200 en Capordia comprende dos GPU; eso no basta para dar una memoria única a un programa previsto para una sola tarjeta. Documenta el mecanismo de reparto del software antes de esperar un beneficio de él.

Establecer el inventario sin modificar los ajustes

En NVIDIA, los comandos siguientes recogen la versión de la herramienta, la lista de GPU y algunos atributos en formato CSV. Consulta primero la ayuda instalada: los campos y funciones disponibles dependen de la versión. La documentación de NVIDIA recomienda identificadores como el UUID para seguir un dispositivo, ya que el orden de los índices puede cambiar. Conserva las unidades tal como las escribe la herramienta. Estas lecturas no lanzan una tarea GPU ni califican su rendimiento.

Para AMD, recoge la versión con «amd-smi version», y luego el inventario y las propiedades estáticas con «amd-smi list --json» y «amd-smi static --json». Comprueba las opciones con la ayuda de tu instalación. AMD SMI supone una GPU AMD y su controlador; la documentación consultada es la de AMD SMI 27.0.0. Un campo no disponible debe quedar como «no establecido», con su motivo, en lugar de recibir un valor adivinado.

Archiva después las versiones de la aplicación y de sus bibliotecas. El distintivo CUDA de NVIDIA SMI no demuestra por sí solo la versión del toolkit instalado. Para ROCm, contrasta la combinación de GPU, sistema y versión con la matriz correspondiente. En ambos casos, la prueba decisiva sigue siendo el lanzamiento de tu aplicación en el entorno realmente previsto.

El archivo proporciona los comandos NVIDIA y AMD que hay que ejecutar en tu máquina y luego adjuntar al acta. Se basan en las documentaciones oficiales; en este ejemplo no se ha medido ningún resultado CUDA o ROCm. El archivo de comandos descargable recoge ambas ramas y los campos que hay que adjuntar al acta.

nvidia-smi --version
nvidia-smi --help-query-gpu
nvidia-smi -L
nvidia-smi --query-gpu=index,name,uuid,memory.total --format=csv

Convertir cada requisito en un control observable

Una buena línea de recepción relaciona un criterio, un método y una prueba documental. «Suficiente almacenamiento» se convierte, por ejemplo, en: ubicación de trabajo identificada, espacio disponible registrado antes del lanzamiento y exportación abierta desde su destino. La cantidad necesaria es la de tu trabajo, incluidos los archivos intermedios; esta guía no presupone una capacidad de disco asociada a cada GPU.

Fija las unidades antes de comparar dos mediciones. Un GB decimal equivale a mil millones de bytes; un GiB equivale a 2 elevado a 30 bytes. Las herramientas pueden mostrar las notaciones inglesas GB y GiB, o MiB para una unidad más pequeña. Conserva el valor bruto y su unidad, y luego indica la conversión si corresponde. No descartes una configuración solo por la diferencia de notación entre una ficha y una medición.

Para la red, prueba el flujo del proyecto: mismo destino, mismos permisos y un tipo de archivo representativo. Una descarga aislada no cualifica la exportación de miles de resultados pequeños. Mide y documenta la transferencia en ambos sentidos si el proyecto la utiliza, y luego anota el umbral que exige tu calendario. Sin un umbral decidido antes de la prueba, una duración observada sigue siendo solo una observación.

El estado «no ejecutado» vale más que un éxito sin prueba. La cuadrícula CSV deja vacías las columnas de observación, fecha y evidencia. Puedes eliminar un control fuera de alcance únicamente explicando por qué y conservando la aprobación del responsable de la decisión.

Hacer de la tarea de referencia un traspaso de turno

Elige una muestra autorizada que ponga de manifiesto las restricciones del trabajo real. Una demostración minúscula es útil para verificar el lanzamiento; no sustituye a un caso que revele el pico de memoria, los archivos intermedios o la exportación final. Registra el identificador del conjunto de prueba, las versiones y la parametrización. La carpeta compartida referencia el método de entrega de los secretos sin registrar su valor.

El responsable de la aplicación realiza un ciclo completo desde un arranque conocido hasta la apertura de las salidas. El operador vuelve a hacer después el recorrido a partir del procedimiento, sin depender de un estado oculto en la terminal del primer operador. El objetivo es verificar un traspaso utilizable: rutas, permisos, lanzamiento, ubicación de los registros y recuperación.

Define también qué ocurre tras un fallo controlado. Una salida temporal debe poder distinguirse de un resultado aceptado. El expediente de recepción no debe inventar un mecanismo de reanudación que la aplicación no posea: constata el que existe y remite al procedimiento de migración para organizar los lotes interrumpidos. Si el cálculo es numérico, la tolerancia pertenece al protocolo de negocio; la identidad bit a bit no es un requisito universal.

Cuando compares varias configuraciones, mantén este protocolo constante. Anota también los errores y las pruebas a repetir. La decisión final puede preferir una opción porque simplifica la cola de trabajo, la recepción o el calendario; no necesita convertir una sola medición en una clasificación general de GPU.

Leer un ejemplo rellenado sin tomarlo por una medición

El ejemplo descargable «Taller de planos» es totalmente ficticio. Un equipo quiere procesar un corpus de prueba de doce documentos técnicos y luego obtener un índice consultable por los revisores. Los doce documentos son una hipótesis de organización; no se ofrece ninguna velocidad, consumo de memoria ni medición de GPU. El objetivo H100 es un candidato de encuadre, que deberá confirmarse tras examinar el software y la carga.

El responsable de la aplicación prepara el lanzamiento y las credenciales previstas. Operaciones controla los accesos y la devolución de los archivos. La persona encargada de los resultados debe confirmar que cada documento tiene una salida legible y una referencia en el índice. En este escenario, todavía no ha podido abrir la exportación desde su destino. Las líneas de hardware y de aplicación siguen sin ejecutarse; por tanto, la decisión ficticia es «puesta en servicio bloqueada».

Este ejemplo muestra cómo asignar responsabilidades y tomar una decisión explicable sin fabricar un éxito. La ausencia de una prueba de exportación no es una simple nota al margen: bloquea precisamente el uso que exige resultados recuperables. El nuevo intento deberá retomar este control, adjuntar su evidencia y fechar la decisión. No basta con borrar el comentario en la tabla.

Rechazar, aceptar con reserva o aplazar la decisión

Un criterio bloqueante no satisfecho detiene la recepción del alcance correspondiente. Un control imposible no pasa a ser superado por defecto: genera un estado «bloqueado» o «no ejecutado», una acción y un propietario. Evita usar «reserva» para ocultar un requisito previo del trabajo. Si una salida no se puede recuperar, aceptar solo el cálculo no autoriza la cadena completa.

Una reserva puede ser adecuada para un punto secundario si el uso autorizado está claramente limitado, si existe una solución temporal verificada y si alguien acepta ese alcance. Inscribe una fecha límite de nuevo control y lo que ocurrirá si no se cumple. Una recepción limitada a una prueba no equivale a la recepción de la producción.

El acta conserva la decisión, los controles que la justifican y los que siguen abiertos. La aceptación técnica no confirma ni un pago ni una fecha contractual: esos seguimientos mantienen sus propias referencias. Una vez alcanzados los criterios, el equipo entrega a operaciones el lanzamiento, las versiones, las ubicaciones de los datos y el procedimiento de salida.

Descargar y usar el expediente de recepción versión 1

La plantilla Markdown sirve como portada y acta. La tabla CSV proporciona los controles que hay que personalizar, con columnas para el nivel de prueba, el responsable, el criterio decidido antes de la prueba, el método, la observación, la evidencia y el estado. Abre el CSV en UTF-8 con la coma como separador; los campos de resultado están deliberadamente vacíos. Conserva una copia en blanco antes de trabajar.

Abre la plantilla con un editor de texto y la tabla con una hoja de cálculo. Adapta el ejemplo ficticio a tus requisitos y luego registra las observaciones en tu propia máquina. La licencia proporcionada autoriza el uso y la adaptación conservando el aviso; los nombres de productos y las documentaciones externas mantienen sus derechos respectivos.

Utiliza esta recepción para autorizar un alcance preciso y, después, actualízala cuando cambien las versiones, los datos o el modo de explotación. No constituye un benchmark universal ni una garantía de ausencia de interrupciones. La guía de migración toma el relevo cuando hay que trasladar un estado de trabajo y explicar el destino de cada lote.