1. 项目缘起：为什么选择VLLM来部署这两个“大家伙”？

最近在折腾大模型本地部署的朋友，估计都绕不开一个名字：vLLM。这玩意儿现在火得不行，几乎成了高性能推理服务的代名词。我这次的任务，是把两个参数规模不小的模型——Qwen3-30B-A3B-Instruct-2507-FP8和GLM-5——给稳稳当当地跑起来。选vLLM，不是跟风，而是实打实的需求驱动。

先说说这两个模型。Qwen3-30B-A3B-Instruct-2507-FP8，这个名字看着就长，信息量也大。Qwen3是通义千问的第三代模型，30B参数，A3B这个后缀通常指代特定的架构变体或优化版本，Instruct说明是指令微调过的，2507可能是版本号，而最关键的 FP8 ，意味着这个模型权重是8位浮点数格式的。FP8是个好东西，它能在保持较高精度的前提下，显著降低显存占用和计算开销，对于30B这种规模的模型，想流畅跑起来，FP8几乎是必选项。另一个是GLM-5，智谱AI的第五代大模型，具体参数规模可能从几十亿到上千亿不等，我部署的这个版本同样对推理效率有很高要求。

那么，为什么是vLLM？简单说，就是三个字： 高吞吐 。传统的推理框架，像Hugging Face的 transformers 库，在自回归生成任务（就是大模型一个字一个字往外蹦的过程）中，有一个核心瓶颈：KV Cache的管理效率低下。每次生成新token，都需要读取和更新所有已生成token的Key和Value缓存，这个过程如果调度不好，就会造成大量的内存访问浪费和计算资源闲置。vLLM的核心黑科技 PagedAttention ，就是受操作系统虚拟内存和分页思想启发，把连续的KV Cache打散成一块块“页”，然后像操作系统管理内存一样来管理这些页。这样一来，它就能实现：

1. 近乎零浪费的显存利用 ：不同序列（可以理解为同时处理的多个用户提问）的KV Cache可以共享物理块，碎片大大减少。
2. 高效的并行计算 ：注意力计算可以更高效地组织，GPU算力利用率飙升。
3. 灵活的调度 ：支持Continuous Batching（连续批处理），新请求可以随时加入，老请求生成完了就释放资源，不会让GPU等。

对于部署Qwen3-30B-FP8和GLM-5这种模型，我们通常不是给自己一个人用，而是要搭建一个能同时服务多个请求的API服务。这时候，vLLM在吞吐量上的优势就是碾压级的。你可能会听到另一个名字——Ollama。Ollama的优势在于开箱即用、生态友好，特别适合个人快速在本地拉起一个模型进行对话和测试。但它的设计重心在易用性和资源管理，在极限的吞吐量和多用户并发处理上，和专为生产环境高性能推理设计的vLLM不是同一个赛道的产品。所以，如果你的场景是“自己玩玩”，Ollama很香；如果是“团队共用”或者“集成到应用里”，vLLM是更专业的选择。

2. 环境奠基：从零搭建一个稳定的vLLM运行环境

部署的第一步，永远是准备好战场。环境没弄好，后面全是坑。我选择在Ubuntu 22.04 LTS系统上进行，这是目前深度学习社区最主流、生态最完善的选择。下面是我一步步搭建环境的实录，其中几个关键点直接决定了后续的成败。

2.1 系统级依赖与CUDA环境

首先，确保你的系统有NVIDIA显卡，并且驱动已经正确安装。可以通过 nvidia-smi 命令验证。接下来是CUDA Toolkit，vLLM对CUDA版本有要求，建议使用CUDA 12.1或更高版本。我选择的是CUDA 12.4。

# 安装CUDA 12.4（以Ubuntu为例，具体请参考NVIDIA官方文档）
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-ubuntu2204.pin
sudo mv cuda-ubuntu2204.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/12.4.0/local_installers/cuda-repo-ubuntu2204-12-4-local_12.4.0-550.54.14-1_amd64.deb
sudo dpkg -i cuda-repo-ubuntu2204-12-4-local_12.4.0-550.54.14-1_amd64.deb
sudo cp /var/cuda-repo-ubuntu2204-12-4-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-12-4

安装后，别忘了将CUDA路径加入环境变量，通常写入 ~/.bashrc ：

