Define a workload and run the recommender.
Coastline simulates feasible GPU configurations and ranks them by the selected policy.Simulating & ranking…
| # | Layout | Batch | Throughput | Est. time | Energy |
|---|
| ID | Model | GPUs | Batch | Epochs | Duration | Power | Arrival | |
|---|---|---|---|---|---|---|---|---|
| Queue is empty — add a job above, or import a CSV in admin mode. | ||||||||
Runs the queue on the sysadmin-declared cluster and reports per-job + cluster metrics. CSV import accepts multiple trace schemas (flexible column aliases).
Pick a configuration and one or more models.
Each model predicts the same config so you can compare them directly.Running each model…
| Model | Throughput | Est. time | Power/GPU | Energy |
|---|
Pick a workload — model, fine-tuning method, sequence length, batch, epochs, dataset size. Set the hardware budget (either a single Total GPUs number, or Nodes × GPUs / node). Pick a policy: Multi-objective ranks candidates by a weighted mix of throughput and power (Balanced / Performance / Energy-saver presets), Minimum GPUs returns the fewest GPUs that still satisfy feasibility.
The Prediction model controls which simulator estimates throughput + power for each candidate: Kavier (analytical, fast, calibrated on the 4-model set) or one of 10 data-driven ML models. Cache lookup returns exact-match historical runs (~0% MdAPE when the workload is in the dataset; nothing otherwise).
Click Recommend configuration. Coastline generates a feasibility-filtered grid of candidates, simulates each one, ranks them, and shows the top results.
Each row in the Recommendations table has a small Schedule button that appends that configuration to the workload queue. Kavier's per-GPU power for the workload is captured at scheduling time so the cluster-wide energy summary reflects the real workload.
The queue stores the four fields a FIFO scheduler needs: request ID, arrival, num_gpus, predicted duration. Use the inline form to add a single job, or click Admin → Import CSV to bulk-load a trace. Column aliases tolerated: submission_time or arrival_time for arrival; num_gpus or number_gpus for GPU count; duration_ms, duration_s, or predicted_duration_s for duration. Optional columns: request_id, llm_model, fine_tuning_method, batch_size, power_watts_per_gpu.
Run cluster (FIFO) simulates the queue running on the sysadmin-declared cluster (see the masthead readout). Strict head-of-line FIFO; oversized jobs (more GPUs than the cluster has) are skipped defensively. Per-job: start / end / wait / completion time + energy. Cluster-wide: total runtime, average wait, average JCT, total energy. Per-GPU power comes from Kavier when the job's full workload config is known, otherwise a 350 W/GPU placeholder.
The run also draws a Cluster timeline — GPUs allocated over time (against the dashed capacity ceiling) above jobs-in-queue over time, on a shared axis. Hover or focus the chart and use the arrow keys to read GPUs in use and queue depth at any moment.
Pick one concrete configuration (model + method + GPU + tokens + batch + layout) and check the predictors you want to compare. Each runs the same config in an isolated subprocess and reports throughput / runtime / power / energy. Used to compare data-driven vs analytical predictors on the same workload (the thesis Exp1 comparison, one row at a time).
Every action — recommend, schedule, queue add/remove/run, errors — is logged at the bottom of the page with timestamp + level (info / ok / err). Capped at 50 entries; the Clear button resets it. Toast banners fade after 5 seconds, but the log keeps a permanent record so failures are never lost.
GET /api/health · GET /api/infrastructure ·
POST /api/recommend · POST /api/predict ·
GET|POST /api/queue · DELETE /api/queue/{id} ·
POST /api/admin/run · POST /api/admin/import ·
POST /api/admin/clear