1. Elegir el punto de partida que corresponde al proyecto
Una base Ubuntu es adecuada cuando sabes organizar tu pila de software y describir sus dependencias del sistema. Una preparación PyTorch permite señalar el framework central del proyecto. Blender indica una necesidad de creación o renderizado. La preparación personalizada sirve cuando tu aplicación ya tiene condiciones específicas que estas etiquetas resumen mal.
Estas opciones no incluyen automáticamente tu código, tus pesos, tus datos ni tus licencias. Escribe qué debe estar disponible, qué aportas tú y qué vas a verificar al arrancar. El nombre de una preparación no debe eximirte de comprobar la versión que realmente se ejecuta.
Una buena solicitud no consiste en enumerar todas las herramientas conocidas. Describe el camino útil: leer una entrada, cargar un recurso, calcular y escribir un resultado. Esto ayuda a distinguir una dependencia obligatoria de una herramienta de comodidad y a diagnosticar la etapa que falta.
Desplaza la tabla para leer todas las columnas.| Preparación | Necesidad a describir | Control propio del proyecto |
|---|---|---|
| Ubuntu | Versión esperada y dependencias del sistema indispensables | Tu programa arranca con las bibliotecas necesarias. |
| PyTorch | Python, variante del framework y extensiones | Import, cálculo en el backend y tarea representativa. |
| Blender | Versión, extensiones, recursos vinculados y formato de exportación | Proyecto abierto y etapa de procesamiento verificada. |
| Personalizada | Procedimiento, versiones y archivos de referencia | Cada criterio del pliego de preparación se controla. |
2. Escribir un cuaderno de preparación compacto
Para un proyecto Python, distingue el sistema, el intérprete, los paquetes y los recursos de la aplicación. Mantén las versiones exactas cuando una dependencia las exija. Cuando aceptes un rango, explica el control que permitirá validarlo. «Instalar las últimas versiones» es difícil de conciliar con un entorno de referencia.
Ejemplo didáctico: tu proyecto clasifica imágenes con una extensión nativa. Tu solicitud indica la versión de Python, la variante de PyTorch elegida, la referencia del proyecto y los requisitos previos de la extensión. Proporciona tres imágenes de control autorizadas y describe la forma de salida esperada. No anuncia un rendimiento ni una memoria suficiente sin una prueba.
El expediente de preparación puede ser breve: un README, un archivo de dependencias y una referencia de código bastan si los pasos y los accesos están claros. Conserva los parámetros modificables en un archivo aparte para que un nuevo tamaño de batch no convierta la solicitud en otra instalación.
Objetivo: clasificar una pequeña muestra de imágenes
Código: repositorio y revisión del proyecto
Python: versión requerida por la aplicación
PyTorch: versión y variante CUDA o ROCm elegidas
Extensiones: versiones, procedencia y requisitos previos de compilación
Entradas: muestra autorizada e identificadores esperados
Control: salida por identificador, formato válido, resultado releíble
Entrega de accesos: procedimiento aparte, sin secretos en esta ficha3. Examinar las dependencias propias de PyTorch
Verifica la cadena de cálculo antes de multiplicar los paquetes. El selector oficial de PyTorch permite elegir una instalación según la plataforma. CUDA y ROCm no son dos nombres intercambiables de un mismo binario. El framework principal puede funcionar mientras que un operador especializado o una extensión del proyecto sigue siendo incompatible.
Si una extensión debe compilarse, su construcción puede requerir herramientas y bibliotecas adicionales. La documentación de PyTorch precisa que la instalación del paquete torch no proporciona automáticamente las cadenas de compilación necesarias para todas las extensiones. Indica estos requisitos previos en el procedimiento; un comando de instalación que intenta compilar no es una anomalía que haya que ocultar.
Planifica tres controles separados: importación del framework, pequeño cálculo en el dispositivo y operación que utiliza la extensión. Si los dos primeros pasan y el tercero falla, dispones de un diagnóstico más preciso que un simple «PyTorch no funciona». Anota el primer error completo y las versiones implicadas.
4. Elegir cómo describir el entorno
Para los paquetes Python, un procedimiento de reconstrucción con un entorno virtual suele ser una base sencilla. Se dirige a un intérprete y separa las dependencias del proyecto. No describe toda la máquina: conserva las necesidades del sistema en el README y no presentes la copia de un directorio instalado como un procedimiento portátil.
Si tu proyecto ya utiliza un contenedor, proporciona su receta, su referencia y los parámetros indispensables para el lanzamiento. Un tag puede cambiar; una referencia por huella identifica con más precisión una imagen determinada. No obstante, hay que organizar las actualizaciones y revalidar el proyecto. El contenedor no demuestra, por sí solo, el acceso a la GPU ni la presencia de tus datos.
Elige el mecanismo que sepas mantener. Una imagen muy completa puede ocultar dependencias inútiles; una receta demasiado minimalista puede dejar instalaciones manuales fuera del expediente. En ambos casos, el control de la aplicación sigue siendo el punto de comparación. Estas indicaciones describen tu preparación, sin presuponer las modalidades de entrega de una imagen por parte del servicio.
5. Preparar los notebooks y los proyectos gráficos
Un notebook ayuda a explorar los datos y a visualizar una salida. Sin embargo, su archivo y el proceso que ejecuta sus celdas son distintos: las variables de una sesión anterior no constituyen una dependencia documentada. Antes de transferir, reinicia el kernel y ejecuta las celdas en orden; registra la versión de Python utilizada.
Cuando el ensayo se convierte en un procesamiento habitual, prepara un punto de entrada que no obligue a manipular las celdas una por una. La guía dedicada al paso del notebook al script detalla esta transformación. Tu solicitud de preparación debe identificar la necesidad del notebook, sin confundir la interfaz de trabajo con un control exitoso del programa.
Para Blender u otro programa gráfico, añade los recursos relacionados, las extensiones y el procedimiento de exportación. Un proyecto que se abre en tu equipo puede depender de archivos ubicados en otro lugar. Pregúntate cómo otra máquina encontrará cada uno de ellos y qué pequeño resultado permitirá verificar la cadena antes del trabajo completo.
6. Recibir con criterios y un resultado revisado
Al recibir la puesta a disposición, compara las versiones observadas con tu ficha. Ejecuta el diagnóstico y luego el caso de aplicación previsto. Para las tres imágenes del ejemplo, comprueba que cada identificador tenga una salida, que las categorías sean válidas y que los archivos producidos se puedan releer. Una pantalla sin errores no sustituye este balance.
Conserva las diferencias útiles: versión distinta, extensión ausente, entrada inaccesible, salida escrita en otro lugar. Distingue lo que impide empezar de lo que solo requiere una actualización de la documentación. Para pedir ayuda, adjunta la referencia del pedido y un fragmento mínimo; no es necesario enviar todo tu corpus.
Una preparación validada para la muestra no garantiza ni la capacidad de memoria ni el comportamiento de todas las cargas futuras. Aumenta después el volumen con un objetivo definido y examina el primer límite que encuentres. Conserva por último el procedimiento corregido: se convierte en tu referencia para el próximo alquiler.