What Neocloud actually means
Reclaiming the Term
“Neo” usually marks an evolutionary step: a change in kind, not the specialisation of something that already exists. By that standard, a GPU-heavy cloud is not yet a neocloud. It may be novel in places, technically demanding, and commercially important, but it is still a specialization within the existing cloud model rather than its successor. If accelerator rental gets the prefix, what do we call the step beyond machine-hours, clusters, and capacity held in advance? This is our attempt to reclaim the word for its intended purpose.
An essay from LILY Labs
Ask what a neocloud is and you get a description of an inventory. Racks of accelerators, sold by the hour or by the month, to companies training or serving models. The demand is real, the businesses are real, and the buildings going up to serve them are among the most technically demanding structures in commercial construction at the moment.
None of that earns them the title “Neo”.
The prefix is a claim. "Neo" asserts that something has changed in kind rather than in degree, and a claim like that is worth testing rather than repeating. Tested, it does not hold. What the market calls a neocloud is a specialized data centre with a particular fill: accelerators instead of general-purpose servers, AI workloads instead of mixed enterprise ones. The specialized data centre is not a new concept. It is one of the oldest concepts in the industry wearing a new hat.
The specialization is old
Purpose-built computing facilities have existed for as long as there have been workloads worth building around.
Supercomputing and national laboratory sites were designed around a narrow class of numerical work, with power delivery, cooling, and interconnect chosen for it and poorly suited to much else. Carrier hotels and internet exchange buildings were specialized in a different direction entirely: not compute, but cross-connect density and network adjacency, which is how a small number of street addresses became disproportionately important to the way traffic moves. Financial co-location halls were specialized around distance to a matching engine, to the point that cable length was sold as a product feature. Crypto-mining facilities were specialised around cheap power and heat rejection, and were willing to drop redundancy and latency guarantees that other tenants would treat as mandatory.
Each of these is a real specialization with real engineering behind it. Each looks different from a general-purpose colocation hall in its electrical design, its mechanical design, or its network topology. Not one of them was described as a new kind of cloud, because everyone involved understood what they were looking at: a data centre built around a workload.
The AI facility is the first entry in that lineage to arrive with its own category name. The reason is not architectural. It is that this workload arrived with more capital behind it than the previous ones, and a market with that much capital moving through it generates vocabulary.
What actually differs, and it is not small
The engineering deserves to be stated accurately, because the argument here is not that AI facilities are ordinary.
Three things genuinely change at the level of the building.
Power density is the first. NVIDIA's published specification for a GB200 NVL72 rack puts its draw above one hundred kilowatts, against a general-purpose hall designed around racks pulling a small fraction of that. This is not an increment. It changes the substation relationship, the busway, the distribution topology, and the assumption about how much of the floor can be populated at once.
Heat rejection is the second. Above a certain density, moving air stops being sufficient at any sensible cost, and the facility goes to liquid: direct-to-chip cold plates, coolant distribution units, facility water loops, rear-door heat exchangers. Retrofitting an air-cooled hall to do this is often not economic, which is why so much of the current build is new construction rather than conversion.
The fabric is the third, and the one most specific to the workload. A large training run is a synchronised collective operation, so the slowest link sets the pace for the whole job. That pushes the design toward non-blocking topologies, rail-optimised layouts, and a cable plant with very little tolerance for error. A network that would be perfectly acceptable for mixed enterprise traffic will ruin the economics of a training cluster.
Anyone who has commissioned one of these buildings has done something difficult, under time pressure, with hardware that changes generation faster than buildings can be built. The point is not that this is easy. The point is what kind of difficulty it is. It is mechanical, electrical, and topological. It is the difficulty of constructing a facility, which is a different problem from inventing an abstraction.
The part that did not move
Now ask a different question. Not what is inside the building, but what the customer buys.
They buy an instance. A node. A cluster on a term commitment. They choose a configuration, provision it, hold it, and pay for the period it is held rather than for the work it performs. If a job finishes early, the reservation continues. If the fleet sits idle between batches, the meter runs. Utilization is the tenant's problem, queueing is the tenant's problem, capacity planning is the tenant's problem, exactly as they were when the rented machine had no accelerator in it at all.
The software stack confirms it. SemiAnalysis, which has covered these providers in more technical detail than most, has made the point that a great deal of what they ship is Slurm running on Kubernetes: a batch scheduler out of the HPC tradition layered onto a container orchestrator out of the web tradition. Both are good software. Neither is new, and putting them together is an integration achievement rather than an architectural one. The scheduler is the old scheduler. The orchestrator is the old orchestrator. The thing being scheduled is a container wrapping a process, and the thing being sold is a machine-hour.
A tenant renting capacity in a liquid-cooled hall in 2026 is buying the same unit they bought in 2006, in a different size at a different price. The building around that unit has been transformed. The unit has not.
What an evolutionary step looks like
If we make the claim that this is the wrong use of the word, it is fair to ask what the right one would be. There is a usable test, and the industry has already run it once, in storage.
Before object storage, buying storage meant provisioning a volume. You chose a size, attached it to a machine, paid for the capacity whether or not anything was in it, and resized it by hand when it filled. Object storage changed the unit of account. There is nothing to size, nothing to attach, and no empty capacity to pay for. You put a byte in and you are billed for the byte you put in. That is not a better disk. It is a different thing to buy, which is why it displaced what came before instead of sitting alongside it.
Compute has not had that step. The hourly virtual machine was one, and a significant one: it moved the unit from a machine you purchased and depreciated to a machine you rented and released. That was twenty years ago. What has arrived since has refined the same unit rather than replacing it. Containers made a machine easier to fill and a deployment easier to reproduce. Orchestrators made a fleet of machines easier to manage. Function platforms came closest, billing per invocation, but underneath each invocation sat a container on a virtual machine, which is precisely why cold starts, concurrency limits, and maximum execution times all exist. The abstraction was priced per call and implemented per machine, and the implementation kept showing through.
So the test is short. Does the customer still provision a machine, hold it, and pay for holding it? If the answer is yes, then the specialization may be significant and the engineering may be exceptional, yet the category has not moved.
By that test, an AI facility is a classic data centre with a particularly demanding tenant.
Semantics matter
This can read as pedantry about vocabulary. There is a practical reason it is not.
Categories are how buyers evaluate. When something genuinely new appears, the people assessing it need a category to put it. The comparison set they reach for decides which questions they ask. If "neocloud" has been spent on "a data centre with different hardware in it", then the next real step in the cloud arrives with no name and gets evaluated against accelerator rental: what is the hourly rate, which configurations are available, how long is the commitment. Those are reasonable questions to put to a landlord. They are the wrong questions to ask about something that does not sell hours or machines at all.
Count the layers in a current deployment. A physical machine. A hypervisor dividing it. A guest operating system inside each division. A container runtime inside the guest. An image format for the container. An orchestrator to place the containers. A network layer to govern how the placed containers reach each other. A declarative configuration language to instruct the orchestrator. A pipeline to build the images and apply the configuration.
Every one of those layers is a reasonable answer to a real problem, and the problem is almost always the layer beneath it. The hypervisor exists because a physical machine is too large a unit to sell. The guest OS exists because the application expects an operating system. The container exists because the guest OS is too heavy and too slow to ship for every change. The orchestrator exists because containers have to be placed somewhere. The network layer exists because orchestrated containers move and their addresses will not hold still. The configuration language exists because the orchestrator has to be told what to do, and the pipeline exists because the configuration has to be produced and applied by something.
The result is a Frankenstein assembly. Each part is defensible on its own. The whole is a thing nobody would have designed deliberately, and it is charged in full to the person deploying an application: in machine-hours held rather than work performed, in capacity sitting idle because it had to be provisioned in advance, in the engineering time to operate the layers, and in the expertise required to reason through all of them when something breaks.
An evolutionary step is not another layer on top. It is composition. The stack gets composed down into a single layer, with the isolation, placement, and scheduling that the intermediate layers used to provide folded into the one layer that remains.
That is the move that changes the unit of account, and it changes it for a structural reason. The machine-hour survives because there is a machine in the middle of the arrangement and somebody has to hold it. Take away the layers whose purpose was to divide, wrap, and place that machine, and there is nothing left to hold. What remains is work submitted and work performed. Storage reached that position already, which is why nobody provisions an empty bucket and waits.
How that is done is a separate argument and a longer piece. The point here is narrower. Collapsing the stack into a single layer rather than filling up a data center with specialized silicon and more advanced cooling.
None of this takes anything away from the people building AI facilities. Getting a hundred kilowatts into a rack, taking the heat back out, and wiring a hall so that no single link becomes the straggler is hard work, and it is being done quickly and mostly well.
It is a data centre. A specialized, very expensive data centre, in a lineage of specialized data centers that runs back decades. Given the rapid developments in the AI space, that specialization is worth pursuing, worth financing, and worth admiring. It is not a new cloud, and the word should be kept for whatever changes what you rent.
You build. We carry.
Start for free. Read the docs. Talk to us about migrating a workload.