{"resourceId":"scn-gatech-nexus-vast-data-storage-20261011","versions":[{"version":"external-8577ef66bdee1e4e2125bf294d18168086b593f5141a3161e531ce61921b7266","resource":{"id":"scn-gatech-nexus-vast-data-storage-20261011","title":"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","organization":"Georgia Institute of Technology with University of Illinois Urbana-Champaign (NCSA); funded by the U.S. National Science Foundation","sector":"Higher education / academic research computing","geography":"United States (Atlanta, Georgia; Urbana-Champaign, Illinois)","publishedAt":"2026-10-11","publicationDate":"2026-10-11","eventDate":"2026-10-12","sourceName":"Supercomputing News","sourceLabel":"Supercomputing News (SCN Staff) report","sourceUrl":"https://www.supercomputing.news/hpc/georgia-tech-nexus-supercomputer-nsf-access-nairr","evidenceClass":"independent-reporting","outcomeClass":"emerging","topics":["infrastructure","governance-procurement","operating-model"],"finding":"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.","sledRelevance":"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":"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.","architectureImplications":"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.","governanceImplications":"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.","securityPrivacyImplications":"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.","caveats":"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.","streamIds":["vast-data"],"roles":{"sales":"Nexus gives a credible higher-education reference: a public university chose VAST as the single data platform for a national NSF AI resource. Use it to open conversations with research-computing directors planning NSF, NAIRR or state-funded GPU clusters about shared data layers for mixed training, inference and persistent services. Do not present it as proof of performance or savings; the system was pre-production and no storage metrics are published. Position discovery around allocation-driven multi-user demand and operating budgets instead.","engineering":"Engineers should treat Nexus as an architecture pattern, not a benchmark: eight VAST Ceres V2 appliances on a dedicated storage fabric serving DGX B200 and RTX PRO 6000 pools, non-blocking for one and oversubscribed for the other. Conflicting public specs on fabric type and node counts mean any design reuse must start from the official hardware guide. Validate per-pool bandwidth, metadata behavior under many small-user projects, and cross-site data placement with NCSA before quoting comparable designs to other campuses.","delivery":"For delivery teams the lesson is operational: a national-allocation system brings thousands of external users, quotas and retention questions to the storage layer. Plan onboarding, allocation-linked quota automation, checkpoint storage sizing and support runbooks with the campus HPC operations group. Because Nexus was pre-production when reported, treat schedules and service levels as unproven. Acceptance should be tied to measured throughput per pool and to documented data-placement rules across the two host sites."},"roleDetails":{"sales":{"customerProblem":"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"],"discoveryQuestions":["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?"],"valueHypothesis":"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.","potentialEngagement":"A scoped architecture review comparing a campus's planned GPU cluster with the Nexus storage pattern, ending in a validation test plan.","unsupportedClaims":["Any storage performance or time-to-result improvement at Nexus","Cost savings or operating-cost reductions","Production readiness (system was pre-production when reported)"]},"engineering":{"fit":"Fits mixed-GPU research clusters needing one shared high-bandwidth namespace; fit for oversubscribed pools depends on workload I/O profiles.","architectureIntegration":"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.","proofOfValue":["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":{"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.","skillsAdoption":"Operators must learn appliance-style storage management alongside Slurm, container and service-tier operations; external users need data-placement guidance.","governanceCheckpoints":["Allocation-to-quota policy approval","Data retention and purge policy for external users","Site placement review for persistent services"],"acceptanceCriteria":["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"]}},"retrievedAt":"2026-10-29T22:06:09-05:00","enrichedAt":"2026-10-29T22:13:03-05:00","enrichmentBasis":"retrieved source","accessibilityWorkforceImplications":"Free compute for approved projects and planned course allocations could widen access for smaller institutions; host staff must support many external users.","procurementImplications":"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.","operatingModelImplications":"Two-site operation (Georgia Tech and NCSA) with Slurm pools plus persistent services requires cross-institution operating agreements.","peerReview":"unknown","sourceVerification":{"openedUrl":"https://www.supercomputing.news/hpc/georgia-tech-nexus-supercomputer-nsf-access-nairr","referenceExcerpt":"Storage comes from eight VAST Data Ceres V2 all-flash appliances, about 10.8 PB of raw NVMe capacity in total.","promptVersion":"sled-research-v4.0","model":null,"basis":"agent-reported inspection"}}}]}