search

vllm-project / vllm

A high-throughput and memory-efficient inference and serving engine for LLMs
https://docs.vllm.ai
Apache License 2.0
26.99k stars 3.96k forks source link

[Usage]: How to determine whether the vllm engine is full with requests or not #3897

Open man2machine opened 5 months ago

man2machine commented 5 months ago

Your current environment

Collecting environment information...
PyTorch version: 2.1.2+cu121
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.5 LTS (x86_64)
GCC version: (conda-forge gcc 13.2.0-5) 13.2.0
Clang version: Could not collect
CMake version: version 3.26.4
Libc version: glibc-2.31

Python version: 3.11.8 (main, Feb 26 2024, 21:39:34) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.4.0-144-generic-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: 12.4.99
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: 
GPU 0: NVIDIA A100-SXM4-80GB
GPU 1: NVIDIA A100-SXM4-80GB
GPU 2: NVIDIA A100-SXM4-80GB
GPU 3: NVIDIA A100-SXM4-80GB
GPU 4: NVIDIA A100-SXM4-80GB
GPU 5: NVIDIA A100-SXM4-80GB
GPU 6: NVIDIA A100-SXM4-80GB
GPU 7: NVIDIA A100-SXM4-80GB

Nvidia driver version: 535.129.03
cuDNN version: Probably one of the following:
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn.so.8
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn_adv_train.so.8
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn_ops_train.so.8
/usr/local/cuda-12.1/targets/x86_64-linux/lib/libcudnn.so.8
/usr/local/cuda-12.1/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8
/usr/local/cuda-12.1/targets/x86_64-linux/lib/libcudnn_adv_train.so.8
/usr/local/cuda-12.1/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8
/usr/local/cuda-12.1/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8
/usr/local/cuda-12.1/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8
/usr/local/cuda-12.1/targets/x86_64-linux/lib/libcudnn_ops_train.so.8
/usr/local/cuda-12.2/targets/x86_64-linux/lib/libcudnn.so.8
/usr/local/cuda-12.2/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8
/usr/local/cuda-12.2/targets/x86_64-linux/lib/libcudnn_adv_train.so.8
/usr/local/cuda-12.2/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8
/usr/local/cuda-12.2/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8
/usr/local/cuda-12.2/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8
/usr/local/cuda-12.2/targets/x86_64-linux/lib/libcudnn_ops_train.so.8
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   48 bits physical, 48 bits virtual
CPU(s):                          256
On-line CPU(s) list:             0-254
Off-line CPU(s) list:            255
Thread(s) per core:              1
Core(s) per socket:              64
Socket(s):                       2
NUMA node(s):                    2
Vendor ID:                       AuthenticAMD
CPU family:                      25
Model:                           1
Model name:                      AMD EPYC 7763 64-Core Processor
Stepping:                        1
Frequency boost:                 enabled
CPU MHz:                         1402.745
CPU max MHz:                     2450.0000
CPU min MHz:                     1500.0000
BogoMIPS:                        4900.45
Virtualization:                  AMD-V
L1d cache:                       2 MiB
L1i cache:                       2 MiB
L2 cache:                        32 MiB
L3 cache:                        256 MiB
NUMA node0 CPU(s):               0-63,128-191
NUMA node1 CPU(s):               64-127,192-254
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Mmio stale data:   Not affected
Vulnerability Retbleed:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP always-on, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 invpcid_single hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload vgif umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca

Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] torch==2.1.2
[pip3] torchvision==0.16.2
[pip3] triton==2.1.0
[conda] faiss-gpu                 1.8.0           py3.11_h4c7d538_0_cuda12.1.1    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] libfaiss                  1.8.0           h046e95b_0_cuda12.1.1    pytorch
[conda] libjpeg-turbo             2.0.0                h9bf148f_0    pytorch
[conda] libmagma                  2.7.2                h173bb3b_2    conda-forge
[conda] libmagma_sparse           2.7.2                h173bb3b_3    conda-forge
[conda] libtorch                  2.1.2           cuda120_h86db2e7_300    conda-forge
[conda] magma                     2.7.2                h51420fd_3    conda-forge
[conda] mkl                       2023.2.0         h84fe81f_50496    conda-forge
[conda] numpy                     1.26.4          py311h24aa872_0  
[conda] numpy-base                1.26.4          py311hbfb1bba_0  
[conda] pytorch-cuda              12.1                 ha16c6d3_5    pytorch
[conda] pytorch-mutex             1.0                        cuda    pytorch
[conda] torch                     2.1.2                    pypi_0    pypi
[conda] torchvision               0.16.2              py311_cu121    pytorch
[conda] triton                    2.1.0                    pypi_0    pypiROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: 0.3.3
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
        GPU0    GPU1    GPU2    GPU3    GPU4    GPU5    GPU6    GPU7    NIC0    NIC1    NIC2    NIC3    CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X      NV12    NV12    NV12    NV12    NV12    NV12    NV12    SYS     PXB     SYS     SYS     0-63,128-191    0               N/A
