VLLM相关问题

目录

一、使用V100的显卡，设置多个进程并发调用Vllm加载的大模型时发现，模型运行起来的时间是累加起来的，说明vllm响应的多并发是按照串行的方式。

二、在引用vllm包的时候提示“ImportError: No module named vllm”

三、vllm中的参数enforce_eager设为True后会导致统计的推理时间变长

四、swap_space 设为多少合适？如何进行选择？

五、VLLM无法加载AWQ量化的模型

六、Vllm加载Qwen2.5-7B-Instruct-GPTQ-Int4Qwen2.5-14B-Instruct-GPTQ-Int4模型提示错误。

七、vLLM不能同时运行多个模型

八、vllm部署Qwen3-30B-A3B的时候，提示：There appear to be 1 leaked shared_memory objects to clean up at shutdown warnings.warn('resource_tracker: There appear to be %d '

九、使用vllm部署Qwen3-30B-A3B的时候，提示：LLVM ERROR: Failed to compute parent layout for slice layout

1. fork vs spawn 的核心区别

2. 为何推荐 spawn？

3. 性能权衡与优化

4. 官方推荐与社区实践

5. 总结

---

一、使用V100的显卡，设置多个进程并发调用Vllm加载的大模型时发现，模型运行起来的时间是累加起来的，说明vllm响应的多并发是按照串行的方式。

原因：目前这个问题不清楚是因为Vllm的不支持Vllm的原因还是其他原因。

二、在引用vllm包的时候提示“ImportError: No module named vllm”

（一）错误提示：

Traceback (most recent call last):
  File "test.py", line 3, in <module>
    from vllm import LLM, SamplingParams
ImportError: No module named vllm

（二）排查：

首先，排查是否正确安装了vllm包，如果没有的话，就pip install vllm。

我这里是正常安装了的，甚至又重新装了一遍。

（三）原因：

当前或父级目录下有一个文件夹名字vllm与vllm库名字冲突，import命令将其放在了vllm库优先级之前，换个路径运行就可以了，或者重命名文件夹（我选择重命名了文件夹）。

三、vllm中的参数enforce_eager设为True后会导致统计的推理时间变长

1.概念：

enforce_eager是一个参数，用于控制vLLM是否始终使用PyTorch的eager模式（即时执行模式），默认为False，vLLM会默认使用eager模式和CUDA图的混合模式来执行操作，这种混合模式旨在提供最大的性能和灵活性。

CUDA图是PyTorch中用于优化性能的一种技术。禁用CUDA图（即设置enforce_eager为True）可能会影响性能，但可以减少内存需求。对于小型模型，CUDA图可能对性能提升有帮助，但对于大型模型，性能差异可能不大

2.总结：

（1）如果模型较小，且性能是关键考虑因素，可以考虑使用CUDA图，即默认状态，不做变动。
（2）如果模型较大，或者需要减少内存使用，可以考虑启用enforce_eager。
（3）在实际部署之前，最好进行一系列的测试，以确定最佳的配置。可以先尝试不启用enforce_eager，如果遇到显存不足或性能问题，再考虑启用它。

3.解决方案：

最终去掉了这个参数后，总体推理时间恢复到20s，如果设置enforce_eager=True，则推理时间为100s+，推理时间差距太大了。

from vllm import LLM, SamplingParams

llm = LLM(
        model="model/Qwen2.5-32B-Instruct-GPTQ-Int4",
        tensor_parallel_size=8,
        trust_remote_code=True,
        dtype="half",
        max_num_batched_tokens=32768,  # 减小批处理token数--最大32768可能超出内存
        gpu_memory_utilization=0.85,  # 降低GPU显存使用率
        swap_space=4,  # 增加CPU内存交换空间
        # enforce_eager=True,  # 强制即时执行模式
        max_num_seqs=64,  # 限制最大序列数
        # max_model_len=4096,  # 限制模型最大长度(这个参数是R1蒸馏的模型必须要有的)
    )

四、swap_space 设为多少合适？如何进行选择？

swap_space 参数的选择需要根据以下几个因素来权衡：
1.模型大小：
Qwen2.5-32B 模型约需要 32GB 的模型权重空间
在 half precision (FP16) 下，基础内存需求约为 16GB
运行时还需要额外的内存用于 attention cache 和中间激活值
2.GPU显存容量：
如果您使用 8 张 GPU (tensor_parallel_size=8)
每张卡大约需要处理 32B/8 ≈ 4GB 的模型权重
加上运行时内存，每张卡实际需求会更高
3.swap_space 计算参考公式：
recommended_swap = (model_size_gb / num_gpus) * swap_factor

选择建议：
1.保守设置：
如果 GPU 显存较小，设置较大的 swap_space (6-8GB)
会牺牲一些性能，但能确保稳定运行
2.平衡设置：
对于常见的配置，设置 4GB 通常是个不错的选择
在性能和稳定性之间取得平衡
3.激进设置：
如果 GPU 显存充足，可以设置较小的 swap_space (2GB或更少)
能获得更好的性能，但要注意监控内存使用
4.动态调整：
可以从较大值开始（如 6GB）
逐步减小并监控性能和稳定性
找到最适合您硬件的值
5.监控指标：
如果看到 OOM 错误，需要增加 swap_space
如果 CPU 使用率过高，可能 swap 太大
如果生成速度明显变慢，可以尝试减小 swap_space
6.# 根据不同情况选择 swap_space
    swap_space=6,  # 如果 GPU 显存较小（如 24GB）
    # swap_space=4,  # 如果 GPU 显存较大（如 32GB）
    # swap_space=2,  # 如果 GPU 显存充足（如 40GB+）

五、VLLM无法加载AWQ量化的模型

结论：经过实验，VLLM无法加载AWQ量化的模型。

六、Vllm加载Qwen2.5-7B-Instruct-GPTQ-Int4Qwen2.5-14B-Instruct-GPTQ-Int4模型提示错误。

提示内容：The input size is not aligned with the quantized weight shape. This can be caused by too large tensor parallel size.（输入大小与量化权重形状不对齐。这可能是由太大的张量并行大小引起的）

设置的参数：

python -m vllm.entrypoints.openai.api_server \
--model /data/sxw/3-model/Qwen2.5-14B-Instruct-GPTQ-Int4  \
--served-model-name Qwen2.5-14B-Instruct-GPTQ-Int4 \
--gpu-memory-utilization 0.85 \
--max-num-batched-tokens 32768 \
--max-model-len 8192 \
--dtype half \
--tensor-parallel-size 8 \
--swap-space 4 \
--max-num-seqs 100 \

修改参数：

python -m vllm.entrypoints.openai.api_server \
--model /data/sxw/3-model/Qwen2.5-14B-Instruct-GPTQ-Int4  \
--served-model-name Qwen2.5-14B-Instruct-GPTQ-Int4 \
--gpu-memory-utilization 0.85 \
--max-num-batched-tokens 32768 \
--max-model-len 4096 \
--dtype half \
--tensor-parallel-size 8 \
--swap-space 4 \
--max-num-seqs 64 \

 提示：Total number of attention heads (40) must be divisible by tensor parallel size (7)

并行数设为8不合适，并且并行数还得能被40整除，于是将tensor-parallel-size设为4。但依然报错

UserWarning: resource_tracker: There appear to be 1 leaked shared_memory objects to clean up at shutdown warnings.warn('resource_tracker: There appear to be %d '。

Failed: Cuda error /workspace/csrc/custom_all_reduce.cuh:364 'invalid argument'

最终原因：是Qwen2.5-7B-Instruct-GPTQ-Int4和Qwen2.5-14B-Instruct-GPTQ-Int4的模型在用vllm运行的时候，只能使用一张卡。tensor parallel size 只能设为1。

七、vLLM不能同时运行多个模型

经过测试，在Vllm使用命令已经加一个模型运行后，再运行另一个模型，就会提示：OSError: [Errno 98] Address already in use，尝试可参考：vLLM 同时部署多个模型及调用_vllm部署多个模型-CSDN博客

所以，Vllm无法像ollama那样同时加载多个模型在显存中，想调用哪个的模型的时候就直接使用API等方式调用。

八、vllm部署Qwen3-30B-A3B的时候，提示：There appear to be 1 leaked shared_memory objects to clean up at shutdown warnings.warn('resource_tracker: There appear to be %d '

使用的解决方案是：调整环境变量规避问题

• 设置 VLLM_WORKER_MULTIPROC_METHOD 为 spawn（默认为 fork），减少共享内存泄漏风险：

export VLLM_WORKER_MULTIPROC_METHOD=spawn

其他可能原因及解决方法

1. 未正确关闭模型实例

• 原因 : 在服务结束后（如程序退出），若未主动释放模型占用的共享内存资源，系统会提示内存泄漏。

• 解决方法 : 显式调用模型清理函数或关闭服务。

  from vllm import LLM, SamplingParams
  
  # 加载模型
  llm = LLM(model="Qwen/Qwen3-30B")
  
  # 使用后释放资源
  del llm # 或调用特定清理接口（根据实际 API 文档调整）

2. 多进程/异步任务未完全终止

• 原因 : 如果使用了多进程或异步推理任务，某些后台进程可能仍在运行并占用共享内存。

• 解决方法 : 确保所有子进程正常终止。

  import multiprocessing
  
  # 启动进程
  process = multiprocessing.Process(target=run_model)
  process.start()
  process.join() # 等待进程结束

3. 框架版本兼容性问题

• 原因 : vLLM 或 Python 的 multiprocessing 模块可能存在旧版本的共享内存管理缺陷。
• 解决方法 : 升级到最新版本：

  pip install --upgrade vllm

  pip install --upgrade torch

4. 手动清理残留资源

• 临时方案 : 手动查找并删除残留的共享内存对象。

  # 查看当前共享内存
  ipcs -m
  
  # 删除指定 ID 的共享内存（替换为实际 ID）
  ipcrm -m <shmid>

• 注意 : 此操作需谨慎，避免误删其他进程的内存。

九、使用vllm部署Qwen3-30B-A3B的时候，提示：LLVM ERROR: Failed to compute parent layout for slice layout

解决方法：把dtype不能设为half，设为float32.

十、export VLLM_WORKER_MULTIPROC_METHOD 设置为spawn 和fork有什么区别？更推荐哪个？

1. fork vs spawn 的核心区别

特性	fork (默认)	spawn (推荐)
工作原理	复制父进程的全部内存和状态	重新启动 Python 解释器，仅传递必要参数
速度	快（直接复制内存）	较慢（重新初始化）
安全性	低（可能继承父进程锁/句柄导致死锁）	高（避免共享状态残留）
CUDA/GPU 兼容性	差（子进程可能继承父进程的 CUDA 上下文导致崩溃）	好（独立初始化 CUDA 环境）
跨平台支持	仅类 Unix 系统（Linux/MacOS）	所有系统（包括 Windows）
适用场景	简单、无 GPU 的纯 CPU 任务	涉及 GPU、多线程或复杂依赖的任务

2. 为何推荐 spawn？

在 vLLM 的 GPU 推理场景 中，spawn 是更安全的选择，原因如下：

1. 避免 CUDA 上下文污染

   • fork 会复制父进程的 CUDA 上下文，导致子进程与父进程共享 GPU 资源，可能引发 CUDA_ERROR_ILLEGAL_ADDRESS 等错误。

   • spawn 通过重新初始化 CUDA 环境，确保每个子进程有独立的 GPU 上下文。

2. 防止死锁和资源泄漏

   • fork 会复制父进程的所有线程和锁，若父进程中有未释放的锁（如 PyTorch 内部锁），子进程可能直接死锁。

   • spawn 从头初始化进程，避免了锁和线程状态的继承。

3. 兼容复杂依赖

   • 当使用 PyTorch、TensorFlow 等涉及底层硬件加速的库时，spawn 能更好地处理库的初始化流程。

 

3. 性能权衡与优化

指标	fork	spawn
启动延迟	低（毫秒级）	较高（秒级）
内存占用	高（复制父进程内存）	低（按需初始化）
长期稳定性	低	高

• 优化建议：
  若因 spawn 导致启动变慢，可通过预加载模型权重或复用 Engine 实例减少重复初始化开销。

4. 官方推荐与社区实践

• vLLM 官方文档 明确指出：在涉及 GPU 的分布式推理中，应优先使用 spawn 方法 (vLLM Docs)。

• PyTorch 多进程指南 建议：使用 CUDA 时，spawn 是唯一安全的选择 (PyTorch Multiprocessing)。

5. 总结

• 优先选择 spawn：适用于所有涉及 GPU、CUDA 或复杂依赖的 vLLM 部署场景。

• 谨慎使用 fork：仅在纯 CPU 推理且无复杂线程/锁交互的简单任务中使用。