VCF 9.1 AI Foundry: Turning GPU Capacity into Governed AI Services

TL;DR

The VCF 9.1 AI Foundry image presents a useful operating model for private AI: raw compute enters on one side, passes through automation, isolation, observability, and validation controls, then emerges as a consumable AI service. The value is not simply the presence of GPUs. It is the ability to convert infrastructure into repeatable, secured, monitored, and supportable environments.

VMware Cloud Foundation 9.1 provides many of the platform capabilities needed to build this model, including VCF Automation, VCF Operations, VCF Networking, vSphere Kubernetes Service, and VMware Private AI capabilities. However, the foundry does not operate automatically. Architects and platform teams must still define service classes, tenancy boundaries, security profiles, telemetry requirements, lifecycle ownership, release gates, and operational responsibilities.

Introduction

The image of a VCF 9.1 AI Foundry works because it frames private AI as a production system rather than a hardware purchase.

On the left, GPU, CPU, memory, storage, and networking resources are depicted as raw material. In the middle, those resources move through three control cells: automate, isolate, and observe. On the right, the platform releases finished environments such as AI workstations, Kubernetes platforms, inference services, and tenant GPU capacity.

That progression captures a problem many infrastructure teams are beginning to encounter. Installing accelerators does not create an AI platform. It creates capacity that still needs to be allocated, configured, secured, measured, patched, recovered, and supported.

The foundry metaphor shifts the architecture conversation from, “How many GPUs do we own?” to, “How reliably can we turn that capacity into governed services?”

The Image Is a Mental Model, Not a Product Diagram

There is no single VCF component officially named the “VCF AI Foundry.” The term is being used here as an architectural and operating-model metaphor.

That distinction matters because the image compresses several platform layers into one production line. A real implementation may involve VCF Automation, VCF Operations, VCF Networking, vSphere, vSAN, vSphere Kubernetes Service, VMware Private AI Foundation with NVIDIA, VCF Private AI Services, identity systems, enterprise data platforms, external model repositories, and separately packaged security capabilities.

The image is therefore best interpreted as a capability map:

Foundry zone	Architectural meaning
Raw GPU capacity	Physical and virtual compute, memory, storage, networking, and accelerator inventory
Automate	Catalogs, blueprints, placement logic, policy inputs, configuration, and lifecycle actions
Isolate	Tenant boundaries, network segmentation, identity, data protection, ingress, egress, and workload trust
Observe	Capacity, performance, security, compliance, cost, model, and service telemetry
Validate	Technical, security, operational, and consumption-readiness gates
Finished environments	Supported services with documented interfaces, limits, ownership, and lifecycle expectations

This model is valuable because it makes the control path visible. It also exposes what must exist between hardware procurement and production release.

The Scenario: A Private AI Request Enters the Platform

Consider an application team requesting an inference environment for a retrieval-augmented generation service.

The request appears simple:

• access to an approved model
• GPU-backed inference
• private enterprise data
• an API endpoint
• predictable performance
• development and production environments

The platform must translate that request into much more than a virtual machine or Kubernetes namespace. It must resolve capacity, placement, networking, identity, data access, model provenance, runtime configuration, security policy, observability, backup, release validation, and cost ownership.

The foundry pipeline can be represented as follows:

The important point is that deployment is only one stage. A successful foundry must also determine whether the resulting service is safe, measurable, recoverable, and ready for consumption.

Scope and Terminology Guardrails

Several terms in this architecture can become misleading when they are used too broadly.

AI Platform

An AI platform is not merely a cluster containing GPUs. It includes the interfaces, control mechanisms, software services, policies, and operating practices required to deliver AI capabilities repeatedly.

AI Workstation

An AI workstation is typically an individual or small-team environment intended for development, experimentation, data science, or model testing. It should not automatically inherit the availability, security, or support expectations of a production inference service.

AI Kubernetes Platform

A GPU-enabled vSphere Kubernetes Service cluster provides a foundation for containerized AI workloads. It does not remove the need to govern namespaces, images, secrets, storage, network policy, model artifacts, and release pipelines.

