FastDeploy大模型部署实战：从核心原理到生产级应用-编程阁

1. 项目概述：从零到一，理解FastDeploy的核心价值

如果你正在为如何将动辄数十亿、上百亿参数的大模型（LLM）或视觉语言模型（VLM）高效、稳定地部署到生产环境而头疼，那么FastDeploy这个名字你应该不陌生。作为飞桨（PaddlePaddle）生态下的官方部署套件，FastDelease的目标非常明确：解决大模型从训练到实际应用“最后一公里”的工程难题。它不是另一个简单的推理框架，而是一个集成了前沿优化技术、面向多种硬件平台、提供生产级服务能力的全栈部署解决方案。

我接触过不少部署工具，从早期的ONNX Runtime、TensorRT-LLM，到后来流行的vLLM，每个工具都有其特定的适用场景和优势。FastDeploy给我的第一印象是“务实”且“野心勃勃”。务实在于，它直接瞄准了工业部署中最核心的痛点：如何在有限的硬件资源下，同时满足高吞吐、低延迟的服务水平目标（SLO），并最大化资源利用率。野心勃勃则体现在，它试图通过一系列自研的核心技术，如负载均衡式PD分解、统一KV缓存传输等，来构建一个比现有方案更具竞争力的统一部署层。

简单来说，FastDeploy想做的，是让你拿到一个训练好的模型（无论是飞桨自家的ERNIE系列，还是兼容HuggingFace生态的模型），都能通过几条简单的命令，快速启动一个高性能、可扩展的推理服务，而无需再花费大量精力去手动集成各种优化库、编写复杂的调度逻辑。这对于算法工程师和运维工程师而言，无疑能大幅降低部署门槛，将精力更多地聚焦在业务逻辑本身。

2. 核心设计理念与架构拆解

2.1 为什么需要FastDeploy？传统部署的瓶颈

在深入技术细节前，我们先聊聊为什么大模型部署如此特殊和困难。传统的CV或NLP模型部署，模型参数相对固定，输入输出维度明确，我们可以轻松地用TensorRT或OpenVINO进行静态图优化和批处理。但大模型，尤其是自回归生成的LLM，带来了几个前所未有的挑战：

动态的序列长度：每次请求的输入（Prompt）长度和输出（Generation）长度都是可变的，且可能相差巨大。这导致计算图和内存分配无法预先静态确定。
巨大的内存占用：模型参数本身（如70B模型约140GB FP16）和推理过程中为每个请求维护的KV Cache（键值缓存）会消耗海量显存。KV Cache的大小与批次大小（batch size）和序列长度成正比，是制约吞吐量的关键因素。
不均衡的计算负载：在自回归生成过程中，模型每次只预测下一个token（即每次前向传播只计算一个token），但需要加载全部参数和对应的KV Cache。这导致了极高的“内存带宽受限”特性，计算单元（如GPU的SM）经常在等待数据从显存中读取，利用率不高。
复杂的服务场景：在线服务中，请求是随机到达的，需要系统具备动态调度、资源隔离、请求排队、优先级处理等能力。

FastDeploy的整个架构设计，正是为了系统性地应对这些挑战。它的核心思路可以概括为：“解耦、调度、复用”。

2.2 负载均衡式PD分解：资源利用率的革命性提升

这是FastDeploy最具特色的技术之一，也是其与vLLM等方案形成差异化的关键。PD分解，即“Prefill-Decode”分解。理解这一点至关重要。

在一个典型的LLM请求处理中，包含两个阶段：

Prefill（预填充）阶段：处理用户输入的整个Prompt。这个阶段计算密集，需要一次性读取整个Prompt对应的KV Cache并计算出来，对算力要求高，但通常耗时相对较短。
Decode（解码）阶段：基于Prefill阶段产生的KV Cache，逐个token地自回归生成回复。这个阶段内存带宽受限，每次计算量小，但耗时很长（取决于生成长度）。

在传统部署中，一个请求的这两个阶段在同一个GPU实例上连续执行。这会导致资源利用的“跷跷板”效应：Prefill阶段算力吃紧，但Decode阶段算力闲置，主要受限于内存带宽。

