From the Research Universities edition of November 1, 2026
Purdue cuts per-group GPU limits on its near-100%-utilized Gautschi AI cluster to 2x purchase and adds a 2x-charged burst queue from 2 November
Purdue University Rosen Center for Advanced Computing (RCAC) · University research computing (HPC and GPU clusters) · United States (Indiana)
- Publisher
- Purdue RCAC
- Original publication
- Posted 28 October 2026; changes effective Monday 2 November 2026 (RCAC announcement)
- Source retrieved
- 2026-11-02
- Event date
- 2026-11-02
What happened
RCAC says Gautschi's AI partition, in production for 19 months, has crept toward 100% utilization while normal-queue waits grew and preemptible jobs rarely started. Because groups buy GPU hours rather than GPUs and Gautschi cannot use Slurm Fairshare, every group could run up to 24 H100s at once. From 2 November the normal-queue limit becomes twice the GPUs a group purchased (minimum two), maximum walltime drops from two weeks to four days, a new burst queue allows up to eight GPUs for eight hours at twice the GPU-hour charge, one burst job per group, and preemptible jobs get a 10-minute grace period to checkpoint. RCAC modeled options: a 2x limit frees 50.45 GPUs (31.53% of the cluster) for pending jobs versus 5.86% for 4x and 0.54% for a cut to 16; 78.3% of the 97 groups would not notice the new limit.
Why it matters
A data-backed example of a campus AI cluster hitting saturation and moving from generous flat limits to purchase-proportional access with paid burst capacity. Research computing directors facing the same demand can reuse the modeling approach and see the trade-offs for heavy users.
Evidence and measured results
Read the full announcement including the design-options table. Figures are RCAC's own usage analysis; wait-time data, job counts and outcomes after the change are not yet available.
Limitations and uncertainty
Operator announcement with internal data; no independent evaluation and no post-change results. Purdue-specific purchase model limits transfer. Other campuses use Fairshare or national allocations.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-02; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- A shared AI cluster at full utilization gives long waits and unfair access when a few groups use far more than they bought.
- Stakeholders
- Research computing director
- Vice president for research
- Faculty advisory committee
- Heavy-use research groups
- Discovery questions
- What is your GPU partition utilization and wait time?
- How do purchases map to scheduling priority today?
- Can your accounting charge a premium for burst use?
- Value hypothesis
- Purchase-proportional limits and paid burst capacity may cut waits for most groups while keeping large runs possible.
- Potential engagement
- A review of GPU allocation and queue policy using the customer's job logs.
- Unsupported claims
- Shorter waits are guaranteed
- Heavy users will not be harmed
- The 2x factor fits other campuses
Pre-sales engineering
Role takeaway
- Fit
- Fits condo or purchase-based GPU clusters running Slurm where Fairshare does not suit the purchase model.
- Architecture and integration
- Slurm QOS tiers with per-account GPU limits, walltime caps, a multiplier-charged burst QOS and preemption grace time.
- Prerequisites
- Per-group usage history
- Accounting with charge multipliers
- Checkpoint-capable workloads
- Constraints
- Institution-specific purchase model
- No post-change data
- Shorter walltimes for long jobs
- Security
- No new security controls; keep accounting and QOS changes under change management.
- Proof of value
- Simulate limits on historical job logs
- Track wait times before and after
- Measure preemptible job start rates
Delivery
Role takeaway
- Work
- Model usage, consult users, configure QOS, set up burst billing and publish checkpointing guidance.
- Dependencies
- Slurm accounting data
- Billing system
- User support and consultations
- Ownership
- Research computing center with faculty advisory oversight.
- Skills and adoption
- Researchers learn checkpointing and when to use burst; staff learn QOS tuning.
- Governance checkpoints
- Advance user notice
- Advisory committee review
- Post-change review after one term
- Acceptance criteria
- Median normal-queue wait falls by an agreed amount (proposal)
- Preemptible jobs start regularly
- Burst charges billed correctly
- Risks
- Heavy users lose throughput
- Burst queue contention
- Jobs lost without checkpointing
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?
Slurm quality-of-service tiers (normal, preemptible, burst) replace Fairshare for a GPU-hour purchase model; burst jobs target full eight-GPU nodes with fast GPU-to-GPU links.
Governance
Who approves, reviews and stays accountable for outcomes?
Access rules now tie concurrency to investment, with a single burst job per group to protect fairness.
Security and privacy
What data, permissions and controls need testing?
Not addressed; this is a scheduling and allocation change.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Heavy users face shorter walltimes and must checkpoint; RCAC points them to consultations on checkpointing.
Procurement
What should contracts, pricing and exit terms secure?
Encourages groups that need large GPU counts often to buy enough to cover about half their regular usage.
Operating model
Which teams own the service once it runs?
Shows a shift from growth-phase generosity to rationing by purchase share and surcharge as AI demand saturates a cluster.
Publication history
- 2026-11-01Research Universities · Issue 544 resources
Stable resource ID: purdue-gautschi-ai-cluster-gpu-limits-burst-qos-20261028