bloomchat: the training recipe behind SambaNova's 176B multilingual chat model

The repository is a transparency artifact, not a runnable training pipeline

The bloomchat repository contains the data preparation, tokenization, training and inference code for BLOOMChat-176B-v1, a 176 billion parameter multilingual chat model that is instruction tuned from BLOOM (176B) on assistant-style conversation datasets and supports conversation, question answering, and generative answers in multiple languages. The purpose of publishing it is stated in the training section, where the README explains that the models were trained on SambaNova's in-house Reconfigurable Dataflow Unit, and that the scripts will not work for training on GPU, however we want to give better insight and transparency on the hyper-parameters that were used to train this model. That is a candid framing. You are reading the recipe to understand the setup, not to rerun it. The repository layout matches, with `data_prep/`, `tokenization_prep/`, `training/`, and `rdu_quick_start/` directories, plus a `docs/` folder, tests, and packaging files.

Data prep depends on a separate SambaNova repository

The environment setup section starts outside this repository. You clone SambaNova's Generation Data Preparation repo, create a virtual environment, set up the environment using that repo's instructions, and run `pip install datasets`. The preprocessing step then lives under `data_prep`, and the README gives the commands to run it:

`cd data_prep`, then `python prepare_oa_dolly.py` and `python subsample_openchatkit.py`

After those run, two files should exist under the `data_prep` directory, `oasst1_dolly.jsonl` and `bloom_ock_100K_each.jsonl`. The README also notes that further preprocessing had been done on the original datasets, and that the relevant code is in the `data_prep` directory. The dependency on an external repository for the tokenization stage is the pattern to notice. Much of what looks like a self-contained pipeline here actually calls into `generative_data_prep`, which means the two repositories have to be version-matched for the pipeline to behave as documented.

The preprocessing step is explicitly not fully reproducible

The README carries a disclaimer that is worth reading before you plan any replication work. It states that the OIG dataset preprocessed for BLOOMChat might not be 100% reproducible using the OIG dataset from OpenChatKit, and that the maintainers will update soon about the other steps necessary to reproduce the dataset. That single sentence changes what this repository can be used for. The model weights are on Hugging Face and are the reproducible artefact; the dataset construction is a best-effort record. The README also flags a practical detail about the file paths. The two jsonl files are referenced in the tokenization code, so the data prep commands need to be run within `tokenization_prep`, otherwise the file paths have to be changed. That kind of cross-directory coupling is a common source of silent breakage in pipeline repositories, and here it is documented rather than left to be discovered.

Tokenization is a set of bash scripts that take a repository path

The tokenization stage uses the same Generation Data Preparation repository, and the scripts that call it are under `tokenization_prep`. The bash scripts take one argument, which is the absolute path to the generation data preparation repo, and the README gives the example sequence:

`cd tokenization_prep`, then `bash tokenization_oa_dolly.sh /home/.../generative_data_prep` and `bash tokenization_openchatkit.sh /home/.../generative_data_prep`

Running those produces two directories under `tokenization_prep`, `oasst1_dolly_out` and `bloom_ock_100k_out`, and each of those contains two subdirectories. The `splits` directory holds the original text and the `hdf5` directory holds the tokenized text that gets fed into the model. Separating raw and tokenized output is a sensible choice, because it lets you inspect what the tokenizer produced before committing to a training run, and it means you can reuse the split data across experiments. The dependency list in `pyproject.toml` reflects the same stack, with `tokenizers` and `transformers == 4.27.0` pinned, along with `accelerate`, `huggingface_hub >= 0.9.0`, `pydantic`, and a Flask stack for serving.

Training is a two step recipe, and it targets hardware you probably do not have

The README is explicit that the training scripts will not work on GPU, and the scripts that were run on the RDU are under `training`. The model is run directly from Hugging Face, using a built-in wrapper provided by SambaFlow, the SDK for the RDU, and the README directs anyone interested in running models on RDUs to get in touch with SambaNova. The training data is documented as three sets, the OIG dataset from OpenChatKit, Dolly 2.0, and OASST1, and the process is described as a two step process. First a model is trained using the OIG dataset from OpenChatKit. Second, that model is trained further using Dolly 2.0 and OASST1, which produces the final model. The project is hosted on SambaNova DataScale systems using what the README calls SambaNova's Reconfigurable Dataflow Architecture.

Inference on GPU is delegated to the Bloom inference tooling

For anyone who wants to run rather than train, the README is short. You create a Python virtual environment for these packages:

pipenv --python 3.9
pipenv sync

The rest of the setup is delegated to the Hugging Face tutorial for BLOOM 176B inference, with an instruction to follow that tutorial's environment setup and stop before the BLOOM inference via command line section. The README also leaves a TODO in place, asking for instructions on how to install `deepspeed` as needed for the bloom-inference. So the practical picture is that the inference path in this repository is a pointer to another project, with a dependency gap acknowledged in the text. The packaging metadata is similarly generic, with the project name `sambanova-bloomchat`, a description calling it a standard Python template for Python based repositories, and an entry point registered under `timmins.display` pointing at `inferency.py`.

The tooling is a full Python quality stack

The badges and the configuration files show what a review-conscious project looks like. The CI is CircleCI, the Python requirement is 3.7 or newer, and pre-commit is enabled with black for code style, flake8 for pep8, bandit for security, isort for imports, and mypy for type checking. The `pyproject.toml` repeats the same set as configuration, with the isort profile set to black and a `known_first_party` entry for `sambanova_*` packages, bandit excluding the tests directory, and mypy setting `warn_return_any` and `warn_unused_configs` while excluding tests and docs. Pytest is configured with fast and slow markers, warnings turned into errors, and coverage collected over the `data_prep` and `tokenization_prep` packages with branch coverage and HTML plus XML reports. The repository also carries a `.gitleaks.toml`, which is a sensible inclusion for a project that ships scripts that fetch data from the internet. The licence is a custom one that GitHub cannot classify, with the file at the repository root, and the last push was on 2026-08-13.

Editorial conclusion

bloomchat fits a researcher or engineer who wants to study how a 176 billion parameter multilingual chat model was assembled, and who has access to SambaNova DataScale systems, because the training scripts will not run on a GPU. It is the wrong tool for a team that simply wants to run the model, since the weight host is on Hugging Face and a hosted chat space exists, and it is the wrong tool for reproducing the dataset exactly, because the README itself says the preprocessed OIG data may not be 100% reproducible. Before you plan around this repository, read the training data section and the disclaimers, and budget for the separate generative_data_prep dependency, which most of the pipeline scripts call into.

Frequently asked questions

Official sources

1. Issues
2. README
3. sambanova/bloomchat on GitHub