FastDeploy的PD分解，将Prefill和Decode两个阶段调度到不同的、异构的硬件实例上执行。例如，可以将计算密集的Prefill任务调度到高算力（如H100）的GPU上快速完成，然后将生成的KV Cache通过高速网络（如NVLink或RDMA）传输到成本更低、显存更大的GPU（如A100或A10）上进行长时间的Decode生成。

这样做的好处是显而易见的：

资源利用率最大化：高算力卡专攻短时高负载的Prefill，高显存卡专攻长时低负载的Decode，各司其职，避免了单一卡在不同阶段资源闲置的问题。
成本优化：可以用少量昂贵的高算力卡搭配大量相对便宜的大显存卡来构建集群，在满足相同SLO的前提下，降低总体拥有成本（TCO）。
提升系统吞吐量：Prefill的快速完成释放了高算力卡，使其可以更快地服务下一个请求的Prefill，而Decode任务在专用卡上排队执行，互不干扰。

FastDeploy通过内置的智能调度器（Router）来实现这一过程，对用户透明。你只需要定义好集群中不同角色的实例（Prefill实例和Decode实例），剩下的负载均衡和请求路由由FastDeploy自动完成。

2.3 统一KV缓存传输与全局缓存池化

PD分解带来了一个关键问题：Prefill实例产生的KV Cache如何高效地传输给Decode实例？这就是“统一KV缓存传输”库要解决的问题。

FastDeploy实现了一个轻量级、高性能的传输层，它能够智能地选择最优的传输路径：

节点内传输：如果Prefill和Decode实例在同一台物理服务器的不同GPU上，优先使用NVLink（如果可用），这是目前GPU间最快的互联技术。
跨节点传输：如果实例分布在不同的服务器上，则使用RDMA（远程直接内存访问）技术，绕过操作系统内核和CPU，实现GPU显存的直接远程读写，极大降低延迟和CPU开销。

更进一步的优化是全局缓存池化。想象一下，多个用户可能输入了相同或相似的问题（例如“介绍一下你自己”）。在传统方式下，每个请求都需要独立计算一遍这些公共前缀的KV Cache，造成重复计算。FastDeploy的全局缓存池允许将计算过的公共前缀KV Cache在集群范围内进行共享和复用。后续的请求如果命中了这些缓存，可以直接跳过这部分计算，直接从缓存中读取，显著降低Prefill阶段的延迟和计算开销。这对于高并发、存在热点问题的服务场景（如客服机器人）效果尤为显著。

3. 核心功能深度解析与实操要点

3.1 全量化格式支持：精度与性能的权衡艺术

大模型部署中，量化是压缩模型、提升推理速度、降低显存占用的必备手段。FastDeploy支持非常全面的量化格式，从相对保守的W8A16到极其激进的W2A16，以及最新的FP8格式。

W8A16 / W4A16 / W2A16：这里的“W”指权重（Weight），“A”指激活（Activation）。WnA16表示权重被量化为n比特（如8bit, 4bit, 2bit），而激活值保持FP16（半精度浮点数）。这是目前最主流的后训练量化方案，能大幅减少模型参数的存储空间和加载时的内存带宽压力，对解码（Decode）阶段的加速效果明显。通常，W4A16能在精度损失极小（<1%）的情况下，将显存占用降低至原来的1/4左右，是性价比极高的选择。
W8A8 / W4A8：将激活值也进行8bit量化。这能进一步加速计算，因为低精度矩阵运算在现代GPU（如从Hopper架构开始的FP8 Tensor Core）上可以获得更高的吞吐。但激活量化对精度更敏感，通常需要配合少量的校准数据。
FP8：这是NVIDIA Hopper架构引入的新的8位浮点数格式。与整数量化（INT8）不同，FP8保持了浮点数的表示方式，动态范围更大，对于大模型这种动态范围广的计算更为友好。FastDeploy v2.5新增的W4AFP8量化，即权重为4bit整数，激活为FP8，旨在追求极致的性能与精度平衡。

实操心得：量化策略选择在实际项目中，我的经验是：
首选W4A16：对于绝大多数追求通用性和性能平衡的场景，从W4A16开始尝试。使用FastDeploy提供的量化工具，用几百条代表性的数据做一下校准，测试在业务数据集上的精度表现，通常都能获得满意的结果。
性能极致选W4A8/FP8：如果硬件支持（如H100）且对吞吐有极致要求，可以尝试W4A8。FP8则是未来更主流的方向，如果模型和硬件都支持，应优先考虑。
谨慎使用W2A16：2bit量化对精度损伤较大，通常只用于对精度要求极低、或作为更复杂方案（如MoE模型中的专家权重）的一部分。使用前必须进行严格的评估。
注意KV Cache量化：除了权重和激活，KV Cache也可以量化。FastDeploy支持对KV Cache进行8bit量化，这能进一步减少Decode阶段的内存占用，对于超长对话或处理长文档的场景非常有用。

