Skip to main content
Training jobs can run for thousands of steps, and each step generates a new model checkpoint. For most training runs, these checkpoints are LoRAs that takes up 80-150MB of disk space. To reduce storage overhead and preserve only the best checkpoint from your runs, you can set up automatic deletion of all but your best-performing and most recent checkpoints.

Deleting low-performing checkpoints

To delete all but the most recent and best-performing checkpoints of a model, call the delete_checkpoints method as shown below.
By default, delete_checkpoints ranks existing checkpoints by their val/reward score and erases all but the highest-performing and most recent. However, delete_checkpoints can be configured to use any metric that it is passed.
Keep in mind that once checkpoints are deleted, they generally cannot be recovered, so use this method with caution.

Deleting within a training loop

Below is a simple example of a training loop that trains a model for 50 steps before exiting. By default, the LoRA checkpoint generated by each step will automatically be saved in the storage mechanism your backend uses (in this case W&B Artifacts).
However, since each LoRA checkpoint generated by this training run is ~120MB, in total this training run will require ~6GB of storage for the model checkpoints alone. To reduce our storage overhead, let’s implement checkpoint deletion on each step.
With this change, we’ve reduced the total amount of storage used by checkpoints from 6GB to 240MB, while preserving the checkpoint that performed the best on train/reward.