El desplegament de VMware Private AI Foundation amb NVIDIA sobre VCF 9.1 no és una simple instal·lació d'un producte més. Es tracta d'una integració profunda que abasta des de la infraestructura del centre de dades fins als models d'intel·ligència artificial que consumeixen els equips de dades. Perquè aquest ecosistema funcioni en producció, cal prendre decisions arquitectòniques des del primer dia i entendre que cada capa —virtualització, Kubernetes, xarxes, identitat, registres d'artefactes i governança de models— s'ha de dissenyar de manera cohesionada. A Q2BSTUDIO, empresa especialitzada en aplicacions a mida i tecnologia cloud, hem acompanyat organitzacions en aquest tipus de projectes i sabem que l'èxit depèn tant de la preparació tècnica com de la claredat en els rols de propietat.
El primer pas, i potser el més crític, és decidir com els usuaris consumiran la capacitat de càlcul GPU. VMware Private AI Foundation ofereix dues vies principals: màquines virtuals de deep learning (DL VM) i clústers Kubernetes natius de VMware (VKS). Les DL VM són ideals per a investigadors que necessiten un entorn interactiu amb Jupyter, control total sobre les llibreries i una GPU dedicada per a experimentació ràpida. En canvi, els clústers VKS estan pensats per a serveis d'inferència en producció, pipelines de MLOps i aplicacions que requereixen escalat horitzontal. No es recomana implementar ambdós camins sense una governança comuna; altrament, es corre el risc de crear illes d'IA on els models, identitats i xarxes es gestionin de forma independent. Una bona pràctica és definir des de l'inici si l'entorn prioritza la flexibilitat del científic de dades o la repetibilitat de l'enginyer de plataforma.
L'elecció del model de xarxa del Supervisor (vSphere Supervisor) marca un límit de recuperació que moltes organitzacions subestimen. VCF 9.1 permet usar xarxes basades en VDS (vSphere Distributed Switch) o l'arquitectura VPC de VCF Networking. Si es planeja un model de consum amb VCF Automation, multiinquilí i xarxes self-service, l'opció correcta és VPC des del principi. Migrar de VDS a VPC després de tenir càrregues de treball en producció implica redeploy del Supervisor, no un canvi de configuració rutinari. Això afecta namespaces, polítiques, quotes, registres de contenidors i certificats. A Q2BSTUDIO recomanem realitzar aquesta anàlisi juntament amb la definició dels serveis cloud AWS/Azure que donaran suport al pla de recuperació davant desastres.
La preparació del clúster GPU ha d'anar més enllà de comprovar que el maquinari és compatible. Cal validar la combinació exacta de firmware, BIOS, controlador NVIDIA host i guest, perfil de vGPU o assignació directa, i llicenciament. Incloure el controlador NVIDIA a la imatge d'ESXi mitjançant vSphere Lifecycle Manager evita derives i assegura que qualsevol host reemplaçat tingui la mateixa configuració. A més, és fonamental reservar almenys un node GPU per a manteniment; un clúster on totes les GPUs estan permanentment assignades no té marge operatiu. La gestió de la capacitat ha de considerar no només la memòria GPU, sinó també l'ample de banda de xarxa est-oest, el rendiment d'emmagatzematge i les relacions CPU/GPU de les càrregues de treball.
Harbor, el registre d'artefactes, s'ha de tractar com a infraestructura de primer nivell. Una fallada a Harbor pot impedir que els workers de VKS arrenquin, que els models es descarreguin o que els endpoints d'inferència s'actualitzin. Cal separar projectes per tipus d'artefacte: imatges de plataforma, components del GPU Operator, models en quarantena, models aprovats i aplicacions signades. El flux de promoció de models ha d'incloure escaneig de vulnerabilitats, verificació de llicències i un registre de procedència. Els models grans (LLMs, embeddings) poden ocupar desenes de gigabytes, per tant el dimensionament de Harbor ha de contemplar múltiples versions, replicació i espai temporal per a pujades. La seguretat d'aquest registre es complementa amb les pràctiques de ciberseguretat que implementem a cada projecte.
Els certificats, DNS i identitat són dependències que sovint es converteixen en colls d'ampolla. És obligatori construir un inventari de tots els endpoints (Supervisor API, Private AI Services, Harbor, proveïdor d'identitat, etc.) abans de la instal·lació. Validar la resolució DNS des de diferents xarxes i assegurar que les cadenes de certificats siguin completes. La identitat s'ha d'assignar mitjançant grups, no usuaris individuals, amb rols clarament diferenciats: administradors d'infraestructura, operadors de plataforma, científics de dades i auditors. Deshabilitar la validació de certificats per 'accelerar' una instal·lació només trasllada el problema a l'operació del dia següent.
La instal·lació de Private AI Services segueix un model de dos nivells: a nivell de Supervisor es registra l'operador del servei, i a nivell de namespace s'activa per a un tenant concret. En entorns amb VCF Automation, gran part d'aquest procés es pot exposar a través de catàlegs de serveis, permetent als equips de dades sol·licitar clústers VKS o DL VM amb polítiques predefinides. Tanmateix, fins i tot sense automatització, els administradors poden usar la CLI de VCF i kubectl per gestionar l'activació. L'important és que cada namespace tingui definides les seves quotes de GPU, classes de VM, polítiques d'emmagatzematge i accés a Harbor.
La validació s'ha de fer per capes: primer la infraestructura (health de VCF, detecció de GPUs, xarxa), després la plataforma (Supervisor, Harbor), després els serveis AI (operador, galeria de models) i finalment les càrregues de treball. Una DL VM ha d'executar nvidia-smi correctament i també un petit workload de PyTorch o TensorFlow que utilitzi la GPU. Un clúster VKS ha de tenir workers capaços de programar un pod amb GPU i alliberar el recurs netament. La validació no acaba fins que es desplega un model d'inferència i s'obté una resposta vàlida.
Les operacions del dia següent abasten la monitorització de la capacitat GPU, la rotació de certificats, la gestió del cicle de vida dels catàlegs i la governança de models. Cada model ha de moure's per estats: esborrany, provat, aprovat, publicat i retirat. El pla d'actualització ha de considerar tot el stack: des d'ESXi i el controlador NVIDIA fins a les versions dels serveis AI i els blueprints d'automation. No existeix un botó de rollback únic; cada capa té el seu propi mecanisme de recuperació (backup de Harbor, restauració de statefulsets de VKS, reconstrucció de DL VM a partir de blueprints). Per això és essencial documentar les combinacions validades i practicar els procediments de recuperació abans d'un incident real.
A Q2BSTUDIO ajudem les empreses a dissenyar i implementar plataformes d'IA empresarial que integren agents IA, dashboards de BI / Power BI i automatització de processos, tot sobre infraestructures cloud privades o híbrides. La nostra experiència ens mostra que la clau està a planificar l'arquitectura de Supervisors, registres i models abans d'escriure la primera línia de codi o d'encendre una GPU. Si la seva organització està considerant VMware Private AI Foundation amb NVIDIA, us convidem a contactar-nos perquè junts definim un camí que converteixi la IA en un actiu governat, segur i escalable.
