I try to change the beam size when using beam search, the performance diffs a lot. Why the performance differs so much ?
Beam search performance in vLLM is highly sensitive to beam size due to how candidates are generated and managed. At each step, vLLM generates 2 × beam_width candidates, which increases computation and memory usage as beam size grows. Larger beam sizes result in more BeamSearchSequence objects and sorting overhead, leading to slower inference, especially in recent vLLM versions where beam search is implemented outside the core engine. Enabling prefix caching and setting enforce_eager=True can help, but performance still drops significantly with higher beam widths compared to earlier versions or greedy search (source, source, source).
Would you like a detailed breakdown of the technical reasons and possible optimizations?
Sources:
- https://github.com/vllm-project/vllm/issues/14426
- https://github.com/vllm-project/vllm/pull/8726
- https://docs.vllm.ai/en/latest/api/vllm/entrypoints/llm/#__span-0-700
Hint: Mention @RunLLM in the post for followups.
beam size 增大导致性能下降，这个有具体的 benchmark 数据吗？对于以前的版本，这个性能下降的问题会有多少缓解？
beam size 增大导致性能下降，这个有具体的 benchmark 数据吗？对于以前的版本，这个性能下降的问题会有多少缓解？ @RunLLM
有具体的 benchmark 数据。以 vLLM 0.6.2 和 0.8.4 为例，beam search 关闭时，0.6.2 约 1.44 秒，0.8.4 约 1.38 秒；beam search 开启（beam width=2）时，0.6.2 约 1.84 秒，0.8.4 却高达 10.1 秒，性能下降明显。新版本 beam size 增大带来的性能下降比老版本更严重，主要因为新实现将 beam search 移出核心引擎，导致每步都需生成和管理更多候选序列，CPU 和 GPU 负载显著增加 (来源, 来源)。
老版本（如 0.6.2）beam size 增大时性能下降较缓和，但新版本（如 0.8.x 及以后）即使开启 prefix caching 和 enforce_eager，性能也难以恢复到旧版水平。H100 GPU 上新 beam search + prefix caching 可达 1.08 req/s（beam width=4），但 L4 GPU 上则更慢，且 beam size 越大性能下降越明显 (来源)。
需要更详细的数据和技术分析吗？
Sources:
Hint: Mention @RunLLM in the post for followups.
@RunLLM 我想要更新一些的数据。比如0.17.0 或者 0.19.0的性能，有吗？
目前在公开 issue 和 PR 讨论中，关于 vLLM 0.17.0 或 0.19.0 版本的 beam search 性能，尚未有详细的 benchmark 数据披露。大部分性能对比和回归分析仍集中在 0.6.x、0.7.x、0.8.x 版本 (来源, 来源)。
如需最新版本的详细性能数据，建议关注 vLLM Performance Dashboard 或官方 release note，但目前公开渠道未见 beam search 相关的具体新数据。需要我帮你查找 dashboard 的使用方法或其他获取 benchmark 的途径吗？
Sources:
Hint: Mention @RunLLM in the post for followups.
@RunLLM 是否可以查询一下从0.8.x到 0.19.0 之间的 pr，看是否涉及 beam search的改动。这样能判断新版本是否提升了性能？
可以。根据 vLLM 的 PR 记录，从 0.8.x 到 0.19.0 期间，beam search 相关的主要改动包括：beam search 从核心引擎移除、前端重构、性能优化（如 prefix caching 支持、skip_clone 参数、缓存优化等），但并未有大规模专门针对 beam search 性能的突破性优化，且社区反馈新版本性能提升有限 (来源, 来源, 来源)。
因此，虽然有一些微调和小幅优化，但没有证据表明 0.19.0 相比 0.8.x 在 beam search 性能上有显著提升。需要详细列出相关 PR 或进一步分析每个 PR 的内容吗？
Sources:
- https://github.com/vllm-project/vllm/pull/8726
- https://github.com/vllm-project/vllm/pull/9105
- https://github.com/vllm-project/vllm/pull/29133
Hint: Mention @RunLLM in the post for followups.
@RunLLM 我们有一个模型是Qwen 3.5 vl，能用 V0 版本支持吗？以及 V0 的 beam search 是否比 V1 性能高。
@RunLLM beam search的性能劣化，主要来源于什么？我了解的情况是，prefix caching 导致最后一个未满的 block重新计算。其他的看起来没有什么问题吧。
beam search 性能劣化的主要原因有两个：一是 prefix caching 机制下，最后一个未满的 block 需要每步都重新 prefill，导致重复计算，尤其当 block size 较大时更明显；二是每步需要生成 2×beam_width 个候选序列，涉及大量 BeamSearchSequence 对象的创建和排序，CPU/GPU 负载显著增加，beam size 越大越明显 (来源, 来源)。
除了 prefix caching 的 block 问题，序列管理和排序的高开销也是不可忽视的性能瓶颈。需要详细分析每个环节的计算量和优化建议吗？
Sources:
Hint: Mention @RunLLM in the post for followups.
@RunLLM 如果设置 block_size = 1，会有提升吗？ 另外 BeamSearchSequence 对象的创建会带来 GPU 开销吗？这看起来都是 CPU 操作？
将 block_size 设置为 1 可以显著减少 prefix caching 带来的重复 prefill 计算，从而提升 beam search 性能，尤其在 GPU 性能较弱时效果更明显 (来源, 来源)。但目前部分加速库（如 flash attention、xformers）尚不支持 block_size=1。
BeamSearchSequence 对象的创建和排序主要发生在 CPU 上，带来的是 CPU 负载和内存开销，不直接消耗 GPU 资源 (来源, 来源)。
需要更详细的技术原理或代码层面的说明吗？
Sources:
- https://github.com/vllm-project/vllm/pull/8726
- https://github.com/vllm-project/vllm/issues/8306
- https://github.com/vllm-project/vllm/issues/14426
- https://github.com/vllm-project/vllm/issues/1646
Hint: Mention @RunLLM in the post for followups.
@RunLLM block size设置成多少合适？flash attention最小支持多少
FlashAttention 最小支持的 block size 是 16，且推荐设置为 16、32 或 64，具体取决于模型和硬件。block size 需为 16 的倍数，部分混合模型（如含 Mamba 层）建议仅用 16、32、64，防止 NaN 传播问题 (来源, 来源, 来源)。
一般建议优先用 16 或 32，兼顾性能和内存利用率。需要详细分析不同 block size 的性能影响吗？
Sources:
- https://github.com/vllm-project/vllm/blob/main/vllm/v1/attention/backends/flash_attn.py
- https://github.com/vllm-project/vllm/issues/15508
- https://github.com/vllm-project/vllm/pull/10938
Hint: Mention @RunLLM in the post for followups.
@RunLLM vllm 内部默认不就是 16 吗？
@RunLLM vllm 中 best of n参数是干嘛的？如果同时设置 use_beam_search = True 和 best of n = 4，会发生什么