From the Research Universities edition of October 20, 2026
Indiana University adds 208 NVIDIA H100 GPUs to its Quartz HPC system after 312 users faced waits of eight hours or more, and slices nodes to a quarter per job
Indiana University (UITS Research Technologies) · Public research university (research computing) · United States (Indiana)
- Publisher
- Indiana University IT News
- Original publication
- 19 October 2026
- Source retrieved
- 2026-10-21
What happened
IU IT News reported on 19 October 2026 that UITS Research Technologies added 52 Lenovo SD665-N nodes to the Quartz HPC system, each with two AMD EPYC 9454 CPUs, 1.5 TB of RAM and four NVIDIA H100 80GB GPUs, for 208 new GPUs. The stated demand case: in the prior six months Quartz and Big Red 200 served 1,189 researchers and students, nearly half using GPU partitions; 312 users waited eight hours or more for jobs to start, affecting over 34,000 jobs; one lab ran 7,308 AlphaFold3 jobs on only 48 H100s. Usage analysis showed most GPU jobs need one GPU, so most new nodes will be sliced to a quarter of a node per job to stop oversized requests locking out others. Expected reductions in wait times are aims, not measured results.
Why it matters
Gives a rare set of concrete demand numbers (users, wait times, jobs affected) behind a campus GPU purchase, and a specific allocation policy, node slicing based on usage analysis, that other research computing groups can compare against their own queues.
Evidence and measured results
Opened the IU IT News article dated 19 October 2026 and read the full text, including usage statistics, node specifications, the slicing policy and the researcher quote.
Limitations and uncertainty
IU's own IT news item. Demand statistics are self-reported without methodology, and the article gives no cost, funding source or post-deployment wait-time data. A researcher quote says "200 new H100" GPUs while the article body says 208.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-20; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Research computing groups face long GPU queues and need evidence to justify and allocate new capacity.
- Stakeholders
- Research computing director
- Chief information officer
- Vice president for research
- Faculty HPC advisory committee
- Discovery questions
- What share of GPU jobs use only one GPU?
- How many users wait more than eight hours for jobs to start?
- Which workloads need newer GPU generations?
- Value hypothesis
- Scheduler-log analysis may let an institution right-size a GPU purchase and allocation policy before spending capital.
- Potential engagement
- A three- to four-week scheduler-log analysis and capacity model with recommended partition and slicing policies.
- Unsupported claims
- A specific reduction in wait times
- Cost-effectiveness of the purchase
- Research output gains
Pre-sales engineering
Role takeaway
- Fit
- Fits existing clusters with measurable queue pressure from mostly single-GPU workloads; less fit for large multi-GPU training.
- Architecture and integration
- New GPU nodes added to an existing scheduler with partitions that slice nodes per job and a route for multi-GPU work.
- Prerequisites
- Scheduler logs with per-job GPU and memory use
- Facility power and cooling for new nodes
- Partition and fair-share policy
- Constraints
- Slicing limits large multi-GPU jobs
- Funding and cost not disclosed
- Software requiring newer GPU generations
- Security
- Standard HPC account and data controls; confirm GPU sharing does not expose memory between jobs under the chosen slicing method.
- Proof of value
- Compare median and 90th-percentile wait times before and after expansion
- Measure GPU utilisation on sliced nodes
- Track multi-GPU job wait times separately
Delivery
Role takeaway
- Work
- Analyse usage, set partition and slicing policy, communicate changes to users and monitor waits and utilisation.
- Dependencies
- Node installation and acceptance testing
- Faculty agreement on allocation rules
- Monitoring dashboards
- Ownership
- Central research computing with faculty HPC governance.
- Skills and adoption
- User guidance on requesting right-sized GPU jobs; workshops for labs moving from older GPUs.
- Governance checkpoints
- Allocation policy approval before launch
- Three-month wait-time review
- Annual capacity review
- Acceptance criteria
- Proposal: median GPU job wait below an agreed target three months after launch
- Proposal: share of users waiting over eight hours reported quarterly
- Proposal: sliced-node utilisation above an agreed threshold
- Risks
- Demand growth outpacing new capacity
- Multi-GPU users disadvantaged by slicing
- No post-launch measurement
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?
Adds H100 nodes within an existing cluster rather than a new system; per-job slicing to one GPU and a quarter of a node assumes most workloads fit one 80GB GPU, which usage data supported.
Governance
Who approves, reviews and stays accountable for outcomes?
Allocation policy is set from historical usage analysis, an approach that is auditable and adjustable; the article does not describe exceptions for multi-GPU jobs.
Security and privacy
What data, permissions and controls need testing?
Not addressed in the article.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Expanded access is framed for both researchers and students; no training or support staffing changes are described.
Procurement
What should contracts, pricing and exit terms secure?
Incremental node purchase into an existing system; cost and vendor terms are not given.
Operating model
Which teams own the service once it runs?
Central research technologies run allocation using usage data, which makes wait-time and utilisation monitoring an ongoing operational duty.
Publication history
- 2026-10-20Research Universities · Issue 423 resources
Stable resource ID: indiana-university-quartz-208-h100-gpus-queue-waits-20261019