What is an AI factory, and how do you build one?
An AI factory is a repeatable, facility-scale system that turns power, GPUs, networks and storage into models and tokens, and keeps doing so reliably. This guide explains what is inside one, from a single GPU to a full site, and how to build it in three stages: Day 0 design, Day 1 bring-up and Day 2 operations. It also covers the choice between your hardware and ours, and what changes when the site is air-gapped.
What an AI factory is
"AI factory" is used widely and loosely. In this article it means a specific thing: a purpose-built site, or part of one, that is designed, built and run as one system to train and serve AI models. It has compute, networks, storage, a serving layer, a gateway where people and applications connect, and an operations layer that keeps all of it healthy.
The word "factory" is useful because it points at what matters: repeatability and throughput. A factory is not a pile of servers. It is a unit you can describe, build the same way twice, measure, operate and grow.
It differs from a general-purpose cluster in three ways.
- It is designed around the AI workload. The network, the cooling and the power plan follow from how models are trained and served, not the other way round.
- It is built from repeatable units. You add capacity by adding another unit, not by redesigning the site.
- It is operated as a service. Someone is responsible for it staying up, fast and explainable, from the power feed to the application.
The build-up, layer by layer
Our AI Factory page shows this as an animation. Here is the same sequence in words.
GPU
Everything starts with one accelerator. It is the unit that does the arithmetic.
Node
Several GPUs sit inside one server, called a node. Inside the node they talk to each other over a scale-up fabric: a very fast link that lets the GPUs behave as if they were one larger device. This matters because a large model is often split across the GPUs of a node.
Rack
Nodes stack into racks. A rack brings power distribution, cooling and a management switch with it. The rack is where the physical limits first appear: how much power can be delivered and how much heat can be removed.
Scalable unit
Racks are grouped into a scalable unit. This is the repeatable building block of the factory. If you know what one unit delivers, and what it needs from the site, you can plan the next ten.
Compute fabric
Units are joined by a compute fabric, the network that carries traffic between GPUs on different nodes. A common pattern is rail-optimised: each GPU's network port lands on its own leaf switch, so traffic from the same position in every node stays on its own rail.
Spine
A spine layer joins every leaf switch, so any GPU can reach any other in two hops. That bound keeps behaviour predictable as the factory grows.
Planes
To grow beyond what one fabric can carry, the fabric is repeated in parallel planes. Each plane multiplies bandwidth and scale.
The rest of the factory
Compute is not the whole site. Storage runs on its own network. Management runs on separate in-band and out-of-band networks, so you can reach and recover hardware even when the main network is down. At the top, a gateway gives people and applications one place to connect, with keys, sessions and queueing, on your domain.
Day 0, Day 1, Day 2
We split the work into three stages, and one team does all three.
Day 0: design
Day 0 produces the plan. It covers:
- Workload sizing. What the factory must train or serve, for how many people or systems, at what concurrency.
- Hardware. Yours or ours, and what the site needs to host it.
- Power, cooling and network. The facility side, sized to the unit you will build.
- Model selection. Which open-weight models the factory will serve.
- Security and compliance requirements. The controls the factory has to meet, written down before anything is bought.
Mistakes are cheapest to fix on Day 0. A network that is the wrong shape for the workload, or a cooling plan that cannot carry the load, is expensive to correct after the racks arrive.
Day 1: build and go live
Day 1 turns the plan into a working factory:
- Installation of the hardware.
- The serving stack.
- The gateway and keys on your domain.
- Acceptance testing against the criteria agreed on Day 0, before anyone depends on it.
Acceptance testing is where a factory becomes a service. It should be repeatable and written down, so it can be run again after any change.
Day 2: operations
Day 2 is the longest stage, and the one that decides whether the factory earns its keep. It is where hardware fails, firmware drifts, software is updated and workloads change.
We operate the factory with the MIRASTACK operations stack. It includes:
- MIRASTACK Observe. Observability from the power feed to the business KPI, correlating signals from building systems, power, servers and firmware, network fabric, storage, hypervisors and Kubernetes. When something breaks, it produces an explainable root cause analysis, a chain of "why" questions with the evidence cited.
- CI/CD integrations. Release risk scoring, blast-radius prediction, change impact analysis and compliance gates in the pipeline.
- MIRASCAN (preview). Software and cryptography bills of materials, quantum-readiness reports and passive TLS analysis.
- Governance. The open EGAProtocol puts an identity on every message, builds human approval into the protocol and keeps an immutable audit trail.
Read more on the Day 2 operations page.
Hardware: yours or ours
An AI factory does not need a particular purchasing model. There are two paths.
- Your hardware. You already own, or are buying, the GPUs. We design around your site and equipment, bring it live and run it.
- Our hardware. We supply the GPUs. The factory still sits in your data centre and runs on your domain.
In both cases the location and the domain are yours. The arrangement for hardware, models, term and the parts we operate is set per agreement.
Air-gapped factories
Some sites cannot be connected to the internet at all: defence, parts of the public sector, and some financial and critical-infrastructure environments. An air-gapped AI factory has to work with no outside connection from the first day.
That changes several things:
- The serving stack and the models are installed from inside the site.
- Observability cannot send telemetry to a cloud service. It has to run entirely on the premises.
- Governance matters more, because there is no outside party watching.
This is why our operations stack is built air-gapped first: every product has to work with no internet connection before it is allowed to use one. For the wider case for on-premises AI, see On-prem sovereign AI and our sovereign AI page.
What an AI factory is not
- Not a hosted API. A hosted endpoint is the right answer when the data may leave your site. If it may not, you need a factory on the site. Compare the dedicated endpoint.
- Not a one-off project. The build is the short part. Operating it is the long part.
- Not tied to one model. The factory serves open-weight models selected with you, and the choice can change.
Questions to ask before you start
- What workload will run first, and how many people or systems will depend on it?
- Which regulations or internal policies decide where it may run?
- Do you bring the hardware, or do you want it supplied?
- What does acceptance mean on your side, and who signs it?
- Who will be on call on Day 2, and what can they approve?
- What happens when the site has no internet connection?
If you can answer even half of these, a Day 0 conversation is the right next step.
Talk to us
We design, build and run AI factories. Talk to us, or write to hello@mirastacklabs.ai with the workload, the number of people or systems, and where it must run. To see the offer in short form, go to the AI Factory page.