A Research Grant Can Fund the GPUs. The Campus Still Has to Support Them.

A research team gets word that funding has been approved for new GPU equipment. There is a vendor quote in hand, a research deadline on the calendar, and a team ready to get started. At that point, moving the purchase order can feel like the obvious next step—and it may be.

Before the order goes out, though, the campus still has to determine what the complete system requires, where it should run, what it will cost beyond the equipment purchase, and who will own it after installation.

Purchasing funded equipment and creating an operating research service are related, but they are not the same project.

The goal is not to slow the research down. It is to keep the research schedule from being reset later by a facility, network, funding, or ownership question that could have been identified earlier.

Start with the research—not the equipment quote

A GPU model and quantity do not define the whole requirement. Before the campus evaluates a location or deployment path, the research need should be clear enough to guide the discussion.

• What work will the system perform: training, inference, simulation, visualization, data analysis, teaching, or a mix?
• Who will use it, and will it serve one lab, several departments, or a wider research community?
• Where are the source data now, and how much data must move into, through, and out of the environment?
• Are any of the data sensitive, regulated, contractually restricted, or subject to research-security requirements?
• What performance, availability, and completion-time expectations actually matter to the research?
• When is the first meaningful workload expected, and how might demand grow after the initial project?
• Is the need steady, bursty, seasonal, or tied to a defined grant period?

These questions may change the infrastructure path. A persistent, heavily used shared resource can point toward a different answer than a short-term project with uncertain utilization or a workload that needs occasional access to specialized hardware.

The order matters. The work, users, data, timing, and operating expectations should guide the infrastructure discussion—not be reverse-engineered from an equipment quote after the fact.

Translate the purchase into a complete system profile

The vendor quote may define the compute equipment well. The campus needs the rest of the operating picture.

Equipment and site requirements

• Final rack count, dimensions, operating weight, shipping configuration, and delivery path
• Required rack power, voltage, connections, redundancy assumptions, and startup or operating characteristics
• Cooling method, heat load, temperatures, flow, water quality, and any facility-side liquid-cooling interface
• Service clearances, floor-loading requirements, cable routes, piping routes, staging, and installation needs
• Manufacturer site-planning, commissioning, warranty, and support requirements

Network, storage, and data movement

• Cluster fabric and GPU-to-GPU communication requirements
• Campus, research, and external network connections
• Storage performance, usable capacity, data protection, backup, archive, and growth
• Expected data flows between instruments, laboratories, storage, collaborators, cloud services, and national or regional resources
• Security boundaries, identity and access, logging, and data-governance requirements

Operations

• Platform administration, scheduling, monitoring, patching, and user support
• Facilities monitoring and response for power, cooling, leaks, alarms, and environmental conditions
• Software, licensing, research applications, and workload onboarding
• Hardware support, spares, service access, lifecycle planning, and eventual refresh or retirement

For planning purposes, power, cooling, space, structural loading, site conditions, delivery logistics, network, storage, and operations belong in one system profile. The purchase is not just a collection of GPUs. It has to be delivered, connected, operated, supported, and used.

Keep the deployment path open long enough to compare it

An existing campus data center may be the right location. It should not become the answer simply because it is the first location discussed.

Depending on the workload, data, schedule, utilization, staff capability, and available infrastructure, realistic paths may include:

• Expanding an existing shared campus research-computing environment
• Installing the system in the campus data center
• Using another campus or system-wide facility
• Using a regional or national research-computing resource
• Using cloud, colocation, or a managed platform
• Combining several approaches in a hybrid model

The useful question is not, “Do we prefer on-premises or cloud?” It is, “Which path best fits this research requirement and the constraints we actually have?”

That comparison should include performance and data movement, but also schedule, recurring cost, staff capacity, governance, utilization, expansion, and how easily the path can change as the research evolves.

Separate the equipment budget from the full operating commitment

Funding rules vary by program and project. Site preparation, installation, support, personnel, software, and operating expenses may be treated differently, so the campus should confirm what the specific award or budget actually covers.

What should not be assumed is that a funded equipment purchase automatically funds the complete service around it.

The broader cost picture may include:

• Electrical and cooling changes
• Network and storage expansion
• Installation, rigging, commissioning, and professional review
• Software and licensing
• Utility, water, and facility operating costs
• Hardware maintenance and vendor support
• Research-computing, network, security, and facilities staff time
• User onboarding, training, allocation, and support
• Capacity for growth, lifecycle replacement, and decommissioning

