- Models — the models available to dispatch
- On-Demand Capacity — purchasable GPU types with their current
$/GPU-hour, and whether a run starts now or queues
--output json for machine-readable output. For pricing mechanics, see Billing.
The weight cache
Runs boot from a cluster-side weight cache and never download weights at start-up. A model that isn’t cached can’t be dispatched — a config naming one fails at dispatch, before any GPU is reserved. To see only the cached models for a reserved cluster you hold:GPU types
To list every GPU type you can dispatch on:--gpu-type, or let the platform pick. Placement favours clusters that already have your model cached, since a cache miss means a full weight download.
Choosing a model
Validate first. Start with the smallest model that exercises your environment end to end — a short run on a small model catches config and reward-function bugs for a fraction of the cost. Keepmax_steps low and watch that the loss or reward moves at all.
Then scale. Once the environment is proven, move to the model you actually care about and raise batch_size and group_size for a more stable reward signal. MoE models with small active parameter counts give strong performance per GPU-hour.
Size the run with the [deployment] block — see Full Fine-Tuning for single-node and multi-node examples.
Thinking mode
Some model families support a thinking mode that produces extended chain-of-thought before the final answer. It tends to help on tasks that benefit from multi-step reasoning — math, code, logic — at the cost of longer completions, which means more tokens generated per rollout and more wall-clock per step. Thinking is controlled through the renderer and sampling config; see prime-rl Configuration.Billing
How GPU-hours are metered and where rates come from.
Full Fine-Tuning
Config schema and dispatch reference.