export PATH=/usr/local/cuda-12.4/bin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/usr/local/cuda-12.4/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

执行 source ~/.bashrc 使其生效，然后运行 nvcc --version 确认安装成功。

注意 ：CUDA版本与PyTorch等深度学习框架的版本必须匹配。如果你后续需要安装特定版本的PyTorch，需要根据其官方提供的CUDA兼容性表格来选择CUDA版本。

2.2 Python虚拟环境与关键包安装

我强烈建议使用 conda 或 venv 创建独立的Python虚拟环境，避免包冲突。

# 使用conda创建环境（假设已安装Anaconda或Miniconda）
conda create -n vllm_env python=3.10 -y
conda activate vllm_env

# 或者使用venv
python3.10 -m venv vllm_env
source vllm_env/bin/activate

接下来安装PyTorch。务必去PyTorch官网根据你的CUDA版本选择正确的安装命令。对于CUDA 12.4，我使用的命令是：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124

现在，安装vLLM本身。这里有个大坑： 是否启用FlashAttention 。FlashAttention是一种优化注意力计算的核心算法，能极大提升速度并减少显存占用。vLLM对其有很好的集成，但安装稍微麻烦点。

方案一：安装预编译的、带FlashAttention的vLLM（推荐） 这是最省事的方法，vLLM官方提供了预编译的wheel包。

pip install vllm

这个命令会自动安装一个与你的系统兼容的、尽可能优化的版本。对于大多数常见环境（如CUDA 12.1+），它会包含FlashAttention支持。

方案二：从源码安装，以启用特定优化 如果你想确保启用了FlashAttention-2（最新版），或者需要最新的开发特性，可以从源码安装。

# 首先安装FlashAttention-2
pip install flash-attn --no-build-isolation

# 然后从源码安装vLLM
git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .  # “-e”是开发模式，方便修改代码

从源码安装时，编译过程可能会遇到各种环境问题，比如特定版本的gcc、ninja等。如果遇到错误，需要根据报错信息逐一解决系统依赖。

验证vLLM安装是否成功，并且FlashAttention是否启用：

python -c "import vllm; print(vllm.__version__); from vllm import _custom_ops; print('Custom ops (like FlashAttention) are available.')"

如果没有报错，并打印出版本号，说明基本环境OK。

2.3 模型文件准备：FP8与原始格式的差异

这是部署Qwen3-30B-FP8模型特有的环节。FP8模型不是直接下载就能用的原始PyTorch模型（ .bin 或 .safetensors 文件），它通常是经过一个叫做 量化 （Quantization）的过程转换而来的。量化将模型权重从高精度（如FP16/BF16）转换为低精度（如INT8/FP8），以减小模型体积和加速推理。

你需要明确模型来源。通常有两种情况：

1. 直接下载FP8量化模型 ：有些模型发布方会直接提供量化好的模型文件，例如在ModelScope或Hugging Face上，模型ID可能就包含了 -FP8 后缀。你需要使用对应的下载工具（如 git-lfs ）将整个仓库克隆下来。

   git lfs install
   git clone https://www.modelscope.cn/your-model-path/Qwen3-30B-A3B-Instruct-2507-FP8.git
   

2. 自行量化 ：如果只有原始模型（如FP16），你需要使用量化工具（如vLLM内置的 vllm.quantization 模块，或AWQ、GPTQ等量化算法工具包）将其转换为FP8格式。这个过程需要额外的计算资源和时间，并且要确保量化后的精度损失在可接受范围内。对于新手，强烈建议直接寻找可靠的预量化模型。

GLM-5的部署则相对常规，直接从Hugging Face或ModelScope下载原始模型文件即可。确保你有足够的磁盘空间，这两个模型加起来可能超过100GB。

实操心得 ：在下载大模型前，先检查模型的配置文件 config.json 。里面会明确写明 torch_dtype （如 float16 , bfloat16 ）和 quantization_config 。对于FP8模型，其 torch_dtype 可能仍然是 float16 ，但会有一个单独的量化配置文件（如 quantize_config.json ）来描述FP8的量化参数。vLLM在加载时会自动识别这些配置。

3. 核心部署实战：启动vLLM服务并加载模型

