[Multi Modal] Add an env var for message queue max chunk bytes

[jennyyyyzhen]

Context:
One perf bottleneck of multimodal inference is IPC. vLLM uses shared memory to broadcast small data and zmq to broadcast large data. Currently, max chunk bytes are hardcoded to be 10MB, while Llama4 single image embedding size is ~11MB, which means it now uses zmq to broadcast input. An easy way to improve multimodal perf is to increase max chunk bytes size and use shared mem.

server

HF_CHECKPOINT=meta-llama/Llama-4-Scout-17B-16E-Instruct
VLLM_MQ_MAX_CHUNK_BYTES_MB=100 vllm serve $HF_CHECKPOINT --swap-space 16 --disable-log-requests -tp 8 --max_model_len 32000 --enable_multimodal_encoder_data_parallel

benchmark

 python benchmarks/benchmark_serving.py --backend openai-chat --model $HF_CHECKPOINT --dataset-name hf --dataset-path lmarena-ai/VisionArena-Chat --hf-split train --num-prompts 1000 --endpoint /v1/chat/completions --max-concurrency 32 --ignore-eos --seed 0

100Mb max chunk bytes

============ Serving Benchmark Result ============
Successful requests:                     1000      
Benchmark duration (s):                  107.45    
Total input tokens:                      87321     
Total generated tokens:                  128000    
Request throughput (req/s):              9.31      
Output token throughput (tok/s):         1191.28   
Total Token throughput (tok/s):          2003.97   
---------------Time to First Token----------------
Mean TTFT (ms):                          480.92    
Median TTFT (ms):                        444.84    
P99 TTFT (ms):                           1247.23   
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          22.97     
Median TPOT (ms):                        22.88     
P99 TPOT (ms):                           26.75     
---------------Inter-token Latency----------------
Mean ITL (ms):                           22.79     
Median ITL (ms):                         18.05     
P99 ITL (ms):                            185.07    
==================================================

10 Mb max chunk bytes (baseline)

============ Serving Benchmark Result ============
Successful requests:                     1000      
Benchmark duration (s):                  118.35    
Total input tokens:                      87321     
Total generated tokens:                  128000    
Request throughput (req/s):              8.45      
Output token throughput (tok/s):         1081.50   
Total Token throughput (tok/s):          1819.30   
---------------Time to First Token----------------
Mean TTFT (ms):                          672.31    
Median TTFT (ms):                        582.51    
P99 TTFT (ms):                           2586.21   
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          24.20     
Median TPOT (ms):                        23.72     
P99 TPOT (ms):                           37.31     
---------------Inter-token Latency----------------
Mean ITL (ms):                           24.01     
Median ITL (ms):                         17.97     
P99 ITL (ms):                            230.45    
==================================================

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

🚀

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @jennyyyyzhen.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[houseroad]

This looks reasonable.

It will be good to add some unittest (can be done in a follow up PR like last time :-) ).

[houseroad]

Can you rebase?

[houseroad]

Also wondering @njhill 's thoughts?

[njhill]

Thanks @jennyyyyzhen. I think it may be better for this kind of parameter to be an env var rather than adding to the scheduler config object. Do you think you could add it here instead: https://github.com/vllm-project/vllm/blob/main/vllm/envs.py

Partly because I think we may make other optimizations here soon which could make this unnecessary.

Also WDYT about increasing the default to e.g. 16MB so that it will cover llama4 single image at least?

[jennyyyyzhen]

@njhill Sure. I'll make it an env var to unblock llama4 performance. I can increase the default value if there are no other concerns. However, since we also have multi-image use cases and single-image requests may be batched together, the env var is still necessary to adjust the max chunk size.

[houseroad]

We can do both: 1) increase default value, 2) introduce an env var to config it. We can use two PRs (one PR/diff one thing) to do it or in one PR is fine.

[njhill]

We can do both: 1) increase default value, 2) introduce an env var to config it. We can use two PRs (one PR/diff one thing) to do it or in one PR is fine.

@houseroad yes exactly :) may as well do both in this PR?

[jennyyyyzhen]

@houseroad @njhill updated PR with both 1) and 2)

[houseroad]

Looks good.