DeepInfra has announced a cluster with more than 1,000 NVIDIA B300 GPUs and more than 2 MW of power capacity. Those two numbers sound precise, yet they leave a buyer with the questions that decide whether a cluster can actually enter service: what the power figure includes, how the nodes are networked, where checkpoint data lands and how much redundancy sits behind the headline capacity.
The useful reading is not that 2 MW is a standard budget for 1,000 B300 GPUs. It isn't. The announcement describes one deployment and does not publish its node design, fabric topology, storage architecture, cooling plant or measured workload power. A procurement team can still use the disclosure as a reality check, provided it keeps verified facts separate from planning estimates.
Quick answer
A 1,000-GPU B300 cluster is a facility project before it is a server order. If the design uses eight-GPU systems, it needs at least 125 compute nodes. NVIDIA rates a DGX B300 at 14.5 kW, so 125 DGX-class systems would represent about 1.81 MW of maximum compute-node load before external switches, shared storage and other rack equipment. That is an illustrative reference, not a claim about DeepInfra's equipment.
Any proposal described only as "1,000 GPUs and 2 MW" is therefore incomplete. Ask whether the power number means available IT power, contracted utility capacity, measured draw or whole-facility load. The answer changes the design.
What DeepInfra has actually disclosed
DeepInfra's 1 September 2026 announcement says the Hillsboro cluster has more than 1,000 NVIDIA B300 GPUs and more than 2 MW of power capacity. It is intended to support the humans& research lab through DeepInfra's dedicated DeepCluster service.
The release does not identify the server manufacturer, exact GPU count, CPU platform, storage system, network fabric, rack count or cooling method. It also does not say whether the 2 MW figure includes facility cooling or only the computing estate. Treat all of those details as unknown.
| Item | Publicly stated | Still required for a design review | | --- | --- | --- | | Accelerator | More than 1,000 NVIDIA B300 GPUs | Exact count, GPU form factor and node model | | Power | More than 2 MW of capacity | IT or facility scope, sustained load, peak load and redundancy | | Location | Hillsboro, Oregon | Hall layout, rack density and cooling system | | Service | Dedicated DeepCluster capacity | Fabric, storage, scheduler, tenancy and service boundaries | | Workload | Frontier-model development | Training mix, checkpoint profile, utilisation target and recovery objective |
That gap is normal for a launch announcement. It is not enough for procurement.
Converting 1,000 GPUs into nodes and racks
NVIDIA's HGX B300 design places eight B300 GPUs in one baseboard, with 288 GB of HBM3e per GPU and 2.3 TB per node. Dividing 1,000 GPUs by eight gives 125 nodes. Because DeepInfra says "more than" 1,000, its real count must be at least that large and may not divide neatly into eight-GPU blocks.
NVIDIA's DGX B300 is a useful physical proxy for one air-cooled eight-GPU node. It occupies 10U, weighs 168 kg in the AC power-supply configuration and has a published 14.5 kW power consumption figure. A simple 125-node reference produces:
- 1,000 GPUs and 288 TB of aggregate HBM capacity.
- 1,250U of compute equipment, equal to almost 30 fully packed 42U racks before practical power, airflow and service limits.
- 1.8125 MW of compute-node power at the DGX B300 rating.
- Roughly 6.18 million BTU per hour of compute heat at NVIDIA's published 49,476 BTU/h per system.
No competent rack plan would simply fill 30 racks to 42U. Four DGX B300 systems already consume 40U and can reach 58 kW, which pushes the deployment towards at least 32 compute racks and demands a cooling design that can carry that density. Network, storage and management racks sit on top of that count.
These calculations are planning references only. An OEM HGX B300 system may use a different chassis, power profile and cooling method. Final figures must come from the selected server bill of materials and the data centre's approved operating envelope.
Why the 2 MW figure needs a definition
Power language often becomes vague precisely where a project becomes expensive. Four different numbers may all be called "cluster power":
1. Nameplate capacity: the total rating on feeds or power supplies. It says little about expected draw. 2. Available IT power: the allocation delivered to compute, network and storage racks. 3. Measured or modelled IT load: the workload-dependent demand after power caps and utilisation assumptions. 4. Whole-facility load: IT equipment plus chillers, pumps, fans and electrical losses.
If a reference design already places the compute nodes near 1.81 MW, a 2 MW IT allocation leaves less than 190 kW before allowing for a larger-than-1,000 GPU count. Switches, storage, CPU-heavy service nodes and management systems must fit inside the remaining budget. If 2 MW means total facility demand, the arithmetic is tighter still.
The buyer should request a load schedule that names every rack, expected sustained demand, capped maximum, feed arrangement and failure case. PUE belongs in the facility model, not as a hand-waving multiplier attached to a GPU quotation.
The network is part of the compute system
An HGX B300 node can expose eight ConnectX-8 interfaces for east-west GPU traffic, each rated up to 800 Gb/s. Across 125 nodes, that creates 1,000 high-speed endpoints. The port count alone does not tell you whether the fabric is non-blocking, how many switch stages are required or what happens during a link or switch failure.
Training traffic, distributed inference and storage I/O also behave differently. A fabric designed around average throughput may stall collective operations when many ranks communicate at once. Oversubscription that is tolerable for inference services can be a bad bargain for synchronous training.
Start with the workload communication pattern, then choose InfiniBand or Ethernet, rail layout, oversubscription, routing and failure domains. Our network guide for 1,000-GPU clusters explains the decision in more detail, while the GPU Cluster Configurator can turn a node count into a fabric and rack bill of materials.
Storage can waste an expensive cluster quietly
The DeepInfra announcement says nothing about storage. That omission matters because a 1,000-GPU job can lose large amounts of paid compute time while waiting for data ingestion, checkpoint writes or recovery reads.
A useful storage brief should state dataset size, read pattern, checkpoint size, checkpoint interval, number of simultaneous jobs and required restart time. Peak bandwidth is only one part of it. Metadata load, small-file behaviour, failure recovery and the path between storage clients and the GPU fabric can decide whether the advertised number survives contact with production.
Local NVMe can stage hot data and absorb temporary writes, but it does not replace shared durable storage. A design also needs space for container images, model artefacts, logs, scheduler state and the copies held during data movement.
Questions to put into the request for proposal
Before comparing prices, require written answers to these points:
- Does the quoted power cover compute equipment, all IT equipment or the entire facility?
- What is the sustained workload target, the capped maximum and the design response to a failed feed?
- Which exact B300 systems are proposed, and what do their approved thermal specifications require?
- Is the scale-out fabric blocking or non-blocking for the intended job, and which failures reduce available bandwidth?
- What measured checkpoint and dataset tests will form part of acceptance?
- How will failed GPUs, nodes, optics, links and drives be removed from service without derailing long jobs?
- Which utilisation, job-completion and recovery metrics will the operator report after handover?
A server quotation cannot answer those questions on its own.
When dedicated capacity makes sense
Dedicated B300 capacity suits teams with a stable queue, large distributed jobs and enough engineering staff to keep the estate busy. It can also make sense when workload isolation, data location or scheduling control rules out shared public capacity.
Do not jump to 1,000 GPUs because a model can technically scale that far. A team that has not measured scaling efficiency at 64 or 128 GPUs should spend money on that evidence first. Poor data loading, collective communication or job recovery gets more expensive as the allocation grows.
For buyers who want ownership without operating a data hall, Buy & Host separates equipment ownership from facility operations. Teams building their own estate can compare current HGX server platforms and use our existing 1,000-GPU cluster guide to structure the wider design review.
GPUMachines view
DeepInfra's disclosure is useful because it puts an order of magnitude on a modern B300 deployment. It should not become a sizing rule. Using NVIDIA's DGX reference, compute nodes alone can approach the announced capacity figure; the unknown network, storage, cooling and redundancy choices are therefore the story, not footnotes.
The sound procurement sequence is workload test, repeatable node design, fabric proof, storage proof, facility validation and only then volume purchase. Buying the accelerators first is how a 1,000-GPU project becomes a very expensive commissioning exercise.