Partner with the NRP
Integrate on-site resources with national infrastructure and bring burstable AI-enabled hardware to the pool.
“Hubs with on-site resources are encouraged to integrate with national resources through mechanisms such as the NRP or PATh.”
The three advantages NSF names
The solicitation names three advantages to integrating with a national resource. Each is quoted below in its own words, with what that one is on the NRP.
- Administration, handled “access to system administration support and services”
- The consortium buys the nodes and keeps them. The NRP installs the operating system, configures the machine, patches it, and handles upgrades — all it needs is IPMI access. Occasionally we will ask someone on site to reboot a node or swap a drive.
- Surge past local capacity “the ability to surge to utilize additional resources beyond local capacity periodically”
- When a deadline outruns the Hub’s own machines, its members schedule onto the rest of the pool through the same Kubernetes API they already use — no second cluster to learn, and no second allocation to apply for.
- Idle hardware does work “the ability to share underutilized resources when available”
- Contributors keep first claim on their own nodes whenever they want them. Between campaigns those nodes run somebody else’s science opportunistically instead of nothing, and the contributor’s researchers get the same courtesy back.
- 400+
- Nodes
- 70+
- Locations
- 3
- Continents
- 5K+
- Users
What the NRP can provide
NSF 26-513 organises a proposal around five elements. Below are its own headings for them, and the NRP infrastructure that relates to each. What the solicitation actually asks for is in the solicitation.
- Element 1 Hub consortium stakeholders, vision, and key deliverables
A letter of support or collaboration, on request. Beyond that, the arrangement is not a new one to describe: the NRP already pools contributed hardware across more than 70 sites, governed by the research community that uses it, and free to community colleges and R1 universities on the same terms.
- Element 2 Computing, data, and AI infrastructure
Contributed nodes join one Kubernetes cluster spanning more than 70 sites, and the institution that paid for a node keeps priority on it. Nothing about that is specific to this program — it is how every site in the NRP already joins.
- Element 3 Partnerships with regional stakeholders
A Hub integrated with the NRP joins a fabric that is already in service: one API across more than 70 sites, Open Science Data Federation caches placed near the people reading from them, and perfSONAR measurement between sites, so a slow path is a diagnosis rather than a mystery.
- Element 4 Development of an AI infrastructure workforce
Facilitators and student operators can work on a production cluster alongside the team that runs it, rather than on a testbed of their own. Bi-weekly office hours, recorded trainings on Docker, Kubernetes and JupyterHub, and the National Research Platform workshop series are open to anyone and already on the calendar.
- Element 5 Faculty training and instructional material development
Hosted JupyterHub and an OpenAI-compatible endpoint serving open-weight models are running now, and neither asks a faculty member to learn Kubernetes. A course is a namespace and a URL, and we size it before the semester starts.
Eligibility, deadlines, award sizes, review criteria, and everything the program actually requires are in NSF 26-513. The NRP is not the program and has no part in reviewing proposals for it.
Questions about integrating?
Happy to talk it through at whatever stage you are at — how integration would work for the resources you have in mind, the technical detail behind any of the above, or a letter of support if one would be useful. Reach us at [email protected].