环境就绪，模型到位，接下来就是最激动人心的环节：把模型跑起来。vLLM提供了一个非常强大的命令行工具 vllm serve ，它基于FastAPI封装了一个高性能的OpenAI兼容的API服务器。

3.1 启动Qwen3-30B-FP8模型服务

假设你的FP8模型目录路径是 /path/to/Qwen3-30B-A3B-Instruct-2507-FP8 。启动服务的基本命令如下：

vllm serve /path/to/Qwen3-30B-A3B-Instruct-2507-FP8 \
  --model qwen3-30b-fp8 \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 8192 \
  --api-key your-api-key-here \
  --port 8000

这个命令的每一个参数都至关重要，我来逐一拆解：

• vllm serve [model] : 核心命令， [model] 可以是本地路径，也可以是Hugging Face模型ID。
• --model qwen3-30b-fp8 : 指定一个模型名称，这个名称会在API端点中使用（例如 /v1/completions ）。可以自定义，方便识别。
• --tensor-parallel-size 2 : 这是多卡并行的关键参数 。30B的模型，即使用FP8量化，单张24GB显存的卡（如RTX 4090）也很难放下。这里设置为2，表示使用两张GPU进行张量并行（Tensor Parallelism），将模型层均匀地拆分到两张卡上。你需要根据你的显卡数量和显存大小调整这个值。如果是4张卡，可以设为4。
• --gpu-memory-utilization 0.9 : 告诉vLLM可以占用每张GPU显存的90%。留出一点余量给系统和其他进程，避免OOM（内存溢出）。这个值可以微调，如果遇到CUDA内存错误，可以适当调低，如0.85。
• --max-model-len 8192 : 设置模型支持的最大上下文长度（总token数）。Qwen3-30B通常支持32K，但设置一个合理的值可以平衡性能和内存。如果你不需要极长的上下文，设为8192或16384可以节省大量KV Cache内存。
• --api-key your-api-key-here : 为API服务设置一个密钥，用于简单的权限控制。客户端请求时需要携带这个key。
• --port 8000 : 指定服务监听的端口号。

执行命令后，如果一切正常，你会看到大量的日志输出，最后停留在类似 INFO: Application startup complete. 的信息，并且没有报错。此时，服务已经在后台运行，监听 http://localhost:8000 。

3.2 启动GLM-5模型服务

启动GLM-5的命令类似，但参数可能需要调整。假设GLM-5的路径是 /path/to/GLM-5 。

vllm serve /path/to/GLM-5 \
  --model glm-5 \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.85 \
  --max-model-len 4096 \
  --port 8001

注意这里的变化：

• --tensor-parallel-size 4 : GLM-5的参数规模可能更大，需要更多的GPU进行张量并行。这里假设用了4张卡。
• --port 8001 : 因为Qwen3服务已经占用了8000端口，GLM-5服务需要换一个端口，比如8001。这样你就可以在同一台机器上同时运行两个模型服务。

3.3 服务验证与API调用

服务启动后，如何验证它工作正常？最快的方法是使用vLLM自带的OpenAI兼容的API。

首先，用 curl 测试一下completions接口：

curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-api-key-here" \
  -d '{
    "model": "qwen3-30b-fp8",
    "prompt": "请用中文介绍一下你自己。",
    "max_tokens": 100,
    "temperature": 0.7
  }'

更常用的可能是chat completions接口（如果模型支持对话格式）：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-api-key-here" \
  -d '{
    "model": "qwen3-30b-fp8",
    "messages": [
      {"role": "system", "content": "你是一个乐于助人的AI助手。"},
      {"role": "user", "content": "你好，请做个自我介绍。"}
    ],
    "max_tokens": 200,
    "temperature": 0.8
  }'

如果返回一个包含生成文本的JSON响应，并且没有错误，恭喜你，模型服务部署成功了！

你也可以使用任何兼容OpenAI API的客户端库，比如Python的 openai 库：

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key-here",
    base_url="http://localhost:8000/v1" # 注意这里指向你的vLLM服务地址
)

response = client.chat.completions.create(
    model="qwen3-30b-fp8",
    messages=[{"role": "user", "content": "你好"}],
    max_tokens=50
)
print(response.choices[0].message.content)

4. 高级配置与性能调优：让服务更稳、更快

