AI Rack Density Is Rewriting the ICT Specification: What to Get Right at Design Stage
The Specification Is Moving Faster Than the Build Programme
Data centre infrastructure has always been designed with headroom. The assumption underneath that practice was that the rate of change was predictable: density would rise gradually, cable counts would rise gradually, and a specification set at design stage would remain adequate for most of the facility life.
AI workloads have broken that assumption. The gap between the density a facility was designed for and the density it is being asked to support has widened faster in the last two years than in the preceding decade. For teams commissioning ICT infrastructure inside these buildings, that creates a specific and avoidable problem: infrastructure specified correctly against today’s requirement can be inadequate well inside its warranty period.
This is not an argument for over-specifying everything. It is an argument for knowing precisely which decisions are expensive to reverse and making those ones deliberately.
Where the Density Numbers Actually Sit
It is worth being specific, because the figures quoted in general coverage span an enormous range and they are not interchangeable.
Cabling Installation and Maintenance describes rack densities climbing from a long-standing norm of 10 to 15 kW to 50 to 100 kW and beyond, and puts Nvidia GB200 NVL72 systems at roughly 120 kW per rack.
The more useful picture comes from Uptime Institute, which sets out how much the same class of workload can vary depending on how it is configured. The Blackwell NVL72 flagship is rated at 132 kW in a tall but otherwise fairly common 19 inch rack. Standard 64 GPU racks can operate within 80 to 90 kW. Fitting four 8 GPU server frames per rack reduces fully loaded sustained power to under 50 kW. Halving the number of server frames again brings it to around 26 kW sustained maximum. Opting for lower powered GPUs or alternative accelerators can bring rack power below 20 kW.
That range, from below 20 kW to 132 kW, is the actual story. Uptime’s framing is that density choices for AI training are becoming more complex rather than converging on a single answer, and the spread above is why. The density a hall ends up at is the result of configuration decisions taken elsewhere in the programme, frequently after the infrastructure specification has been written.
One threshold matters more than the rest for physical planning. Air cooling is broadly viable to around 20 to 30 kW per rack. Above that the cooling strategy changes, and a change in cooling strategy is a change in the physical plan, not just the mechanical scope.
The practical consequence for ICT delivery is that "high density" is no longer a useful specification term. The design needs a number, a tolerance, and a stated position on what happens when that number is exceeded in a subset of the halls.
The Fibre Count Problem
The change that affects structured cabling teams most directly is not power. It is fibre volume.
AI training shifts network traffic away from predictable north to south flows and toward dense, low latency east to west communication between thousands of GPUs. That change in traffic pattern changes the physical topology. Cabling Installation and Maintenance reports that AI data centres can require on the order of ten times more fibre than conventional facilities, with a single GB200 NVL72 rack demanding roughly 864 fibres across its GPU, CPU and storage fabrics, driving leaf-spine fabrics and links at 400G and 800G.
Ten times the fibre is not simply ten times the material cost. It changes containment sizing, pathway capacity, bend radius management, the practicality of the routing plan, the labelling scheme, and the amount of time required for testing and documentation. A containment design that is adequate for a conventional hall becomes physically unworkable when the fibre count rises by an order of magnitude, and containment is one of the more expensive things to change once the building is up.
Cooling Changes the Physical Plan, Not Just the Mechanical Scope
The cooling threshold noted above has a direct consequence for the ICT scope, and it is one that frequently gets treated as somebody else’s problem.
Once a hall moves past the point where air cooling is viable and into liquid, the physical volume above and around the racks changes. Pipework, manifolds and the associated containment all need routing. So does the power distribution. So does the data containment carrying an order of magnitude more fibre than a conventional hall.
The coordination problem in a high density hall is therefore materially harder than in a conventional one, not because any individual element is more difficult, but because there is more of everything competing for the same space and correspondingly less slack in the sequencing between trades.
Projects that treat containment coordination as something to resolve on site, in the way that is usually workable on a commercial fit-out, are the ones that lose weeks. In this environment the coordination has to happen on drawings, before anybody is on site, and it has to include the ICT scope rather than adding it afterwards.
What to Get Right at Design Stage
Five decisions are considerably cheaper to make correctly at the start than to revisit later.
Pathway and containment capacity, sized against a credible upper bound on fibre count rather than the initial deployment. This is the single most expensive item to retrofit and the one most frequently under-specified.
The testing regime, agreed in writing before equipment is ordered. What is tested, to what tolerance, in what format, and who receives the results. On high density builds, Tier 2 OTDR characterisation and bidirectional testing should be assumed rather than negotiated.
The labelling and documentation convention, defined before the first cable is pulled and applied identically by every engineer on every shift. At these fibre counts, a labelling scheme that is applied retrospectively is not recoverable in any practical sense.
Trade coordination sequencing for the overhead volume, agreed between the electrical, mechanical and ICT scopes at design stage rather than resolved by whoever arrives on site first.
The standards position. TIA-942 remains the primary data centre reference and it has been revised. The specific revision being worked to should be stated explicitly in the specification rather than assumed, because assuming it is the fastest route to two parties working to different documents.
The Constraint That Does Not Appear on the Drawings
There is a final item that belongs in the design conversation even though it is not a design decision.
The volume of ICT infrastructure work these builds require is rising considerably faster than the number of engineers who have delivered to data centre standards before. That gap is already affecting live programmes across the UK and Europe. A specification can be perfect and still fail on schedule if the delivery resource assumed in the programme is not actually available in the market at the point it is needed.
Programmes that pre-qualify specialist ICT delivery capacity at design stage, rather than tendering for it when the building is ready, are the ones that hold their dates. That is a planning decision, and like the others in this article, it is much cheaper to make early.
iCobus provides specialist ICT delivery capacity for data centre and large commercial programmes across the UK and Europe, from design support and installation through to testing, documentation and handover. If you have a programme in planning, we are happy to talk through what the delivery side needs to look like.
