Hyperparameter Tuning¶
Ray Tune integration — bridge between Learner and Ray Tune's training API.
LearnerTrainable ¶
Bases: Trainable
Ray Tune Trainable wrapping a tsfast Learner.
Enables Population-Based Training and other schedulers that require the class-based Trainable API.
Pass create_learner and optionally apply_config and
scheduler_fn via tune.with_parameters.
Args (via tune.with_parameters):
create_learner: factory (config) -> Learner
apply_config: optional (lrn, config) -> None that applies
mutated hyperparameters to an existing Learner for actor reuse.
If not provided, reset_config returns False (actor rebuilt).
scheduler_fn: optional factory (optimizer, total_steps) -> scheduler
for LR scheduling across training iterations. When provided,
config["n_iter"] must specify the total number of iterations.
report_metrics ¶
Wrap a Learner's log_epoch to also report metrics and checkpoints to Ray Tune.
The original log_epoch (progress bar, custom loggers, etc.) still runs;
Ray Tune reporting is added after it.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
lrn
|
a Learner instance whose |
required | |
checkpoint_every
|
int | None
|
save a checkpoint every N epochs. |
1
|
Source code in tsfast/tune.py
ray_device ¶
Detect the device assigned to this Ray worker.
Source code in tsfast/tune.py
resume_checkpoint ¶
Load checkpoint into Learner if Ray Tune is resuming this trial.
trial_resources ¶
Ray Tune resources dict packing k trials per GPU: {"cpu": n_cpus, "gpu": 1/k} (packing step 4: enforce).
k comes from the measure → decide → verify workflow in
:mod:tsfast.training.profiling (probe_gpu_saturation →
recommend_trials_per_gpu → measure_packing_curve).
Fractional GPUs are a purely logical resource — Ray bin-packs k trials onto one
device and sets CUDA_VISIBLE_DEVICES, with no memory or compute isolation. Pair
with :func:apply_gpu_quota inside the trainable for actual memory enforcement.
Source code in tsfast/tune.py
apply_gpu_quota ¶
Cap this process's CUDA caching allocator to its slice of the device (packing step 4: enforce).
Call at the top of the trainable. Makes OOM deterministic: a config fails iff it exceeds its own slice, independent of which neighbors happen to run — so a sampled (non-guaranteed) worst-case footprint degrades gracefully instead of taking down co-located trials.
The CUDA context (~0.5 GB per process on consumer cards) lives outside the torch
allocator, so it is subtracted from each slice: with k = 1/share co-located
processes the allocator caps plus the k contexts then sum to margin of device
memory. With the default context_bytes=0 the sum can exceed the device at
high k — pass the probed SaturationProbe.context_overhead_bytes (or
PackingRecommendation.context_overhead_bytes).
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
share
|
float
|
this trial's GPU fraction, e.g. |
required |
context_bytes
|
int
|
per-process CUDA context overhead from the saturation probe |
0
|
margin
|
float
|
fraction of device memory budgeted across all co-located trials |
0.9
|
device
|
CUDA device (defaults to the current one) |
None
|