IBM experimental dataloaders

[daviswer]

This PR introduces an experimental PyTorch-native dataloader from IBM that is distributed, stateful, checkpointable, composable and rescalable. It is intended for use in large-scale model pretraining, particularly in research settings where rapid iteration between datasets may be required. It automatically and invisibly handles data sharding, shuffling, subdataset weighting, checkpoint saving and loading, and more, with minimal overhead and high throughput.

• Add experimental dataset source file
• Add experimental dataloader builder, hooked into torchtitan cfg
• Update torchtitan cfg with additional dataset arg fields
• Update train script to build experimental dataloader instead of hf depending on cfg flags
• Replace the existing C4-mini example dataset with one that matches the expected formatting for the experimental dataloader
• TODO: port over unit tests as well
• TODO: preprocessing script(s) for the new dataset format
• TODO: further cleanup/iteration

[facebook-github-bot]

Hi @daviswer!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[fegin]

This will break the usage of the existing dataloader checkpoint.

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[gokulavasan]

Thanks for the PR! Reviewing it now

[gokulavasan]

Finished one pass through the PR. Left comments to understand the code better

[gokulavasan]

For multiple (sub) datasets, would this be specified as a list of str?

[daviswer]

For multiple subdatasets, we have it set up to take a string of comma-separated names. There's an example comment in train_configs/llama3_8b.toml:

datasets = "CommonCrawl,C4,Github,Wikipedia,Books,ArXiv,StackExchange"
dataset_weights = "67,15,4.5,4.5,4.5,2.5,2"

Of course this can be changed if another format is more convenient

[gokulavasan]

i) Are all the tokens for a single doc present in one row+col?
ii) What is the need to pretokenize the data instead of storing raw text alone?

[daviswer]

1. The expected format is for each document to occupy one row in the pyarrow file. Because docs are different lengths, there's not really any consistent notion of columns anymore (or viewed another way, the doc rows all occupy the single "tokens" column of the shard file)
2. Right now we pretokenize to enable chunking - currently, we can yield portions of a document at a time, without ever having to load the whole doc into memory at once, which is helpful in the case of extremely long docs. This gets more difficult for raw text since we have to split on tokens rather than on characters, but we don't know the token boundaries until after tokenization. Support for dynamic tokenization is on the todo list though!

[gokulavasan]

From the description, it looks like only num_workers=1 is supported per rank. Thus self.rank would be sufficient in this case. Just to confirm, for num_workers > 1, do you foresee each worker storing their state from the worker process directly to local disk?

[daviswer]

Yes that's the eventual plan for supporting num_workers > 1

[gokulavasan]

Can you elaborate on why "shard" sublist must have the same length? For example, when the input dataset folder is created with arrow files inside - does each file correspond to a shard? In that case, is each file expected to have the same length?

[daviswer]

I suppose it's not strictly necessary that shards have the same length, we just take that shortcut because this function is only ever used to reassign per-worker data structures from load_worldsize to worldsize. So far we've been able to assume that workers all hold the same fundamental data structures so this hasn't been an issue. This doesn't get called on any actual data shard files - apologies for unclear naming/commenting here

[gokulavasan]

Does the sharded list is a basically a list of list of indices? And does this return a list of indices that is owned by this rank? If that is the case, could this be a really large list for huge datasets?

Update: Looking at the code further down, this seems to be for in-memory buffers instead of sample/doc indices?

[daviswer]

Yes your update is correct. We never actually materialize the full list of doc indices owned by each worker, because as you say, this gets very large.

[gokulavasan]

For all parameters that are set as reshard params, this logic figures out which subset of indices in that list of ranges that it owns? Apart from indices assigned to a worker, what are the other states tend to lend well with re-sharding?

And looks like state params are discarded during reshard? Would RNG state be a typical state param?

[daviswer]

Yes RNG state is a typical state param. Reshard params are generally buffers or sets of stateful subworkers

[gokulavasan]

So this function doesn't place any restriction on what world_size could be in relation to load_world_size - is that correct?

[daviswer]

That's correct

[gokulavasan]

once the dataset runs out of data, how is the remaining items in the buffer drained?

[daviswer]

The expectation is a sublayer that never runs out - currently, we just loop over epochs forever

[gokulavasan]

Just to confirm, once a shard is chosen, all the docs within that shard is visited in random order but that shard is exhausted before moving to the next shard?

[daviswer]

Technically, once a shard is chosen, all the docs within the fraction of the shard owned by this worker are visited. But yes that's broadly correct.

[gokulavasan]

I see no reshard_params, so this dataset doesn't support resharding?

[daviswer]

Correct, this one particular dataset needs to sit under a Scalable_Shard_Dataset to support resharding

[gokulavasan]

Finished one pass through the PR. Left comments to understand the code better

[gokulavasan]

Finished one pass through the PR. Left comments to understand the code better

[daviswer]

Thanks for taking a look! Left a bunch of responses, hopefully this brings clarity

[andrewkho]

nit: can we stick with Camel case and remove underscores between words?

[daviswer]

Updating the dataloader to match the latest version in our public repo. Re-syncs to latest main, and incorporates many previously discussed features:

• Remove dependence on the separate metadata "count file" in the dataset directory
• Support n_workers > 1. This is accomplished by shunting all path/rank-dependent setup out of initialization and into a new setup() method, which runs after init but before any other op
• Support HF-style parquet raw text datasets, with tokenization on the fly (for reasonably sized documents/shardfiles)
• Support non-flat data directories: all legal files under the specified location will be included, regardless of depth or location. Enables simple weight-free dataset mixing via a single StreamingDocDataset on the parent directory
• SamplingDataset and ScalableShardDatasetare now implemented as proper _WrapperDatasets, reflecting the intended modular usage
• Fix Weird_Separated_Camel_Case naming convention in favor of ProperClassNaming
• Allow PreloadBufferDataset to shrink back down to the desired size after rescaling to a smaller number of workers