This is not an argument against buying the equipment. It is how the institution makes sure the resource can remain useful after the ribbon-cutting moment has passed.

The exact funding rules depend on the program and award. The planning distinction remains the same: acquiring the equipment and sustaining the service around it are related decisions, and both need an owner.

Put the right campus owners around one fact set

No single department is likely to hold every answer.

The point is not to invite everyone on campus to every meeting. It is to identify which decisions cross organizational lines and make sure those owners are using the same equipment profile, workload assumptions, and schedule.

Use decision gates before the choices harden

The exact process will vary by institution, but four practical gates can keep the project moving without pretending every answer is already known.

1. Before the proposal or funding commitment

• Is the research need defined well enough to estimate the complete resource?
• Have research computing, central IT, and other relevant campus providers been asked whether an existing service or shared path can meet it?
• Are likely institutional commitments and recurring obligations visible?

2. Before the equipment configuration is locked

• Is there one configuration-specific profile for compute, power, cooling, space, network, storage, data, and operations?
• Have realistic deployment paths been compared?
• Are major unknowns assigned to named owners with dates for resolution?

3. Before the purchase order is released

• Has the proposed site and delivery route been checked against the actual equipment requirements?
• Are required changes, approvals, funding, and schedule accounted for?
• Is there a named operational owner for both the computing platform and the supporting facility systems?

4. Before delivery and go-live

• Is the site ready, including network, storage, security, monitoring, support, and commissioning?
• Are responsibilities clear for installation, acceptance, incident response, user access, and ongoing operation?
• Does leadership understand any remaining assumptions or staged limitations?

A gate does not always produce a yes-or-no answer. It may confirm the proposed path, approve a limited first phase, require one more validation item, or keep another path open until the evidence is complete.

Build one shared readiness brief

A practical first step is a short, shared project brief—not another long committee report.

At minimum, it should contain:

1. The research workload, users, data, timing, and growth case
2. The proposed equipment configuration and manufacturer requirements
3. The proposed deployment path and alternatives considered
4. Known site, network, storage, security, and operational conditions
5. Capital costs, recurring costs, and the owner of each budget
6. Named decision owners, open questions, required evidence, and decision dates

Mark each important item as known, assumed, or still unknown. An unknown is not proof that the campus cannot support the project. It identifies what must be established before the next commitment.

What if the campus data center is not ready?

That does not automatically mean the research has to stop, and it does not automatically mean the building should be upgraded.

Possible response categories include:

• Adjusting the equipment configuration, phasing, or schedule
• Using an existing shared campus platform
• Validating or modifying the proposed campus location
• Selecting another campus, regional, colocation, cloud, or managed environment
• Using a temporary or hybrid path while a longer-term capability is developed
• Rescoping the first deployment around the most important research requirement

These are paths to evaluate, not a recommendation for any specific campus. The right answer depends on the actual workload, equipment, data, facility, schedule, operating model, and institutional priorities.

Five questions for the leadership conversation

Before the order is approved, leadership should be able to ask:

1. What research work will this resource support, for whom, and on what timeline?
2. What does the complete system require—not only the GPUs, but power, cooling, space, network, storage, data protection, and operations?
3. Why is the proposed deployment path the best fit, and what alternatives were considered?
4. What site changes and recurring costs sit outside the equipment purchase, and who is funding them?
5. Who is accountable for carrying the project from purchase through installation, commissioning, and ongoing service?

If an answer is still unknown, name the owner and the evidence needed. That is a much better planning position than allowing a reasonable assumption to become an unofficial commitment.

What a readiness assessment can—and cannot—tell you

A readiness assessment can organize the reported workload, infrastructure, ownership, budget, and timeline and expose assumptions or unknowns before they become commitments.

It cannot confirm that a room can support a specific system, validate a network or storage design, determine award allowability, or select the institution's deployment path. Those conclusions require the actual award, equipment, site, and qualified campus, provider, technical, or engineering review appropriate to the decision.

Its value is identifying that work while the equipment, budget, location, and delivery path can still change.

This page provides readiness and decision-framing guidance. It does not provide engineering verification, grant-compliance advice, procurement approval, or a site-specific infrastructure recommendation.