University Data Center Sizing for Research Computing: A Two-Workload Framework
Admin systems and research clusters age on different clocks and draw power on different curves. A refresh sized around one starves the other.
By Uniqcli Team · · 7 min read
Sector Guide
University data center sizing for research computing is a two-spec problem, not one
A campus data center refresh usually starts with the easy half: replace aging servers running the SIS, ERP, email, and identity with modern rack units at roughly the same density, add UPS headroom, call it done. That plan works fine for administrative IT. It fails the moment a research computing group needs GPU nodes for a genomics pipeline, a materials-science simulation, or a campus AI initiative, because that workload has a completely different power, cooling, and network profile than the systems it shares a room with. Sizing a facility around administrative load and treating research computing as an add-on is one of the most common reasons campus data centers hit power or cooling ceilings not long after a refresh. The fix isn't a bigger version of the same design — it's sizing the two workloads separately from day one, then deciding how much they actually need to share.
Why admin systems and research clusters can't share one spec
Administrative IT is predictable. A rack of virtualization hosts running the student information system, financial aid, HR, and email draws a fairly flat 4-6 kW per rack, spikes modestly during registration weeks, and idles the rest of the year. Standard hot-aisle/cold-aisle air cooling handles it without drama, and a UPS sized for graceful shutdown covers the risk profile: if it goes down for twenty minutes during a planned failover, nobody's semester is at risk.
Research computing doesn't behave that way. A single rack of GPU nodes for machine learning or molecular dynamics can pull 30-50 kW or more, and unlike admin load, it runs at or near that ceiling for days or weeks during an active simulation or training run. That density moves the cooling conversation from CRAC units to rear-door heat exchangers or direct liquid cooling, and the power conversation from "enough circuits" to "enough amperage per rack, with room to add more."
The two workloads also fail differently. A researcher's node going down mid-job means re-running a computation that may have run for days — expensive in time even if no data is lost. An admin system going down mid-transaction means a support ticket. Those are different availability requirements, and forcing them into one uptime target either overspends on redundancy for research nodes or underspends on the systems that actually need it.
How much power and cooling does a research computing cluster actually need?
Sizing starts with what the researchers plan to run, not a generic square-footage estimate. A CPU-bound cluster for genomics alignment or statistical modeling looks like a beefed-up admin rack — call it 8-12 kW per rack, air-cooled, standard networking. A GPU cluster for deep learning or large-scale simulation is different: modern accelerators concentrate enough heat per rack unit that air cooling struggles past roughly 20 kW per rack, which is why most new GPU deployments plan liquid cooling at the rack or chip level from the outset rather than retrofitting it later.
Power distribution has to match that density. A rack pulling 40+ kW needs higher-amperage PDUs and circuits sized with headroom for the next GPU generation, not just this year's — accelerator power draw has climbed with each refresh, and a facility wired to today's exact number is undersized in a few years. Building 20-30% headroom into the research zone's power and cooling specifically, above the margin used for admin systems, is the difference between a facility that absorbs the next grant-funded cluster and one that needs a construction project to do it.
Network design matters as much as power. Clusters running distributed training or tightly coupled simulations need low-latency, high-bandwidth interconnects between nodes — a different fabric than the 1/10 GbE that comfortably serves file shares and admin applications. Planning that fabric as a separate zone, rather than extending the campus network core, keeps a burst of research traffic from degrading performance for everyone else.
What should actually be shared between the two zones
Full separation into two physical facilities is rarely the right answer for a campus budget, and it isn't necessary. Physical security, fire suppression, generator backup, and the building envelope itself are worth sharing — they don't scale with workload type, and duplicating them is pure overhead. What shouldn't be shared is the electrical distribution downstream of the main switchgear, the cooling loop, and the network core: those need independent sizing and zoning so a research cluster's peak draw or a cooling-loop fault doesn't cascade into the other zone.
A practical layout treats the facility as one building with two data halls, or one hall with two clearly zoned areas: a standard-density zone for admin, storage, and CPU-bound research on conventional air cooling, and a high-density zone provisioned for liquid cooling and heavy power with room to expand as GPU adoption grows. That zoning decision, made at the design stage, is far cheaper than adding liquid cooling to a room that wasn't plumbed for it.
Staging and integration benefit from the same separation. Admin refresh hardware — servers, switches, UPS units — is a known quantity most integrators handle routinely: unboxing, racking, cabling, burn-in before delivery. GPU nodes and their cooling infrastructure benefit from a staging partner who can validate the liquid-cooling connections and network fabric before it reaches campus, since a DOA node found after installation costs a research team weeks, not hours.
Building the refresh timeline around two different lifecycles
Admin infrastructure and research computing hardware age on different clocks, and a single five-year refresh cycle for the whole facility ignores that. Administrative servers and storage typically run a comfortable 5-7 year lifecycle before performance or support-contract economics push a refresh. GPU hardware for research computing moves faster — new accelerator generations arrive roughly every 12-24 months with meaningful performance and efficiency gains, and grant-funded research groups often want to refresh sooner to stay competitive for compute-intensive proposals.
Budgeting for that means separating capital planning lines for the two zones rather than bundling everything into one facility-wide request. It also means the physical and electrical infrastructure — longest lifecycle, highest replacement cost — should be sized for the research hardware two generations out, not just this cycle's, since ripping out PDUs and cooling loops for the next GPU refresh is far more disruptive than swapping servers.
Sizing checklist for a two-workload refresh
Questions to work through with facilities and research leadership before finalizing specs.
- Per-rack kW targets set separately for admin, CPU research, and GPU research zones
- Cooling method (air vs. liquid) chosen per zone, not facility-wide
- 20-30% power/cooling headroom built into the research zone specifically
- Network fabric for research clusters specified independently from the admin/campus core
- Electrical distribution and cooling loop zoned so one workload's peak doesn't affect the other
- Shared infrastructure identified: security, fire suppression, generator, building envelope
- Refresh timeline split into separate capital lines for admin (5-7 yr) and GPU research (12-24 mo)
- Staging/burn-in plan for GPU nodes and liquid-cooling connections before campus delivery
- Physical expansion path confirmed for the next hardware generation, not just current specs
Frequently asked
How much power does a university GPU cluster need per rack?
It depends on the accelerator and node density, but modern GPU racks commonly run 20-50+ kW, well above the 4-8 kW typical of an administrative server rack. That density is why most new GPU deployments plan for liquid cooling rather than air alone, and why power distribution needs headroom for the next hardware generation.
Can research computing and administrative IT share the same data center room?
Yes, if the room is zoned rather than treated as one uniform environment. Shared security, fire suppression, and generator backup are fine; electrical distribution, cooling loops, and network fabric should be sized and zoned separately so a research cluster's peak draw doesn't degrade admin systems or vice versa.
Does a research computing cluster need liquid cooling?
CPU-bound research workloads often run fine on air cooling at admin-adjacent densities. GPU-bound workloads typically don't — once a rack climbs past roughly 20 kW, air cooling struggles to keep up, which is why liquid cooling at the rack or chip level has become the default plan for new GPU deployments rather than a later retrofit.
How often should a university refresh GPU research computing hardware?
GPU accelerator generations typically turn over every 12-24 months with meaningful performance and efficiency gains, faster than the 5-7 year cycle typical for administrative servers. Budgeting research hardware on its own capital line, separate from the broader IT refresh, keeps that faster cycle from being forced onto systems that don't need it — or ignored on those that do.
What's the biggest mistake in sizing a campus data center for research computing?
Extending the administrative facility's power, cooling, and network design to cover research computing as an afterthought. It's a common reason campus data centers hit power or cooling ceilings within a couple of years — the fix is sizing the research zone on its own workload profile from the start, with headroom for the next hardware generation.
Related resources
Go deeper
Higher education solutions
How Uniqcli sources, stages, and delivers IT infrastructure for university campuses and research institutions.
Learn moreAI and data infrastructure
GPU compute, storage, and networking built for AI, machine learning, and high-performance research workloads.
Learn moreBrowse the catalog
Search server, storage, networking, and cooling infrastructure across manufacturer lines.
Learn moreSizing a refresh for two workloads at once?
Uniqcli sources and stages infrastructure for both sides of a campus data center refresh — administrative systems and research computing clusters — with sell pricing and logistics handled through one point of contact.