Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add docker image for BERT e2e inference task #455

Merged
merged 8 commits into from
Jul 16, 2024

Conversation

mattcjo
Copy link
Contributor

@mattcjo mattcjo commented Jun 27, 2024

Issue #, if available:

Description of changes:
A inference script (e2e2/test/images/bert-inference/infer.py) has been added, along with its dependencies (e2e2/test/images/bert-inference/requirements.txt), in a new docker file (e2e2/test/images/bert-training/Dockerfile.bert-inference). Building the dockerfile will produce an image that will run a BERT inference job on GPU.

The testing of the docker image took place on a g5.2xlarge instance utilizing the AMI: ami-05e885690ca33b527. The goal of the image is to run an inference workload through a BERT model. There are two inference modes: latency and throughput. These are two different modes that optimize for latency or throughput.

The results of the test show that the running the docker image starts up and executes the BERT inference job for latency optimization as expected :

docker run --rm --gpus all -e INFERENCE_MODE=latency aws-bert-inference:latest python infer.py

==========
== CUDA ==
==========

CUDA Version 12.5.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

/usr/local/lib/python3.11/dist-packages/huggingface_hub/file_download.py:1132: FutureWarning: `resume_download` is deprecated and will be removed in version 1.0.0. Downloads always resume when possible. If you want to force a new download, use `force_download=True`.
  warnings.warn(
GPU is available
Running inference in latency mode with batch size 1
Inference Mode: latency
Average time per batch: 0.0075 seconds
Throughput: 132.61 samples/second

The results of the test show that the running the docker image starts up and executes the BERT inference job for throughput optimization as expected :

docker run --rm --gpus all -e INFERENCE_MODE=throughput aws-bert-inference:latest python infer.py

==========
== CUDA ==
==========

CUDA Version 12.5.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

/usr/local/lib/python3.11/dist-packages/huggingface_hub/file_download.py:1132: FutureWarning: `resume_download` is deprecated and will be removed in version 1.0.0. Downloads always resume when possible. If you want to force a new download, use `force_download=True`.
  warnings.warn(
GPU is available
Running inference in throughput mode with batch size 8
Inference Mode: throughput
Average time per batch: 0.0129 seconds
Throughput: 619.77 samples/second

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@weicongw
Copy link
Contributor

I'm not an expert on inference tasks, but can we get the Sequence Length in the performance data? Also, how long does each inference take? Can we run multiple inferences and calculate the p50 and p99 latency?

@weicongw
Copy link
Contributor

Overall, this PR looks good to me.

@mattcjo
Copy link
Contributor Author

mattcjo commented Jul 11, 2024

I'm not an expert on inference tasks, but can we get the Sequence Length in the performance data? Also, how long does each inference take? Can we run multiple inferences and calculate the p50 and p99 latency?

@weicongw So the sequence length will always be 128. As far as p50 and p99 latency, I'm not sure how much insight we'd gain from these metrics based on how short running of a test it is.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thinking just name this as Dockerfile, following the current pattern neuron and nvidia images

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm good with that. Added on a prefix as I wasn't sure what the directory structure would like at first.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done :)

# Install Python 3.11
RUN apt-get update && apt-get install -y \
software-properties-common && \
add-apt-repository ppa:deadsnakes/ppa && \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mattcjo @weicongw what are your opinions of different ways of installing dependencies like python in these images? I see weicong's is building from source in the neuron image

# install Python
RUN wget -q https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tgz \
&& tar -xzf Python-$PYTHON_VERSION.tgz \
&& cd Python-$PYTHON_VERSION \
&& ./configure --enable-shared --prefix=/usr/local \
&& make -j $(nproc) && make install \
&& cd .. && rm -rf ../Python-$PYTHON_VERSION* \
&& ln -s /usr/local/bin/pip3 /usr/bin/pip \
&& ln -s /usr/local/bin/$PYTHON /usr/local/bin/python \
&& ${PIP} --no-cache-dir install --upgrade \
pip \
setuptools

do you see a benefit in being consistent for all our images?

Copy link
Contributor Author

@mattcjo mattcjo Jul 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, in theory, I prefer installing directly from source as that gives us the most control and consistency. My main issue with it is that you need to specify the minor version as well. I feel like the system package manager does a good job and is far easier to use, but would like to hear everyone's take. I can make arguments for both.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One other thing to add on... My main point in support of installing from source is that there are sometime new features and optimizations introduced in minor releases. This has the potential of leading to different performance results between minor versions. The likelihood of this happening, or being of any significance? I think pretty low, but something worth noting

Copy link
Contributor

@ndbaker1 ndbaker1 Jul 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to those points, and irrespective of execution i think having shared expectations across our images is also a good idea (unless there are obvious requirements derived from software/hardware differences)

my 2 cents is that i like building from source if we're already doing it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me. I'll make the changes now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

ca-certificates \
cmake \
curl \
emacs \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you can trim any of these out I would but nbd 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually only included those because they were in our other images - https://github.com/aws/aws-k8s-tester/blob/cc66356a28d11fdd4a60573d2a2bbe502a14dbab/e2e2/test/images/neuron/Dockerfile#L39C1-L43C10

Was just trying to keep things consistent and start to identify common patterns amongst our images. Maybe these are required in the other image...? If not, I would definitely advocate for us to remove.

Copy link
Contributor

@ndbaker1 ndbaker1 Jul 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea agreed, its not blocking me though

steps:
- uses: actions/checkout@v3
- run: docker build --file e2e2/test/images/bert-inference/Dockerfile e2e2/test/images/bert-inference
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as much as i prefer setting the build workspace to the exact path, I think it's set to . in the other images because its built from the root in other workflows. Can you double check this will work

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't work because the image build references e2e2/test/images/bert-inference/requirements.txt. If we set the path to ., instead of the full path, then it doesn't know it exists. This is actually something I was wanting to discuss, python dependency declaration/management, but was hoping it'd be a down the line thing (not a short convo)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i agree, i don't love the full path but we'll need to make sure it works with our current setup

@cartermckinnon cartermckinnon merged commit f5c1831 into aws:main Jul 16, 2024
5 checks passed
@mattcjo mattcjo deleted the e2e2-bert-inference branch July 16, 2024 17:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants