[Bug]: Qwen2-VL incoherent output with OpenAI API

[SinanAkkoyun]

Your current environment

The output of `python collect_env.py`

Collecting environment information...
WARNING 10-27 12:26:23 cuda.py:22] You are using a deprecated `pynvml` package. Please install `nvidia-ml-py` instead, and make sure to uninstall `pynvml`. When both of them are installed, `pynvml` will take precedence and cause errors. See https://pypi.org/project/pynvml for more information.
WARNING 10-27 12:26:23 cuda.py:76] Detected different devices in the system: 
WARNING 10-27 12:26:23 cuda.py:76] NVIDIA A100 80GB PCIe
WARNING 10-27 12:26:23 cuda.py:76] NVIDIA GeForce RTX 4090
WARNING 10-27 12:26:23 cuda.py:76] NVIDIA GeForce RTX 4090
WARNING 10-27 12:26:23 cuda.py:76] NVIDIA GeForce RTX 4090
WARNING 10-27 12:26:23 cuda.py:76] Please make sure to set `CUDA_DEVICE_ORDER=PCI_BUS_ID` to avoid unexpected behavior.
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 22.04.4 LTS (x86_64)
GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Clang version: Could not collect
CMake version: version 3.30.0
Libc version: glibc-2.35

Python version: 3.10.13 (main, Sep 11 2023, 13:44:35) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.15.0-122-generic-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: 
GPU 0: NVIDIA A100 80GB PCIe
GPU 1: NVIDIA GeForce RTX 4090
GPU 2: NVIDIA GeForce RTX 4090
GPU 3: NVIDIA GeForce RTX 4090

Nvidia driver version: 535.183.01
cuDNN version: Could not collect
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
Address sizes:                        46 bits physical, 48 bits virtual
Byte Order:                           Little Endian
CPU(s):                               32
On-line CPU(s) list:                  0-31
Vendor ID:                            GenuineIntel
Model name:                           13th Gen Intel(R) Core(TM) i9-13900KS
CPU family:                           6
Model:                                183
Thread(s) per core:                   2
Core(s) per socket:                   24
Socket(s):                            1
Stepping:                             1
CPU max MHz:                          6000.0000
CPU min MHz:                          800.0000
BogoMIPS:                             6374.40
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand 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 rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req umip pku ospke waitpkg gfni vaes vpclmulqdq tme rdpid movdiri movdir64b fsrm md_clear serialize pconfig arch_lbr flush_l1d arch_capabilities
Virtualization:                       VT-x
L1d cache:                            896 KiB (24 instances)
L1i cache:                            1.3 MiB (24 instances)
L2 cache:                             32 MiB (12 instances)
L3 cache:                             36 MiB (1 instance)
NUMA node(s):                         1
NUMA node0 CPU(s):                    0-31
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:        Not affected
Vulnerability Reg file data sampling: Mitigation; Clear Register File
Vulnerability Retbleed:               Not affected
Vulnerability Spec rstack overflow:   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 SW sequence; BHI BHI_DIS_S
Vulnerability Srbds:                  Not affected
Vulnerability Tsx async abort:        Not affected

