From the Cisco edition of October 29, 2026
Internet2 and Cisco deploy two Cisco AI PODs at the University of Nebraska-Lincoln and Sacramento State as shared GPU capacity for the National Research Platform
Internet2 with Cisco; University of Nebraska-Lincoln; California State University, Sacramento · Higher education / research computing infrastructure · United States (Nebraska, California; national research platform)
- Publisher
- Internet2
- Original publication
- Internet2 news release, Sept. 22, 2026
- Source retrieved
- 2026-10-30
What happened
Internet2, through its industry relationship with Cisco, supported deployment of Cisco AI PODs at the University of Nebraska-Lincoln and Sacramento State that join the NSF-supported National Research Platform (NRP), a community-operated pool of compute contributed by over 70 organizations and run as one Kubernetes fabric (Nautilus). Combined, the two PODs provide 8 NVIDIA H200 GPUs with 1.1 TB of GPU memory, 128 CPU cores, 2 TB of system memory and 90 TB of NVMe flash; each site has one Cisco UCS C845A M8 chassis and a BlueField-3 DPU with up to 2x200 Gbps to campus and national R&E networks. Internet2 says the pre-validated design reduces integration risk and setup time and is a repeatable model for other contributors. No utilization, performance or cost figures are reported.
Why it matters
Shows a concrete public higher-ed path for Cisco AI infrastructure: small, standardized GPU nodes contributed to a shared research platform rather than each campus building its own cluster. Relevant to research universities and regional/state universities with limited budgets.
Evidence and measured results
Opened the Internet2 release and read it in full, including the hardware list and the description of NRP and Internet2 network contributions. It is a joint-relationship announcement, so claims about reduced integration risk are the parties’ own and are not measured.
Limitations and uncertainty
Joint announcement by a member association and its industry partner; no independent evaluation, utilization data or cost. Published Sept. 22, 2026, before most items in this edition; included as the first cisco-stream baseline for research-computing deployments. Only 8 GPUs in total, so this is a modest increment.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-30; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Campus researchers lack GPU capacity, and budgets cannot fund large standalone clusters.
- Stakeholders
- Research computing directors
- CIOs
- Vice presidents for research
- State or regional R&E network operators
- Discovery questions
- How often do local GPU queues exceed capacity today?
- Is the campus already connected to NRP or a regional R&E network at 100G or more?
- Who would operate and support a hosted node?
- Value hypothesis
- Contributing a standardized node to a shared platform may give researchers access to more capacity than a single small cluster.
- Potential engagement
- Feasibility assessment for contributing a node to NRP or a state research network.
- Unsupported claims
- Measured cost savings
- Utilization or performance gains
- That other campuses get the same hardware terms
Pre-sales engineering
Role takeaway
- Fit
- Fits research universities with existing R&E connectivity and Kubernetes skills.
- Architecture and integration
- UCS GPU servers, Nexus switching, Intersight management, BlueField-3 DPU links into the Nautilus Kubernetes fabric.
- Prerequisites
- High-bandwidth R&E uplink
- Data center power and cooling for GPU servers
- Kubernetes operations skills
- Constraints
- Only 8 GPUs across two sites
- No published performance or utilization data
- Pooled capacity limits local priority
- Security
- Classify which research data may run on shared nodes; regulated data needs separate controls.
- Proof of value
- Measure job wait time before and after
- Measure throughput to data caches
- Track monthly utilization by local versus external users
Delivery
Role takeaway
- Work
- Install, integrate with NRP and support a hosted GPU node.
- Dependencies
- NRP onboarding
- Campus network upgrades
- Facilities power and cooling
- Ownership
- Campus research computing group with central IT networking
- Skills and adoption
- Research computing staff need Kubernetes and Intersight skills; researchers need onboarding to the shared platform.
- Governance checkpoints
- Data classification review before joining
- Agreement on local versus platform priority
- Annual usage review
- Acceptance criteria
- Node joins the fabric and passes health checks
- Availability target agreed and met
- Monthly usage report shared with research office
- Risks
- Local users expect priority on pooled hardware
- Hidden power and support costs
- Small capacity relative to demand
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Pre-validated UCS plus Nexus plus Intersight nodes are designed to slot into a multi-region Kubernetes fabric; high-bandwidth R&E connectivity and data caches (OSDF nodes) are part of the design, not optional extras.
Governance
Who approves, reviews and stays accountable for outcomes?
Capacity is pooled and community-operated, so allocation, priority between local and platform users, and acceptable-use rules sit with NRP and host campuses; the release does not describe them.
Security and privacy
What data, permissions and controls need testing?
Not addressed; shared multi-tenant research compute requires campus review of what data classes (e.g., controlled or regulated research data) may run on contributed nodes.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Framed as narrowing cyberinfrastructure gaps between institutions; does not quantify how many researchers or students use the new capacity.
Procurement
What should contracts, pricing and exit terms secure?
Hardware was directed through Internet2’s industry relationship with Cisco; the release does not state cost or whether campuses paid. Other campuses should not assume equivalent terms.
Operating model
Which teams own the service once it runs?
Host campuses operate hardware that serves external users, which needs agreed support, maintenance and power responsibilities.
Publication history
- 2026-10-29Cisco · Issue 0111 resources
Stable resource ID: internet2-cisco-ai-pods-national-research-platform-unl-sacramento-state-20260922