Inference Service

An inference service is a consumption endpoint, not just a running model server. It requires a defined API contract, authentication model, performance objective, scaling method, model version policy, telemetry path, and rollback procedure.

Tenant GPU Cloud

A tenant GPU cloud is a consumption and isolation model. It requires quotas, placement policies, fair-use controls, ownership boundaries, and a method for handling contention or exhaustion.

The Foundry Starts with Raw Capacity, Not a Service

The left side of the image correctly treats hardware as raw material.

Accelerators matter, but they are only one dependency. A production AI service also consumes CPU, host memory, storage throughput, network bandwidth, management services, identity infrastructure, certificates, logging capacity, backup capacity, and operational labor.

A useful capacity model should therefore include more than the number and type of available GPUs.

Capacity concern	Question the platform team must answer
Accelerator compatibility	Which GPU generations, profiles, drivers, and runtime combinations are supported?
Placement	Can a request be placed without creating a fragile or highly contended failure domain?
Memory	Does the workload fit within available device and host memory under expected concurrency?
Storage	Can storage sustain model loading, checkpoints, vector access, and data-pipeline throughput?
Networking	Are data paths, east-west traffic, management flows, and user access appropriately designed?
Availability	What happens when a host, GPU, network path, or supporting service fails?
Lifecycle	How will firmware, drivers, hypervisors, runtimes, and models be upgraded together?
Cost	Which team owns reserved capacity, idle capacity, shared services, and burst consumption?

Raw capacity becomes useful only when these constraints are translated into service-level rules.

Automate: Turn Intent into a Reproducible Build

The first control cell in the image is automation. This is where an infrastructure request becomes a defined service workflow.

VCF Automation can provide the self-service and blueprint layer for VM-based, Kubernetes-based, and AI-oriented environments. VMware Private AI Foundation with NVIDIA also provides catalog patterns for use cases such as AI workstations, GPU-enabled Kubernetes clusters, and GPU-backed inference services.

The architecture value comes from what the automation layer standardizes.

Catalog Inputs

A well-designed catalog request should collect inputs that influence architecture and policy, not expose every low-level configuration option to the consumer.

Useful inputs may include:

• service type
• business owner
• technical owner
• development or production classification
• data sensitivity
• requested capacity class
• required availability
• expected duration
• network exposure
• approved model or runtime
• cost center
• expiration or review date

The catalog should capture intent. The blueprint and policy layers should translate that intent into controlled implementation choices.

Blueprint Responsibilities

A production blueprint may need to coordinate:

• project or tenant selection
• compute placement
• VM or Kubernetes provisioning
• storage policies
• network creation or attachment
• identity and role assignments
• secrets retrieval
• runtime installation
• model-service deployment
• telemetry registration
• backup enrollment
• policy validation
• release status

The blueprint should also define what happens after initial deployment. Day-2 operations such as resizing, updating, reconfiguring, rotating credentials, changing model versions, troubleshooting, and retiring the environment are part of the service design.

Automation Is Not the Same as Standardization

Automating an inconsistent process only makes inconsistency faster.

The platform team still needs:

• approved service patterns
• versioned blueprint releases
• documented input contracts
• compatibility testing
• promotion between environments
• rollback procedures
• drift detection
• ownership for failed requests
• deprecation rules for old templates

The foundry becomes reliable when the same service request produces a predictable result across repeated deployments.

Isolate: Make Tenancy and Trust Explicit

The green isolation chamber in the image represents one of the most important differences between a demonstration environment and a production AI platform.

AI workloads can combine sensitive data, high-value model artifacts, privileged service identities, external dependencies, shared accelerators, and unpredictable user-generated inputs. The trust model must account for all of them.

VCF Networking and NSX-based controls can provide segmentation, routing, distributed enforcement, virtual private cloud boundaries, and integration with Kubernetes networking. Advanced VMware vDefend capabilities can add deeper lateral-security and inspection functions where licensed and designed into the solution.

The isolation model should be defined across several dimensions.

Tenant Isolation

