vLLM性能调优：max_num_seqs参数深度解析与最佳实践

14 阅读

引言

在深度学习推理领域，vLLM凭借其高吞吐量和低延迟的特性，已成为部署大语言模型（LLM）的主流框架之一。然而，要充分发挥vLLM的性能潜力，深入理解其核心调度参数至关重要。其中，max_num_seqs作为控制并发请求数量的关键参数，直接影响系统的资源利用率和响应速度。本文将从源码层面剖析max_num_seqs的工作原理，探讨其对内存、调度和性能的多维影响，并提供实用的调优建议，帮助你在实际部署中做出明智的配置决策。

参数定义与默认值

max_num_seqs是vLLM调度器中的一个核心配置项，用于限制单个调度步骤中同时处理的最大序列（即请求）数量。在vLLM的源码中，该参数定义于vllm/vllm/config/scheduler.py的SchedulerConfig类，其默认值为128。

DEFAULT_MAX_NUM_SEQS: ClassVar[int] = 128

这个默认值适用于大多数场景，但在实际部署中，需要根据硬件资源（尤其是GPU内存）和业务需求进行调整。

核心作用机制

调度器层面的限制

在vLLM的调度器（Scheduler）中，max_num_seqs被转换为max_num_running_reqs，用于限制同时处于运行状态（RUNNING）的请求数量。调度器在每次调度时，会检查当前运行中的请求数是否已达到上限，若达到则停止从等待队列中调度新请求。

# 调度器初始化
self.max_num_running_reqs = self.scheduler_config.max_num_seqs

# 调度循环中
if len(self.running) == self.max_num_running_reqs:
    break

这意味着，当运行中的请求数达到max_num_seqs时，新到达的请求将进入等待队列（WAITING），直到有运行中的请求完成或被抢占。这种机制确保了系统不会因过度并发而导致资源耗尽。

内存分配与缓冲区大小

max_num_seqs不仅影响调度，还直接决定了Worker中多个缓冲区的分配大小。这些缓冲区用于存储请求状态、输入数据和KV Cache的块表。

RequestState缓冲区

在vllm/vllm/v1/worker/gpu/states.py中，RequestState类使用max_num_reqs（即max_num_seqs）来分配所有请求相关的状态缓冲区。例如：

self.prompt_len = np.zeros(self.max_num_reqs, dtype=np.int32)
self.prefill_token_ids = UvaBuffer(self.max_num_reqs, self.max_model_len, dtype=torch.int32)

其中，prefill_token_ids缓冲区的大小为max_num_reqs × max_model_len × 4字节（int32类型）。以max_num_seqs=128、max_model_len=32768为例，仅此一个缓冲区就需要128 × 32768 × 4 = 16MB内存。所有请求状态缓冲区的总大小与max_num_seqs成正比，因此增大该参数会显著增加GPU内存占用。

InputBuffers与BlockTables

InputBuffers用于存储每个推理步骤的输入数据，其大小同样受max_num_seqs影响。BlockTables则用于管理KV Cache的块表，其分配也依赖于max_num_seqs。这些缓冲区的内存占用会随着max_num_seqs的增大而线性增长，因此在配置时需要谨慎评估GPU内存容量。

数据并行（DP）场景下的特殊含义

在vLLM-Ascend等支持数据并行的版本中，max_num_seqs表示每个DP group允许处理的最大请求数。总并发能力由以下公式决定：

总并发能力 = max_num_seqs × data_parallel_size

例如，若max_num_seqs=16，data_parallel_size=2，则系统最多可同时处理32个请求。如果实际并发请求数超过此值，多余的请求将排队等待。在性能测试中，建议确保max_num_seqs × data_parallel_size >= 实际总并发数，否则等待时间会被计入TTFT（Time To First Token）和TPOT（Time Per Output Token）等指标，导致性能数据失真。

与max_num_batched_tokens的关系

max_num_seqs和max_num_batched_tokens共同决定了批处理的能力。max_num_batched_tokens限制单次推理步骤中处理的总token数，而max_num_seqs限制请求数。vLLM在配置验证中强制要求max_num_batched_tokens >= max_num_seqs，否则会抛出异常。

if self.max_num_batched_tokens < self.max_num_seqs:
    raise ValueError(...)