3.2 高级加速技术：让推理“飞”起来

除了量化，FastDeploy集成了多项前沿的推理加速技术。

推测解码：这是当前大模型推理加速的热门技术。其核心思想是使用一个小的、快速的“草稿模型”来一次性预测多个未来的token，然后用原始的大模型（“验证模型”）来并行地验证这些token。只有被大模型接受的token才会被输出。这相当于用少量额外的计算，换取了生成token数的减少，从而提升整体吞吐。FastDeploy的推测解码实现需要你准备一个草稿模型（如同一个模型的浅层版本或小模型），并在服务配置中启用。
多令牌预测：一些先进的模型（如Google的Gemma 2）在训练时就被设计为一次预测多个token。FastDeploy能够利用模型的这种原生能力，在Decode阶段一次生成多个token，直接减少自回归步数，是比推测解码更“原生”和高效的加速方式。
分块预填充：对于超长的Prompt，一次性进行Prefill会占用大量显存且可能导致延迟波动。分块预填充技术将长Prompt切分成多个块（Chunk），逐块进行Prefill和Decode的流水线处理。这样可以将峰值显存需求分摊开，使系统能够处理更长的上下文，并且让第一个token的输出时间更早，优化用户体验。

3.3 多硬件支持：拥抱国产算力生态

这是FastDeploy另一个非常重要的战略价值。它不仅支持NVIDIA GPU，还广泛支持国产AI芯片，如昆仑芯XPU、海光DCU、天数智芯GPU、燧原GCU、沐曦GPU等。这意味着，你可以用同一套代码和部署流程，在不同的国产算力平台上运行你的大模型，极大地降低了适配和迁移的成本。

每类硬件的安装和部署细节略有不同，主要体现在环境依赖、驱动和编译选项上。FastDeploy的文档为每种硬件提供了详细的安装指南。例如，对于昆仑芯XPU，你需要安装特定的驱动和PaddlePaddle版本；对于海光DCU，则需要基于ROCm生态进行适配。

注意事项：多硬件部署的坑
算子兼容性：并非所有模型的所有算子都能在每一种国产硬件上完美支持。在选型前，务必查阅FastDeploy的“支持模型列表”，确认你目标模型在目标硬件上的支持状态。最好能进行小规模的可行性测试。
性能差异：不同硬件架构、内存带宽、计算单元设计会导致性能差异。需要根据实际的吞吐和延迟要求进行性能基准测试，不能简单地将NVIDIA GPU上的预期性能平移到其他硬件上。
软件栈成熟度：国产硬件的软件栈（驱动、编译器、算子库）仍在快速发展中，可能会遇到一些NVIDIA生态中不常见的问题。保持与硬件厂商和FastDeploy社区的沟通非常重要。

4. 从安装到第一个服务：完整实操流程

4.1 环境准备与安装（以NVIDIA GPU为例）

假设我们在一台装有Ubuntu 20.04/22.04和NVIDIA驱动的服务器上部署。

步骤1：创建并激活Python虚拟环境强烈建议使用虚拟环境来管理依赖，避免污染系统环境。

conda create -n fastdeploy python=3.10 -y conda activate fastdeploy

如果你的Python版本是3.11或3.12，也需要确保在FastDeploy的支持范围内。

步骤2：安装PaddlePaddleFastDeploy依赖于特定版本的PaddlePaddle。根据CUDA版本选择对应的安装命令。例如，对于CUDA 12.0：

python -m pip install paddlepaddle-gpu==0.0.0.post120 -f https://www.paddlepaddle.org.cn/whl/linux/gpu/develop.html

这里的版本号0.0.0.post120是一个占位符，你需要从PaddlePaddle官网获取与你的CUDA和系统匹配的最新开发版或稳定版安装命令。

步骤3：安装FastDeploy最推荐的方式是通过预编译的wheel包安装，这省去了从源码编译的麻烦。