GPU1    NV12     X      NV12    NV12    NV12    NV12    NV12    NV12    SYS     PXB     SYS     SYS     0-63,128-191    0               N/A
GPU2    NV12    NV12     X      NV12    NV12    NV12    NV12    NV12    PXB     SYS     SYS     SYS     0-63,128-191    0               N/A
GPU3    NV12    NV12    NV12     X      NV12    NV12    NV12    NV12    PXB     SYS     SYS     SYS     0-63,128-191    0               N/A
GPU4    NV12    NV12    NV12    NV12     X      NV12    NV12    NV12    SYS     SYS     SYS     PXB     64-127,192-254  1               N/A
GPU5    NV12    NV12    NV12    NV12    NV12     X      NV12    NV12    SYS     SYS     SYS     PXB     64-127,192-254  1               N/A
GPU6    NV12    NV12    NV12    NV12    NV12    NV12     X      NV12    SYS     SYS     PXB     SYS     64-127,192-254  1               N/A
GPU7    NV12    NV12    NV12    NV12    NV12    NV12    NV12     X      SYS     SYS     PXB     SYS     64-127,192-254  1               N/A
NIC0    SYS     SYS     PXB     PXB     SYS     SYS     SYS     SYS      X      SYS     SYS     SYS
NIC1    PXB     PXB     SYS     SYS     SYS     SYS     SYS     SYS     SYS      X      SYS     SYS
NIC2    SYS     SYS     SYS     SYS     SYS     SYS     PXB     PXB     SYS     SYS      X      SYS
NIC3    SYS     SYS     SYS     SYS     PXB     PXB     SYS     SYS     SYS     SYS     SYS      X 

Legend:

  X    = Self
  SYS  = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
  NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
  PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
  PXB  = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
  PIX  = Connection traversing at most a single PCIe bridge
  NV#  = Connection traversing a bonded set of # NVLinks

NIC Legend:

  NIC0: mlx5_0
  NIC1: mlx5_1
  NIC2: mlx5_2
  NIC3: mlx5_3

How would you like to use vllm