把服务跑起来只是第一步，要让它在生产环境中稳定、高效地运行，还需要进行一系列调优。这部分内容往往是文档里不会细说的“黑魔法”。

4.1 理解并配置vLLM的推理参数

vllm serve 命令支持大量参数，下面是一些对性能影响巨大的关键参数：

• --max-num-batched-tokens : 这是控制吞吐量的核心参数之一 。它定义了每次前向传播（forward pass）时，所有正在处理的序列（包括用户输入和模型已生成的部分）的token总数上限。设置得越大，GPU利用率越高，吞吐量可能越大，但延迟也会增加，并且需要更多显存来存储KV Cache。对于30B模型，在2张4090上，可以从2048开始尝试，逐步增加（如4096, 8192），同时用 nvidia-smi 监控显存使用情况，找到一个吞吐量和延迟的平衡点。
• --max-num-seqs : 同时处理的最大请求数（即batch size）。这个值受 --max-num-batched-tokens 和 --max-model-len 限制。如果每个请求都很长，那么能同时处理的请求数就少。通常可以设置为 --max-num-batched-tokens 除以平均请求长度。
• --block-size : PagedAttention中一个“页”的大小，默认是16。这个值一般不需要改，但在某些极端序列长度下，调整它可能会影响内存碎片和效率。除非你非常了解PagedAttention的原理，否则建议保持默认。
• --swap-space : 当GPU显存不足时，vLLM可以将部分KV Cache交换到CPU内存。这个参数指定交换空间的大小（以GiB为单位）。这虽然会严重增加延迟，但可以让你运行上下文长度远超显存容量的任务。慎用，仅作为应急方案。
• --quantization : 如果你加载的是AWQ或GPTQ量化模型（非FP8），需要在这里指定量化方法，如 --quantization awq 。

一个调优后的启动命令可能长这样：

vllm serve /path/to/Qwen3-30B-A3B-Instruct-2507-FP8 \
  --model qwen3-30b-fp8 \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 16384 \
  --max-num-batched-tokens 6144 \
  --max-num-seqs 32 \
  --served-model-name qwen3-api # 在OpenAI格式的响应中返回的模型名

4.2 监控与日志：洞察服务状态

部署后，必须知道服务是否健康、性能如何。vLLM提供了Prometheus格式的指标端点。

• 基础健康检查 ：访问 http://localhost:8000/health ，应该返回简单的健康状态。
• 性能指标 ：访问 http://localhost:8000/metrics ，会返回一大堆Prometheus格式的指标数据，包括：
  • vllm:num_requests_running : 当前正在处理的请求数。
  • vllm:num_requests_swapped : 被交换到CPU的请求数。
  • vllm:request_latency_seconds : 请求延迟分布。
  • vllm:gpu_utilization : GPU利用率。
  • vllm:kv_cache_usage_ratio : KV Cache的使用率。

你可以使用Prometheus和Grafana来收集和可视化这些指标，搭建一个完整的监控看板。这对于分析服务瓶颈、进行容量规划至关重要。

另外，启动服务时可以通过 --log-level debug 来获取更详细的日志，但在生产环境中建议使用 info 级别以减少日志量。

4.3 处理“vllm serve输出不一致”问题

这是网络热词中提到的一个具体问题。所谓“输出不一致”，通常指相同输入下，模型每次生成的输出不同（即使 temperature=0 ）。这很可能不是vLLM的bug，而是由以下原因导致：

1. 非确定性算法 ：GPU上的浮点运算，尤其是低精度（如FP8、FP16）矩阵乘法，由于并行计算和硬件优化，本身可能存在微小的非确定性。这种非确定性在绝大多数应用中可忽略不计，但在极端严谨的科学计算中需要注意。
2. 采样策略 ：即使 temperature=0 （贪婪搜索），如果使用了 top_p （核采样）或 top_k ，仍然可能引入随机性。确保在需要确定性输出的场景下，将 temperature 设为0，并且不设置 top_p 和 top_k 。
3. 连续批处理（Continuous Batching） ：vLLM的连续批处理为了高效，可能会动态重组batch中请求的顺序，这理论上不应该影响单个请求的计算图，但在极其复杂的模型和特定硬件下，可能存在极边缘的影响。
4. 模型权重加载问题 ：如果模型文件在下载或量化过程中损坏，也可能导致奇怪的行为。

