La llegada de la inteligencia artificial a las empresas ya no es una promesa de futuro: es una realidad que exige decisiones inmediatas. Sin embargo, cuando un equipo de infraestructura recibe la primera solicitud para dar soporte a cargas de IA, la tentación es empezar por el hardware: pedir presupuestos de servidores con GPU, elegir entre Kubernetes o máquinas virtuales, o decidir si el clúster será Dell o VxRail. Ese enfoque, aunque comprensible, suele ser un error estratégico. La decisión fundamental no es tecnológica, sino de modelo operativo. Con la llegada de VMware Cloud Foundation 9.1, las organizaciones cuentan con más opciones que nunca para ejecutar IA en entornos privados, pero aprovecharlas correctamente requiere un cambio de mentalidad: primero el servicio, después el clúster.
En este artículo, analizamos cómo las empresas pueden diseñar una arquitectura de IA sobre VCF 9.1 que sea escalable, gobernable y preparada para el futuro. Y, a lo largo del camino, veremos cómo una empresa de desarrollo de software como Q2BSTUDIO puede acompañar este proceso con soluciones de IA para empresas, integración de nube y aplicaciones a medida.
El primer error común es pensar que el clúster de GPU es el servicio. En realidad, el clúster es solo un recurso subyacente. Lo que realmente importa es definir un contrato de servicio: ¿qué tipo de carga de trabajo se va a ejecutar? ¿Qué nivel de aislamiento necesita? ¿Quién es responsable del ciclo de vida? ¿Cómo se miden y asignan los costes? Si el equipo de plataforma no responde a estas preguntas antes de que llegue el primer servidor con GPU, cada decisión no tomada se convertirá en una incidencia, una excepción o una discusión fuera de horario.
VCF 9.1, anunciado por Broadcom, introduce mejoras significativas en observabilidad de IA, soporte para Kubernetes multiinquilino, redes de alta velocidad y nuevas opciones de almacenamiento como la desduplicación global de vSAN. Estas capacidades son ingredientes de plataforma, pero no definen el modelo operativo. Por ejemplo, la plataforma permite asignar GPUs completas mediante DirectPath, particionar con vGPU o MIG, o incluso ejecutar inferencia solo con CPU. La elección correcta depende del caso de uso, no de la tecnología disponible.
Un marco práctico es definir clases de servicio de IA antes de desplegar cualquier infraestructura. Por ejemplo: un sandbox para experimentación, un servicio compartido de inferencia, una capa dedicada para producción, y un entorno regulado para datos sensibles. Cada clase de servicio debe especificar el modelo de acceso a GPU (compartido, dedicado, por lotes), el anillo de ciclo de vida (laboratorio, producción controlada, regulado), el tipo de almacenamiento (para modelos, datasets, checkpoints, logs) y el modelo de coste. Esto evita que cada petición se convierta en un diseño a medida y que el clúster se convierta en un vertedero de experimentos.
La decisión de ubicación (placement) es la primera gran encrucijada. ¿Se añaden GPUs a un dominio de cargas de trabajo existente? Es rápido y barato, pero riesgoso si más tarde llegan cargas de producción. ¿Se crea un dominio de trabajo dedicado para IA? Ofrece mejor aislamiento de ciclo de vida y rendimiento, pero incrementa el coste inicial. VCF 9.1, especialmente en entornos con VxRail, permite una vía intermedia: usar nodos Dell vSAN Ready Nodes en un dominio separado, manteniendo la homogeneidad dentro del dominio y la compatibilidad con el ecosistema Broadcom. La clave es validar las matrices de soporte antes de comprar.
Otro aspecto crítico es el modelo de tenencia. En IA, la tenencia no es solo autenticación. Implica definir qué inquilinos pueden compartir GPUs, qué datos pueden montar, qué redes pueden alcanzar, y qué métricas son visibles. Una buena práctica es combinar varias capas: proyecto + namespace para entornos de experimentación, segmentación NSX para inferencia compartida, y dominio de trabajo completo para cargas reguladas. El equipo de plataforma debe exponer estas opciones en un catálogo de servicios, para que los equipos de negocio no tengan que entender la topología completa de VCF.
El almacenamiento es otro punto donde muchos subestiman la complejidad. Los modelos pueden ser pequeños, pero los datasets de entrenamiento, los embeddings, los checkpoints y los logs de inferencia pueden crecer rápidamente. VCF 9.1 ofrece políticas de vSAN diferenciadas: una política de alto rendimiento para vectores, otra de capacidad para datasets históricos, y una de retención para logs. No usar una política genérica para todo es fundamental para evitar cuellos de botella y costes ocultos. Además, la gestión del ciclo de vida del dato (retención, eliminación, gobernanza) debe estar integrada en la clase de servicio.
La red también merece atención separada. No es lo mismo el tráfico de gestión que el de GPU a GPU para entrenamiento distribuido, o el de almacenamiento para checkpointing. VCF 9.1 soporta GPUDirect RDMA y Enhanced DirectPath I/O para dispositivos NVIDIA ConnectX y BlueField, lo que permite un rendimiento cercano al metal. Pero si el primer clúster se diseña solo para inferencia básica, puede que no soporte los patrones de tráfico de un futuro entrenamiento distribuido. La recomendación es diseñar pensando en la evolución, pero sin sobredimensionar para el primer caso de uso.
El coste es el gran olvidado en muchos despliegues on-premise. Mientras que en la nube pública el gasto en GPU es visible en la factura mensual, en un centro de datos privado puede quedar oculto en el presupuesto de capital. VCF 9.1 incluye mejoras en VCF Operations con datos de coste normalizados según el estándar FOCUS, lo que permite comparar el coste de la nube privada con la pública y hacer showback o chargeback por hora de GPU, por endpoint o por almacenamiento. Implementar un modelo de coste desde el principio evita que la plataforma se convierta en un subsidio oculto para experimentos de IA.
En este contexto, contar con un socio tecnológico que entienda tanto de infraestructura como de desarrollo de aplicaciones es una ventaja competitiva. Q2BSTUDIO ofrece servicios de software a medida que pueden integrar los modelos de IA con los procesos de negocio, desarrollar interfaces personalizadas para los equipos de ciencia de datos, y construir los paneles de observabilidad y coste que necesita la organización. Además, su experiencia en servicios cloud AWS y Azure permite híbridar cargas de trabajo, moviendo el entrenamiento pesado a la nube cuando sea necesario y manteniendo la inferencia en local para cumplir con requisitos de latencia o data residency.
Otro aspecto donde Q2BSTUDIO suma valor es en la creación de agentes IA y asistentes virtuales que se integran con los sistemas empresariales. Estos agentes, basados en modelos de lenguaje y recuperación aumentada (RAG), requieren una infraestructura que garantice baja latencia y seguridad. La compañía también ayuda a implementar ciberseguridad en el acceso a los modelos, protegiendo datos sensibles y cumpliendo con normativas. Y, por supuesto, sus servicios inteligencia de negocio con Power BI permiten visualizar las métricas de rendimiento y coste de la IA, conectando la infraestructura con la toma de decisiones.
Para cerrar, el mensaje central es claro: no empiece por el clúster de GPU. Empiece por el modelo operativo. Defina clases de servicio, elija el modelo de tenencia, diseñe el ciclo de vida, el almacenamiento y la red, y establezca la visibilidad de costes. Después, deje que VCF 9.1 y su ecosistema de socios como Q2BSTUDIO se encarguen de la implementación. La inteligencia artificial no es solo un problema de hardware: es un desafío de arquitectura, gobernanza y colaboración entre equipos. Abordarlo con una estrategia sólida evitará que el primer proyecto exitoso se convierta en un patrón heredado que nadie puede gestionar.
