vLLM部署实战：从零搭建Qwen3-30B-FP8与GLM-5高性能推理服务

2026/8/5 7:39:22 拓冰建站浏览量

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打散成一块块“页”，然后像操作系统管理内存一样来管理这些页。这样一来，它就能实现：

近乎零浪费的显存利用：不同序列（可以理解为同时处理的多个用户提问）的KV Cache可以共享物理块，碎片大大减少。
高效的并行计算：注意力计算可以更高效地组织，GPU算力利用率飙升。
灵活的调度：支持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），以减小模型体积和加速推理。

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

直接下载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
```
自行量化：如果只有原始模型（如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，而是由以下原因导致：

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

排查步骤：

首先，在一个全新的、干净的Python环境中，用最简单的脚本测试：固定随机种子（torch.manual_seed(0),torch.cuda.manual_seed_all(0)），用temperature=0，发送完全相同的请求多次。
对比使用vLLM和直接使用Hugging Facetransformers库（同样设置种子和温度）的输出。如果两者在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驱动。

首先，确保Windows主机已安装最新版的NVIDIA显卡驱动。
在WSL2的Ubuntu中，不需要单独安装完整的CUDA Toolkit驱动，但需要安装CUDA Toolkit的用户态部分。按照NVIDIA官方指南，通常是通过apt安装cuda-toolkit-12-4这样的包。
安装完成后，在WSL2中运行nvidia-smi应该能正确显示GPU信息。
后续的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，社区的力量通常能帮你找到答案。

建站实战干货