Arquitectura de proyectos IA: Entornos, versiones y almacenamiento

Organizando el caos de los proyectos de IA

Gestionar herramientas de inteligencia artificial puede volverse rápidamente desordenado. Desde múltiples instalaciones de ComfyUI hasta forks especializados como Wan2GP, la tentación es simplemente descargar todo y esperar que funcione.

La clave para mantener un sistema respirable está en planificar la estructura de directorios desde el inicio. Separar las versiones del software es fundamental.

Gestión de entornos: venv versus Conda

No todos los proyectos se comportan igual. Los más modernos, como APIs con FastAPI o frameworks LLM ligeros, funcionan perfectamente bien con `venv`. Son puros y dependen principalmente de PyPI.

Por otro lado, los proyectos que requieren compilación nativa, versiones específicas de CUDA o librerías científicas antiguas suelen necesitar `conda`. Conda es más robusto porque maneja dependencias binarias complejas como libc, MKL o cudatoolkit, algo que sería un infierno intentar replicar con pip.

La tendencia actual es alejarse de Conda para el desarrollo cotidiano, pero en video generativo y forks complejos, la documentación oficial suele exigir entornos conda.

Estructura de versiones: ComfyUI

Para proyectos temperamentales como ComfyUI, versionar explícitamente es mucho más sano que actualizar encima. La estructura ideal separa las actualizaciones por versión:

ComfyUI/
 ├── 0.21.0/
 │    ├── venv
 │    └── custom_nodes
 ├── 0.22.0/
 │    ├── venv
 │    └── custom_nodes

Aquí es donde explotan las incompatibilidades silenciosas entre los custom nodes y las APIs internas.

Organizando Python: anidar las versiones

Al organizar el intérprete, la estructura jerárquica gana sobre la plana. Es mucho más escalable agrupar las versiones bajo una carpeta padre:

Python/
 ├── 3.11/
 ├── 3.12/
 └── 3.13/

Esto evita convertir la raíz del disco en una sopa visual y facilita los backups parciales o el uso de symlinks para apuntar a la versión activa.

Optimización de almacenamiento con HDD, SSD y Symlinks

Una estrategia potente es separar el almacenamiento: usar un HDD para archivos masivos como modelos y checkpoints, y conectarlo al trabajo activo en un SSD mediante symlinks.

HDD/
 └── Models/
     ├── checkpoints/
         ├── ## -> symlink al SSD
         └── diffusion_models/
             ├── ## -> symlink al SSD

Usar prefijos especiales como `##` en los archivos de modelos es una idea inteligente para forzarlos al principio del listado, reduciendo el tiempo de búsqueda y la fatiga mental.

Caso de estudio: Wan2GP y Conda

Wan2GP es un fork de ComfyUI enfocado en generación de video. Dado que su documentación menciona exclusivamente `conda`, lo correcto es mantenerlo en su entorno oficial, aislando cada versión (working, test, archive) para evitar romper el ecosistema base.

El verdadero enemigo no es el disco duro, sino perder la capacidad de entender tu propio laboratorio. Una buena arquitectura reduce drásticamente la complejidad y evita que los forks evolucionen hacia una masa caótica de dependencias pegadas con cinta adhesiva.