Tenancy determines which organizational unit owns, administers, and pays for an environment. It should also determine which resources can be shared.

A tenant boundary may affect:

• catalog visibility
• quota assignment
• project membership
• namespace access
• network connectivity
• data availability
• logging visibility
• support routing
• cost attribution

Workload Isolation

Development notebooks, training jobs, inference APIs, vector databases, and agent services do not necessarily belong in the same trust zone.

Separate workload classes when they have different:

• exposure models
• data classifications
• administrative owners
• runtime privileges
• scaling behavior
• availability requirements
• supply-chain risks

Data Isolation

Network segmentation alone does not protect enterprise data.

The platform must also govern:

• data-source authorization
• service identities
• encryption
• secrets
• retrieval boundaries
• vector indexes
• cached prompts and responses
• model inputs and outputs
• retention
• audit evidence

Accelerator Isolation

Shared GPU capacity introduces performance and ownership questions in addition to security concerns.

The architecture must define whether accelerators are:

• dedicated to one workload
• shared within a tenant
• shared across tenants
• assigned through supported partitioning
• passed directly to a VM
• scheduled through Kubernetes
• reserved for production
• available for opportunistic workloads

The isolation model must match both the hardware capabilities and the service guarantee being offered.

Observe: Prove the Service Is Healthy and Worth Its Cost

The violet observability chamber in the image is not simply a dashboard wall. It is the evidence layer of the foundry.

VCF Operations can contribute infrastructure, capacity, performance, compliance, and operational telemetry. VCF 9.1 also introduces additional AI-focused monitoring and private AI service capabilities. Some AI-specific dashboards and integrations depend on supporting components, so the telemetry architecture should be validated rather than assumed.

A useful observability model spans four layers.

Resource Telemetry

Resource telemetry shows whether the underlying infrastructure is healthy and sufficiently utilized.

Examples include:

• GPU utilization
• device memory usage
• temperature and power
• CPU and host memory
• storage latency and throughput
• network throughput
• host and cluster health
• capacity remaining

Platform Telemetry

Platform telemetry shows whether the runtime and shared services are functioning.

Examples include:

• Kubernetes cluster health
• node and namespace status
• controller failures
• container restarts
• scheduling delays
• runtime versions
• registry availability
• certificate health
• identity-service dependencies

AI Service Telemetry

AI service telemetry shows whether the consumer-facing capability is meeting its objective.

Examples include:

• request latency
• time to first token
• throughput
• error rate
• queue depth
• concurrency
• tokens processed
• model version
• failed retrievals
• endpoint availability
• output-policy violations

Governance Telemetry

Governance telemetry shows whether the service remains within approved boundaries.

Examples include:

• blueprint version
• configuration drift
• network-policy compliance
• privileged access
• model provenance
• data-source changes
• security events
• exceptions
• cost-center mapping
• expiration status

A GPU can be fully utilized while the service is failing its consumers. Conversely, low GPU utilization may be acceptable for a latency-sensitive service that reserves capacity for bursts. Infrastructure metrics must therefore be interpreted in the context of the service objective.

Validation Is the Release Gate

The image places validation immediately before finished AI environments. That is where the foundry metaphor becomes operationally useful.

A deployment should not become a supported service merely because the automation workflow completed.

A release gate should confirm evidence across multiple domains:

Validation domain	Example evidence
Provisioning	All requested components exist and match the approved blueprint version
Capacity	Required compute, memory, storage, and accelerator resources are available
Networking	Expected routes, name resolution, ingress, egress, and segmentation are functioning
Identity	Human and service access matches the approved role model
Security	Required policies are attached, enforcement is active, and exceptions are recorded
Runtime	Drivers, libraries, Kubernetes components, and model-serving software are healthy
Performance	The service meets defined latency, throughput, or concurrency thresholds
Observability	Logs, metrics, alerts, dashboards, and ownership are confirmed
Recovery	Backup, rebuild, rollback, or restoration procedures have been tested
Governance	Model, data, cost center, owner, expiration, and support information are recorded

