eunomia-bpf / eunomia-bpf/gpu_ext
About the vllm part of GPU_EXT
- Dominant language
- C
- Stars
- 68
- Forks
- 6
- PR merge metrics
- No merged PRs in 30d
Description
Hi,
Recently I have read your paper <>, it's really an innovative
and amazing work. I am now working on reproducing the vllm benchmark improvements using your open source gpu_ext repo. I have several questions about the vllm part:
1. The paper claims that with RTX 5090 and Qwen-30B FP8, the decode throughput improves 1.3x vs vllm's cpu-offload, while in a recent commit of gpu_ext(https://github.com/eunomia-bpf/gpu_ext/commit/1fe87b25f4614762868bef160e9675a20b6fad87), it says that these two approaches are not comparable. So the throughput actually becomes worse and the real improvements is TPOT, right? Will you continue to improve the vllm throughput under UVM mode?
2. I have tested Qwen3-4B (dense model) with 10G 3080 and Qwen2-57B-A14B (moe model) with 80G H100.
- The Qwen3-4B case shows thoughtput improvements, because I use max-model-len(2048) and max-num-seq(8), vllm can start with this setting even without cpu-offload, so I guess the forced cpu-offload setting descrease the throughput. While under UVM, since the weights can fit in the gpu, the head part of the bench is fast, but become lower and lower when requests descrease.
- The Qwen2-57B case shows a significant descrease on the throughput, just like commit in gpu_ext says.
since I need to limit the max-num-seq under UVM, it's really hard to compare with cpu-offload in a fair way, is it OK to limit the max-num-seq under cpu-offload? Besides, should the picked model size slightly smaller than the gpu size, or can exceed the gpu size?
I am not sure if my test scenarios is appropriate for gpu_ext.
3. Do we have a better way to get rid of the --max-num-seqs config?
Thanks for your time and glad to hear from you.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.