Field notes / Latest
Engineering notes from operating open infrastructure: the failures, design decisions, and upstream work that make open infrastructure better.
Browse all field notes
Compare GPU VMs, bare metal, Kubernetes, and managed inference for AI workloads. Learn which architecture fits your performance, control, scaling, and operational needs.
Read field note
Learn the real cost of vendor lock-in and how open infrastructure can help businesses maintain flexibility, portability, and choice.
Read field note
Why does AI inference slow down in production? Learn how queueing, batching, GPU memory, storage, networking, and autoscaling affect LLM latency.
Read field note
Compare GPU VMs, bare metal, Kubernetes, and managed inference for AI workloads. Learn which architecture fits your performance, control, scaling, and operational needs.
AI infrastructure decisions often begin with a technology request:
“We need GPUs.”
“We should run this on Kubernetes.”
“We need bare metal for performance.”
“We need somewhere to host this model.”
But each of those statements jumps to an infrastructure choice before defining what the workload actually needs.
A distributed training job running continuously for days has very different requirements from a development environment. A customer-facing inference service behaves differently from a batch embedding workload. And an organization operating dozens of models across several engineering teams faces a different problem from a team that simply needs one reliable model endpoint.
The better question is not which infrastructure option is best for AI?
It is:
Which level of infrastructure control and abstraction gives this workload what it needs without creating unnecessary operational complexity?
GPU virtual machines, bare metal, Kubernetes, and managed inference can all be appropriate answers. But they do not sit at exactly the same layer of the stack. Kubernetes, for example, can run on either VMs or bare metal. Managed inference abstracts much of that infrastructure away altogether.
Understanding that distinction is the first step toward making a better architecture decision.
Before selecting a platform, define what actually needs to run.
Important questions include:
Two workloads using the same GPU model may still require completely different architectures.
A research team might value rapid provisioning and full control over its software stack. A platform team running many production services may care more about scheduling, deployment automation, observability, and shared capacity. Another organization may have no reason to operate GPU infrastructure at all if the real requirement is simply to expose a model to an application.
Infrastructure should follow those requirements rather than organizational preference for a particular technology.
GPU-backed virtual machines provide a familiar cloud operating model while preserving substantial control over the environment.
Teams can select their operating system, frameworks, model-serving software, networking, storage, and deployment tooling. VMs also fit naturally into existing cloud patterns around tenancy, access control, automation, monitoring, and workload separation.
They are often a strong fit for:
GPU VMs also do not necessarily mean heavily abstracted GPU access. OpenStack, for example, supports PCI passthrough, which can expose physical PCI devices such as GPUs directly to a guest.
For the underlying implementation details, see the OpenStack Nova PCI passthrough documentation.
The tradeoff is that the organization still operates most of the environment above the VM.
Teams remain responsible for the operating system, drivers, model-serving software, application deployment, monitoring, and often scaling. Capacity may also remain assigned to a VM even when GPU utilization falls, depending on how the environment is designed.
GPU VMs therefore provide a useful middle ground: significant infrastructure control without requiring the team to operate the physical servers underneath it.
Bare metal removes the hypervisor layer and gives the workload direct use of the physical server.
That can matter when teams require precise control over GPU topology, drivers, host configuration, networking, accelerators, or specialized interconnects. Dedicated hardware can also provide straightforward physical resource isolation.
Bare metal becomes particularly relevant for:
But bare metal should not automatically be translated as “faster.”
Actual performance depends on the workload and the full architecture around it: GPU configuration, interconnect topology, networking, storage throughput, NUMA placement, software libraries, and how any virtualized alternative has been configured.
If virtualization is not the limiting factor, removing it may deliver little practical benefit.
Bare metal also introduces operational responsibilities. Hardware provisioning, failures, firmware, lifecycle management, capacity placement, and host configuration become more visible to the operator. Dedicated servers can also be harder to divide efficiently among small or intermittent workloads.
The right reason to choose bare metal is therefore not simply maximum theoretical performance.
It is that direct hardware control or dedicated infrastructure is important enough to justify the extra operational responsibility.
Kubernetes is frequently discussed as though it were an alternative to virtual machines or bare metal.
Strictly speaking, it is not.
Kubernetes is an orchestration layer. Its worker nodes may themselves be virtual machines or physical servers.
That distinction matters because Kubernetes solves a different problem: coordinating workloads consistently across a pool of infrastructure.
Its value becomes stronger when the challenge changes from “run this model” to manage many services, users, models, and deployment lifecycles.
Kubernetes can provide capabilities such as workload scheduling, declarative deployments, service discovery, automated recovery, rolling updates, workload scaling, resource controls, and multi-team operational consistency.
GPU resources can also be exposed to Kubernetes workloads through device plugins and requested as schedulable resources.
For a technical overview, see the official Kubernetes GPU scheduling documentation.
This makes Kubernetes particularly relevant for:
But Kubernetes does not remove infrastructure complexity. It relocates and formalizes it.
Someone still needs to operate cluster nodes, GPU integrations, networking, storage, observability, upgrades, scheduling policies, and the capacity underneath the cluster.
This creates an important distinction:
Kubernetes can reduce application-level operational work while increasing platform-level responsibilities.
That tradeoff makes sense when there is a genuine orchestration problem to solve.
For a deeper look at how training and inference place different demands on a Kubernetes environment, see VEXXHOST's guide to AI workloads on Kubernetes.
Sometimes the organization does not really need an infrastructure platform.
It needs an application to use a model reliably.
With managed inference, much of the underlying infrastructure becomes the provider's responsibility. Instead of operating GPU servers, Kubernetes clusters, model-serving runtimes, and deployment infrastructure, the application consumes a managed endpoint.
This can be attractive for:
The tradeoff is reduced infrastructure control.
Runtime customization may be more constrained. Model availability and serving capabilities depend on the provider. Organizations must still evaluate where processing occurs, how data is handled, what governance controls apply, and whether the deployment meets residency or compliance requirements.
Managed inference is therefore not simply an easier version of self-hosting.
It represents a different operating decision:
the organization has decided that running the model-serving infrastructure itself does not create enough value to justify owning that layer.
The most important row may be the first one.
These approaches solve problems at different layers and can therefore be combined rather than treated as four mutually exclusive choices.
A mature environment may use several models simultaneously.
Developers might experiment on GPU VMs while long-running training jobs consume dedicated GPU nodes. Kubernetes may orchestrate production services across that infrastructure, while some standardized model-serving workloads are consumed through managed inference endpoints.
A workload can also change architecture as it matures.
An experimental model may begin on a VM. Once multiple applications depend on it, Kubernetes may provide better deployment and operational consistency. If the serving layer later becomes standardized and operating it no longer creates value, consuming the model through managed inference may become the better choice.
The reverse can happen too. A managed endpoint may be appropriate initially, while later requirements around customization, control, economics, or data placement justify operating the model internally.
Architecture should be allowed to evolve with the workload.
A useful way to approach the decision is to work from the top of the stack downward.
Choose managed inference when:
Your main requirement is to use a model reliably through an application, and operating GPU or serving infrastructure provides little strategic value.
Consider Kubernetes when:
You need to orchestrate many workloads, models, services, teams, or deployment lifecycles consistently.
Then ask what Kubernetes itself should run on.
Choose GPU VMs when:
You need flexible accelerated infrastructure, strong workload isolation, and software-stack control without managing physical servers.
Consider bare metal when:
Direct hardware access, specialized networking, dedicated resources, or strict isolation requirements justify the additional operational burden.
Whichever model appears appropriate, validate it against GPU utilization, workload duration, scaling patterns, operational maturity, infrastructure expertise, compliance, data residency, portability, cost predictability, storage requirements, and network behavior.
Choosing Kubernetes because it is the default modern platform.
A stable, isolated inference service does not automatically need a GPU-enabled Kubernetes platform around it.
Choosing bare metal simply because it sounds faster.
Benchmark the actual workload and identify whether virtualization is genuinely a bottleneck.
Buying GPU capacity before understanding utilization.
Accelerators provide little value while workloads are waiting on data, preprocessing, storage, networking, or incoming requests.
Building a platform when an endpoint would solve the problem.
Owning more infrastructure does not automatically create more strategic value.
Optimizing peak performance while ignoring operations.
Availability, monitoring, recovery, upgrades, capacity management, and failure handling eventually determine whether the system can run reliably.
Treating GPUs in isolation from storage and networking.
Slow model loading, constrained east-west bandwidth, or insufficient storage throughput can undermine an otherwise powerful GPU environment.
The useful part of this decision is that organizations do not necessarily need to commit to one abstraction permanently.
VEXXHOST GPU Infrastructure supports accelerated environments built around the workload, including VM, bare-metal, and container access models. The underlying infrastructure can be deployed in VEXXHOST facilities or around customer-owned GPU hardware.
For teams where orchestration is the real requirement, VEXXHOST Managed Kubernetes provides an upstream Kubernetes platform with managed or supported operating models.
OpenStack infrastructure and private cloud deployment can provide the compute, networking, storage integration, tenancy, and lifecycle foundation beneath those workloads when greater infrastructure control is required.
And when the real requirement is simply to make a model available to an application, VEXXHOST AI Inference provides a managed model-serving layer for open, commercial, or custom models.
The architecture question should therefore begin with the workload, not the product.
There is no universally correct infrastructure layer for AI.
Some workloads genuinely need dedicated hardware. Others benefit from Kubernetes orchestration. Many run comfortably on GPU VMs. And some applications should never require their engineering teams to think about GPU infrastructure at all.
The objective is not to standardize everything on bare metal, VMs, Kubernetes, or managed inference.
It is to use the lowest level of infrastructure complexity necessary to satisfy the workload's technical, operational, governance, and performance requirements.
If those requirements are still unclear, VEXXHOST can help evaluate the workload, deployment constraints, and operating model before infrastructure decisions become expensive assumptions. Explore VEXXHOST AI Advisory!
Choose from Atmosphere Cloud, Hosted, or On-Premise.
Simplify your cloud operations with our intuitive dashboard.
Run it yourself, tap our expert support, or opt for full remote operations.
Leverage Terraform, Ansible or APIs directly powered by OpenStack & Kubernetes
