When I ran this locally, and added additional logging to check how much time was spent up to when GPTQ calibration is finished (so after gptq:calibrated 66 layers in 6.8s is printed), I found out that the whole part up until that took a bit more than the ~7,8 seconds the calibration takes, making me have to change the gptq seconds reservation parameter to ~25 seconds.

Not pointing this out to invalidate your submission, in fact it was super useful as a baseline to mine. Luckily the fix is easy, as I mentioned above, it didn't hurt performance much. I decided to port over the AR generation of samples for GPTQ to avoid the above hassle though, as it's a tried and already accepted method, so you could do that as well.

Thanks, this is a good point.

Our local H100 runs used GPTQ_RESERVE_MS=9000, and on those three seeds training stopped at ~591.1s with the log showing gptq:calibrated 66 layers in 6.8s, so 9s was sufficient under our script's accounting on our setup.

That said, you're right that the printed 6.8s only reflects the logged calibration call, not necessarily all GPTQ-side overhead between the end of training and the end of calibration. So for portability/re-runs on slightly different setups, a larger reserve like ~25s is safer.

This doesn't change the reported scores, but it is a useful reproducibility note. We've since also moved to AR self-generated GPTQ calibration in later branches for exactly this reason.