El despliegue de VMware Private AI Foundation con NVIDIA sobre VCF 9.1 no es una simple instalación de un producto más. Se trata de una integración profunda que abarca desde la infraestructura del centro de datos hasta los modelos de inteligencia artificial que consumen los equipos de datos. Para que este ecosistema funcione en producción, es necesario tomar decisiones arquitectónicas desde el primer día y entender que cada capa —virtualización, Kubernetes, redes, identidad, registros de artefactos y gobernanza de modelos— debe diseñarse de forma cohesionada. En Q2BSTUDIO, empresa especializada en aplicaciones a medida y tecnología cloud, hemos acompañado a organizaciones en este tipo de proyectos y sabemos que el éxito depende tanto de la preparación técnica como de la claridad en los roles de propiedad.
El primer paso, y quizás el más crítico, es decidir cómo los usuarios consumirán la capacidad de cómputo GPU. VMware Private AI Foundation ofrece dos vías principales: máquinas virtuales de deep learning (DL VM) y clústeres Kubernetes nativos de VMware (VKS). Las DL VM son ideales para investigadores que necesitan un entorno interactivo con Jupyter, control total sobre las librerías y una GPU dedicada para experimentación rápida. En cambio, los clústeres VKS están pensados para servicios de inferencia en producción, pipelines de MLOps y aplicaciones que requieren escalado horizontal. No se recomienda implementar ambos caminos sin una gobernanza común; de lo contrario, se corre el riesgo de crear islas de IA donde los modelos, identidades y redes se gestionen de forma independiente. Una buena práctica es definir desde el inicio si el entorno prioriza la flexibilidad del científico de datos o la repetibilidad del ingeniero de plataforma.
La elección del modelo de red del Supervisor (vSphere Supervisor) marca un límite de recuperación que muchas organizaciones subestiman. VCF 9.1 permite usar redes basadas en VDS (vSphere Distributed Switch) o la arquitectura VPC de VCF Networking. Si se planea un modelo de consumo con VCF Automation, multiinquilino y redes self-service, la opción correcta es VPC desde el principio. Migrar de VDS a VPC después de tener cargas de trabajo en producción implica redeploy del Supervisor, no un cambio de configuración rutinario. Esto afecta a namespaces, políticas, cuotas, registros de contenedores y certificados. En Q2BSTUDIO recomendamos realizar este análisis junto con la definición de los servicios cloud AWS/Azure que darán soporte al plan de recuperación ante desastres.
La preparación del clúster GPU debe ir más allá de comprobar que el hardware es compatible. Es necesario validar la combinación exacta de firmware, BIOS, controlador NVIDIA host y guest, perfil de vGPU o asignación directa, y licenciamiento. Incluir el controlador NVIDIA en la imagen de ESXi mediante vSphere Lifecycle Manager evita derivas y asegura que cualquier host reemplazado tenga la misma configuración. Además, es fundamental reservar al menos un nodo GPU para mantenimiento; un clúster donde todas las GPUs están permanentemente asignadas no tiene margen operativo. La gestión de la capacidad debe considerar no solo la memoria GPU, sino también el ancho de banda de red este-oeste, el rendimiento de almacenamiento y las relaciones CPU/GPU de las cargas de trabajo.
Harbor, el registro de artefactos, debe tratarse como infraestructura de primer nivel. Un fallo en Harbor puede impedir que los workers de VKS arranquen, que los modelos se descarguen o que los endpoints de inferencia se actualicen. Es necesario separar proyectos por tipo de artefacto: imágenes de plataforma, componentes del GPU Operator, modelos en cuarentena, modelos aprobados y aplicaciones firmadas. El flujo de promoción de modelos debe incluir escaneo de vulnerabilidades, verificación de licencias y un registro de procedencia. Los modelos grandes (LLMs, embeddings) pueden ocupar decenas de gigabytes, por lo que el dimensionamiento de Harbor debe contemplar múltiples versiones, replicación y espacio temporal para subidas. La seguridad de este registro se complementa con las prácticas de ciberseguridad que implementamos en cada proyecto.
Los certificados, DNS e identidad son dependencias que a menudo se convierten en cuellos de botella. Es obligatorio construir un inventario de todos los endpoints (Supervisor API, Private AI Services, Harbor, proveedor de identidad, etc.) antes de la instalación. Validar la resolución DNS desde distintas redes y asegurar que las cadenas de certificados sean completas. La identidad debe asignarse mediante grupos, no usuarios individuales, con roles claramente diferenciados: administradores de infraestructura, operadores de plataforma, científicos de datos y auditores. Deshabilitar la validación de certificados para 'agilizar' una instalación solo traslada el problema a la operación del día siguiente.
La instalación de Private AI Services sigue un modelo de dos niveles: a nivel de Supervisor se registra el operador del servicio, y a nivel de namespace se activa para un tenant concreto. En entornos con VCF Automation, gran parte de este proceso se puede exponer a través de catálogos de servicios, permitiendo a los equipos de datos solicitar clústeres VKS o DL VM con políticas predefinidas. Sin embargo, incluso sin automatización, los administradores pueden usar la CLI de VCF y kubectl para gestionar la activación. Lo importante es que cada namespace tenga definidas sus cuotas de GPU, clases de VM, políticas de almacenamiento y acceso a Harbor.
La validación debe hacerse por capas: primero la infraestructura (health de VCF, detección de GPUs, red), luego la plataforma (Supervisor, Harbor), después los servicios AI (operador, galería de modelos) y finalmente las cargas de trabajo. Una DL VM debe ejecutar nvidia-smi correctamente y también un pequeño workload de PyTorch o TensorFlow que utilice la GPU. Un clúster VKS debe tener workers capaces de programar un pod con GPU y liberar el recurso limpiamente. La validación no termina hasta que se despliega un modelo de inferencia y se obtiene una respuesta válida.
Las operaciones del día siguiente abarcan la monitorización de la capacidad GPU, la rotación de certificados, la gestión del ciclo de vida de los catálogos y la gobernanza de modelos. Cada modelo debe moverse por estados: borrador, probado, aprobado, publicado y retirado. El plan de actualización debe considerar todo el stack: desde ESXi y el controlador NVIDIA hasta las versiones de los servicios AI y los blueprints de automation. No existe un botón de rollback único; cada capa tiene su propio mecanismo de recuperación (backup de Harbor, restauración de statefulsets de VKS, reconstrucción de DL VM a partir de blueprints). Por eso es esencial documentar las combinaciones validadas y practicar los procedimientos de recuperación antes de un incidente real.
En Q2BSTUDIO ayudamos a las empresas a diseñar e implementar plataformas de IA empresarial que integran agentes IA, dashboards de BI / Power BI y automatización de procesos, todo sobre infraestructuras cloud privadas o híbridas. Nuestra experiencia nos muestra que la clave está en planificar la arquitectura de Supervisores, registros y modelos antes de escribir la primera línea de código o de encender una GPU. Si su organización está considerando VMware Private AI Foundation con NVIDIA, le invitamos a contactarnos para que juntos definamos un camino que convierta la IA en un activo gobernado, seguro y escalable.
