Admin Pages

User quotas, hardware registry, schedule windows, Rubrics, audit, and usage

Requires the admin role. For CLI equivalents, see sf admin.

Users and quotas (/admin)

• User list: role, status, current usage;
• Create local accounts, change roles (admin / operator), disable / enable, delete;
• Per-user quotas: concurrent GPUs, concurrent jobs, daily GPU-hours, allowed profiles, queue priority;
• Rubrics card: versioned CRUD for LLM-judge scoring rule templates, referenced by the judge service.

Concurrency quota and daily budget are two different things

	Governs	What happens when exceeded
Concurrent GPUs / jobs	How much you can hold at once	Submission is rejected (queuing would not help)
Daily GPU-hours	How much you can burn in a day	The job queues, and dequeues automatically after the budget resets at midnight

With only a concurrency quota, one person running 8 GPUs all day and one running them for ten minutes look equally compliant to the platform — while the bill differs by 140×. Set 0 for unlimited.

The number the gate reads is the same one the usage page shows (integrated over the platform’s local day, including the elapsed portion of running jobs), so “today’s budget is used up” can be checked against the user’s own usage page.

Both respect the FORGE_QUOTA_ENFORCE master switch; with it off, they display but do not block.

Dequeue order: first come first served, or fairness first

FORGE_SCHED_POLICY: "fair-share"    # default: priority-fifo
FORGE_FAIRSHARE_WINDOW_H: 24        # look-back window in hours

priority-fifo (default) sorts by priority then submission time. Fine for a single team.

fair-share puts recently-lighter users first within the same priority. An explicitly granted priority still wins — fairness should not override a decision. It compares relative usage (recent GPU-hours ÷ quota GPUs): 100 GPU-hours from someone with a 64-GPU quota is not the same as 100 GPU-hours from someone with 8.

When to switch: more than three teams sharing one cluster. Before that, first-come-first-served is easier to predict; after it, one person submitting 20 jobs within quota fills the queue, and that becomes an interpersonal problem blamed on the platform.

Admin users: roles, enable/disable, concurrent GPU and job quotas.

Platform settings (/admin/settings)

Hardware

Registry management for GPU series (compute weight, memory, Ray pin, Slurm constraint, total GPU count) and profiles (shape + tuning overrides). Changes take effect hot (each instance pulls on its refresh interval).

Schedules

Per-series daily run windows and enforcement switches: no dequeuing outside the window, running jobs paused after a grace period (checkpoint preserved), automatic resume when the window opens.

Other

Deployment-level settings such as Playground availability scope, plugin governance switches, and diagnostics model configuration.

Audit (/admin/audit)

Audit trail of all sensitive operations: who changed quotas / roles / the hardware registry and when, whose job was stopped, which plugin was published or disabled. Filterable by actor / type / time.

Usage (/usage)

GPU-hour statistics: aggregated by user / GPU series / day, with daily reports generated automatically. This is the basis for quota adjustments.

Maintenance mode

The maintenance switch at the top of the admin page = sf admin maintenance drain/resume: drain the cluster (jobs paused, checkpoints preserved) → upgrade → resume (training auto-continues). The status page shows whether the cluster is safe to restart.