OOMptimizer: bucketing batch size profiles to make GPUs go 🔥

[pzelasko]

What does this PR do ?

Major contributions:

• Canary-1B can be trained with 5x larger batch sizes compared to our earlier baseline. It maxes out GPU utilization (memory, compute, and power consumption wise). As a result the mean training step time is 2.75x longer, resulting in a training throughput of 5x / 2.75x ~= 180% of the original recipe. I managed to reproduce Canary-1B in about 40k training steps on the same number of GPUs, changing only bucketing/batch size settings using new features in this PR.
  • Update: actually reproduces Canary-1B in half of the training time with slightly improved WERs.
  • Update 2: also reproduced Canary-1B in the original training time using 4x less GPUs.
• Note: these tools are applicable to all ASR models and can easily be made applicable to any (audio|text)->(audio|text) model.
• OOMptimizer script that given a model config and bucket bins, finds the optimal batch sizes for each bucket bin. Optimal = maximum GPU utilization.
• 2D bucketing with a dedicated estimation script and dataloading support. Allows to stratify sampling by input and output sequence lengths, resulting in improved training throughput for encoder-decoder models.
• Ability to filter out examples exceeding a tokens-per-second threshold during training (e.g. some datasets have very severe outliers, 20x more tokens than median).
• Enables concurrent bucketing, speeding up the start of the training loop (in my experiments reduces the wait time from ~2min to ~20 seconds). With this setting, the bucketing buffer is filled asynchronously and lets the sampler draw batches when it's at least 10% filled, so the training can start faster.
• Documentation and examples of usage of the new features.
• Unit and integration for the new features.

Collection: ASR

Changelog

• Add specific line by line info of high level changes in this PR.

Usage

• You can potentially add a usage example below

# Add a code snippet demonstrating how to use this 

GitHub Actions CI

The Jenkins CI system has been replaced by GitHub Actions self-hosted runners.

The GitHub Actions CI will run automatically when the "Run CICD" label is added to the PR.
To re-run CI remove and add the label again.
To run CI on an untrusted fork, a NeMo user with write access must first click "Approve and run".

Before your PR is "Ready for review"

Pre checks:

• Make sure you read and followed Contributor guidelines
• Did you write any new necessary tests?
• Did you add or update any necessary documentation?
• Does the PR affect components that are optional to install? (Ex: Numba, Pynini, Apex etc)
  • Reviewer: Does the PR have correct import guards for all optional libraries?

PR Type:

• New Feature
• Bugfix
• Documentation

If you haven't finished some of the above items you can still open "Draft" PR.

Who can review?

Anyone in the community is free to review the PR once the checks have passed.
Contributor guidelines contains specific people who can review PRs to various areas.

Additional Information

• Related to # (issue)

[titu1994]

Very interesting approach to maximize the batch size, minor comments but it looks good.

[titu1994]

Needs a bit of doc for all the cases

[titu1994]

What does relative gap mean?

[pzelasko]

Added doc to explain

[titu1994]

What's this used for ? Might as well use hydra with a dataclass than click

[pzelasko]

Right, I went with click out of an old habit. This auto-parses bucket duration bins [1,2,3,4] to list of floats.

[titu1994]

You can use restore_from(..., return_config=True)...

[pzelasko]

Ended up going with --module-name and --config-path like discussed offline. It works well.

[pzelasko]

I realized we can make a post-processing pass on the max_batch_size list and merge buckets with identical batch sizes. Merging buckets will improve randomization. If the original num_buckets was large enough to trigger merging, that approach will lead us to an optimal number of buckets.

[galv]

It is theoretically possible to do these three lines in a cuda stream capture with "relaxed" mode to avoid doing any sort of GPU-side computation. However, it will work only for code that has no data-dependent shapes (like torch.nonzero). Note that I haven't run your code and don't know how slow it is right now.

[pzelasko]

It is surprisingly fast - for ~30 buckets the total runtime seems within 1-2 minutes. If CUDA graph "relaxed" mode would be "ok" with skipping NCCL ops then we might even incorporate this as a training time calibration (which we can't do now because these steps trigger NCCL syncs, if one GPU dies and other doesn't, it would hang). But even as-is I think this is a viable approach.

[pzelasko]

For lots of buckets (i.e. 100+) it takes a while. We should try the "relaxed" CUDA graph trick, and if it works, make a follow up PR.

[galv]

just curious how long "a while" is.

The relaxed cuda graph trick definitely won't always work unfortunately... I spoke with someone who works on end-to-end training and he told me that there is a cudaStreamSynchronize() is the torch.amp.GradScaler, which will prevent using relaxed stream capture for models that do gradient scaling in mixed precision training.

[pzelasko]

I think it's around 15 minutes for 150 buckets.

[ko3n1g]

Suggested change

	--prompt '[{"role":"user","slots":{"source_lang":"en","target_lang":"en","task":"asr","pnc":"yes"}}]' \
	--prompt \'[{"role":"user","slots":{"source_lang":"en","target_lang":"en","task":"asr","pnc":"yes"}}]\' \

I think that should do the trick @pzelasko

[pzelasko]

Thanks... I was seriously scratching my head with this one lol.

[pzelasko]

It also resulted with an error. I am disabling the check so this PR may go in. If we can figure out how to work around the quoting issue, I will enable the check in a follow up PR.

[ko3n1g]

hope you don't mind my comments!

[galv]

Forgot to hit approve last time.

[ko3n1g]

will merge this after pipeline pass