|
|
2 gadi atpakaļ | |
|---|---|---|
| .. | ||
| data | 4 gadi atpakaļ | |
| img | 4 gadi atpakaļ | |
| qa | 4 gadi atpakaļ | |
| .dockerignore | 4 gadi atpakaļ | |
| .gitmodules | 6 gadi atpakaļ | |
| Dockerfile | 4 gadi atpakaļ | |
| LICENSE.md | 7 gadi atpakaļ | |
| README.md | 2 gadi atpakaļ | |
| convert.py | 4 gadi atpakaļ | |
| convert_test.py | 4 gadi atpakaļ | |
| dataloading.py | 4 gadi atpakaļ | |
| feature_spec.py | 4 gadi atpakaļ | |
| full_test_suite.md | 4 gadi atpakaļ | |
| inference.py | 3 gadi atpakaļ | |
| load.py | 4 gadi atpakaļ | |
| ncf.py | 2 gadi atpakaļ | |
| neumf.py | 4 gadi atpakaļ | |
| neumf_constants.py | 4 gadi atpakaļ | |
| prepare_dataset.sh | 4 gadi atpakaļ | |
| requirements.txt | 4 gadi atpakaļ | |
| test_cases.sh | 4 gadi atpakaļ | |
| test_dataset.sh | 4 gadi atpakaļ | |
| test_featurespec_correctness.py | 4 gadi atpakaļ | |
| transcode.py | 4 gadi atpakaļ | |
| utils.py | 4 gadi atpakaļ | |
| verify_dataset.sh | 7 gadi atpakaļ | |
This repository provides a script and recipe to train the Neural Collaborative Filtering (NCF) model to achieve state-of-the-art accuracy. The content of this repository is tested and maintained by NVIDIA.
The NCF model focuses on providing recommendations, also known as collaborative filtering with implicit feedback. The training data for this model should contain binary information about whether a user interacted with a specific item. NCF was first described by Xiangnan He, Lizi Liao, Hanwang Zhang, Liqiang Nie, Xia Hu and Tat-Seng Chua in the Neural Collaborative Filtering paper.
The implementation in this repository focuses on the NeuMF instantiation of the NCF architecture. We modified it to use dropout in the FullyConnected layers. This reduces overfitting and increases the final accuracy. Training the other two instantiations of NCF (GMF and MLP) is not supported.
Contrary to the original paper, we benchmark the model on the larger ML-20m dataset instead of using the smaller ML-1m dataset because we think this is more realistic for production type environments. However, using the ML-1m dataset is also supported.
This model is trained with mixed precision using Tensor Cores on Volta, Turing, and the NVIDIA Ampere GPU architectures. Therefore, researchers can get results 2x faster than training without Tensor Cores while experiencing the benefits of mixed precision training.
This model is based mainly on Embedding and FullyConnected layers. The control flow is divided into two branches:
The outputs from those branches are concatenated and fed to the final FullyConnected layer with sigmoid activation. This can be interpreted as a probability of a user interacting with a given item.
Figure 1. The architecture of a Neural Collaborative Filtering model. Taken from the Neural Collaborative Filtering paper.
The following features were implemented in this model:
The following performance optimizations were implemented in this model:
This model supports the following features:
| Feature | NCF PyTorch | |:---:|:--------:| | Automatic Mixed Precision (AMP) | Yes | | Multi-GPU training with Distributed Data Parallel (DDP) | Yes | | Fused Adam | Yes |
Mixed precision is the combined use of different numerical precisions in a computational method. Mixed precision training offers significant computational speedup by performing operations in half-precision format while storing minimal information in single-precision to retain as much information as possible in critical parts of the network. Since the introduction of tensor cores in Volta, and following with both the Turing and Ampere architectures, significant training speedups are experienced by switching to mixed precision -- up to 3x overall speedup on the most arithmetically intense model architectures. Using mixed precision training previously required two steps:
The ability to train deep learning networks with lower precision was introduced in the Pascal architecture and first supported in CUDA 8 in the NVIDIA Deep Learning SDK.
For information about:
Mixed precision training is turned off by default. To turn it on issue the --amp flag to the main.py script.
TensorFloat-32 (TF32) is the new math mode in NVIDIA A100 GPUs for handling the matrix math, also called tensor operations. TF32 running on Tensor Cores in A100 GPUs can provide up to 10x speedups compared to single-precision floating-point math (FP32) on Volta GPUs.
TF32 Tensor Cores can speed up networks using FP32, typically with no loss of accuracy. It is more robust than FP16 for models which require a high dynamic range for weights or activations.
For more information, refer to the TensorFloat-32 in the A100 GPU Accelerates AI Training, HPC up to 20x blog post.
TF32 is supported in the NVIDIA Ampere GPU architecture and is enabled by default.
This section describes how you can train the DeepLearningExamples RecSys models on your own datasets without changing the model or data loader and with similar performance to the one published in each repository. This can be achieved thanks to Dataset Feature Specification, which describes how the dataset, data loader and model interact with each other during training, inference and evaluation. Dataset Feature Specification has a consistent format across all recommendation models in NVIDIA’s DeepLearningExamples repository, regardless of dataset file type and the data loader, giving you the flexibility to train RecSys models on your own datasets.
Data flow can be described abstractly: Input data consists of a list of rows. Each row has the same number of columns; each column represents a feature. The columns are retrieved from the input files, loaded, aggregated into channels and supplied to the model/training script.
FeatureSpec contains metadata to configure this process and can be divided into three parts:
Specification of how data is organized on disk (source_spec). It describes which feature (from feature_spec) is stored in which file and how files are organized on disk.
Specification of features (feature_spec). Describes a dictionary of features, where key is feature name and values are features’ characteristics such as dtype and other metadata (for example, cardinalities for categorical features)
Specification of model’s inputs and outputs (channel_spec). Describes a dictionary of model’s inputs where keys specify model channel’s names and values specify lists of features to be loaded into that channel. Model’s channels are groups of data streams to which common model logic is applied, for example categorical/continuous data, user/item ids. Required/available channels depend on the model
The FeatureSpec is a common form of description regardless of underlying dataset format, dataset data loader form and model.
The typical data flow is as follows:
Fig.1. Data flow in Recommender models in NVIDIA Deep Learning Examples repository. Channels of the model are drawn in green
As an example, let’s consider a Dataset Feature Specification for a small CSV dataset.
feature_spec:
user_gender:
dtype: torch.int8
cardinality: 3 #M,F,Other
user_age: #treated as numeric value
dtype: torch.int8
user_id:
dtype: torch.int32
cardinality: 2655
item_id:
dtype: torch.int32
cardinality: 856
label:
dtype: torch.float32
source_spec:
train:
- type: csv
features:
- user_gender
- user_age
files:
- train_data_0_0.csv
- train_data_0_1.csv
- type: csv
features:
- user_id
- item_id
- label
files:
- train_data_1.csv
test:
- type: csv
features:
- user_id
- item_id
- label
- user_gender
- user_age
files:
- test_data.csv
channel_spec:
numeric_inputs:
- user_age
categorical_user_inputs:
- user_gender
- user_id
categorical_item_inputs:
- item_id
label_ch:
- label
The data contains five features: (user_gender, user_age, user_id, item_id, label). Their data types and necessary metadata are described in the feature specification section.
In the source mapping section, two mappings are provided: one describes the layout of the training data, the other of the testing data. The layout for training data has been chosen arbitrarily to showcase the flexibility. The train mapping consists of two chunks. The first one contains user_gender and user_age, saved as a CSV, and is further broken down into two files. For specifics of the layout, refer to the following example and consult the glossary. The second chunk contains the remaining columns and is saved in a single file. Notice that the order of columns is different in the second chunk - this is alright, as long as the order matches the order in that file (that is, columns in the .csv are also switched)
Let’s break down the train source mapping. The table contains example data color-paired to the files containing it.
The channel spec describes how the data will be consumed. Four streams will be produced and available to the script/model. The feature specification does not specify what happens further: names of these streams are only lookup constants defined by the model/script. Based on this example, we can speculate that the model has three input channels: numeric_inputs, categorical_user_inputs, categorical_item_inputs, and one output channel: label. Feature names are internal to the FeatureSpec and can be freely modified.
In order to train any Recommendation model in NVIDIA Deep Learning Examples one can follow one of three possible ways:
One delivers already preprocessed dataset in the Intermediary Format supported by data loader used by the training script (different models use different data loaders) together with FeatureSpec yaml file describing at least specification of dataset, features and model channels
One uses a transcoding script
One delivers dataset in non-preprocessed form and uses preprocessing scripts that are a part of the model repository. In order to use already existing preprocessing scripts, the format of the dataset needs to match the one of the original datasets. This way, the FeatureSpec file will be generated automatically, but the user will have the same preprocessing as in the original model repository.
The Dataset Feature Specification consists of three mandatory and one optional section:
feature_spec provides a base of features that may be referenced in other sections, along with their metadata.
Format: dictionary (feature name) => (metadata name => metadata value)<br>
source_spec provides information necessary to extract features from the files that store them.
Format: dictionary (mapping name) => (list of chunks)<br>
channel_spec determines how features are used. It is a mapping (channel name) => (list of feature names).
Channels are model specific magic constants. In general, data within a channel is processed using the same logic. Example channels: model output (labels), categorical ids, numerical inputs, user data, and item data.
metadata is a catch-all, wildcard section: If there is some information about the saved dataset that does not fit into the other sections, you can store it here.
The following section lists the requirements in order to start training the Neural Collaborative Filtering model.
This repository contains a Dockerfile that extends the PyTorch NGC container and encapsulates some dependencies. Aside from these dependencies, ensure you have the following components:
For more information about how to get started with NGC containers, refer to the following sections from the NVIDIA GPU Cloud Documentation and the Deep Learning Documentation:
Running PyTorch
For those unable to use the PyTorch NGC container, to set up the required environment or create your own container, refer to the versioned NVIDIA Container Support Matrix.
To train your model using mixed or TF32 precision with Tensor Cores or using FP32, perform the following steps using the default parameters of the NCF model on the ML-20m dataset. For the specifics concerning training and inference, refer to the Advanced section.
Clone the repository.
git clone https://github.com/NVIDIA/DeepLearningExamples
cd DeepLearningExamples/PyTorch/Recommendation/NCF
Build an NCF PyTorch Docker container.
After Docker is set up, you can build the NCF image with:
docker build . -t nvidia_ncf
The NCF PyTorch container can be launched with:
docker run --runtime=nvidia -it --rm --ipc=host -v ${PWD}/data:/data nvidia_ncf bash
This will launch the container and mount the ./data directory as a volume to the /data directory inside the container.
Any datasets and experiment results (logs, checkpoints etc.) saved to /data will be accessible
in the ./data directory on the host.
Download the data from https://grouplens.org/datasets/movielens/20m/ and put it in /data/ml-20m/ml-20m.zip.
Preprocessing consists of sorting the data, dropping the duplicates, renumbering users and items, selecting last interaction of each user to include in the test set, then randomly generating negative test set members (scoring candidates). The preprocessed train and test data is then saved in PyTorch binary format to be loaded just before training.
Note: Preprocessing requires PyTorch and should therefore be run inside the Docker container.
To preprocess the ML-20m dataset, you can run:
./prepare_dataset.sh
Note: This command will return immediately without downloading anything if the data is already present in the /data directory.
This will store the preprocessed training and evaluation data in the /data directory so that it can be later
used to train the model (by passing the appropriate --data argument to the ncf.py script).
After the Docker container is launched, the training with the default hyperparameters (suitable for a DGX-1V or DGX A100 with 8 GPUs) can be started with:
python -m torch.distributed.launch --nproc_per_node=8 --use_env ncf.py --data /data/cache/ml-20m --checkpoint_dir /data/checkpoints/
This will result in a checkpoint file being written to /data/checkpoints/model.pth.
The trained model can be evaluated by passing the --mode test flag to the run.sh script:
python -m torch.distributed.launch --nproc_per_node=1 --use_env ncf.py --data /data/cache/ml-20m --mode test --load_checkpoint_path /data/checkpoints/model.pth
The following sections provide greater details of the dataset, running training and inference, and the training results.
The ncf.py script contains most of the training and validation logic. Data loading and preprocessing code is located in dataloading.py.
The model architecture is defined in neumf.py. Some initial data preprocessing is located in convert.py.
The logger directory contains simple bookkeeping utilities for storing training results.
The transcode.py script enables transcoding data from a CSV containing preprocessed data to a format accessible by the model.
To view the full list of available options and their descriptions, use the -h or --help command-line option, for example:
python ncf.py --help
The following example output is printed when running the sample:
usage: ncf.py [-h] [--data DATA] [--feature_spec_file FEATURE_SPEC_FILE] [-e EPOCHS] [-b BATCH_SIZE] [--valid_batch_size VALID_BATCH_SIZE] [-f FACTORS]
[--layers LAYERS [LAYERS ...]] [-n NEGATIVE_SAMPLES] [-l LEARNING_RATE] [-k TOPK] [--seed SEED] [--threshold THRESHOLD] [--beta1 BETA1] [--beta2 BETA2]
[--eps EPS] [--dropout DROPOUT] [--checkpoint_dir CHECKPOINT_DIR] [--load_checkpoint_path LOAD_CHECKPOINT_PATH] [--mode {train,test}]
[--grads_accumulated GRADS_ACCUMULATED] [--amp] [--log_path LOG_PATH]
Train a Neural Collaborative Filtering model
optional arguments:
-h, --help show this help message and exit
--data DATA Path to the directory containing the feature specification yaml
--feature_spec_file FEATURE_SPEC_FILE
Name of the feature specification file or path relative to the data directory.
-e EPOCHS, --epochs EPOCHS
Number of epochs for training
-b BATCH_SIZE, --batch_size BATCH_SIZE
Number of examples for each iteration. This will be divided by the number of devices
--valid_batch_size VALID_BATCH_SIZE
Number of examples in each validation chunk. This will be the maximum size of a batch on each device.
-f FACTORS, --factors FACTORS
Number of predictive factors
--layers LAYERS [LAYERS ...]
Sizes of hidden layers for MLP
-n NEGATIVE_SAMPLES, --negative_samples NEGATIVE_SAMPLES
Number of negative examples per interaction
-l LEARNING_RATE, --learning_rate LEARNING_RATE
Learning rate for optimizer
-k TOPK, --topk TOPK Rank for test examples to be considered a hit
--seed SEED, -s SEED Manually set random seed for torch
--threshold THRESHOLD, -t THRESHOLD
Stop training early at threshold
--beta1 BETA1, -b1 BETA1
Beta1 for Adam
--beta2 BETA2, -b2 BETA2
Beta1 for Adam
--eps EPS Epsilon for Adam
--dropout DROPOUT Dropout probability, if equal to 0 will not use dropout at all
--checkpoint_dir CHECKPOINT_DIR
Path to the directory storing the checkpoint file, passing an empty path disables checkpoint saving
--load_checkpoint_path LOAD_CHECKPOINT_PATH
Path to the checkpoint file to be loaded before training/evaluation
--mode {train,test} Passing "test" will only run a single evaluation; otherwise, full training will be performed
--grads_accumulated GRADS_ACCUMULATED
Number of gradients to accumulate before performing an optimization step
--amp Enable mixed precision training
--log_path LOG_PATH Path for the JSON training log
The NCF model was trained on the ML-20m dataset. For each user, the interaction with the latest timestamp was included in the test set, and the rest of the examples are used as the training data.
This repository contains the ./prepare_dataset.sh script that automatically preprocess the training and validation datasets.
By default, the preprocessed data will be placed in /data/cache.
NCF supports all datasets that include a Feature Specification file and are properly formatted. For details, refer to the BYO dataset section.
To preprocess and train on the ML-1m dataset run:
./prepare_dataset.sh ml-1m
python -m torch.distributed.launch --nproc_per_node=8 --use_env ncf.py --data /data/cache/ml-1m
This implementation supports using other datasets thanks to BYO dataset functionality. The BYO dataset functionality allows users to plug in their dataset in a common fashion for all Recommender models that support this functionality. Using BYO dataset functionality, the user does not have to modify the source code of the model thanks to the Feature Specification file. For general information on how BYO dataset works, refer to the BYO dataset overview section.
There are three ways to plug in user's dataset:
1. Provide an unprocessed dataset in a format matching the one used by ml-20m, then use ml-20m's preprocessing. Feature Specification file is then generated automatically.
The required format of the user's dataset is:
user_id, item_id and timestampThe correct torch.tensor dataset files together with the Feature Specification yaml file will be generated automatically by preprocessing script.
The following example shows how to use this way of plugging a user's dataset:
Build the NCF image with:
docker build . -t nvidia_ncf
Launch the container with:
docker run --runtime=nvidia -it --rm --ipc=host -v ${PWD}/data:/data nvidia_ncf bash
Inside the container run:
./prepare_dataset.sh like_movielens
This will preprocess the data/like_movielens/ratings.csv file and save the output in data/cache/like_movielens
To run the training on 1 GPU:
python -m torch.distributed.launch --nproc_per_node=1 --use_env ncf.py --data /data/cache/like_movielens
To run the training on 8 GPUs
python -m torch.distributed.launch --nproc_per_node=8 --use_env ncf.py --data /data/cache/like_movielens
One can also add direct support for your dataset in the prepare_dataset.sh and load.py scripts.
This model defines three channels, each accepting a single feature:
The training script expects two mappings:
As this NeuMF implementation computes list ranking metrics, the testing set actually consists of lists of candidates. Usually, all entries in a list share the same user id, although this is not mandatory. All entries from a given list must appear consecutively in the testing set. List boundaries are not marked in the testing set. All lists must have the same length. This length must be set by the metadata:test_samples_per_series parameter in the Feature Specification yaml file.
There are the following constraints of BYO dataset functionality for this model:
The name of the training script is ncf.py. Because of the multi-GPU support, it should always be run with the torch distributed launcher like this:
python -m torch.distributed.launch --nproc_per_node=<number_of_gpus> --use_env ncf.py --data <path_to_dataset> [other_parameters]
The main result of the training are checkpoints stored by default in /data/checkpoints/. This location can be controlled
by the --checkpoint_dir command-line argument.
The validation metric is Hit Rate at 10 (HR@10) with 100 test negative samples. This means that for each positive sample in the test set, 100 negatives are sampled. All resulting 101 samples are then scored by the model. If the true positive sample is among the 10 samples with the highest scores we have a "hit," and the metric is equal to 1; otherwise, it's equal to 0. The HR@10 metric is the number of hits in the entire test set divided by the number of samples in the test set.
Inference can be launched with the same script used for training by passing the --mode test flag:
python -m torch.distributed.launch --nproc_per_node=<number_of_gpus> --use_env ncf.py --data <path_to_dataset> --mode test [other_parameters]
The script will then:
--checkpoint_dir directoryThe performance measurements in this document were conducted at the time of publication and may not reflect the performance achieved from NVIDIA’s latest software release. For the most up-to-date performance measurements, go to NVIDIA Data Center Deep Learning Product Performance.
NCF training on NVIDIA DGX systems is very fast; therefore, in order to measure train and validation throughput, you can simply run the full training job with:
./prepare_dataset.sh
python -m torch.distributed.launch --nproc_per_node=8 --use_env ncf.py --data /data/cache/ml-20m --epochs 5
At the end of the script, a line reporting the best train throughput is printed.
Validation throughput can be measured by running the full training job with:
./prepare_dataset.sh
python -m torch.distributed.launch --nproc_per_node=8 --use_env ncf.py --data /data/cache/ml-20m --epochs 5
The best validation throughput is reported to the standard output.
The following sections provide details on how we achieved our performance and accuracy in training and inference.
Our results were obtained by following the steps in the Quick Start Guide in the PyTorch 21.04-py3 NGC container on NVIDIA DGX A100 (8x A100 40GB) GPUs.
The following table lists the best hit rate at 10 for DGX A100 with 8 A100 40GB GPUs. It also shows the time to reach this HR@10. Results are averages across 20 random seeds.
| GPUs | Batch size / GPU | Accuracy - TF32 | Accuracy - mixed precision | Time to train - TF32 | Time to train - mixed precision | Time to train speedup (TF32 to mixed precision) |
|---|---|---|---|---|---|---|
| 1 | 1048576 | 0.958925 | 0.958892 | 140.771 | 94.2386 | 1.49 |
| 8 | 131072 | 0.958938 | 0.959089 | 30.0928 | 23.7362 | 1.27 |
Our results were obtained by following the steps in the Quick Start Guide in the PyTorch 21.04-py3 NGC container on NVIDIA DGX-1 with 8x V100 16GB GPUs.
The following table lists the best hit rate at 10 for DGX-1 with 8 V100 16GB GPUs. It also shows the time to reach this HR@10. Results are averages across 20 random seeds. The training time was measured excluding data downloading, preprocessing, validation data generation and library initialization times.
| GPUs | Batch size / GPU | Accuracy - FP32 | Accuracy - mixed precision | Time to train - FP32 | Time to train - mixed precision | Time to train speedup (FP32 to mixed precision) |
|---|---|---|---|---|---|---|
| 1 | 1048576 | 0.958857 | 0.958815 | 302.443 | 145.423 | 2.08 |
| 8 | 131072 | 0.958768 | 0.959052 | 53.7044 | 34.2503 | 1.57 |
To reproduce this result, start the NCF Docker container interactively and run:
./prepare_dataset.sh
python -m torch.distributed.launch --nproc_per_node=8 --use_env ncf.py --data /data/cache/ml-20m
Our results were obtained by following the steps in the Quick Start Guide in the PyTorch 21.04-py3 NGC container on NVIDIA DGX-1 with 8x V100 32GB GPUs.
The following table lists the best hit rate at 10 for DGX-1 with 8 V100 32GB GPUs. It also shows the time to reach this HR@10. Results are averages across 20 random seeds. The training time was measured excluding data downloading, preprocessing, validation data generation and library initialization times.
| GPUs | Batch size / GPU | Accuracy - FP32 | Accuracy - mixed precision | Time to train - FP32 | Time to train - mixed precision | Time to train speedup (FP32 to mixed precision) |
|---|---|---|---|---|---|---|
| 1 | 1048576 | 0.958992 | 0.959002 | 310.467 | 153.616 | 2.02 |
| 8 | 131072 | 0.95871 | 0.958925 | 55.716 | 36.3384 | 1.53 |
To reproduce this result, start the NCF Docker container interactively and run:
./prepare_dataset.sh
python -m torch.distributed.launch --nproc_per_node=8 --use_env ncf.py --data /data/cache/ml-20m
Our results were obtained by following the steps in the Quick Start Guide in the PyTorch 21.04-py3 NGC container on NVIDIA DGX-2 with 16x V100 32GB GPUs.
The following table lists the best hit rate at 10 for DGX-2 with 16 V100 32GB GPUs. It also shows the time to reach this HR@10. Results are averages across 20 random seeds. The training time was measured excluding data downloading, preprocessing, validation data generation and library initialization times.
| GPUs | Batch size / GPU | Accuracy - FP32 | Accuracy - mixed precision | Time to train - FP32 | Time to train - mixed precision | Time to train speedup (FP32 to mixed precision) |
|---|---|---|---|---|---|---|
| 1 | 1048576 | 0.958756 | 0.958833 | 289.004 | 143.61 | 2.01 |
| 8 | 131072 | 0.958864 | 0.958806 | 52.1788 | 33.7456 | 1.55 |
| 16 | 65536 | 0.958905 | 0.958893 | 37.7075 | 27.174 | 1.39 |
To reproduce this result, start the NCF Docker container interactively and run:
./prepare_dataset.sh
python -m torch.distributed.launch --nproc_per_node=16 --use_env ncf.py --data /data/cache/ml-20m
The box plots below show the best accuracy achieved in each run. Twenty experiments were performed for each configuration.
The plots below show the validation accuracy over the course of training. One sample curve is shown for each configuration.
Results are averages over 20 runs for each configuration.
Our results were obtained by following the steps in the Quick Start Guide in the PyTorch 21.04-py3 NGC container on NVIDIA DGX A100 (8x A100 40GB) GPUs. Performance numbers (in items per second) were averaged over an entire training epoch.
| GPUs | Batch size / GPU | Throughput - TF32 (samples/s) | Throughput - mixed precision (samples/s) | Throughput speedup (TF32 to mixed precision) | Strong scaling - TF32 | Strong scaling - mixed precision |
|---|---|---|---|---|---|---|
| 1 | 1048576 | 22.59M | 34.08M | 0.66 | 1 | 1 |
| 8 | 131072 | 110.16M | 142.90M | 0.77 | 4.88 | 4.19 |
Our results were obtained by following the steps in the Quick Start Guide in the PyTorch 21.04-py3 NGC container on NVIDIA DGX-1 with 8x V100 16GB GPUs.
The following table shows the best training throughput:
| GPUs | Batch size / GPU | Throughput - FP32 (samples/s) | Throughput - mixed precision (samples/s) | Throughput speedup (FP32 to mixed precision) | Strong scaling - FP32 | Strong scaling - mixed precision |
|---|---|---|---|---|---|---|
| 1 | 1048576 | 10.42M | 21.84M | 0.48 | 1 | 1 |
| 8 | 131072 | 60.03M | 95.95M | 0.63 | 5.76 | 4.39 |
Our results were obtained by following the steps in the Quick Start Guide in the PyTorch 21.04-py3 NGC container on NVIDIA DGX-1 with 8x V100 32GB GPUs.
The following table shows the best training throughput:
| GPUs | Batch size / GPU | Throughput - FP32 (samples/s) | Throughput - mixed precision (samples/s) | Throughput speedup (FP32 to mixed precision) | Strong scaling - FP32 | Strong scaling - mixed precision |
|---|---|---|---|---|---|---|
| 1 | 1048576 | 10.14M | 20.65M | 0.49 | 1 | 1 |
| 8 | 131072 | 58.50M | 91.77M | 0.64 | 5.77 | 4.44 |
Our results were obtained by following the steps in the Quick Start Guide in the PyTorch 21.04-py3 NGC container on NVIDIA DGX-2 with 16x V100 32GB GPUs.
The following table shows the best training throughput:
| GPUs | Batch size / GPU | Throughput - FP32 (samples/s) | Throughput - mixed precision (samples/s) | Throughput speedup (FP32 to mixed precision) | Strong scaling - FP32 | Strong scaling - mixed precision |
|---|---|---|---|---|---|---|
| 1 | 1048576 | 10.90M | 22.16M | 0.49 | 1 | 1 |
| 8 | 131072 | 62.16M | 98.56M | 0.63 | 5.7 | 4.45 |
| 16 | 65536 | 92.20M | 134.91M | 0.68 | 8.46 | 6.09 |
Our results were obtained by running the inference.py script in the PyTorch 21.04 NGC container on NVIDIA DGX A100 with 1x A100 GPU.
TF32
| Batch size | Throughput Avg | Latency Avg | Latency 90% | Latency 95% | Latency 99% |
|---|---|---|---|---|---|
| 1024 | 2.96198e+06 | 0.000346 | 0.00037 | 0.000374 | 0.000383 |
| 4096 | 1.16823e+07 | 0.000351 | 0.000375 | 0.000382 | 0.000389 |
| 16384 | 4.01876e+07 | 0.000408 | 0.000442 | 0.000443 | 0.000445 |
| 65536 | 5.06161e+07 | 0.001295 | 0.001319 | 0.001321 | 0.001324 |
| 262144 | 5.62193e+07 | 0.004663 | 0.004655 | 0.00466 | 0.005091 |
| 1048576 | 5.74678e+07 | 0.018246 | 0.018258 | 0.018261 | 0.018276 |
FP16
| Batch size | Throughput Avg | Latency Avg | Latency 90% | Latency 95% | Latency 99% |
|---|---|---|---|---|---|
| 1024 | 2.9068e+06 | 0.000352 | 0.000379 | 0.000383 | 0.000401 |
| 4096 | 1.1149e+07 | 0.000367 | 0.000394 | 0.000396 | 0.000402 |
| 16384 | 4.46873e+07 | 0.000367 | 0.000391 | 0.000397 | 0.000406 |
| 65536 | 7.15357e+07 | 0.000916 | 0.001064 | 0.001068 | 0.001071 |
| 262144 | 8.02216e+07 | 0.003268 | 0.00327 | 0.003272 | 0.00338 |
| 1048576 | 8.27085e+07 | 0.012678 | 0.012685 | 0.012688 | 0.012809 |
Our results were obtained by running the inference.py script in the PyTorch 21.04 NGC container on NVIDIA DGX-1 with 1x V100 16GB GPU.
FP32
| Batch size | Throughput Avg | Latency Avg | Latency 90% | Latency 95% | Latency 99% |
|---|---|---|---|---|---|
| 1024 | 1.91315e+06 | 0.000535 | 0.000557 | 0.000565 | 0.000589 |
| 4096 | 7.4782e+06 | 0.000548 | 0.000566 | 0.000577 | 0.000718 |
| 16384 | 2.15241e+07 | 0.000761 | 0.000783 | 0.000791 | 0.000842 |
| 65536 | 2.77005e+07 | 0.002366 | 0.00242 | 0.002431 | 0.002435 |
| 262144 | 2.95251e+07 | 0.008879 | 0.008888 | 0.008895 | 0.008932 |
| 1048576 | 2.92491e+07 | 0.03585 | 0.03603 | 0.036078 | 0.036144 |
FP16
| Batch size | Throughput Avg | Latency Avg | Latency 90% | Latency 95% | Latency 99% |
|---|---|---|---|---|---|
| 1024 | 2.00172e+06 | 0.000512 | 0.000538 | 0.000546 | 0.000577 |
| 4096 | 8.08797e+06 | 0.000506 | 0.000519 | 0.000535 | 0.000569 |
| 16384 | 3.22482e+07 | 0.000508 | 0.000516 | 0.000519 | 0.000557 |
| 65536 | 5.20587e+07 | 0.001259 | 0.001265 | 0.001267 | 0.001278 |
| 262144 | 5.66404e+07 | 0.004628 | 0.004636 | 0.004638 | 0.004642 |
| 1048576 | 5.66507e+07 | 0.018509 | 0.018547 | 0.018556 | 0.018583 |
The performance measurements in this document were conducted at the time of publication and may not reflect the performance achieved from NVIDIA’s latest software release. For the most up-to-date performance measurements, go to NVIDIA Data Center Deep Learning Product Performance.
Neural Collaborative Filtering is a relatively lightweight model that trains quickly with this relatively smaller dataset, ML-20m. Because of that, the high ratio of communication to computation makes it difficult to efficiently use more than 8 GPUs. Typically, this is not an issue because when using 8 GPUs with FP16 precision, the training is sufficiently fast. However, if you’d like to scale the training to 16 GPUs and beyond, you might try modifying the model so that the communication-computation ratio facilitates better scaling. This could be done, for example, by finding hyperparameters that enable using a larger batch size or by reducing the number of trainable parameters.
In the default settings, the additional memory beyond 16GB may not be fully utilized. This is because we set the default batch size for the ML-20m dataset to 1M, which is too small to fill up multiple 32GB GPUs completely. 1M is the batch size for which we experienced the best convergence on the ML-20m dataset. However, on other datasets, even faster performance can be possible by finding hyperparameters that work well for larger batches and leverage additional GPU memory.