Services / Private AI
Keep AI and your data in-house
Private AI & GPU platform
Retrieval over your own documents, a model served behind it, and fine-tuning when it earns its place. We build the GPU, storage and Kubernetes layer all three run on, on hardware you own or capacity you rent, with your data staying inside your network.
A fixed-scope read of the workloads and the platform to run them, typically one to two weeks, and the fee credits against the engagement if you go ahead. Not ready for that? Send us the shape of what you want to run and get a written reply within two business days.
AI does not have to mean sending your data and your models to somebody else’s cloud. For a lot of organizations that is the whole question. The material a model is trained or grounded on is the business, and the prompts and the outputs are a record of how the business actually works. Some of it cannot leave for legal reasons, and some of it simply should not.
There is a second reason, and it outlasts the first. Running AI on infrastructure you control means you can say what ran, on which hardware, against which data, and show that to an auditor without asking a third party for a report. In regulated sectors that is expected rather than optional.
Then there is the dependency itself. A provider’s model roadmap becomes your roadmap: versions are deprecated on their schedule, terms change on their schedule, and the bill is repriced on their schedule. Owning the platform underneath does not remove every dependency, but it puts the ones that remain on terms you can see.
What we build
The platform your AI workloads run on, not the workloads themselves: GPU compute, the storage that keeps it fed, the network around it, and the Kubernetes layer that schedules and isolates the whole thing.
- GPU nodes, bare metal or virtualized. Cards scheduled to containers, or passed through whole to a virtual machine where a workload should own one. The NVIDIA GPU Operator manages both paths, though not identically: on container nodes it installs the driver, the container toolkit and the device plugin; on passthrough nodes it binds the cards to VFIO and advertises them to the cluster, and the driver goes inside the guest.
- The driver and device lifecycle. The part that breaks quietly: driver and toolkit versions, container runtime configuration, and the monitoring that tells you a card is degrading before a job does.
- Storage in two tiers. An S3-compatible object store, which we build and run, for datasets and model artifacts, because that is the interface the tooling already speaks. Faster block or file storage alongside it for the working set a running job actually touches.
- Scheduling and isolation. GPUs are advertised to the cluster as a schedulable resource, so a workload requests cards the way it requests CPU, and per-team caps are namespace quota on that resource. Newer Kubernetes can allocate devices by attribute rather than by count, which earns its keep where the cards in a cluster are not identical. Isolation follows the hardware: a workload holding a whole card has it to itself, inside the namespace and network boundaries you already run, and finer partitioning needs cards built for it. Which part of the network matters depends on what you run: for training and fine-tuning, the path between the storage and the cards, which is where a platform quietly stops keeping them busy; for serving, that same path decides how fast a model loads and a new replica comes up rather than steady-state throughput; once either spans several nodes, the path between the cards themselves.
Owned or rented
GPUs are hard to procure, so the platform is designed to run on hardware you own or capacity you rent, without changing how your teams use it. We can advise on the shape it needs to take: how much memory per card, how many cards per node, and what has to sit behind them. Specifying and buying it stays with you. We do not resell hardware and we hold no margin in what you choose.
The constraint most people meet first is not the cards. GPU nodes draw several times what general compute does, and an existing rack, room or colo contract is often written for a density they exceed. That is worth establishing before anyone signs a purchase order, and it is one of the reasons renting can be the right first move even when owning is the plan.
Where the platform ends
This is the platform layer, not the model layer. The models and their tuning are yours, and so is the AI layer you build on them: the agents, the gateways, the MCP servers, and everything your data scientists produce. The serving runtime is the one piece that sits on the line, and we scope it with you per engagement rather than assuming it falls on either side.
The alternatives
Renting capacity and running inference in your own cloud account. Several vendors will run their inference stack inside your account, so the data plane never leaves it. If your constraint is that no third party may hold your data, that may be enough, and it starts faster and cheaper than anything on this page. What it does not change is that the control plane is theirs: it sees what you run, it has to reach in to operate, and demonstrating control to an auditor still routes through their word. Where your constraint is contractual rather than architectural, that is the better route and we will say so.
A turnkey AI appliance. The large infrastructure vendors sell an integrated stack with a support organization behind it and a name your procurement already knows. That is a real advantage and for some buyers it settles the question. The trade is the familiar one: the platform is theirs, priced per node on their terms, and leaving later is a migration rather than a handover.
Your own Kubernetes team. Often the right answer, and the one that looks cheapest. The cluster part they already know; what bites is underneath it: driver and toolkit versions that have to match across nodes, a container runtime configured for the cards, storage fast enough to keep the GPUs busy, and upgrades that behave differently once a driver is in the path. None of that is beyond a good team, and none of it is fast to learn on a deadline. Where they should own it, we would rather build it alongside them and leave than become the reason they never did.
Why this practice
Most AI platforms do not fail on the GPUs. They fail on storage that cannot feed the cards, a network that cannot carry it, isolation that does not hold, and a cluster nobody can upgrade without losing a weekend. Those four are where this practice has spent years: distributed storage in production, the networking underneath a cluster, namespace and RBAC boundaries that hold between teams, and upgrades run to a cadence rather than deferred. That was for a regional cloud provider and for clients in regulated sectors on their own premises, which means other companies’ production rather than a single in-house estate. GPUs and their lifecycle are what we add on top of it. The work is led by a principal engineer, with senior specialists brought in as the work requires.
Running it afterwards
Building the platform and operating it are separate engagements. When you want it run for you, or want cover while your own team runs it, that is the Kubernetes platform engagement, and it covers this platform the same way it covers any other. When private AI is part of a larger sovereign buildout, SECO, our sovereign private cloud, runs VMs, containers and AI on the same control plane.
Do we need to own GPUs to start?
No. The platform is built the same way on hardware you buy or on capacity you rent, and which one makes sense depends mostly on how steady the workloads are. Renting first and buying once you know your real utilization is a reasonable sequence.
Can several teams share one GPU?
Sometimes, and it depends on the cards. Giving a whole card to a workload is straightforward. Splitting one across several is a different problem with real constraints, and we size it against the hardware you have or plan to buy rather than assuming it works.
Do you build our models, AI agents or MCP servers?
No. We build and run the platform underneath them. The serving runtime is scoped per engagement, and everything above it stays yours. If what you need is a partner for the model layer, we will tell you that is what you need.
How large a platform do you build?
An enterprise AI factory rather than a supercomputer. Up to 32 GPU hosts and 256 cards, on Ethernet, with RoCE in the design where the workloads need it, is the scale this practice builds to. Beyond that, at thousands of hosts and tens of thousands of GPUs, you are in a different discipline with different people, and we have not built one. That boundary is not about the fabric, since both Ethernet and InfiniBand are run at either end of the range; it is about the operational practice a fabric that size demands. If that is where you are heading, tell us early: it is work we want and intend to be doing, and we would rather be straight about what we would have to prove first than let you find the gap mid-project.
How long does a private AI platform take?
The build is rarely the critical path; hardware usually is. Cards ordered today can be months out, and the rack and power work behind them takes its own time, which is one more reason renting first can move the date left. How long the whole thing takes is a property of what you are running and what you already have, and the assessment is where that stops being a guess rather than where it starts.
Where does our data actually sit?
On storage you own, inside your network, under your access controls. Datasets and model artifacts live in the object store; the working set a running job touches sits on the faster tier underneath it. Prompts, outputs and logs land in your own systems. Nothing leaves the cluster unless you send it somewhere, and we work inside those controls rather than around them.
What does a private AI assessment produce?
A written read of what you want to run and what it takes to run it: the shape of the hardware, meaning memory per card, cards per node and the storage and network behind them; whether owning or renting fits the way you will actually use it; what your existing racks and power can take; and a platform design specific enough to build from. The output is yours, and it is written so you could hand it to someone else. If the answer is that you should not build this, it says so.
How is this different from a Kubernetes platform engagement?
This is the GPU-specific buildout: the shape of the hardware, the GPU lifecycle, and the storage and scheduling decisions that follow from them. Operating the platform afterwards is the Kubernetes platform engagement.
Keeping AI in-house?
Tell us what you want to run and what the constraints are. You will get a written reply within two business days: whether this is a fit, and what we would propose as a first step. Where you have given us enough to price it, that comes with it. No call required.