排查步骤 ：

• 首先，在一个 全新的、干净的Python环境 中，用最简单的脚本测试：固定随机种子（ torch.manual_seed(0) , torch.cuda.manual_seed_all(0) ），用 temperature=0 ，发送完全相同的请求多次。
• 对比使用vLLM和直接使用Hugging Face transformers 库（同样设置种子和温度）的输出。如果两者在 transformers 下一致，在vLLM下不一致，那么问题可能出在vLLM的某个环节。
• 检查vLLM的issue列表，看是否有类似报告。有时特定模型架构或量化格式可能需要vLLM的特殊适配。
• 尝试使用 --disable-custom-all-reduce 等高级参数（如果存在），禁用一些可能引入非确定性的优化。

在我的实测中，对于主流的FP16/BF16和FP8模型，在 temperature=0 时，vLLM的输出是高度稳定的。如果遇到不一致，优先从环境和参数配置上排查。

5. 生产化部署考量：Docker与多模型服务

个人测试用命令行启动就够了，但要用于团队共享或线上服务，就需要更工程化的部署方式。

5.1 使用Docker封装vLLM服务

Docker能保证环境一致性，方便迁移和扩展。vLLM官方提供了Docker镜像，但通常我们需要自定义，比如预装特定模型。

创建一个 Dockerfile ：

# 使用带有CUDA的PyTorch基础镜像
FROM pytorch/pytorch:2.3.0-cuda12.1-cudnn8-runtime

# 安装系统依赖和vLLM
RUN apt-get update && apt-get install -y git curl && \
    pip install --no-cache-dir vllm

# 将模型文件复制到镜像中（假设模型已下载到本地目录）
# 注意：这会导致镜像巨大，适用于内部网络或特定模型。
# 更佳实践是在启动容器时通过卷挂载模型目录。
COPY ./models /app/models

# 设置工作目录和启动命令
WORKDIR /app
EXPOSE 8000
CMD ["vllm", "serve", "/app/models/Qwen3-30B-A3B-Instruct-2507-FP8", \
     "--model", "qwen3", \
     "--port", "8000", \
     "--gpu-memory-utilization", "0.9"]

然后构建并运行：

docker build -t vllm-qwen3-service .
docker run --gpus all -p 8000:8000 -v /path/to/your/models:/app/models vllm-qwen3-service

这里使用了 -v 参数将宿主机上的模型目录挂载到容器内，避免了修改模型就要重做镜像的麻烦。

5.2 使用vLLM的Multi-LoRA或Multi-Model Serving

vLLM从某个版本开始，实验性地支持在一个服务中加载多个模型（或同一个基座模型的多个LoRA适配器）。这对于管理多个模型版本或进行A/B测试非常有用。不过，截至我撰写时，这个功能可能还在积极开发中，API和稳定性可能会有变化。

更稳定和常见的多模型部署方案是 为每个模型启动独立的vLLM服务进程 ，然后在前端使用一个 API网关 （如Nginx, Traefik）或 模型路由层 来分发请求。例如：

• http://your-api-host:8000 -> Qwen3服务
• http://your-api-host:8001 -> GLM-5服务

然后你可以写一个简单的路由服务，根据请求中的 model 字段，将请求代理到对应的后端端口。这种方式隔离性好，单个模型崩溃不影响其他模型，也方便独立扩缩容。

5.3 性能基准测试：使用vLLM Bench

vLLM自带了一个性能基准测试工具 vllm bench ，可以用来评估你的部署配置能达到的吞吐量（tokens/sec）和延迟。

# 基本用法，对已启动的服务进行测试
vllm bench --backend openai \
           --endpoint http://localhost:8000 \
           --model qwen3-30b-fp8 \
           --dataset sharegpt \
           --num-prompts 100 \
           --request-rate 10 # 每秒发送的请求数

这个命令会模拟一个负载，向你部署的服务发送请求，并统计性能指标。通过调整 --request-rate 和 --num-prompts ，你可以测试服务在不同压力下的表现，找到它的性能拐点和极限。这对于容量规划和性能调优是必不可少的步骤。

6. 避坑指南与疑难杂症排查

一路部署下来，不可能一帆风顺。下面是我踩过或见过的几个典型大坑，以及解决办法。

