The usual advice on AI infrastructure is a shopping list. Buy GPUs. Add fast storage. Upgrade the network. Install Kubernetes. Then, somehow, you have an AI-ready cloud.
Organisations that follow the list often find they have built something expensive and awkward: accelerators one team holds on to while another waits, storage that cannot keep up with training, and a platform nobody outside the infrastructure team can use. The alternative they are offered is simpler and costly in a different way: rent the capability from a global provider and send the data to it.
Neither is an architecture. This article is about what one looks like.
Why ordinary infrastructure struggles
Most enterprise systems — ERP, CRM, email, databases, web applications — are predictable. They run mainly on CPUs, grow gradually and are well served by standard storage and networking.
AI workloads behave differently. They need parallel processing, very large datasets, large amounts of memory, specialised acceleration and fast communication between machines. What serves an ERP system well can be badly matched to training a large model. That is not a tuning problem. It is an architectural one, and three technologies sit at the centre of it: GPUs, high-performance computing and Kubernetes.
GPUs: the acceleration
A CPU is built to work through varied tasks one after another, quickly. A GPU is built to perform a very large number of similar calculations at the same time. The matrix arithmetic at the heart of deep learning, model training, image processing and large-scale analytics is exactly that kind of work.
The practical result is that training finishes far sooner, inference responds faster, and models that would be impractical on CPUs alone become viable. That is why GPU capacity has become a strategic resource for governments, enterprises, universities and cloud providers — and why who owns it has become a question worth asking.
HPC: the scale
High-performance computing is the discipline of running very large, complex workloads across many machines at once. An HPC environment combines dense compute nodes, GPU acceleration, a high-bandwidth, low-latency interconnect, fast storage and frameworks that let one job spread across many systems.
AI needs this as soon as a workload outgrows a single server: training large models, scientific research, financial risk modelling, medical research, engineering simulation. In each case the limit is often not the speed of any one processor but how quickly data moves between processors and storage.
Kubernetes: the orchestration
Kubernetes is the open-source platform that automates how containerised applications are deployed, scaled and managed across a cluster. In an AI environment it is the layer that turns a collection of machines into something teams can actually use.
An AI platform has to run many kinds of work side by side: training jobs, inference services, data pipelines, applications and development environments. Kubernetes gives them one consistent way to be packaged, scheduled, scaled and recovered, and lets workloads move between environments without being rebuilt. Crucially, it can treat GPUs as schedulable resources — allocating them to jobs on demand, sharing them across teams and releasing them when the work is done, instead of assigning machines by hand.
How the three fit together
These technologies are often discussed separately. They work best as one design:
- GPUs are the engines — they make the computation fast.
- HPC is the road network — it lets large workloads move and scale across many machines.
- Kubernetes is the traffic control — it decides what runs where, and keeps it running.
Take any one away and the others underperform. GPUs without orchestration sit idle or fought over. Orchestration without a fast fabric starves the GPUs. A fast fabric with no scheduling is a very expensive network.
An AI-ready cloud is not a pile of accelerators. It is a service people can order.
Five design principles
Compute flexibility. Support CPU, GPU and HPC workloads on one platform, because real AI projects use all three: data preparation on CPUs, training on GPUs, the largest runs across a cluster.
Storage that keeps up. Low latency, high throughput and room to grow. Training is frequently limited by how fast data reaches the accelerators, not by the accelerators themselves.
A high-bandwidth interconnect. Distributed training depends on fast, low-latency communication between nodes. Design the network for the jobs you expect to run, not only the ones you run today.
Security and governance from the start. Identity, access control, encryption and compliance monitoring belong in the design, not bolted onto a cluster already full of sensitive data.
Sovereign deployment options. Many organisations need residency and local control for their AI data. The architecture should support shared, dedicated and sovereign deployments without being rebuilt for each.
The missing layer
Everything above describes infrastructure. What turns it into a cloud is the layer on top: a catalogue teams order from, tenancy that keeps one team’s data and jobs apart from another’s, metering and billing so GPU time is visible and paid for, and governance that treats an AI job like every other workload. It is the part most AI programmes underestimate, and the part that decides whether expensive hardware is used well or waits behind a queue of tickets.
It is also where Oasis Stack sits. It runs above infrastructure you already own — CloudStack, OpenStack, VMware, Kubernetes, bare metal and GPU, on x86 or ARM — and publishes it as services. Cloud Foundation provides the compute, storage, networking and Kubernetes. Infrastructure for AI adds GPU and AI-ready services on top, including AI Factory and WorkspaceAI, and teams keep the frameworks they already use: PyTorch, TensorFlow, JAX and Triton. Governance, Security & Compliance, where adopted, applies the same identity, policy and audit to AI work as to everything else, and Oasis Core puts all of it in one catalogue with one bill.
Infrastructure is the differentiator
Government, banking, healthcare, telecoms, manufacturing, education and energy all have AI ambitions, and all of them will meet the same architecture. The organisations that do best will not be the ones that bought the most accelerators. They will be the ones that built a platform where accelerators, data and governance work as one — on infrastructure they control, and as a service their own people can use.