# 假设你的平台是 Linux x86_64, CUDA 12.0 pip install fastdeploy-gpu -f https://www.paddlepaddle.org.cn/package/fastdeploy/develop/whl/fastdeploy.html

安装脚本会自动从FastDeploy的发布页面寻找适合你环境的wheel包。如果找不到完全匹配的，或者你需要支持特定硬件（如XPU），则需要从源码编译，具体步骤参考官方安装文档。

步骤4：验证安装安装完成后，可以运行一个简单的Python脚本来验证核心功能是否正常。

import fastdeploy as fd print(fd.__version__) # 尝试创建一个简单的运行时配置，检查CUDA是否可用 runtime_option = fd.RuntimeOption() runtime_option.use_gpu() print(“GPU runtime initialized.”)

4.2 下载与准备模型

FastDeploy支持多种模型格式。我们以部署百度最新的ERNIE-4.5-8B模型为例。

方式一：从PaddleNLP下载（推荐）如果模型在PaddleNLP中提供，这是最直接的方式。

# 使用paddlenlp命令行工具下载 pip install paddlenlp paddlenlp download ernie-4.5-8b --output-dir ./ernie-4.5-8b

下载的目录中会包含模型结构文件（model.pdmodel）和权重文件（model.pdiparams）以及分词器配置等。

方式二：转换HuggingFace格式模型对于HuggingFace上的模型，FastDeploy提供了转换工具。

# 安装转换工具依赖 pip install transformers torch # 使用FastDeploy提供的转换脚本 # 假设脚本名为 `convert_hf_to_pd.py`，通常位于FastDeploy源码的 `tools` 目录下 python convert_hf_to_pd.py \ --model_name_or_path THUDM/chatglm3-6b \ --output_dir ./chatglm3-6b-pd \ --dtype fp16

这个脚本会将HF格式的模型权重转换为PaddlePaddle格式。--dtype参数可以指定转换的精度（如fp16, bf16）。

4.3 启动一个最简单的离线推理服务

离线推理适合批量处理或单次测试。FastDeploy提供了简洁的Python API。

import fastdeploy as fd from fastdeploy.serving import LLM # 1. 定义模型路径和运行时选项 model_dir = “./ernie-4.5-8b” runtime_option = fd.RuntimeOption() runtime_option.use_gpu(0) # 使用第0号GPU runtime_option.set_model_format(fd.ModelFormat.PADDLE) # 指定模型格式 # 2. 创建LLM实例并加载模型 # 这里使用‘llama’作为backend，因为ERNIE与Llama结构相似，FastDeploy做了兼容。 # 实际应根据模型类型选择正确的backend，如‘ernie’。 llm = LLM(model_dir=model_dir, runtime_option=runtime_option, model_format=“paddle”, model_type=“llama”) # 注意：需要根据实际模型调整model_type # 3. 准备输入 prompt = “你好，请介绍一下你自己。” messages = [{“role”: “user”, “content”: prompt}] # 4. 执行推理 result = llm.chat(messages, max_length=512, temperature=0.7) print(result[0].response)

这个例子展示了最基本的单次对话。LLM类封装了模型加载、分词、生成的全过程。你需要根据具体模型调整model_type参数，正确的类型可以从官方文档的模型支持列表或示例中找到。

4.4 启动兼容OpenAI API的在线服务

对于生产环境，我们更需要一个常驻的、支持多请求并发的服务。FastDeploy可以一键启动一个兼容OpenAI API格式的HTTP服务。

步骤1：准备配置文件创建一个YAML配置文件，例如serve_config.yaml：

# serve_config.yaml model_path: “./ernie-4.5-8b” # 模型路径 model_format: “paddle” # 模型格式 model_type: “llama” # 模型类型，同上需调整 device: “gpu” # 使用GPU gpu_memory_utilization: 0.9 # GPU显存利用率目标，0.9表示使用90%的显存 max_total_tokens: 8192 # 模型支持的最大总token数（Prompt+Generation） served_model_name: “ernie-4.5-8b” # 服务中模型的名称 api_keys: [“your-api-key-here”] # 可选的API密钥，用于简单鉴权

步骤2：启动服务使用FastDeploy内置的serving模块启动服务：

fastdeploy serve --config-path serve_config.yaml --host 0.0.0.0 --port 8000