I know I can add requests to the AsyncLLMEngine using add_request(, but I am not sure how to find out whether the engine is full with requests and adding more requests will simply cause it to queue up, or it can accept more requests. How can I do this? Is there a way to also get a quantity, like how much % utilization the engine is at as well?

man2machine commented 5 months ago

I see there is the function get_num_unfinished_requests. It appears this tells us whether there are requests running, swapped or waiting. However, I want to know if the engine is "full" as in if it takes in another request, that request will be queued up and will not be processed immediately. Can I do that by using bool(self.scheduler.waiting) or bool(self.scheduler.swapped)?

man2machine commented 5 months ago

In particular I wrote these two functions. Is this the right way to use the engine and scheduler classes or am I missing something?

And is there a way to know the maximum number of requests that can run in parallel?

class _CustomAsyncLLMEngine(_AsyncLLMEngine):
    def has_requests_in_queue(
        self: Self
    ) -> bool:

        return bool(self.scheduler.waiting) or bool(self.scheduler.swapped)

    def get_num_tokens_in_queue(
        self: Self
    ) -> int:

        num_tokens = sum(
            sum(
                sum(
                    len(s.data.prompt_token_ids)
                    for s in g.get_seqs()
                )
                for g in queue
            )
            for queue in (self.scheduler.waiting, self.scheduler.swapped)
        )

        return num_tokens
robertgshaw2-neuralmagic commented 5 months ago

scheduler_config.max_num_seqs will hold the maximum number of running sequences

Curious - why do you need this info? The user should not have to know about this parameter [ just curious what your use case is ]

timxzz commented 4 months ago

@robertgshaw2-neuralmagic I am not sure why the OP wants this info, but for me, I would like to know if the engine is at its capacity, so I can decide whether I should submit more requests.

robertgshaw2-neuralmagic commented 4 months ago

@robertgshaw2-neuralmagic I am not sure why the OP wants this info, but for me, I would like to know if the engine is at its capacity, so I can decide whether I should submit more requests.

vLLM's internal scheduler manages this internally. So you can send all your requests at once

timxzz commented 4 months ago

Thanks for the timely reply! Is there a limit on how many request it can handle or queue? Or it will start rejecting when the limit is reached and the sender will find out then?

timxzz commented 4 months ago

I found #2492 and #3561 are also useful for answering this question.

man2machine commented 4 months ago

Apologies @timxzz @robertgshaw2-neuralmagic , I missed your earlier question regarding why I want to know if the vllm scheduler is full. I would like to know this because I am writing a distributed program that is running multiple vllm instances, and I would not like to submit to an instance which is already full. So if scheduler_config.max_num_seqs contains the maximum number of running sequences can I simply do len(self.scheduler.running) < self.scheduler_config.max_num_seqs to see if it is full or not?

llx-08 commented 3 months ago

Apologies @timxzz @robertgshaw2-neuralmagic , I missed your earlier question regarding why I want to know if the vllm scheduler is full. I would like to know this because I am writing a distributed program that is running multiple vllm instances, and I would not like to submit to an instance which is already full. So if scheduler_config.max_num_seqs contains the maximum number of running sequences can I simply do len(self.scheduler.running) < self.scheduler_config.max_num_seqs to see if it is full or not?

Yes, I believe that's correct. Additionally, you can utilize engine.scheduler.block_manager.get_num_free_gpu_blocks() to determine whether the instance's memory is full or not.

lionelvillard commented 3 months ago

I'm also interesting in this for the same reason as @man2machine. While the proposed solution works, it's not ideal as it requires constant polling from the client (the one sending requests), and it's not optimal (requests can sit in the waiting queue when they can have been processed by another less used vLLM instance).

@llx-08 @timxzz @man2machine @robertgshaw2-neuralmagic I'm curious to know what's your thoughts to avoid polling?

quanliu1991 commented 2 months ago

We have the same confusion @lionelvillard @man2machine, and not limiting the number of requests can leads to two problems

  1. If the number of requests is very large and the CPU is queued, the memory may be used up, causing the ray process to fail.
  2. Too many requests are queued, resulting in increased end-to-end delay or even timeout.
emirhanKural commented 1 week ago

Hello guys,

Is there any limitation on the number of requests in the queue? Because regardless of the number of GPUs, the count of running + pending requests never exceeds 100.

For example, I'm sending 500 concurrent requests to my API, and some of their outputs are shown below:

2xA100

4xA100

When it still continues to receive requests, at the very least, I'm expecting to have the maximum number of Running requests and an increasing number of Pending requests continuously.

I tried to change max_num_seqs as explained in this and as you mentioned above, but nothing changed.

It seems I cannot utilize the full performance of 4 GPUs compared to 2 GPUs in this situation. Am I missing something?

robertgshaw2-neuralmagic commented 1 week ago

@emirhanKural - how are you querying the server? Are you using a single OpenAI client? The OpenAI client can throttle the number of active requests it sends at a time

emirhanKural commented 1 week ago

Hi!

I am using the aiohttp library to send asynchronous requests, and after what you said, I checked and found that it really has a default limit.

Thank you for your help.

emirhanKural commented 3 days ago

Hello again,

I'd like to ask about an indirectly related issue, even though it's not directly associated with the topic at hand.

In my stress tests, I've observed that 2xGPUs perform better than 4xGPUs when sending concurrent requests.

Upon checking the logs, I found that the primary reason for this seems to be the "pending to running" phase. The transition from pending to running is slow, and batching doesn't start effectively until my CUDA blocks are full, the max_num_seqs reaches the necessary count, or the pending requests drop to zero. We can see this from the "Avg generation throughput."

For example, the behavior for 100 concurrent requests is as follows:

2xGPU quickly starts full-performance batching as the CUDA blocks get filled; image

4xGPU, with its significantly more CUDA blocks, waits until max_num_seqs reaches 256 or pending requests drop to zero before starting; image

By looking at the info timestamps, we can see that the "pending to running" process takes about 1 minute. When the number of requests increases, the delay before 4xGPUs start fully performing becomes even longer.

Am I missing something? Is there a way to speed up the Prefill step?

Given this, it seems more effective to use 4 instances with 2 GPUs each rather than a single instance with 8 GPUs in Production.