Skip to main content
This is the operator’s side of --profile. What a user sees is the resource model. Most of it is editable in the console at Settings → Hardware, which reloads hot: each instance picks up a change on its TUNEPLANE_HWCONFIG_REFRESH_INTERVAL.

​
GPU series

Specs and scheduling parameters for one class of GPU (h200 / h100 built-in defaults, overridable via TUNEPLANE_HARDWARE_SERIES JSON):

​
Profiles

A series, a default shape, and the tuning that shape wants. Built-in defaults, overridable with TUNEPLANE_CLUSTER_PROFILES.
Put only keys every experiment shares in overrides. They are applied in struct mode, so a key that does not exist in the target config raises rather than being ignored — and it raises for every job on that profile, not just the one you were tuning.
The console’s Admin → Platform settings → Hardware offers visual editing with hot reload (instances pull on TUNEPLANE_HWCONFIG_REFRESH_INTERVAL).

​
User quotas

TUNEPLANE_QUOTA_ENFORCE=0 downgrades the whole system to “record only, do not block” (for trial periods).

​
Storage quota

--max-storage-gb caps the total held by all of a user’s run directories (working copy + checkpoints + logs). It counts runs/<user>/; the caches (weights, datasets, Volumes) are shared platform infrastructure and are not charged to anyone — the weights one job pulls, every later job uses. They answer different questions: the quota is “who is holding too much”, the watermark is “the disk is about to fill”.

​
Schedule windows

Restrict daily run windows per GPU series (Admin → Platform settings → Schedules): Jobs paused this way resume training automatically when the window reopens.