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

[Usage]: How can i user scheduler with OpenAI Compatible Server #8282

Closed
1 task done
anhnh2002 opened this issue Sep 9, 2024 · 7 comments · Fixed by #8965
Closed
1 task done

[Usage]: How can i user scheduler with OpenAI Compatible Server #8282

anhnh2002 opened this issue Sep 9, 2024 · 7 comments · Fixed by #8965
Labels
good first issue Good for newcomers usage How to use vllm

Comments

@anhnh2002
Copy link

Your current environment

PyTorch version: 2.4.0+cu121
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.6 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
Clang version: Could not collect
CMake version: version 3.29.3
Libc version: glibc-2.31

Python version: 3.10.14 (main, May  6 2024, 19:42:50) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.4.0-193-generic-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: 10.1.243
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: 
GPU 0: NVIDIA A100-PCIE-40GB
GPU 1: NVIDIA A100-PCIE-40GB

Nvidia driver version: 535.183.01
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.9.7
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.9.7
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.9.7
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.9.7
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.9.7
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.9.7
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.9.7
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:                      40 bits physical, 57 bits virtual
CPU(s):                             52
On-line CPU(s) list:                0-51
Thread(s) per core:                 1
Core(s) per socket:                 52
Socket(s):                          1
NUMA node(s):                       1
Vendor ID:                          GenuineIntel
CPU family:                         6
Model:                              134
Model name:                         Intel Xeon Processor (Icelake)
Stepping:                           0
CPU MHz:                            2194.848
BogoMIPS:                           4389.69
Virtualisation:                     VT-x
Hypervisor vendor:                  KVM
Virtualisation type:                full
L1d cache:                          1.6 MiB
L1i cache:                          1.6 MiB
L2 cache:                           208 MiB
L3 cache:                           16 MiB
NUMA node0 CPU(s):                  0-51
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
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; Enhanced / Automatic IBRS; IBPB conditional; RSB filling; PBRSB-eIBRS Not affected; BHI SW loop, KVM SW loop
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Mitigation; TSX disabled
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves wbnoinvd arat avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid md_clear arch_capabilities

Versions of relevant libraries:
[pip3] flake8==7.0.0
[pip3] flake8-bugbear==24.4.26
[pip3] flashinfer==0.1.2+cu124torch2.4
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.26.2
[pip3] nvidia-nccl-cu12==2.20.5
[pip3] onnxruntime==1.18.1
[pip3] sentence-transformers==3.0.1
[pip3] torch==2.4.0
[pip3] torch-stoi==0.2.1
[pip3] torchaudio==2.4.0
[pip3] torchtext==0.18.0
[pip3] torchvision==0.19.0
[pip3] transformers==4.44.2
[pip3] triton==3.0.0
[conda] flashinfer                0.1.2+cu124torch2.4          pypi_0    pypi
[conda] numpy                     1.26.4                   pypi_0    pypi
[conda] nvidia-nccl-cu12          2.20.5                   pypi_0    pypi
[conda] sentence-transformers     3.0.1                    pypi_0    pypi
[conda] torch                     2.4.0                    pypi_0    pypi
[conda] torch-stoi                0.2.1                    pypi_0    pypi
[conda] torchaudio                2.4.0                    pypi_0    pypi
[conda] torchtext                 0.18.0                   pypi_0    pypi
[conda] torchvision               0.19.0                   pypi_0    pypi
[conda] transformers              4.44.2                   pypi_0    pypi
[conda] triton                    3.0.0                    pypi_0    pypi
ROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: N/A
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
GPU0    GPU1    CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X      NV12    0-51    0               N/A
GPU1    NV12     X      0-51    0               N/A

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

How would you like to use vllm

I am currently serving an LLM via the vLLM as an OpenAI Compatible Server. I make API calls as shown below:

completion = llm_client.chat.completions.create(
    model=LLM_MODEL_NAME,
    messages=messages,
    top_p=0.5
)
response = completion.choices[0].message.content.strip()

I would like to introduce a scheduler or prioritize requests in my API calls. Is there a way to specify a priority or use a scheduler directly in the API call, similar to the following?

completion = llm_client.chat.completions.create(
    model=LLM_MODEL_NAME,
    messages=messages,
    top_p=0.5,
    priority=1
)
response = completion.choices[0].message.content.strip()

Could you provide guidance on implementing this feature or suggest an alternative approach?

Before submitting a new issue...

  • Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.
@anhnh2002 anhnh2002 added the usage How to use vllm label Sep 9, 2024
@DarkLight1337
Copy link
Member

DarkLight1337 commented Sep 9, 2024

I think this isn't a primary concern for vLLM. It may be better to implement a separate load-balancing / scheduling layer on top of the vLLM server.

@anhnh2002
Copy link
Author

I think this isn't a primary concern for vLLM. It may be better to implement a separate load-balancing / scheduling layer on top of the vLLM server.

I am using FastAPI wrapped on a vLLM server. I have tried searching for documents to create a priority queue for FastAPI but haven't found any. Do you have any suggestions for me?

@DarkLight1337
Copy link
Member

I haven't done this myself, so I wouldn't consider myself qualified to provide concrete suggestions. You can check out #4873 for more details.

@DarkLight1337
Copy link
Member

Update: I found #5958 which may serve your purpose but currently the PR only considers offline inference.

@anhnh2002
Copy link
Author

Update: I found #5958 which may serve your purpose but currently the PR only considers offline inference.

thanks a lot

@DarkLight1337 DarkLight1337 added the good first issue Good for newcomers label Sep 25, 2024
@DarkLight1337
Copy link
Member

DarkLight1337 commented Sep 25, 2024

#5958 has been merged. It should be quite straightforward to expose this argument to the OpenAI-compatible API.

@DarkLight1337
Copy link
Member

Closing as completed by #8965.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers usage How to use vllm
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants