lmdeploy: PyTorch Engine performance degradation vs Turbomind

Checklist

1. I have searched related issues but cannot get the expected help.
2. The bug has not been fixed in the latest version.

Describe the bug

When benchmarking with the Llama 2 13B chat model and the ShareGPT dataset, I observed a performance degradation in the PyTorch Engine compared to TurboMind.

RPS (requests per second) is less than half.

# Turbomind
concurrency: 128
elapsed_time: 140.528s

number of prompt tokens: 241688
number of completion tokens: 228637
token throughput (completion token): 1626.983 token/s
token throughput (prompt + completion token): 3346.838 token/s
RPS (request per second): 7.116 req/s
RPM (request per minute): 426.961 req/min

# PyTorch Engine
concurrency: 128
elapsed_time: 324.175s

number of prompt tokens: 241688
number of completion tokens: 228637
token throughput (completion token): 705.288 token/s
token throughput (prompt + completion token): 1450.836 token/s
RPS (request per second): 3.085 req/s
RPM (request per minute): 185.085 req/min

Reproduction

GPU: NVIDIA A100-SXM4-80GB

CUDA: 11.8

LMDeploy: 0.2.3

llama2_13b_chat: https://huggingface.co/meta-llama/Llama-2-13b-chat-hf

ShareGPT_V3_unfiltered_cleaned_split.json: https://huggingface.co/datasets/anon8231489123/ShareGPT_Vicuna_unfiltered/resolve/main/ShareGPT_V3_unfiltered_cleaned_split.json

profile_restful_api.py: https://github.com/InternLM/lmdeploy/blob/main/benchmark/profile_restful_api.py

Server

# Turbomind
python3 -m lmdeploy serve api_server /workdir/llama2_13b_chat

# PyTorch Engine
python3 -m lmdeploy serve api_server /workdir/llama2_13b_chat --backend pytorch

Client

python3 /workdir/lmdeploy/benchmark/profile_restful_api.py --server_addr 127.0.0.1:23333 --tokenizer_path /workdir/llama2_13b_chat --dataset /workdir/ShareGPT_V3_unfiltered_cleaned_split.json --concurrency 128 --num_prompts 1000

Environment

sys.platform: linux
Python: 3.9.16 (main, Aug 15 2023, 19:38:56) [GCC 8.3.1 20190311 (Red Hat 8.3.1-3)]
CUDA available: True
MUSA available: False
numpy_random_seed: 2147483648
GPU 0,1: NVIDIA A100-SXM4-80GB
CUDA_HOME: /usr/local/cuda
NVCC: Cuda compilation tools, release 11.8, V11.8.89
GCC: gcc (GCC) 10.2.1 20210130 (Red Hat 10.2.1-11)
PyTorch: 2.1.2+cu118
PyTorch compiling details: PyTorch built with:
  - GCC 9.3
  - C++ Version: 201703
  - Intel(R) oneAPI Math Kernel Library Version 2022.2-Product Build 20220804 for Intel(R) 64 architecture applications
  - Intel(R) MKL-DNN v3.1.1 (Git Hash 64f6bcbcbab628e96f33a62c3e975f8535a7bde4)
  - OpenMP 201511 (a.k.a. OpenMP 4.5)
  - LAPACK is enabled (usually provided by MKL)
  - NNPACK is enabled
  - CPU capability usage: AVX2
  - CUDA Runtime 11.8
  - NVCC architecture flags: -gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_80,code=sm_80;-gencode;arch=compute_86,code=sm_86;-gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_90,code=sm_90
  - CuDNN 8.7
  - Magma 2.6.1
  - Build settings: BLAS_INFO=mkl, BUILD_TYPE=Release, CUDA_VERSION=11.8, CUDNN_VERSION=8.7.0, CXX_COMPILER=/opt/rh/devtoolset-9/root/usr/bin/c++, CXX_FLAGS= -D_GLIBCXX_USE_CXX11_ABI=0 -fabi-version=11 -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -DNDEBUG -DUSE_KINETO -DLIBKINETO_NOROCTRACER -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -O2 -fPIC -Wall -Wextra -Werror=return-type -Werror=non-virtual-dtor -Werror=bool-operation -Wnarrowing -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-unused-parameter -Wno-unused-function -Wno-unused-result -Wno-strict-overflow -Wno-strict-aliasing -Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic -Wno-error=old-style-cast -Wno-invalid-partial-specialization -Wno-unused-private-field -Wno-aligned-allocation-unavailable -Wno-missing-braces -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Werror=cast-function-type -Wno-stringop-overflow, LAPACK_INFO=mkl, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, TORCH_DISABLE_GPU_ASSERTS=ON, TORCH_VERSION=2.1.2, USE_CUDA=ON, USE_CUDNN=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=1, USE_NNPACK=ON, USE_OPENMP=ON, USE_ROCM=OFF, 

TorchVision: 0.14.1a0+5e8e2f1
LMDeploy: 0.2.3+9bb8ba7
transformers: 4.36.0
gradio: 3.50.2
fastapi: 0.104.1
pydantic: 2.6.0

Error traceback

N/A

About this issue

Original URL
State: closed
Created 4 months ago
Comments: 15 (8 by maintainers)

Most upvoted comments

@zhyncs @lvhan028 After some investigation, I found that the key to bad performance is sampling. I have not paid much attention to sampling before. For each batch, I gathered the inputs with the same sampling parameters and performed batched sampling. If all inputs share the very same sampling parameters, everything is good. But in profile_restful_api.py, every input would have a different random_seed, which means sampling would be performed again and again and again, taking way more long time than the model forward.

In this branch, I just ignore the random_seed and force the sampling parameters to be gathered together. With some other optimization(coroutine-friendly engine design), now we have:

concurrency: 128
elapsed_time: 476.190s

number of prompt tokens: 740656
number of completion tokens: 695134
token throughput (completion token): 1459.783 token/s
token throughput (prompt + completion token): 3015.162 token/s
RPS (request per second): 6.300 req/s
RPM (request per minute): 378.000 req/min

Which is even better than the local benchmark. GPU usage is ~90% I think I need to refactor the sampling module, add some customer kernels for it.

grimoire on Feb 24, 2024