这个命令会启动一个服务，监听在8000端口。它提供了与OpenAI ChatCompletion完全兼容的API端点。

步骤3：调用服务你可以使用任何HTTP客户端或OpenAI官方Python库来调用。

from openai import OpenAI # 注意：需要安装 openai 库: pip install openai client = OpenAI( api_key=“your-api-key-here”, # 与配置文件中一致 base_url=“http://localhost:8000/v1" # FastDeploy服务地址 ) completion = client.chat.completions.create( model=“ernie-4.5-8b”, messages=[ {“role”: “user”, “content”: “你好”} ], stream=False # 设置为True可以流式输出 ) print(completion.choices[0].message.content)

通过这种方式，你可以将现有的、基于OpenAI API开发的应用程序，几乎无缝地迁移到自己的私有化模型部署上。

5. 生产级部署进阶与问题排查

5.1 配置PD分离式部署

当你的流量增长，单卡或单实例无法满足需求时，就需要启用PD分离部署。

步骤1：规划实例角色假设我们有两台服务器，Server-A有一张H100（高算力），Server-B有两张A100（大显存）。

Prefill实例：部署在Server-A的H100上，负责快速处理所有请求的Prefill阶段。
Decode实例：部署在Server-B的两张A100上，组成一个实例组，负责处理所有请求的Decode阶段。

步骤2：编写分离部署配置文件需要为Router、Prefill实例和Decode实例分别编写配置。

Router配置 (router.yaml):

# router.yaml router: host: “0.0.0.0” port: 9999 prefills: [“http://server-a:8001”] # Prefill实例地址 decodes: [“http://server-b:8002”, “http://server-b:8003”] # Decode实例地址列表 scheduling_policy: “least_load” # 调度策略：最小负载

Prefill实例配置 (prefill_server.yaml):

# prefill_server.yaml (运行在Server-A) model_path: “./ernie-4.5-8b” model_format: “paddle” model_type: “llama” device: “gpu” gpu_ids: [0] # 使用H100 instance_role: “prefill” # 关键：指定角色为prefill max_prefill_tokens: 4096 # Prefill阶段处理的最大token数

Decode实例配置 (decode_server.yaml):

# decode_server.yaml (运行在Server-B，两个实例配置相同，端口不同) model_path: “./ernie-4.5-8b” model_format: “paddle” model_type: “llama” device: “gpu” gpu_ids: [0] # 第一个A100实例用GPU 0，第二个实例配置为[1] instance_role: “decode” # 关键：指定角色为decode max_total_tokens: 16384 # Decode实例支持的总token数可以设大一些

步骤3：启动服务

在Server-A启动Prefill实例：fastdeploy serve --config-path prefill_server.yaml --host server-a --port 8001
在Server-B启动两个Decode实例（注意端口和gpu_ids要区分）：
- 实例1:fastdeploy serve --config-path decode_server.yaml --host server-b --port 8002
- 实例2:fastdeploy serve --config-path decode_server.yaml --host server-b --port 8003(需修改配置中gpu_ids: [1])
在任意一台机器（或单独一台）启动Router：fastdeploy serve-router --config-path router.yaml

步骤4：客户端调用客户端现在不再直接连接具体的模型实例，而是连接Router。

