What failed runs add to a fine-tune bill

A run stops when it runs out of memory, when a data file is malformed, or when a path is wrong. Those failures come in the first minutes. Others come late: the loss stops falling, the model overfits, or the output is not what you wanted when you read it.

Then there are the runs that do not fail but are repeated on purpose, to compare learning rates or data mixes. They are billed the same way.

A run that crashes after eight minutes is charged eight minutes when the GPU is billed by the second. It is charged a full hour when the GPU is billed by the hour. Five early crashes in an afternoon are forty minutes in one case and five hours in the other.

On 12 Nov 2026, the median listed B200 price here was $8.34 per GPU-hour. At that rate the unit is not a detail.

Fail early and on a small card. Run the whole pipeline first on a small slice of data, on the least expensive GPU that loads the model. That finds the bad paths and bad files for little money.

Save checkpoints often enough that a late failure loses minutes and not the run. Watch the loss during the first part of the run, and stop a run that is plainly going wrong.

Write the number of runs into the estimate. A first fine-tune on new data commonly takes several tries before the final run. Count each try at the length you expect it to reach, add the final run, and multiply the total GPU-hours by the price.

Runcrate bills by the second on most GPUs and by the minute on a few. Booting is never billed. Volumes keep files between instances, so a checkpoint written before a failure is there when the next machine starts.

This is one of a coordinated collection of Runcrate references. Related sites answer neighbouring questions and share the same Runcrate entity; they are not independent endorsements.