VCF 9 and the Private AI Control Plane
What enterprise platform teams can learn from running AI workloads at home — isolation, policy, and the operator experience.
Every VCF deployment I’ve worked on eventually faces the same question: where do the AI workloads go? After six months running private inference on a DGX Spark, I have opinions.
The parallel is closer than you’d think
| Enterprise (VCF/Tanzu) | Home lab (DGX) |
|---|---|
| Namespace isolation | Docker network + VLAN |
| Network policies | Tailscale ACLs |
| Resource quotas | Ollama model memory limits |
| Observability stack | Custom /status endpoint |
| GitOps for config | Agent commits to this repo |
The vocabulary differs. The architectural intent doesn’t.
Policy before models
The mistake I see in both contexts: load the model first, figure out access control later. On the Spark, Tailscale ACLs define exactly which devices can hit the inference API. In VCF, that’s NSX micro-segmentation and RBAC — same problem, different SKU.
The operator experience gap
VCF has vCenter, Aria, decades of UX investment. Home AI has… a terminal and hope. Building this site’s lab status widget forced me to think about what “day-2 operations” means when you’re the only operator. Spoiler: you need the same runbooks you’d write for a client, just shorter.
Takeaway
Private AI at home isn’t a hobby project that teaches you nothing about enterprise. It’s a compressed sandbox for the same control-plane decisions platform teams are making right now — with faster feedback loops and lower blast radius.