client = OpenAI( api_key=“your-key”, base_url=“http://router-server:9999/v1" # 指向Router )

Router会根据调度策略，将请求的Prefill阶段发给Server-A的Prefill实例，生成KV Cache后，再调度到Server-B上负载较小的Decode实例进行生成。整个过程对客户端透明。

5.2 常见问题与排查技巧实录

在实际部署中，你几乎一定会遇到各种问题。以下是我踩过的一些坑和解决方法。

问题1：启动服务时报错CUDA error: out of memory

现象：服务启动失败，或处理第一个请求时崩溃。
排查：
1. 首先检查nvidia-smi，确认GPU显存是否真的被占满。可能是其他进程占用了显存。
2. 检查服务配置中的gpu_memory_utilization参数。默认值可能过高（如0.9），如果你的模型很大，或者同时运行了其他服务，可以尝试调低，例如设为0.8或0.7。
3. 检查max_total_tokens参数。这个值设得越大，为每个请求预留的KV Cache空间就越大。如果并发请求数多，即使每个请求序列不长，总占用也会很大。根据业务实际需求调低此值。
4. 考虑启用KV Cache量化（如果支持），这能显著减少显存占用。
解决：通常通过组合调整gpu_memory_utilization和max_total_tokens可以解决。公式可以粗略估算：单请求显存 ≈ 模型参数量 * 精度字节数 + max_total_tokens * 层数 * 2 * hidden_size * 精度字节数。后者就是KV Cache的大致开销。

问题2：推理速度慢，吞吐量不达标

现象：服务能跑通，但每个请求的处理时间很长，或者单位时间处理的token数（Tokens/s）很低。
排查：
1. 检查硬件：确认是否使用了性能足够的GPU（如A100/H100），并且PCIe通道或NVLink状态正常。使用nvidia-smi topo -m查看GPU间拓扑。
2. 检查配置：是否启用了TensorRT或CUDA Graph等加速后端？在runtime_option中，可以尝试runtime_option.use_trt_backend()和runtime_option.enable_cuda_graph()。但注意，CUDA Graph对动态形状的支持有限，在输入长度变化大的场景下可能不适用。
3. 检查批处理：在线服务中，FastDeploy会自动进行动态批处理。但你需要确保有足够的并发请求来形成有效的批。可以通过压测工具模拟多用户并发请求，观察吞吐是否随并发数上升而提升。
4. 检查量化：是否使用了W4A16或更激进的量化？量化是提升解码速度最有效的手段之一。
5. 使用性能分析工具：利用NVIDIA Nsight Systems或PyTorch Profiler对推理过程进行剖析，找到性能瓶颈是在计算层、内存拷贝还是其他环节。

问题3：服务响应不稳定，部分请求超时

现象：在压力测试下，部分请求耗时异常高，甚至超时。
排查：
1. 检查长尾请求：是否有些请求的Prompt特别长？长Prompt的Prefill阶段耗时本身就长。可以查看服务的日志，关注请求的输入长度。考虑是否启用分块预填充来平滑处理长文本。
2. 检查资源竞争：在PD分离部署中，如果Prefill实例过少，或Decode实例过少，会成为瓶颈。观察Router的监控指标（如果提供），或各个实例的GPU利用率和队列长度。适当增加瓶颈角色的实例数。
3. 检查调度策略：Router的scheduling_policy默认是least_load（最小负载）。也可以尝试round_robin（轮询）。在异构硬件环境中，可能需要更复杂的策略。
4. 检查网络：在PD分离部署中，Prefill和Decode实例间的网络延迟和带宽至关重要。如果跨节点传输，确保RDMA网络已正确配置且带宽充足。可以使用ib_write_bw等工具测试RDMA带宽。

问题4：国产硬件上模型运行出错

现象：在昆仑芯XPU或海光DCU上，模型加载失败或推理结果异常。
排查：
1. 确认模型支持：首要步骤是核对FastDeploy官方文档的“支持模型列表”，确认该模型-硬件组合是经过验证的。
2. 检查环境：严格按照对应硬件的安装指南操作，确保驱动、固件、基础软件栈（如PaddlePaddle的XPU/DCU版本）版本完全匹配。
3. 检查算子：错误信息中如果包含不支持的算子（op），需要反馈给FastDeploy社区或硬件厂商。有时可能需要等待新版本对特定算子的支持。
4. 精度问题：国产硬件在低精度计算（如FP16）上的结果可能与NVIDIA GPU有细微差异，这是由硬件架构和数值计算实现不同导致的。如果业务对精度极其敏感，需要进行详细的精度验证测试。

问题5：与vLLM的兼容性问题

现象：声称兼容vLLM API，但某些特定参数或调用方式不工作。
排查：
1. 理解兼容范围：FastDeploy兼容的是vLLM的核心服务API（即OpenAI兼容的ChatCompletion等接口），并不是100%克隆vLLM的所有内部接口、配置项或Python API。应首先以FastDeploy自身的文档为准。
2. 测试核心功能：重点测试/v1/chat/completions和/v1/completions等主要端点。对于stream、temperature、top_p等常用参数，兼容性通常较好。
3. 关注版本：vLLM本身在快速迭代，FastDeploy的兼容层可能基于某个特定版本的vLLM API实现。如果遇到问题，查阅FastDeploy的Release Notes或提交Issue时说明你使用的vLLM客户端版本。