6.1 显存不足（OOM）问题

这是最常见的问题。错误信息通常包含 CUDA out of memory 。

• 原因1： --tensor-parallel-size 设置过小 。模型太大，一张或几张卡放不下。
  • 解决 ：增加 --tensor-parallel-size ，使用更多GPU。或者尝试启用 --quantization （如果模型有量化版本）。
• 原因2： --max-model-len 或 --max-num-batched-tokens 设置过大 。即使模型权重能放下，为长序列预留的KV Cache也会爆显存。
  • 解决 ：降低这两个参数的值。尤其是 --max-model-len ，根据你的实际需求设置，不要盲目设成模型支持的最大值。
• 原因3： --gpu-memory-utilization 过高 。设为1.0太激进，系统或其他进程需要显存。
  • 解决 ：降低到0.8或0.85。
• 原因4：系统或其它进程占用了显存 。
  • 解决 ：运行服务前，用 nvidia-smi 查看显存占用，尝试用 kill 命令结束不必要的进程，或者重启服务器。

6.2 模型加载失败或输出乱码

• 原因1：模型文件损坏或不完整 。
  • 解决 ：重新下载模型，并用 md5sum 或 sha256sum 校验文件完整性。对于Hugging Face模型，可以尝试用 huggingface-cli 命令下载。
• 原因2：模型格式不被vLLM识别 。vLLM主要支持Hugging Face格式的模型。一些特殊的模型格式（如旧的PyTorch .bin 格式集合）可能需要转换。
  • 解决 ：确保模型目录包含标准的 config.json , model.safetensors (或 .bin ), tokenizer.json 等文件。可以尝试用Hugging Face的 from_pretrained 方法先加载一次，看是否报错。
• 原因3：Tokenizer不匹配 。特别是中文模型，如果tokenizer配置不对，会导致编码错误，输出乱码。
  • 解决 ：检查模型目录下的 tokenizer.json 或 tokenizer_config.json 。确保vLLM使用的是正确的tokenizer。有时需要显式指定tokenizer路径： vllm serve --tokenizer /path/to/tokenizer ... 。

6.3 服务启动慢或第一次推理慢

• 原因 ：第一次启动时，vLLM需要将模型权重加载到GPU，并可能进行一些内核编译和优化（尤其是从源码安装或首次使用某种模型架构时）。
  • 解决 ：这是正常现象。生产环境中，可以在服务启动后，先发送一个“预热”请求，触发这些初始化操作，避免第一个真实用户请求等待过久。

6.4 在WSL2中部署vLLM

网络热词里有“wsl部署vllm”。在Windows Subsystem for Linux 2中部署，主要问题是 需要安装WSL2下的CUDA驱动 。

1. 首先，确保Windows主机已安装最新版的NVIDIA显卡驱动。
2. 在WSL2的Ubuntu中， 不需要 单独安装完整的CUDA Toolkit驱动，但需要安装CUDA Toolkit的 用户态 部分。按照NVIDIA官方指南，通常是通过 apt 安装 cuda-toolkit-12-4 这样的包。
3. 安装完成后，在WSL2中运行 nvidia-smi 应该能正确显示GPU信息。
4. 后续的Python环境、PyTorch、vLLM安装步骤与原生Linux相同。

踩坑实录 ：在WSL2中，有时会遇到GPU显存无法完全释放的问题。如果vLLM进程异常退出后，显存仍然被占用，可以尝试在Windows主机端重启“NVIDIA Display Container LS”服务，或者在WSL2中执行 echo 3 | sudo tee /proc/sys/vm/drop_caches （效果有限）。最彻底的方法是重启WSL实例（ wsl --shutdown ）。

部署像Qwen3-30B-FP8和GLM-5这样的大模型，从环境准备到性能调优，是一个系统工程。vLLM以其卓越的吞吐能力，让这一切变得可行。关键在于理解每个参数背后的含义，根据自身的硬件条件和业务需求（延迟 vs 吞吐）进行精细调整。监控和日志是保障服务稳定的眼睛，而Docker等容器化技术则是走向生产部署的基石。遇到问题别慌，多查日志（ --log-level debug 是你的好朋友），多查GitHub issue，社区的力量通常能帮你找到答案。