0.8.0

This release lets a run choose how it uses device memory, where a deployment allows it, and documents every field a run or pipeline descriptor takes.

Headlines

Choose a run’s memory settings

A run can now set three memory settings for itself:

  • execution.rollout.memoryShare is the share of each device that a reinforcement run’s rollout engine takes.

  • config.model.weightPrecision is the precision the trained model’s weights are held in, fp32 or bf16.

  • execution.memory.offload.weights moves the weights to host memory between passes.

A run that sets none of them trains as before. A run that sets one trains under verl. Optimize refuses a run before it claims devices, and names the setting, when the deployment does not allow the setting or the value. config.model.weightPrecision is part of the configuration hash. For what each setting trades, see Memory settings.

A run records the value of each setting when you start it. training runs get shows the values a verl run trains at, and marks the ones the run set. A later change to the deployment does not change a run, its branches or its retries.

Give verl a setting directly

A run can give verl settings that change only memory and speed, in config.engineSettings, where the deployment allows each one. Use them to fit a new model to its devices. They include FSDP prefetching and padding, and the rollout engine’s batch limits, prefix caching and CUDA graphs. The settings are part of the configuration hash, and training runs get shows them with the configuration. For the settings and what each does, see Engine settings.

Other changes

  • The trainer pages document every descriptor field. New entries include kind, submissionId, smoke, execution.engine, the pipeline descriptor’s fields, the curate stage and the options of training evaluations start.