TL;DR
The image presents VMware Cloud Foundation as an AI star forge: raw compute, storage, networking, identity, security, policy, cost, recovery, and telemetry enter a common platform, then emerge as governed AI services. That metaphor is useful because production AI is not created by installing GPUs alone. It requires a repeatable operating model that can allocate resources, secure data paths, control identities, observe models and infrastructure, recover services, and assign clear ownership.
VCF 9.1 can provide much of that platform foundation through vSphere, vSAN, VCF Networking with NSX, VMware vSphere Kubernetes Service, VCF Automation, VCF Operations, and VCF Private AI Services. The practical goal is not to build one universal AI stack. It is to create a controlled factory that can produce several workload patterns without rebuilding governance and operations for every project.
Introduction
The most expensive mistake in enterprise AI is treating the first successful model deployment as proof that the platform is ready.
A proof of concept may need one GPU host, one model, one data set, and a small group of users. Production introduces a different problem. Multiple teams request accelerators. Models need approved runtimes. Retrieval systems need access to governed data. Agents need tool permissions. Security teams need evidence. Operators need service-level objectives, incident paths, patching windows, and recovery procedures. Finance needs to know whether expensive capacity is being used or merely reserved.
The star forge image captures the right architectural tension. It shows that AI outcomes are not direct products of hardware. They are products of an operating system for infrastructure, policy, delivery, and lifecycle management.
VMware Cloud Foundation can play that role for organizations that already treat private cloud as a strategic platform. VCF 9.1 brings AI, Kubernetes, virtual machines, operations, automation, networking, security, and mixed compute under a more unified operating model. That does not make every AI workload easy, and it does not eliminate MLOps, data governance, or application engineering. It does provide a place where those responsibilities can meet without every AI project becoming an isolated infrastructure island.
The Image Is a Useful Metaphor, Not a Product Diagram
The infographic should be read as a capability model. Its planets, shields, automation arms, observability constellation, and AI worlds are not a one-to-one map of licenses, appliances, or deployment nodes. They represent the domains that a production AI platform must coordinate.
This distinction matters. A visual that says security, automation, observability, Kubernetes, and recovery are built in can be misread as a promise that they appear automatically after installation. In real environments, each capability still requires design decisions, supported hardware, configuration, integrations, operating procedures, and assigned owners. Some capabilities may also depend on specific editions, add-ons, validated solutions, or adjacent products.
The useful question is therefore not, “Does VCF contain every AI component?” The better question is, “Can VCF establish a repeatable control boundary for the infrastructure and platform services that enterprise AI depends on?”
A useful comparison is the difference between a GPU island and a governed AI forge.
| Dimension | GPU Island | Governed AI Star Forge |
|---|---|---|
| Resource delivery | Manual host or cluster assignment | Catalog-driven requests with quotas, placement, and approvals |
| Security | Project-specific firewall and access decisions | Reusable identity, segmentation, egress, and evidence policies |
| Observability | Host health and basic GPU utilization | Infrastructure, accelerator, model, service, audit, and cost signals |
| Lifecycle | Bespoke upgrades and dependency handling | Versioned platform patterns and coordinated lifecycle workflows |
| Recovery | Hardware or VM recovery only | Service, data, model, configuration, and dependency recovery |
| Cost control | Capacity purchased for a project | Shared capacity, utilization tracking, reclamation, and unit economics |
| Ownership | The infrastructure team becomes the default owner | Responsibilities split across platform, AI, data, security, application, and FinOps teams |
The difference is not visual polish. It is whether the organization can onboard the fifth, tenth, and twentieth AI workload without multiplying exceptions.
The Raw Inputs Are More Than GPUs
The left side of the image correctly treats infrastructure as a collection of inputs. Compute capacity is only one of them, even when accelerators are the most visible and expensive component.
Compute and accelerator capacity
A serious design begins with workload characteristics, not a hardware shopping list. Training, fine-tuning, batch inference, real-time inference, simulation, and computer vision can have very different processor, memory, locality, and scheduling requirements. Some services need exclusive accelerator access. Others benefit from shared GPU capacity or can run economically on CPUs.
The placement model must also account for NUMA locality, accelerator topology, failure domains, maintenance behavior, and mobility constraints. Direct device access can improve performance for selected workloads, but exclusive attachment may reduce portability, sharing, or live mobility options. The design decision should therefore be based on measured service requirements rather than a general preference for maximum hardware exposure.
Storage and data services
AI storage is not one data lake. It can include source documents, object data, model artifacts, vector indexes, container images, checkpoints, feature data, prompt and response logs, evaluation results, audit evidence, and application state.
Each data class has different performance, retention, protection, and sovereignty requirements. A recovery design that restores a virtual machine but loses the approved model version, vector index, policy bundle, or data lineage record has not restored the AI service.
Network fabric and security paths
An AI request may cross more boundaries than a conventional application request. A user reaches an application. The application calls a model endpoint. The model retrieves data, queries a vector store, invokes tools, emits telemetry, and may return through an API gateway or load balancer. Agentic workflows can extend that path into ticketing, source control, databases, messaging, or infrastructure control systems.
That makes network architecture a first-order design concern. East-west throughput, north-south access, service discovery, DNS, load balancing, encryption, microsegmentation, egress control, and tool-specific authorization all affect whether an AI service is safe and supportable.
Identity, policy, economics, and recovery
Human users are only part of the identity surface. AI services also use service accounts, workload identities, automation credentials, certificates, secrets, model registries, data connectors, and tool permissions. Access must be scoped to the action and data involved, not granted broadly because the service is “internal.”
Policy also needs economic and resilience dimensions. A workload request should carry enough context to determine its budget, accelerator class, environment, data classification, recovery objective, logging requirement, and approval path. Otherwise, the platform can provision infrastructure but cannot make a defensible operating decision.
The Core Forge Is a Unified Operating Model
The center of the image is where the metaphor becomes operational. The forge is not one product feature. It is the interaction between the request plane, infrastructure plane, workload runtime, security controls, observability, and recovery model.
The diagram below shows what the reader should notice: policy enters before deployment, not after it, and telemetry and recovery remain attached to the service throughout its lifecycle.
VCF Automation as the request and policy plane
VCF Automation should be treated as more than a portal. Its value is the ability to turn architecture decisions into reusable consumption patterns. A well-designed catalog request can collect workload purpose, data classification, environment, accelerator needs, network zone, owner, cost center, recovery objective, and expected service level before infrastructure is created.
The output should be a governed deployment pattern, not an unrestricted blank environment. The strongest patterns expose a small number of supported choices while keeping low-level implementation details behind the platform boundary.
vSphere and mixed compute as the execution substrate
The compute layer provides isolation, scheduling, resource management, and lifecycle behavior for virtual machines and supported container services. VCF 9.1 expands the AI conversation beyond a single accelerator vendor by positioning mixed CPU and GPU infrastructure as part of the platform model.
That flexibility is useful only when it is controlled. Hardware compatibility, firmware, drivers, networking, accelerator mode, and runtime support must be validated as one stack. The platform team should publish supported compute profiles rather than allowing each project to create its own combination.
vSAN and adjacent data platforms as the data substrate
vSAN can provide integrated storage for many VM and Kubernetes use cases, but architects should avoid forcing every AI data pattern into one storage policy. Model artifacts, application state, vector data, high-throughput training data, backup copies, and long-term audit evidence may require different services or tiers.
The platform pattern should define where each data class belongs, how it is encrypted, how it is retained, and how it is restored. Storage architecture must follow the service recovery model, not just capacity forecasts.
VCF Networking with NSX as the trust fabric
NSX capabilities can support segmentation, distributed enforcement, tenant boundaries, routing, and policy-controlled connectivity. For AI, the important design move is to map those controls to data and tool boundaries.
A model endpoint may be allowed to read a curated vector index but denied direct access to the source repository. An enterprise copilot may call an approved internal API but require human approval before using an external tool. A fraud-detection service may need a tightly controlled low-latency path to streaming data while remaining isolated from general user networks.
Microsegmentation becomes valuable when it reflects workload intent. Generic rules around “AI servers” are too broad to support multiple AI service classes safely.
VKS and Private AI Services as the service platform
VMware vSphere Kubernetes Service gives platform teams a Kubernetes-based path for containerized AI applications, operators, data services, and supporting components. VCF Private AI Services adds AI-focused capabilities for supported deployment patterns, including model and GPU observability, model runtimes, governed integrations, and other private AI services documented for the release.
The operational point is not that every AI workload must use Kubernetes. It is that VMs, containers, and AI services can be delivered within one platform boundary while retaining workload-specific runtime choices.
VCF Operations as the observability and lifecycle plane
AI observability has to connect several layers that are often monitored separately:
- Infrastructure health, contention, capacity, and lifecycle status
- GPU utilization, memory pressure, power, temperature, and allocation
- Model latency, time to first token, throughput, cache behavior, and error rate
- Application availability, dependency health, user experience, and business transaction success
- Security events, policy changes, failed access, and audit evidence
- Cost allocation, idle capacity, utilization trends, and forecast demand
A dashboard is not the same as an operating model. Every signal needs an owner, threshold, response action, and escalation path. Broadcom documents AI model and GPU metrics in VCF 9.1, but some dashboards require additional components such as Grafana. That dependency belongs in the platform design and support runbook.
Different AI Worlds Need Different Recipes
The lower half of the image shows several AI outcomes emerging from the same forge. That is the strongest part of the concept. A shared foundation should produce different service patterns, not flatten every workload into one golden image.
| AI service pattern | Dominant bottleneck | Preferred platform emphasis | Critical control |
|---|---|---|---|
| Generative AI and RAG | Inference latency, token throughput, retrieval quality | Model runtime, vector services, GPU or CPU profiles, API delivery | Data-source approval, prompt and response evidence, egress policy |
| Computer vision | Data ingest, accelerator throughput, edge locality | High-bandwidth paths, batch or stream processing, GPU scheduling | Sensor data classification, retention, model drift monitoring |
| Digital twins and simulation | Compute density, storage throughput, deterministic data pipelines | Accelerated compute, large data movement, versioned simulation environments | Reproducibility, dataset lineage, scenario version control |
| Enterprise copilots | Identity, retrieval, tool authorization | Workload identity, private data access, governed connectors | Least privilege, human approval, full tool-call audit |
| Fraud detection | Low latency, stream reliability, evidence retention | Resilient inference endpoints, event pipelines, observability | Decision traceability, false-positive review, rollback path |
| Autonomous operations | Tool safety, change control, closed-loop validation | Agent orchestration, infrastructure telemetry, policy gates | Bounded authority, change approval, automatic rollback |
This is where the platform team should resist over-standardization. The request workflow, network profile, runtime, observability package, and recovery plan should be assembled from approved modules. The modules stay consistent, while the recipe changes by service class.
Governance Must Be Forged into Provisioning
Governance becomes effective when it is machine-readable, versioned, and connected to the delivery workflow. A policy document stored in a shared drive may define intent, but it does not prevent a deployment from bypassing that intent.
The following YAML is a conceptual workload contract. It is not a VCF API schema and should not be pasted into production tooling as-is. Its purpose is to show the fields that a platform team should capture and translate into automation, NSX policy, runtime configuration, observability, and approval workflows.
apiVersion: platform.dtd/v1
kind: AIWorkloadPolicy
metadata:
name: regulated-rag-service
owner: claims-ai-team
spec:
data:
classification: confidential
residency: private-cloud
approvedSources:
- curated-claims-index
platform:
runtime: vks
accelerator:
class: shared-gpu
cpuFallback: true
placement:
minimumFailureDomains: 2
security:
workloadIdentity: required
egress: deny-by-default
microsegmentationProfile: ai-restricted
humanApproval:
requiredFor:
- external-tool-access
- model-version-change
observability:
requiredSignals:
- infrastructure
- gpu
- model
- service
- audit
auditRetentionDays: 365
resilience:
rtoMinutes: 60
rpoMinutes: 15
economics:
costCenter: business-operations
monthlyBudget: set-by-finops
idleReclaimHours: 4
A production implementation would map these fields to approved catalog choices and enforcement points. The platform team must replace the placeholder API version, policy names, cost values, service classes, and recovery objectives with definitions that match its own control system.
Successful execution should produce more than a running endpoint. It should create the workload in an approved placement, apply identity and network controls, attach telemetry, register ownership, create evidence, and expose a recovery path. A request that lacks required data or violates a policy should fail before resources are consumed.
Common failure modes include a policy asking for a GPU class that has no supported capacity, observability being declared without a functioning metrics path, an identity dependency that cannot issue workload credentials, an egress rule that blocks a required service, or a recovery objective that the underlying data service cannot meet. Policy-as-code does not remove architecture work. It makes incomplete architecture visible earlier.
NIST’s AI risk guidance is useful here because governance should span the AI lifecycle. Infrastructure controls contribute to trustworthy operation, but they do not replace model evaluation, content risk management, data quality controls, human oversight, or application-specific testing.
The Operating Model Needs Explicit Owners
The image implies that one forge assembles everything. The organization should not interpret that as one team owning everything.
| Capability | Accountable owner | Operational responsibility |
|---|---|---|
| VCF foundation | Private cloud platform team | Clusters, capacity, lifecycle, availability, supported hardware, and platform health |
| AI service platform | Platform engineering or AI platform team | Catalogs, runtimes, namespaces, model-service patterns, and paved roads |
| Models and evaluation | Data science or MLOps team | Model selection, testing, versioning, promotion, drift review, and retirement |
| Enterprise data | Data owners and stewards | Classification, quality, lineage, access approval, retention, and deletion |
| Network and security | Security and network teams | Identity, segmentation, egress, secrets, evidence, and exception management |
| Business application | Product or application team | User experience, workflow integration, application SLOs, and business outcomes |
| Cost governance | FinOps and platform capacity teams | Allocation, utilization, forecasting, showback, chargeback, and reclamation |
| Recovery | Shared platform, data, and application owners | Protection scope, restore order, validation, and recovery exercises |
This responsibility model should be built into service onboarding. Every production workload needs a named technical owner, business owner, data owner, security reviewer, incident path, and cost center. A catalog that collects technical parameters but not operational ownership creates fast provisioning and slow incident response.
A Phased Path from Infrastructure to AI Factory
The star forge should be built in stages. A large platform program that attempts to deliver every runtime, model, data service, governance control, and use case at once will create complexity before it creates confidence.
The lifecycle below emphasizes progressive proof. Each phase has an exit condition that must be demonstrated before the scope expands.
Discover the demand before designing the supply
Inventory proposed workloads by latency, throughput, data location, model size, user population, runtime, tool access, and recovery needs. Separate experimentation from production demand. The objective is to identify a small number of recurring service classes, not collect a list of every model a team might test.
Exit condition: The organization can describe its initial workload classes, data boundaries, owners, and success measures without naming a specific GPU model.
Establish a supported foundation
Validate VCF release levels, hardware compatibility, accelerator modes, drivers, firmware, storage policies, network paths, identity integrations, certificates, logging, backup, and recovery dependencies. Define what is supported and what remains experimental.
Exit condition: The platform team can reproduce the baseline, patch it, observe it, and recover the management and workload components included in scope.
Pilot one bounded service
Choose a workload with real business value but limited blast radius. Measure end-to-end behavior, not just model speed. Include authentication, data access, network controls, application integration, telemetry, incident response, and a recovery test.
Exit condition: The service meets its defined SLOs, produces evidence, has an assigned owner, and can be restored through a documented procedure.
Productize the paved road
Convert the pilot into reusable catalog items, policy modules, deployment blueprints, observability packs, capacity profiles, validation tests, and runbooks. Remove project-specific assumptions that would prevent reuse.
Exit condition: A second team can consume the pattern without the original engineers manually rebuilding the environment.
Scale tenants and service classes
Add quotas, fairness controls, capacity reservations, shared and exclusive accelerator profiles, tenant boundaries, fleet-level reporting, and recovery exercises. Introduce additional workload recipes only when the operating model can support them.
Exit condition: The platform can onboard multiple teams without weakening support, security, cost visibility, or lifecycle discipline.
Optimize with service economics
Track useful work, not just installed capacity. Depending on the service, useful units may include requests, tokens, images processed, simulations completed, incidents analyzed, or business transactions protected. Compare those units with accelerator hours, energy, storage, network use, support effort, and failure cost.
Exit condition: Capacity and architecture decisions can be defended with observed utilization, service performance, and cost per useful outcome.
Decision Criteria and Readiness Gates
Before calling the environment an AI factory, the architecture team should be able to answer the following questions with evidence:
- Workload fit: Are the dominant services training, fine-tuning, batch inference, real-time inference, retrieval, simulation, computer vision, or agentic workflows?
- Data fit: Where does the data live, how sensitive is it, how quickly does it change, and what may leave the private boundary?
- Runtime fit: Which workloads belong in virtual machines, VKS clusters, container services, or other supported runtimes?
- Accelerator fit: Which services need shared GPUs, exclusive devices, high-speed multi-host paths, or CPU fallback?
- Security fit: Are workload identity, secrets, segmentation, egress, tool access, audit, and exception paths defined?
- Observability fit: Can teams correlate infrastructure, accelerator, model, service, security, and cost signals?
- Resilience fit: Are recovery time and recovery point objectives defined for infrastructure, models, data, indexes, configuration, and applications?
- Operating fit: Are lifecycle, incident, capacity, support, and ownership responsibilities explicit?
- Economic fit: Is there enough utilization and repeat demand to justify owned capacity, and can idle resources be reclaimed?
- Support fit: Are versions, hardware, firmware, drivers, add-ons, and integrations validated against the current support matrices?
A design that cannot answer these questions may still run AI. It is not yet a production AI platform.
Where the Star Forge Metaphor Breaks
The image is intentionally ambitious, but architecture improves when the limits of the metaphor are explicit.
A unified platform is not a complete AI lifecycle
VCF can provide infrastructure, runtimes, operations, automation, security, and private AI capabilities. It does not remove the need for data engineering, model evaluation, prompt and retrieval testing, application design, legal review, user training, or business-process ownership.
Infrastructure recovery is not service recovery
Recovering hosts, virtual machines, or clusters is necessary but insufficient. The service may depend on model artifacts, data indexes, external APIs, certificates, secrets, policy versions, pipelines, and human approval workflows. Recovery must restore the service chain in the correct order and validate business behavior.
Observability does not automatically create accountability
More metrics can produce more dashboards without improving decisions. The operating model must define which signals matter, who acts, what thresholds mean, and how model behavior is correlated with infrastructure conditions.
Zero Trust is a design discipline, not a feature checkbox
Distributed firewalling, encryption, identity controls, and audit trails are important enforcement mechanisms. Zero Trust still requires explicit resource identities, least-privilege policy, continuous verification, bounded tool access, exception handling, and evidence review.
Built-in does not always mean included, enabled, or production-ready
Specific capabilities can depend on VCF edition, validated hardware, VMware Advanced Cyber Compliance, partner products, external observability components, or additional deployment work. Tech-preview features should not be used as production dependencies. Each design must be checked against current product documentation, release notes, compatibility guides, and support statements.
Vendor economics must be validated against the workload
Broadcom publishes efficiency and cost claims for VCF 9.1. Those claims are useful inputs, not a substitute for measurement. Actual economics depend on workload density, accelerator utilization, support model, power, cooling, staffing, refresh cycles, data movement, software entitlements, and the useful output produced by the service.
Conclusion
The AI star forge is a stronger mental model than the familiar “GPU cluster” conversation because it makes the hidden work visible. Production AI is assembled from compute, storage, networking, identity, policy, observability, recovery, cost controls, and operational ownership. The model is only one component inside that system.
VMware Cloud Foundation 9.1 can provide a practical private-cloud foundation for this approach. Its value is not simply that it can host accelerated workloads. Its value is the opportunity to deliver VMs, Kubernetes services, private AI capabilities, security controls, automation, lifecycle management, and observability through a shared operating model.
The architecture still has to be earned. Teams must validate hardware and software combinations, define reusable workload recipes, govern data and tool access, measure end-to-end services, test recovery, assign owners, and prove economics with real utilization. When those controls are built into the provisioning and operating workflow, VCF can become more than infrastructure beneath AI. It can become the forge that turns enterprise capacity into repeatable, secure, observable, and recoverable AI services.
External References
- Broadcom TechDocs: Architectural Options in VMware Cloud Foundation
Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/vmware-cloud-foundation-concepts.html - Broadcom TechDocs: VMware Private AI Foundation with NVIDIA 9.1
Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/private-ai/foundation-with-nvidia/9-1.html - Broadcom: Broadcom Announces VMware Cloud Foundation 9.1, Enabling Secure and Cost-Effective Infrastructure for Production AI
Canonical URL: https://news.broadcom.com/releases/broadcom-announces-vmware-cloud-foundation-9-1 - VMware Cloud Foundation Blog: VCF 9.1: The Secure, Cost-Effective Private Cloud Platform for Production AI
Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/05/vcf-9-1-secure-cost-effective-private-cloud-platform-for-production-ai/ - VMware Cloud Foundation Blog: Streamline, Simplify and Protect all your AI workloads with VCF 9.1
Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/05/streamline-simplify-and-protect-all-your-ai-workloads-with-vcf-9-1/ - VMware Cloud Foundation Blog: Strengthen Zero Trust Security and Resilience with VCF 9.1
Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/05/platform-security-vcf-9-1/ - NVIDIA: NVIDIA Enterprise AI Factory Design Guide White Paper
Canonical URL: https://docs.nvidia.com/ai-enterprise/planning-resource/ai-factory-white-paper/latest/index.html - NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
Canonical URL: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
TL;DR Hybrid cloud architecture should be treated as a controlled decision experiment, not a one-time platform selection. Before moving workloads, model several...