Versions of relevant libraries:
[pip3] numpy==1.26.2
[pip3] nvidia-cublas-cu12==12.1.3.1
[pip3] nvidia-cuda-cupti-cu12==12.1.105
[pip3] nvidia-cuda-nvrtc-cu12==12.1.105
[pip3] nvidia-cuda-runtime-cu12==12.1.105
[pip3] nvidia-cudnn-cu12==9.1.0.70
[pip3] nvidia-cufft-cu12==11.0.2.54
[pip3] nvidia-curand-cu12==10.3.2.106
[pip3] nvidia-cusolver-cu12==11.4.5.107
[pip3] nvidia-cusparse-cu12==12.1.0.106
[pip3] nvidia-ml-py==12.560.30
[pip3] nvidia-nccl-cu12==2.20.5
[pip3] nvidia-nvjitlink-cu12==12.3.101
[pip3] nvidia-nvtx-cu12==12.1.105
[pip3] pynvml==11.5.0
[pip3] pyzmq==26.0.3
[pip3] torch==2.4.0
[pip3] torchvision==0.19.0
[pip3] transformers==4.45.2
[pip3] triton==3.0.0
[conda] numpy                     1.26.2                   pypi_0    pypi
[conda] nvidia-cublas-cu12        12.1.3.1                 pypi_0    pypi
[conda] nvidia-cuda-cupti-cu12    12.1.105                 pypi_0    pypi
[conda] nvidia-cuda-nvrtc-cu12    12.1.105                 pypi_0    pypi
[conda] nvidia-cuda-runtime-cu12  12.1.105                 pypi_0    pypi
[conda] nvidia-cudnn-cu12         9.1.0.70                 pypi_0    pypi
[conda] nvidia-cufft-cu12         11.0.2.54                pypi_0    pypi
[conda] nvidia-curand-cu12        10.3.2.106               pypi_0    pypi
[conda] nvidia-cusolver-cu12      11.4.5.107               pypi_0    pypi
[conda] nvidia-cusparse-cu12      12.1.0.106               pypi_0    pypi
[conda] nvidia-ml-py              12.560.30                pypi_0    pypi
[conda] nvidia-nccl-cu12          2.20.5                   pypi_0    pypi
[conda] nvidia-nvjitlink-cu12     12.3.101                 pypi_0    pypi
[conda] nvidia-nvtx-cu12          12.1.105                 pypi_0    pypi
[conda] pynvml                    11.5.0                   pypi_0    pypi
[conda] pyzmq                     26.0.3                   pypi_0    pypi
[conda] torch                     2.4.0                    pypi_0    pypi
[conda] torchvision               0.19.0                   pypi_0    pypi
[conda] transformers              4.45.2                   pypi_0    pypi
[conda] triton                    3.0.0                    pypi_0    pypi
ROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: 0.6.3.post1
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
GPU0    GPU1    GPU2    GPU3    CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X      PHB     PHB     PHB     0-31    0               N/A
GPU1    PHB      X      PHB     PHB     0-31    0               N/A
GPU2    PHB     PHB      X      PHB     0-31    0               N/A
GPU3    PHB     PHB     PHB      X      0-31    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

Model Input Dumps

No response

🐛 Describe the bug

When running OpenAI API inference, Qwen2-vl-7B-instruct and 2B produce incoherent output as soon as an image is attached. Other VLM models seem to be working fine.
text-only seems to work with Qwen2VL, but introducing images results in

output like this:

``` Q: What is this? Model output: This

Nam: delimited
't screenshot
The

Or: The a is a isScreenshot
]

.py
clipse]
’m are tool):_p this a (ed:

_rate a is_F
V_on/}

ol,}" are can_t lot

</details>


### Before submitting a new issue...

- [X] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the [documentation page](https://docs.vllm.ai/en/latest/), which can answer lots of frequently asked questions.

[DarkLight1337]

@alex-jw-brooks can you add this model to your test suite to check whether the current model implementation is ok? And try to debug any issues (see if your test architecture can be easily debugged in practice)

[SinanAkkoyun]

I tried to follow Qwen's repo instructions:

pip install git+https://github.com/huggingface/transformers@21fac7abba2a37fae86106f87fcf9974fd1e3830
pip install accelerate
pip install qwen-vl-utils
# Change to your CUDA version
CUDA_VERSION=cu121
pip install 'vllm==0.6.1' --extra-index-url https://download.pytorch.org/whl/${CUDA_VERSION}

(installing the qwen-vl-utils for latest vLLM did not resolve this current issue)
And came across this:

WARNING 10-28 00:30:22 qwen2_vl.py:217] Current Qwen2-VL implementation has a bug with `vllm-flash-attn` inside vision module, so we use xformers backend instead. You can run `pip install flash-attn to use flash-attention backend.

Although it 'works', it's extremely slow, for the 7B it took 3.5s to generate The text on the right under the "M" says "LE CHAT NOIR". on a 4090 (with transformers it has around 38.75 tps). pip install flash-attn also did not affect speeds at all (but the warning is gone).

Maybe this insight helps here, I'd love to use qwen2-vl with the latest vLLM version with fastest inference :)

[SinanAkkoyun]

Edit: Only large images (like 2k or 4k) take several seconds of processing (8 seconds for a 4k image), smaller images take under 0.2s. I don't know if this is due to the vision encoder running sequentially or something else and if that's also true for their HF implementation

[DarkLight1337]

Edit: Only large images (like 2k or 4k) take several seconds of processing (8 seconds for a 4k image), smaller images take under 0.2s. I don't know if this is due to the vision encoder running sequentially or something else and if that's also true for their HF implementation

The majority of the time is spent on HF preprocessing. We have plans to move preprocessing out of the critical path to improve the performance.

[SinanAkkoyun]

Cool! Would this mean one would get almost the same performance as with smaller images or something like a 2x performance gain?

[DarkLight1337]

Cool! Would this mean one would get almost the same performance as with smaller images or something like a 2x performance gain?