此外，若max_num_batched_tokens超过max_num_seqs × max_model_len，会触发警告，因为这可能导致意外行为。理解两者的关系有助于合理设置批处理大小，避免资源浪费或性能瓶颈。

影响范围分析

内存占用

max_num_seqs直接影响多个缓冲区的大小，包括请求状态、输入数据和块表。内存占用随max_num_seqs线性增长，因此过大的设置可能导致OOM（Out of Memory）错误。在GPU内存有限的环境中，需要权衡并发能力与内存消耗。

调度性能

  • 吞吐量：较大的max_num_seqs允许更多请求并发处理，可能提高吞吐量，因为GPU可以同时处理更多请求，提高计算资源利用率。
  • 延迟：如果max_num_seqs太小，请求会在等待队列中停留更长时间，增加端到端延迟。
  • 批处理效率：每次推理步骤最多处理max_num_seqs个请求。若实际请求数远小于该值，批处理可能不够满，导致GPU利用率下降；若请求数过多，则需要多步处理，增加延迟。

并发处理能力

max_num_seqs直接限制了系统同时处理的请求数。在数据并行场景下，总并发能力为max_num_seqs × data_parallel_size。若实际并发超过此值，请求将排队，影响用户体验。

调优建议

根据硬件资源调整

  • GPU内存充足：可设置较大的max_num_seqs（如256、512），以提高并发和吞吐量。
  • GPU内存受限：需减小max_num_seqs（如64、32），避免OOM。建议通过监控内存使用情况来动态调整。

根据工作负载调整

  • 高并发场景：确保max_num_seqs × data_parallel_size >= 预期并发数，避免请求长时间等待。
  • 低延迟优先：适当减小max_num_seqs，减少批处理大小，降低单步处理时间，从而降低延迟。
  • 高吞吐量优先：增大max_num_seqs，提高批处理效率，但需注意内存限制。

与max_num_batched_tokens的平衡

  • 确保max_num_batched_tokens >= max_num_seqs。
  • 对于短序列请求，可设置max_num_batched_tokens远大于max_num_seqs，以充分利用token预算。
  • 对于长序列请求，需确保max_num_batched_tokens足够大，以容纳单个请求的完整序列。

数据并行场景

  • 计算总并发能力：总并发能力 = max_num_seqs × data_parallel_size。
  • 根据实际并发需求调整max_num_seqs，确保总并发能力满足要求。

代码示例

在vLLM中设置

from vllm import LLM

llm = LLM(
    model="your-model",
    max_num_seqs=128,  # 设置最大序列数
    max_num_batched_tokens=2048,  # 必须 >= max_num_seqs
)

在vLLM-Ascend中设置

vllm serve Qwen/Qwen3-VL-235B-A22B-Instruct \
    --max-num-seqs 16 \
    --data-parallel-size 2 \
    --max-num-batched-tokens 4096 \
    ...

验证配置

vLLM会在SchedulerConfig中自动验证参数合法性，若max_num_batched_tokens < max_num_seqs，会抛出ValueError。

常见问题解答

Q1: max_num_seqs设置太小会怎样？

A：请求会在等待队列中停留更长时间，导致吞吐量下降和延迟增加（等待时间计入TTFT/TPOT）。

Q2: max_num_seqs设置太大会怎样？

A：GPU内存占用增加，可能导致OOM；若实际请求数远小于该值，批处理效率可能下降，GPU利用率不足。

Q3: 如何确定合适的max_num_seqs？

A：首先根据GPU内存容量估算上限，然后根据实际并发需求计算所需值（max_num_seqs × data_parallel_size >= 并发数），最后通过性能测试找到最佳平衡点。

Q4: max_num_seqs和max_num_batched_tokens的区别？

A：max_num_seqs限制请求数量，max_num_batched_tokens限制token数量，两者共同决定批处理能力。

总结

max_num_seqs是vLLM中一个关键的调度和资源管理参数，它限制了并发请求数，决定了内存分配，并直接影响吞吐量、延迟和GPU利用率。在数据并行场景下，总并发能力等于max_num_seqs乘以数据并行大小。合理设置该参数需要在内存占用、并发能力和性能指标之间找到平衡。通过理解其工作原理和调优策略，你可以更有效地部署vLLM服务，满足不同业务场景的需求。