The release gate creates a clear distinction between “deployed” and “ready for consumption.”

Finished Products Need Different Service Contracts

The right side of the image groups several AI environment types together. Operationally, they should not be treated as interchangeable.

Service class	Primary consumer	Typical boundary	Release evidence	Lifecycle expectation
AI workstation	Data scientist or developer	Individual or small-team project	Runtime validation, storage access, identity, quota, expiration	Frequently rebuilt or refreshed
GPU-enabled VKS cluster	Platform or application team	Tenant cluster, namespace, or project	Cluster health, policies, storage, registry, observability	Versioned platform lifecycle
Managed inference service	Application consumers	API and service boundary	Endpoint health, model version, scaling, latency, security	Controlled releases and rollback
Tenant GPU capacity	Business unit or service provider tenant	Quota and infrastructure boundary	Allocation, placement, network, metering, support ownership	Capacity and consumption lifecycle
Private AI platform service	AI developers and platform teams	Shared platform capability	Service availability, access, data governance, compatibility	Centrally governed shared service

The service contract should state:

• what the consumer receives
• what the platform team operates
• what the consumer must operate
• what is monitored
• what is backed up
• what is excluded
• what limits apply
• how changes are requested
• how incidents are handled
• how the environment is retired

Without this contract, the foundry produces infrastructure artifacts rather than supportable services.

A Practical VCF 9.1 AI Foundry Operating Model

The operating model should connect each control gate to an accountable team.

The diagram highlights an important principle: automation does not eliminate ownership. It exposes where ownership must be assigned.

Platform Engineering

Platform engineering owns the catalog, blueprint framework, integration contracts, release pipeline, service classes, and developer or operator experience.

Infrastructure Operations

Infrastructure operations owns capacity, hardware health, placement domains, core platform lifecycle, backup foundations, and escalation into vendor support.

Network and Security Teams

Network and security teams own trust boundaries, ingress and egress patterns, policy baselines, inspection requirements, identity dependencies, exceptions, and security evidence.

AI or Data Platform Teams

AI and data platform teams own model services, approved runtimes, data integrations, registries, lineage, evaluation methods, and AI-specific operational standards.

Service Owners

Service owners define the business purpose, data use, availability requirement, cost ownership, user population, risk acceptance, and retirement decision.

A production foundry needs all of these roles, even when one team initially performs several of them.

Decision Criteria for Adopting the Foundry Model

The foundry model is most valuable when an organization has repeated AI demand that should be served through a common private-cloud control plane.

It is a strong fit when:

• multiple teams need similar GPU-backed environments
• data locality or sovereignty is important
• infrastructure must support both VMs and Kubernetes
• security policies must be applied consistently
• capacity is scarce or expensive enough to require governance
• platform teams can operate reusable service patterns
• workloads require enterprise identity and network integration
• leadership expects cost, compliance, and operational evidence

It may be premature when:

• there is only one short-lived experimental workload
• the organization lacks an owner for the AI platform
• hardware, driver, runtime, and model compatibility remain unresolved
• no standard data-access model exists
• service-level expectations have not been defined
• the platform team cannot yet support blueprint lifecycle management
• the organization expects a catalog to compensate for missing operational processes

The decision is not simply whether VCF can host AI workloads. The decision is whether the organization is prepared to operate AI as a governed service portfolio.

Risks and Caveats the Image Makes Look Too Easy

The foundry image is effective because it simplifies the system. Real implementations need to restore the complexity that matters.

Catalog Sprawl

Every team may request a slightly different environment. Without service-class discipline, the catalog becomes a collection of one-off templates that cannot be tested or maintained consistently.

Compatibility Boundaries

GPU firmware, host drivers, hypervisor versions, guest drivers, Kubernetes components, container runtimes, AI frameworks, and model servers have interdependent support requirements. Platform lifecycle testing must cover the complete chain.

Security Packaging

Not every advanced inspection or lateral-security feature is necessarily included in the base platform entitlement. Architecture and procurement teams should confirm which capabilities are present, separately licensed, or dependent on additional deployment components.

Data Gravity

