J-BoxPlain answer. Neoclouds need powered capacity on a timeline measured in months, rack densities that support current and next generation GPUs with liquid cooling, and a commercial structure that lets them own or refresh compute without owning the real estate. The partner's job is to make power, cooling and the deal arrive together.
The neocloud clock
A neocloud sells GPU hours. Its customers are waiting, its hardware is on allocation, and every month a cluster sits in a warehouse instead of a hall is a month of revenue it cannot recover. The hyperscale campus that will be ready in 2028 does not help. The colocation hall that was designed for 10 kilowatts a rack does not help either.
What helps is powered capacity, at the right density, in a block the neocloud can fill now and expand next year. That is a different product than most of the industry is building, and it is the one JBox is built around.
Density and cooling realities
Current GPU systems draw power per rack that air cooling cannot remove. Next generation systems draw more. A partner that cannot speak fluently about direct to chip liquid cooling, coolant distribution units, heat rejection and the electrical distribution to feed it is a partner that will deliver a hall the neocloud cannot use.
What to look for:
- Liquid cooling designed into the block, not retrofitted.
- Electrical distribution sized for the density the tenant specifies, with headroom for the next generation.
- Heat rejection that works in the site's climate, with the water story understood.
- A commissioning plan that tests the platform at the tenant's load, not a fraction of it.
Where hyperscale colocation falls short
Hyperscale colocation is built for hyperscale tenants: very large, long term, standardized, and willing to wait for a campus. A neocloud is none of those things. It needs smaller blocks, faster, at higher density, with a deal structure built around hardware it owns and refreshes every few years.
Fitting a neocloud into a hyperscale product means paying for capacity it does not need, on a timeline it cannot accept, under terms written for someone else.
Shell, turnkey or GPUaaS from the neocloud's seat
| Model | Who owns the real estate and plant | Who owns the compute | What the neocloud gets |
|---|---|---|---|
| Powered shell | The owner or a capital partner | The neocloud | Control of the hardware and the refresh cycle; a lease on the powered hall |
| Turnkey | The owner or a capital partner | The owner, leased to the neocloud | Lower capital outlay; less control of refresh |
| GPUaaS | The owner or a capital partner | The owner or partner | Capacity as a service; the neocloud resells or consumes |
Most neoclouds prefer the shell: they want to own the GPUs because the GPUs are the business. Some want turnkey to preserve capital. The partner's job is to structure around the tenant's answer, not to force one.
What a requirement match looks like
A real conversation starts with the neocloud's requirement: megawatts now and next year, density per rack, cooling type, timeline, preferred structure and geography. The partner matches that against sites it actually controls, not sites it has heard about, and comes back with options that include the power position, the probable energization date and what is still preliminary.
If the partner cannot show you the control basis for a site, you are looking at a pipeline, not capacity.
Questions to bring to a first call
- Which sites do you control today, and what documents that control?
- What is the energization date on each, and what is it conditioned on?
- What density and cooling is the block designed for?
- Shell, turnkey or GPUaaS: which can you structure, and who are the capital partners?
- How fast have you delivered commissioned capacity before?
Questions & answers.
Where a site under control has a near term energization date, modular blocks can be commissioned in months. The fastest JBox has delivered is 62 days from construction start. Every site is different.