Service units and allocations for Alpha+Beta

Created by Robert Harrison, Modified on Wed, 20 May at 1:14 AM by Cesar Arias

Allocations

Empire AI — Service Units and Allocations for Alpha+Beta

This article explains how Service Units (SUs) are used to account for compute and storage resources across Alpha and Beta, how institutional allocations are distributed, and how projects can plan SU usage in practice.

Validity period: The service unit multipliers in this article are valid for CY2025, CY2026, and CY2027, until Gamma begins operations, currently expected around June 2027. The multipliers may be revised after Gamma is in operation.

Planning note: The example scenarios in this article are planning illustrations. They are intended to show how SU accounting works across different resource mixes, not to guarantee a specific per-project allocation or cloud-equivalent value.

Service unit multipliers

All compute and storage resources are assigned a value in Service Units (SUs), a model that may already be familiar to users of NSF national facilities. On Alpha and Beta, the current SU multipliers are:

Resource	Multiplier
1 Alpha GPU hour	1 SU
1 Beta GPU hour	2 SU
1 Grace-Grace node hour	0.5 SU
1 TB.month	8.333 SU up to 100 TB; data over 100 TB is not charged in SUs, but is allocated and managed separately
Priority queue access	2x the above
Shared resource access	0.5x the above

These conversion factors are referred to here as multipliers. SUs provide a unified accounting abstraction across different generations of hardware and across different ways of valuing resource use, including internal charge-back cost, delivery cost, or rough public cloud equivalents.

How SU cost is calculated

The cost of a compute job in SUs is calculated as:

Cost in SUs = duration × amount of resources × multiplier

Storage is accounted for monthly based on average use. Each user receives 100 GByte of free storage for their home directory.

Institutional allocations

With the multipliers above, Alpha and Beta together will deliver about 6.3 million SUs per year, so each institutional allocation is 0.7 million SUs per year. Institutions allocate SUs to projects, and those project allocations can then be used across any available resource, which gives projects flexibility while also encouraging efficient use of the shared system.

Empire AI tracks and reports usage monthly, and usage information is also available in near real time to users and managers through command-line tools and dashboard views.

Storage policy

Only about 10% of the actual available storage capacity is included in the SUs made available for institutional allocation. This reflects expected usage patterns, where most projects will primarily consume compute allocations, while projects with larger data footprints are managed separately.

Storage beyond 100 TB is not charged in SUs, but it is not automatic or unlimited. Large storage requests are approved, quota-managed, and scheduled separately because storage capacity is finite and fixed. Specifically:

Data beyond 100 TB is not charged in SUs.
Large storage requests are accommodated on an as-feasible basis with fixed quotas for fixed periods of time, scheduled with projects to support as many large projects as possible.
Projects needing a large allocation of data over an extended period are managed case by case.

If storage becomes scarce, these policies may be adjusted. If a project discovers a need for about 100 TB of storage during execution, submit a ticket to request that access.

What happens when an allocation is exhausted

Projects and institutions are not charged beyond their allocations. If a project or institution exceeds its allocation, normal allocated access does not continue at the same level. Instead, access is reduced to free, low-priority, preemptible queues that are otherwise inaccessible, and projects may also be asked to reduce their storage footprint as described in the terms and conditions.

This policy is intended to provide a smooth end to projects, help ensure full system utilization, and encourage timely use of allocations. Users with no allocation will eventually be transitioned off the system, again as described in the terms and conditions.

Illustrative planning scenarios

Assuming 35 projects per institutional allocation per year, each project would average about 20,000 SUs per year under that distribution model. The scenarios below are illustrative planning examples showing different ways a project could use 20,000 SUs across Alpha and Beta resources.

Scenario	How the 20,000 SUs are used
Scenario 1	Compute only on H100 GPUs with no additional data allocation. This is equivalent to about 2.3 GPUs dedicated all year, with a rough AWS comparison point of about $80K.
Scenario 2	Store 50 TB for a year and compute on H100 GPUs. The storage cost is 50 × 12 TB-months = 5,000 SUs, leaving 15,000 SUs for compute, which is equivalent to about 1.7 H100 GPUs dedicated all year, with a rough AWS comparison point of over $100K.
Scenario 3	Store 100 TB for a year and compute on H100 GPUs. In this case, storage and compute costs are about equal, leaving enough for roughly 1.14 dedicated GPUs, with a rough AWS comparison point of over $120K.
Large data project	A project needs 1 PByte for 3 months. The request is made either in the original proposal or later by ticket. Only 10,000 SUs for the first 100 TB are charged; capacity above that level is scheduled separately for a fixed period of time. As a rough comparison point, 1 PB of fast storage on AWS EBS for 1 year is about $1M.

Cloud cost note: AWS values in these scenarios are rough comparison points intended to convey scale. They are not billing equivalents and may vary significantly depending on service choice, region, commitment model, and data movement.

Large data projects are expected to stage data on and off the system in a timely manner because storage is finite. Projects with very large storage footprints should also expect correspondingly large compute requirements and should plan both together.