Model execution may be close to the GPUs while enterprise data remains behind separate databases, APIs, storage systems, or security zones. The resulting data paths can determine performance and risk more than raw accelerator speed.

Performance Contention

Shared accelerators, storage, network links, and supporting services can create noisy-neighbor effects. Capacity reservations and service tiers must be based on measured behavior.

Observability Fragmentation

Infrastructure, Kubernetes, model-serving, application, data, and security telemetry may live in different systems. A polished dashboard does not automatically create a coherent troubleshooting path.

Recovery Assumptions

A highly available infrastructure cluster does not guarantee that a model endpoint, vector index, fine-tuning job, or agent workflow can be recovered correctly. Recovery requirements must be defined at the service level.

Blueprint Lifecycle

Blueprints are software artifacts. They require source control, reviews, testing, release notes, promotion, deprecation, rollback, and ownership.

Cost Attribution

GPU capacity can remain expensive even while idle. The operating model must distinguish reserved capacity, shared platform cost, consumer usage, stranded capacity, and strategic headroom.

Practical Readiness Gates

Before the first production AI service is released, the platform team should be able to answer the following questions.

Service Definition

• Is the service class documented?
• Are the consumer and platform responsibilities clear?
• Are availability, performance, security, and support expectations defined?

Capacity

• Is the supported accelerator and runtime combination documented?
• Are placement, contention, and failure-domain assumptions understood?
• Is capacity reserved, shared, or dynamically allocated?

Automation

• Is the blueprint version controlled?
• Are input fields governed?
• Are Day-2 changes and retirement automated or documented?
• Is there a rollback or rebuild path?

Security

• Are tenant, workload, data, and administrative boundaries explicit?
• Are ingress, egress, east-west, and management flows documented?
• Are required base and advanced security capabilities licensed and deployed?

Observability

• Are resource, platform, AI service, and governance metrics collected?
• Does each alert have an owner?
• Can operations trace a consumer incident through the complete service stack?

Lifecycle

• Is the full compatibility chain tested?
• Are model, runtime, blueprint, and platform versions recorded?
• Is there a supported upgrade and rollback process?

Governance

• Are model provenance, data access, cost ownership, expiration, and exceptions recorded?
• Is there a periodic review process?
• Can the organization demonstrate why the service remains approved?

A foundry becomes production-ready when these answers are embedded in the service workflow rather than stored only in an architecture document.

Conclusion

The VCF 9.1 AI Foundry image provides a strong mental model for private AI because it focuses attention on the transformation between infrastructure and service delivery.

Raw GPU capacity is only the input. VCF Automation can turn approved intent into repeatable builds. VCF Networking, NSX-based controls, identity, and optional advanced security services can establish isolation. VCF Operations and AI-specific telemetry can provide evidence about capacity, performance, compliance, and service health. Validation gates can then determine whether an environment is ready to be consumed.

The operational challenge is to connect these capabilities through clear service classes, policy inputs, ownership boundaries, lifecycle controls, and release evidence. Organizations that do this well will not merely host AI workloads. They will operate a controlled production system that can repeatedly turn finite infrastructure into governed AI services.

External References

• Broadcom Inc.: Broadcom Announces VMware Cloud Foundation 9.1, Enabling Secure and Cost-Effective Infrastructure for Production AI
  Canonical URL: https://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-vmware-cloud-foundation-91-enabling-secure
• Broadcom TechDocs: VMware Cloud Foundation 9.1
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1.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
• 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: Install VMware Private AI Foundation with NVIDIA using VCF Automation
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/02/24/install-vmware-private-ai-foundation-with-nvidia-using-vcf-automation/
• VMware Cloud Foundation Blog: Day 2 Operations for AI Blueprints in VCF Automation
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/03/05/day-2-operations-for-ai-blueprints-in-vcf-automation/
• VMware Security Blog: VMware vDefend for VCF 9.1: Zero Trust Lateral Security for the AI Era
  Canonical URL: https://blogs.vmware.com/security/2026/05/vdefend-vcf-9-1-zero-trust.html