VMware AI Factory: GPU Pooling, AI Tokenomics, and What VCF Customers Should Do Now
Broadcom shipped VMware AI Factory at Explore 2026. The technology is solid. Here is what it actually means for your infrastructure, your GPU costs, and your agentic AI deployments.
Token costs are about to become your next infrastructure problem. Broadcom projects they will grow 24x by 2030, driven by agentic loops, context expansion, and error correction cycles that compound with every model call. Most enterprises are not ready for that conversation.
VMware AI Factory, announced at Explore 2026, is Broadcom's answer. I've been working with VCF for a long time, and this is one of the more substantive announcements in a while. The feature list matters, but what interests me more is the concept underneath it: AI Tokenomics.
What AI Tokenomics Actually Means
The term sounds like marketing. It isn't.
When you have one model running one task, token cost is a line item. When you have dozens of agents, multiple models, shared GPU pools, and teams across the organization all generating inference traffic, cost attribution becomes a real operational problem. Who is consuming what, and at what rate?
AI Tokenomics is the practice of treating token consumption as a managed resource, the same way you manage CPU cycles or storage IOPS. VMware AI Factory introduces an AI Gateway specifically for this, with intelligent prompt routing, token rate limiting per application, and authorization controls. You can set how much inference budget each workload gets before it becomes a runaway cost center.
That is not a feature. That is a new operational discipline that most infrastructure teams have not built yet.
MetalSoft: From Hardware Arrival to VCF-Ready in Hours
One of the most practical announcements at Explore was the MetalSoft partnership, and it deserves more attention than it got.
MetalSoft is a bare-metal orchestration platform that sits below the VCF hypervisor layer. Its job is to handle everything that happens between "server arrives in the rack" and "ESXi is deployed and cluster-ready." Traditionally, that process involves manual provisioning checklists, cross-vendor firmware coordination, BIOS/BMC policy alignment, driver baseline synchronization, and GPU/NIC verification. For a 50-node AI cluster, this takes weeks and requires people who know exactly what they're doing.
With MetalSoft integrated into the AI Factory workflow, that sequence is automated: server discovery, hardware inventory, BIOS/BMC policies, firmware and driver alignment, network and storage prep, ESXi installation, and readiness validation, all policy-driven without a checklist in sight.
The operational savings here are real. Teams spend hundreds of hours annually on firmware research and manual pre-checks. More importantly, those same manual steps are how you end up with HCL drift, inconsistent configurations, and production incidents that trace back to a server that was never validated properly before it joined the cluster.
Beyond new hardware, this also changes how you think about existing bare metal in your environment. If you have servers that previously ran other workloads, MetalSoft can rediscover, revalidate, and redeploy them as ESXi hosts. That is hardware you already own, converted to AI-ready infrastructure without starting from scratch.
Multi-Tenant GPU Pooling: Fewer Model Copies, Better GPU Utilization
VCF 9.1.1 ships multi-tenant model sharing, and the economics here are worth understanding.
Without it, each team or application that needs model inference typically runs its own model copy. Three teams using Llama 3 means three separate model instances consuming three separate chunks of GPU memory. The utilization numbers on those GPUs are often poor because each team's traffic is bursty.
With multi-tenant sharing, one model instance serves multiple teams across separate namespaces with data isolation maintained between them. GPU utilization improves, redundant memory consumption disappears, and you can support more workloads on the same hardware.
The platform currently supports 150+ open-source models via vLLM, including Nemotron 3, Gemma 4, Qwen, and GLM 5.2. You choose the model, VCF handles the serving infrastructure.
Secure Agent Framework: Why This Is the Most Important Thing Coming
Most of the AI infrastructure conversation focuses on performance and cost. The security conversation is lagging behind, and that gap is dangerous.
Autonomous agents make independent decisions. They call tools, access data, invoke other agents, and in some cases execute code. In a traditional application, you know the blast radius of a bug. In an agentic system, a misbehaving agent can escalate privileges, exfiltrate data, or trigger unintended downstream actions before anyone notices.
The Secure Agent Framework addresses this directly. It sandboxes agents inside isolated containers and enforces what each agent can communicate with, both in terms of tools and other agents. The model is deny-by-default: nothing is accessible unless explicitly configured. Three mechanisms enforce this containment.
First, containers are automatically patched and verified using Buildpacks rather than Dockerfiles, which removes the manual hardening step that most teams skip. Second, agents cannot access each other's credentials or secrets at runtime, with vDefend extending that isolation to external SaaS connections. Third, resource constraints prevent runaway loops, meaning an agent stuck in a retry cycle cannot consume unbounded GPU time or memory before someone catches it.
The trigger for this work was real. Following incidents where AI systems escaped sandboxed environments due to inadequate guardrails, VMware built gateway-based enforcement across every agent-to-model, agent-to-tool, and agent-to-data connection. Everything goes through the gateway. There is no side door.
If you are planning to run autonomous agents in production, this framework is what the conversation with your security team needs to be built around.
What to Do Right Now
These capabilities are useful only if you start measuring early, while it is still cheap to get ahead of the curve.
On token consumption: VCF Operations already tracks model-serving metrics. In the VCF Operations dashboard, navigate to the AI Workloads section and look at token throughput and latency alongside GPU compute and memory utilization per namespace. If you do not have baseline numbers today, you will not know when costs start drifting.
On AI Gateway: When it ships, deployment follows the standard VCF Private AI services model. You configure it at the namespace level, assign token budgets per application or team, and set routing rules that direct prompts to the appropriate model based on cost, latency, or capability requirements. Start designing those policies now, while traffic is still light.
On bare metal readiness: If you have servers in your environment that are not currently in a VCF cluster, run an inventory. MetalSoft's discovery process can validate what you have against the HCL and tell you what is redeployable as AI-ready infrastructure. Converting existing hardware before you order new GPU servers is the fastest path to capacity.
Where This Is Heading
Private cloud is becoming the operating layer for enterprise AI. Not because public cloud cannot run the workloads, but because data sovereignty, cost predictability, and control requirements are pulling inference back on-premises.
VMware AI Factory is Broadcom putting that thesis into product: a complete stack for the customers who need that control to build on VCF. The technology behind it is solid. The question for every VCF customer right now is whether their infrastructure team is ready to operate AI workloads the same way they operate compute, which means instrumentation, governance, and policy from day one.
Nobody should treat 24x by 2030 as a distant forecast. It is the number to plan your capacity and budget around today. The teams that start measuring now will be in a very different position than the ones that wait for the bill.
References
Discussion
No comments yet. Be the first to start the discussion.