In brief
- Ai2 manages clusters containing thousands of NVIDIA H100, B200, and B300 GPUs.
- Under the new system, projects receive GPU time budgets instead of fixed GPUs.
- By default, the scheduler compares usage and allocations over a rolling 7-day window.
- According to Ai2, the new system reduced repairs requiring human intervention by 74%.
In a blog post published on October 9, 2026, Ai2 described a scheduling system it developed to distribute workloads across the research institute’s GPU clusters. Its infrastructure includes thousands of NVIDIA H100, B200, and B300 GPUs, with clusters ranging from 88 to 1,024 GPUs. According to Ai2, demand for resources used by around 150 researchers can reach 2–3 times the available capacity. The new approach assigns GPU time budgets to projects rather than permanently dividing hardware among teams.
Time budgets instead of priority labels
Under Ai2’s previous system, jobs were ranked by priority, and some could be marked as non-preemptible. The organization says this arrangement led over time to high-priority labels becoming widespread, while lower-priority jobs struggled to find resources. Reserving GPUs for specific teams was not always efficient either: resources could sit idle when research needs changed over time.
In the new model, administrators allocate GPU time among projects and research teams. GPU requests are linked to a budget to protect them from preemption. This ties access to resources to project priorities, while jobs without a budget can be preemptible from the outset. Ai2 aims to keep capacity in use when resources would otherwise sit idle.
Rolling window and preemption rules
By default, the scheduler tracks how much GPU time projects use relative to their allocations over a rolling 7-day window. Jobs from groups using less than their share can be prioritized over jobs from groups that have exceeded theirs. As long as there is demand, this comparison is intended to help teams access their budgeted share over time.
When submitting a job, users also specify the minimum runtime needed to make meaningful progress. The job is protected from preemption for that period; after it ends, the system can stop the job and place it back in the queue to rebalance resources. Restartability is also part of the workflow. If the minimum runtime is set to zero, the job does not count against the budget but can be preempted at any time by a budgeted job. Ai2 says it chose 8 hours as the upper limit for minimum runtimes.
The organization says these rules make it possible to drain jobs from servers that need maintenance once their minimum runtimes have elapsed. According to Ai2, this reduced repair work requiring human intervention by 74%. This stands out as a measured outcome not only of the GPU scheduling approach, but also of the infrastructure maintenance process.
Impact on architecture and visualization workflows
Ai2 is not presenting the system as a product for architecture firms or visualization software; it is an approach to managing different workloads on research clusters. Still, for teams sharing GPU servers, the idea of defining resource shares and preemption conditions in advance is worth considering. When workloads with different runtime and resource requirements share the same infrastructure, transparent allocation rules can help with planning.
However, Ai2’s post does not explain whether architectural rendering workloads are compatible with the scheduler. Nor does it cover how rendering or design applications behave after being restarted following preemption. Before evaluating a similar system, architecture and visualization teams should therefore assess hardware requirements, compatibility with the software they use, and whether their workloads can tolerate interruptions. The announcement also does not include licensing, pricing, or availability for external use.
Sources
1 sourceSource texts are not republished; short quotes are marked, everything else is our own summary and commentary.
The practical value of Ai2’s approach is that it defines both resource shares and preemption conditions, rather than allocating GPU resources to teams on a fixed basis. For architecture and visualization teams sharing hardware, it offers an idea for evaluating resource requests under clearer rules; however, that does not make it a ready-to-use rendering tool.
For offices in Turkey, whether a similar setup is worth evaluating depends on how well their workloads tolerate interruptions and whether their software is compatible. Ai2’s post also provides no information about licensing, pricing, or external availability. For now, it is more accurate to view this as an approach to managing shared GPU resources, not as a product choice.
Frequently asked questions
How does Ai2’s GPU scheduler work?
Administrators set GPU time budgets for projects and teams. By default, the system compares usage against allocated time over a rolling 7-day window to schedule jobs.
Can jobs be interrupted by Ai2’s scheduler?
Yes. A minimum runtime is set for each job, and it is protected during that period. Once the period ends, jobs can be placed back in the queue; jobs without a budget can be preempted from the outset.
Can Ai2’s GPU scheduler be used for architectural rendering?
The source provides no information about compatibility with architectural rendering software or availability for that purpose. Ai2 describes the system in the context of managing workloads on research clusters.
