From the VAST Data edition of October 29, 2026
Georgia Tech's NSF-funded Nexus AI supercomputer opens nationally on an eight-appliance VAST Data all-flash storage layer, still pre-production as of Oct 10
Georgia Institute of Technology with University of Illinois Urbana-Champaign (NCSA); funded by the U.S. National Science Foundation · Higher education / academic research computing · United States (Atlanta, Georgia; Urbana-Champaign, Illinois)
- Publisher
- Supercomputing News
- Original publication
- 2026-10-11
- Source retrieved
- 2026-10-30
- Event date
- 2026-10-12
What happened
Supercomputing News reports that Nexus, a $20M NSF Category I capacity system at Georgia Tech's Coda data center, uses eight VAST Data Ceres V2 all-flash appliances (about 10.8 PB raw NVMe) on a separate storage fabric that is non-blocking for DGX B200 nodes and oversubscribed for RTX PRO 6000 nodes. At least 90% of capacity is allocated nationally through ACCESS/NAIRR peer review. As of October 10, ACCESS listed Nexus as pre-production; the ribbon cutting was October 12. No storage performance results are published.
Why it matters
Direct higher-education/research relevance: a public university hosting a national NSF resource selected VAST as the shared data platform for mixed AI training, inference and persistent-service workloads. It is a reference deployment for university research-computing (PACE-style) teams, not evidence of measured benefit.
Evidence and measured results
Independent trade reporting that cites the Nexus hardware guide, NSF award abstract, ACCESS catalog/operations record and Georgia Tech releases. Facts are configuration and governance (allocation rules, funding category, status); there is no benchmark, baseline or user-outcome data. Separately inspected Nexus portal (operator page) confirms 8x VAST Ceres V2, ~10.8 PB raw, 12.8 TB SCM each, BlueField-3 DPUs, but lists the storage fabric as 200-400 Gb Ethernet and 42 RTX nodes/336 RTX GPUs, versus SCN's NDR InfiniBand storage fabric and 38 nodes/304 GPUs.
Limitations and uncertainty
Secondary reporting (AI-assisted drafting per SCN disclosure) with no storage performance data. Operator portal and SCN disagree on storage-fabric type and RTX node/GPU counts; treat specifications as unconfirmed until the hardware guide is checked directly. System was pre-production at reporting time; applications were 'opening soon'. VAST's own social post about the ribbon cutting was not used.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-29; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- University research-computing groups need a shared data layer for national-allocation AI systems that mix batch training, inference and always-on services.
- Stakeholders
- University CIO / VP research computing
- HPC center director (e.g., PACE-style operations)
- Principal investigators on NSF awards
- Research data governance office
- Discovery questions
- Is your next GPU cluster funded under an NSF/NAIRR program with open-allocation requirements?
- How will storage quotas and retention follow external ACCESS allocations?
- Which workloads need persistent services outside Slurm, and where must their data live?
- Value hypothesis
- A single all-flash namespace may simplify serving several GPU pools and service tiers, if measured per-pool throughput meets allocation workloads; Nexus shows the design was chosen, not that it delivered.
- Potential engagement
- A scoped architecture review comparing a campus's planned GPU cluster with the Nexus storage pattern, ending in a validation test plan.
- Unsupported claims
- Any storage performance or time-to-result improvement at Nexus
- Cost savings or operating-cost reductions
- Production readiness (system was pre-production when reported)
Pre-sales engineering
Role takeaway
- Fit
- Fits mixed-GPU research clusters needing one shared high-bandwidth namespace; fit for oversubscribed pools depends on workload I/O profiles.
- Architecture and integration
- Dedicated storage fabric from compute to VAST Ceres V2 appliances with BlueField-3 offload; separate compute fabric for GPU-to-GPU traffic; federation with NCSA systems.
- Prerequisites
- Confirmed hardware guide specifications (fabric type, node counts)
- Per-pool I/O profiles for training, inference and services
- Data-placement policy across host sites
- Constraints
- RTX pool storage links are oversubscribed
- Published link rates are not guaranteed application throughput
- Cross-site services at NCSA connect over 100 Gb Ethernet outside the InfiniBand fabrics
- Security
- Source gives no detail on encryption, tenancy or regulated data on the VAST layer; service placement depends on security requirements, so tenancy controls must be validated separately.
- Proof of value
- Measure sustained read/write per pool under concurrent allocations
- Test checkpoint/restart I/O for multi-node DGX jobs
- Reconcile operator portal and reported specs before reuse
Delivery
Role takeaway
- Work
- Stand up storage operations for an open-allocation AI system: quotas, onboarding, checkpoint sizing, monitoring and support runbooks.
- Dependencies
- ACCESS/NAIRR allocation workflows
- Campus HPC operations staffing
- Vendor support for VAST appliances
- NCSA coordination for federated work
- Ownership
- Host university HPC operations group (PACE at Georgia Tech per the report), with NSF-funded operations support.
- Skills and adoption
- Operators must learn appliance-style storage management alongside Slurm, container and service-tier operations; external users need data-placement guidance.
- Governance checkpoints
- Allocation-to-quota policy approval
- Data retention and purge policy for external users
- Site placement review for persistent services
- Acceptance criteria
- Proposed: documented per-pool throughput meets allocation workload targets
- Proposed: quota provisioning automated from ACCESS allocations
- Proposed: published data-placement rules for both sites
- Risks
- Specification drift between public sources
- Production delays (spring 2026 target already slipped to October)
- Storage contention on oversubscribed pools
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?
Pattern: one shared all-flash VAST namespace feeding two GPU classes plus a persistent-services tier, with a dedicated storage fabric. Oversubscription for RTX nodes means storage bandwidth per node differs by pool. The published link rates are installed capability, not application throughput (per the hardware guide as reported). Federated work with NCSA Delta/DeltaAI implies cross-site data placement decisions.
Governance
Who approves, reviews and stays accountable for outcomes?
NSF solicitation 24-583 requires at least 90% open national allocation; universities hosting such systems must plan storage quotas, retention and data-placement policies for external users they do not employ. NSF funds operations separately via supplements of up to 15% of acquisition cost per year.
Security and privacy
What data, permissions and controls need testing?
Persistent services are placed at Georgia Tech or NCSA based on security, data and networking requirements; users must confirm where data sits. The source does not describe encryption, tenancy or regulated-data controls on the VAST layer.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Free compute for approved projects and planned course allocations could widen access for smaller institutions; host staff must support many external users.
Procurement
What should contracts, pricing and exit terms secure?
NSF Category I awards ($10M-$20M, up to five years) with separate operations supplements shape storage purchasing; reference designs from one award do not transfer automatically.
Operating model
Which teams own the service once it runs?
Two-site operation (Georgia Tech and NCSA) with Slurm pools plus persistent services requires cross-institution operating agreements.
Publication history
- 2026-10-29VAST Data · Issue 014 resources
Stable resource ID: scn-gatech-nexus-vast-data-storage-20261011