From the NVIDIA edition of October 8, 2026
Georgia Tech Nexus docs: 480 NVIDIA GPUs installed (16 DGX B200 nodes / 128 B200 GPUs; 38+6 RTX PRO 6000 Blackwell nodes) with NDR InfiniBand and VAST storage
Georgia Institute of Technology (Nexus) · Higher education research computing · United States — Georgia Tech and NCSA persistent-service nodes
- Publisher
- Nexus documentation (docs.nexus.gatech.edu)
- Original publication
- undated (operator documentation; retrieved 2026-10-08)
- Source retrieved
- 2026-10-09
- Event date
- 2026-10-08
What happened
Nexus operator docs describe an installed system with NVIDIA DGX B200 nodes for tightly coupled AI, NVIDIA RTX PRO 6000 Blackwell Server Edition for flexible GPU computing, and dedicated RTX nodes for long-running services. Inventory totals 72 nodes, 480 GPUs, 8,576 CPU cores and 118 TB system memory: 16 DGX B200 nodes (128 GPUs, 1.44 TB HBM aggregate per node class), 38 scheduled RTX PRO 6000 nodes (304 GPUs) and 6 persistent-service RTX PRO 6000 nodes (48 GPUs) at Georgia Tech and NCSA. Networking includes NDR InfiniBand (QM9700), BlueField-3 and ConnectX-7; storage is VAST (~10.8 PB raw NVMe). Docs warn published interface rates are not guaranteed application throughput and that Georgia Tech and NCSA are distinct sites for data and identity planning. Why now: pairs with the Oct 8 Georgia Tech/Emory investment announcement of Nexus launching in October.
Why it matters
Gives SLED architects concrete NVIDIA platform composition for a NSF-linked university AI factory—useful for peer planning and for Georgia agencies assessing what 'Nexus access' actually means technically.
Evidence and measured results
Opened and read the full Hardware Details page from Nexus docs. Operator-stated inventory and architecture; undated page; no utilization, wait-time or independent audit metrics.
Limitations and uncertainty
Undated operator documentation; inventory may change. Portal marketing figures (464 GPUs / 8,320 cores) differ slightly from this docs total (480 GPUs / 8,576 cores including management nodes)—use docs for engineering. No performance benchmarks.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-09; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Partners hearing 'Nexus' need a clear GPU and tenancy picture before committing staff or matching funds.
- Stakeholders
- Research computing architects
- Agency AI leads
- Partner university CIOs
- Discovery questions
- Do you need DGX-class multi-GPU training or RTX inference/services?
- Will data stay at Georgia Tech or also NCSA?
- What allocation route will you use?
- Value hypothesis
- A concrete inventory briefing can prevent mismatched expectations about capacity and access (interpretation).
- Potential engagement
- A one-hour architecture-read using the hardware docs for a single partner use case.
- Unsupported claims
- Guaranteed application throughput from fabric rates
- That all 480 GPUs are available to every user
- Identical networking at NCSA and GT
Pre-sales engineering
Role takeaway
- Fit
- Strong reference architecture for Blackwell university AI factories; verify live quotas before design freeze.
- Architecture and integration
- Slurm on DGX B200 and scheduled RTX PRO 6000; managed persistent-service RTX nodes; VAST over dedicated storage fabric; NCSA nodes on separate networking.
- Prerequisites
- Allocation and identity
- Workload class (training vs serving)
- Data-location decision GT vs NCSA
- Constraints
- Undated docs may lag install changes
- Portal vs docs count differences
- Published link rates ≠ app throughput
- Security
- Persistent service endpoints need authz and network exposure controls separate from batch tenancy; confirm before public models.
- Proof of value
- Submit a DGX multi-GPU smoke test
- Submit an RTX inference job
- Verify storage mount and site for the dataset
Delivery
Role takeaway
- Work
- Onboard users to the correct partition and enforce data-location checks for multi-site work.
- Dependencies
- Nexus operations runbooks
- VAST mount instructions
- Site federation status
- Ownership
- Nexus ops owns platform; PI owns placement; partner security owns data-class.
- Skills and adoption
- Users need training on GPU-class selection and site boundaries.
- Governance checkpoints
- Data-location confirmation
- Partition fit review
- Post-job cost/usage review
- Acceptance criteria
- Jobs run on intended GPU class (proposed)
- No unintended NCSA/GT data movement (proposed)
- Risks
- Designing to marketing GPU counts
- Exposing persistent services broadly
- Ignoring oversubscription on RTX storage fabric
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?
Two GPU classes (DGX B200 NVSwitch vs RTX PRO 6000) plus separate persistent-service tenancy imply different partitions for training vs inference/services; NCSA nodes sit outside GT InfiniBand fabrics.
Governance
Who approves, reviews and stays accountable for outcomes?
Site boundary warnings mean multi-site workflows need explicit data-location and federation decisions before projects span GT and NCSA.
Security and privacy
What data, permissions and controls need testing?
Persistent-service nodes for model-serving endpoints and gateways need separate exposure and auth controls from Slurm tenancy; docs describe placement dependence on security and data requirements.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Docs are technical operator material; student/educator access claims live on the portal and GT news pages, not here.
Procurement
What should contracts, pricing and exit terms secure?
Peer institutions can use this inventory as a planning reference but must size to their own awards and power/cooling—not copy totals blindly.
Operating model
Which teams own the service once it runs?
Separates batch AI, persistent services and multi-site operations into distinct operating lanes that SLED partners must staff differently.
Publication history
- 2026-10-08NVIDIA · Issue 339 resources
Stable resource ID: gatech-nexus-hardware-dgx-b200-rtx-pro-6000-inventory