You can see in #9238 that preprocessing dominates the overall execution time. Even if we move it out of the critical path so that other processes in vLLM can run at the same time as this preprocessing step, we still have to wait for preprocessing to finish before the inputs can be fed into the model. So probably not much gain in this particular case. The best case is when the preprocessing takes around the same time as the other processes.

[SinanAkkoyun]

@DarkLight1337 Thank you for the insight. What I mean is, would it be worth it to spend time optimizing the preprocessor? Because if so, I'd like to tackle it
If a small image takes less than 200ms, could one expect roughly the same time for a 4k image? (the model itself should not take super long to process the ~1k token prompt of a big image)

[DarkLight1337]

@DarkLight1337 Thank you for the insight. What I mean is, would it be worth it to spend time optimizing the preprocessor? Because if so, I'd like to tackle it If a small image takes less than 200ms, could one expect roughly the same time for a 4k image? (the model itself should not take super long to process the ~1k token prompt of a big image)

Looking at the profiler output in #9238, you can see that much time is taken up by the preprocessor, so speeding that up would definitely help.

However, since most of the preprocessing code is defined inside HuggingFace repo, this is outside our control. See huggingface/transformers#34272

[SinanAkkoyun]

However, since most of the preprocessing code is defined inside HuggingFace repo, this is outside our control.

Right, sorry for the oversight, it also seems that huggingface/transformers#33810 is working on a fix
I hope we can fix the coherency issue for the latest vLLM (otherwise with the older version I can't upgrade to the latest transformers)

[osilverstein]

I just posted a similar issue but with totally different params. I wonder if related at all: issue

[SinanAkkoyun]

@osilverstein I don't think so as any other VLM works for me and it only happens with image input

[SinanAkkoyun]

@DarkLight1337 Regarding the incoherence of Qwen:
With the latest vLLM, Qwen2-VL produces complete garbage with big images (in this case 5120x1440), but for smaller images it works completely fine. (now it makes sense that many can run the model coherently)

Even when supplying 4 smaller images which would easily add up to more tokens than the single big image, it works flawlessly.

Something seems to be off with large image processing

[osilverstein]

@osilverstein I don't think so as any other VLM works for me and it only happens with image input

I hear you, but it seems coincidental both issues occur with large inputs and only on the latest version. Too coincidental? I'll ask you this, if you feed in 8k context and ask it how its doing without image input, is it coherent? Then try the same on openrouter. Would help isolate the issue

[SinanAkkoyun]

@osilverstein Your hypothesis seems to be correct. Throwing an 11k token code (qwens vision_process.py) at Qwen2-VL (no images) and asking it to summarize what it does in 3 sentences it responded with:

The as resp `


  " error) *        (:

 
 Padding
   )
 the `Only `   >
   

   
 *   -type, thisoweredDimension input None_imageMethod `_ image npit_dims format    the Channels
 ` user data = back `GRINARY
 None torch)
   )Like       warnings =.ndarray: or    code code a);


 remaining:_      _shape maximum forwise P ` tool operation2
 P to tensor *
assume be used-to
   R: ` any   IRST_REV
_up the which
 ifImage
 values, res format we
 Unionferredferred andast
Union i thetorch_formatify: *, channel * data
 equals    we * provided: =:
 input
types format *
 if_format   
 original output
 type Asc image a full
 as `, need    of

Very similar incoherence. I'd still like to further discuss this specific problem in your issue

Although I am not sure what this implies as my original issue is not context length depended, 5 smaller images (which have way more tokens than one big) works, but one single slightly bigger image produces incoherent output.
If it helps, 2b was way more incoherent than 7b (but 7b is still very instable)

[SinanAkkoyun]

It might not help at all, but the incoherence looks similar to when I was apply the wrong ROPE scaling (at least that was the case when experimenting with exllamav2)

[SinanAkkoyun]

Interesting finding:
The official pip package v0.6.3 is broken. However, installing https://vllm-wheels.s3.us-west-2.amazonaws.com/nightly/vllm-1.0.0.dev-cp38-abi3-manylinux1_x86_64.whl fixes this issue.
(vLLM API server version 0.6.3.post2.dev139+g622b7ab9)

[Wiselnn570]

Interesting finding: The official pip package v0.6.3 is broken. However, installing https://vllm-wheels.s3.us-west-2.amazonaws.com/nightly/vllm-1.0.0.dev-cp38-abi3-manylinux1_x86_64.whl fixes this issue. (vLLM API server version 0.6.3.post2.dev139+g622b7ab9)

@SinanAkkoyun What does python 3.10.15 should install, seemly I meet the same issue, thanks a lot!!

[SinanAkkoyun]

@Wiselnn570 I installed it in python 3.11, I commented in your issue but I am uncertain why you can't build xformers