企业官网建设流程全解析

1. 先聊聊为什么要单独写一份环境变量和参数附录

做vLLM部署的同学应该都有过这种经历：翻官方文档看到某个参数，知道它能用，但不敢乱调；或者是在别人的配置文件里看到一个环境变量，完全不知道是干什么的，只能照着抄。尤其是当你从单卡部署往多卡、多机部署走的时候，环境变量和启动参数的作用会越来越重要，因为很多分布式行为、显存管理策略、请求调度逻辑，都是靠这些配置项来控制的。

这一篇就是给前面所有vLLM教程补上的一块拼图：把vLLM里常用的环境变量和核心启动参数系统性地过一遍，讲清楚每个参数解决什么问题、应该怎么取值、取值不对会有什么后果。我不打算做成官方文档的翻译版，那样你翻文档就行，没必要看我啰嗦。我更想做的是结合我实际跑模型的经历，告诉你哪些参数是必须懂的、哪些是特定场景才需要的、哪些是看着重要其实日常根本不用动的。

适合阅读这篇内容的人，主要是这几类：

• 刚开始用vLLM部署模型，想知道启动命令里那一长串参数到底是什么意思
• 已经在用vLLM，但遇到显存溢出、并发上不去、多卡效率低等问题，想通过调参解决
• 准备做生产环境部署，需要理解环境变量对镜像构建、容器运行、进程管理的影响

这里有个需要先说明的前提：vLLM的版本更新很快，参数也在不断变化。我下面写的参数和变量，是基于目前主流版本的情况，你实际使用时最好先跑一下vllm --help，看看你手上这个版本支持哪些参数，再对照本文理解含义。整体思路是通用的，具体参数的增减不影响你理解vLLM的设计逻辑。

2. 环境变量才是很多人忽略的"隐藏配置层"

很多人在刚接触vLLM时，注意力全放在启动命令那些--model、--tensor-parallel-size参数上，很少有人会专门去看环境变量。但环境变量在vLLM里扮演的角色其实非常关键，尤其是当你用Docker部署、用systemd管理服务、或者做性能调优的时候，环境变量往往是那个"最后一公里"。

2.1 显存管理相关的环境变量

先说显存，这是部署大模型时最让人头疼的一块。vLLM基于PyTorch和CUDA，所以很多显存相关的行为其实由CUDA和PyTorch的环境变量控制，vLLM自己也有几个重要的显存控制项。

CUDA_VISIBLE_DEVICES是第一个必须掌握的。这个变量的作用是控制当前进程能看到哪几块GPU，说直白点就是给GPU编号。比如一台机器有8张卡，你只想让第3和第5张卡参与计算，就可以设置：

export CUDA_VISIBLE_DEVICES=2,4

设置完之后，程序里看到的GPU编号就变成了0和1，分别对应物理上的第3和第5张卡。这个映射关系特别容易把人绕晕，尤其是在做多卡并行的时候。我的建议是：设置完这个变量后，在代码里先打印一下torch.cuda.device_count()和torch.cuda.get_device_name()，确认你看到的卡号和物理卡号对得上，再往下走。

还有个经常被忽略的细节：CUDA_VISIBLE_DEVICES的顺序是有意义的。CUDA_VISIBLE_DEVICES=4,2和CUDA_VISIBLE_DEVICES=2,4不是一回事，因为前者会把物理4号卡映射成逻辑0号卡，物理2号卡映射成逻辑1号卡。如果你用--tensor-parallel-size 2做张量并行，GPU通信的拓扑结构可能会因为这个顺序不同而产生性能差异。理想情况下，你应该把NVLink带宽最高的卡排在相邻位置，这个在单机8卡的机器上通常就是物理相邻的那几张。

VLLM_WORKER_MULTIPROC_METHOD这个变量算是vLLM自己的一个重要配置，它控制多进程启动方式。vLLM在做张量并行时，会为每张卡启动一个worker进程，这些worker进程之间的通信方式可以通过这个变量来调整，可选值包括fork和spawn。默认情况下用的是fork，因为启动速度快。但如果你发现多卡启动时出现异常、卡死，或者某个worker进程报出奇怪的问题，可以试试改成spawn：

export VLLM_WORKER_MULTIPROC_METHOD=spawn

spawn方式更安全，它会重新导入模块、初始化环境，但启动速度会慢一些。我在实际部署中遇到过一次情况：用默认的fork方式启动多卡推理，偶尔会出现CUDA context初始化冲突，改成spawn后就稳定了。如果你的场景对启动速度没那么敏感，求稳的话可以考虑直接设成spawn。

2.2 内存与CPU相关的环境变量

显存之外，CPU内存也是一个用户常踩坑的地方。vLLM在推理过程中，不仅需要显存来放模型权重和KV Cache，还需要CPU内存来做输入tensor的预处理、调度器的状态管理等等。如果你的并发请求很多、输入很长，CPU内存占用也会涨得比较快。

VLLM_NO_DEPRECATION_WARNING这个变量比较简单，设置后可以关闭弃用警告输出。如果你在代码里二次封装了vLLM，每次启动都打印一堆deprecation警告，可以在启动脚本里加上：

export VLLM_NO_DEPRECATION_WARNING=1

这样日志会干净不少。但我的建议是：在开发调试阶段不要设置，等确认没有重要警告后再关掉，别为了日志干净错过了关键信息。

VLLM_USE_V1这个变量就比较有时代特色了。vLLM在架构迭代过程中，V1引擎逐渐成为主流，官方为了保证兼容性，允许用户通过环境变量强制切换或强制回退：

export VLLM_USE_V1=1 # 强制使用V1引擎 export VLLM_USE_V1=0 # 强制使用旧版引擎

如果你遇到新版本引擎在某些模型或某些算子上行为异常，而旧版本是好的，可以通过这个变量先应急，再等待官方修复。我在一次部署Qwen系列模型时，就遇到过V1引擎下某个版本的bug导致输出概率分布异常，回退到旧引擎后问题消失。这类问题在大型项目中其实不罕见，知道这个开关就多了一条退路。

2.3 日志与调试相关环境变量

日志这块我单独拎出来说，因为排查问题的时候，日志的详细程度往往决定了你要花多少时间才能定位到问题。vLLM内部很多模块支持通过环境变量开启debug级别的日志输出。

比较常用的是VLLM_LOGGING_LEVEL，可以设置成DEBUG、INFO、WARNING、ERROR。默认是INFO，在排查调度器行为、KV Cache分配细节时，可以临时设为DEBUG：

export VLLM_LOGGING_LEVEL=DEBUG

但注意，DEBUG级别的日志量非常大，一个高并发的推理服务，每秒可能刷出几百行日志，磁盘IO和日志系统的压力都会上来。生产环境建议至少保持INFO，非必要不开DEBUG。

还有个容易被忽略的是VLLM_LOGGING_CONFIG_PATH，可以指定一个日志配置文件路径，通过日志配置文件来精细化控制各模块的日志输出格式、输出位置。如果你有统一日志收集的需求，比如接入ELK或者Loki，这个变量会让你省不少事。

2.4 其他值得留意的环境变量

VLLM_ATTENTION_BACKEND是用来指定Attention后端的，可选值包括FLASH_ATTN、XFORMERS、FLASHINFER等。正常情况不用手动设置，vLLM会基于你的GPU型号和依赖安装情况自动选择。但当你的环境里同时装了多个后端库，或者你怀疑默认选择的Attention后端在某个模型上性能不佳、甚至报错时，可以手动指定：

export VLLM_ATTENTION_BACKEND=FLASH_ATTN

这个变量在排查"为什么我的模型推理速度比别人慢"这类问题时非常有用。我有一次在A100上跑长序列推理，速度明显异常，后来发现是因为环境里没装flash-attn，vLLM回退到了xformers后端，长序列下性能差了好几倍。装上flash-attn并手动指定后，速度瞬间正常了。

还有像VLLM_TARGET_DEVICE这个变量，可以设置成cuda或cpu，用于强制指定运行设备。在做纯CPU推理验证时这个很有用，但说句实在话，CPU模式下vLLM的速度真的很慢，只适合做功能验证和教学演示，不适合生产推理。你可以试试看跑个7B模型，然后用curl发个请求等待响应时间，基本就能理解为什么大家都要用GPU了。

我把上面提到的常用环境变量整理成了一张速查表，方便你部署时快速对照：

3. 必懂的启动参数逐个拆解：从模型加载到请求调度

环境变量是"环境层面"的配置，而启动参数是"应用层面"的配置。vLLM的启动参数非常丰富，但从实际使用频率和重要性来看，并没有必要全部背下来。我按功能逻辑把它们分成几组，每组挑重点讲，讲清楚"为什么需要它"。

3.1 模型加载与基本服务配置

--model是最核心的参数，指定你要加载的模型名称或路径。可以填HuggingFace上的模型ID，也可以填本地路径。比如加载Qwen2.5-7B-Instruct，就是：

vllm serve Qwen/Qwen2.5-7B-Instruct

如果网络条件不好，或者有离线部署需求，建议先把模型下载到本地，然后直接填本地路径：

vllm serve /data/models/Qwen2.5-7B-Instruct

这里有一个非常值得注意的点：vLLM对模型格式的支持是有边界的。目前vLLM对safetensors格式支持得最好，对GGUF格式的支持也在逐步完善，但有些量化格式或者经过特殊改造的模型，vLLM可能加载不了。你从网上下载模型时，最好先看一眼文件结构，如果发现没有config.json和tokenizer.json，就要多留个心眼了。

--host和--port控制服务监听的地址和端口。默认是0.0.0.0:8000。注意，默认host是0.0.0.0，意味着所有网络接口都会监听，在公网部署时需要用防火墙或安全组做访问控制，不要把裸的API直接暴露到公网。如果你只想在本地调试，可以改成：

vllm serve /data/models/Qwen2.5-7B-Instruct --host 127.0.0.1 --port 8080

这样只有本机能访问，安全性会好很多。

--served-model-name是个容易被新手忽略的参数。它控制的是API接口中模型名称的显示值。比如你本地部署的模型路径是/data/models/Qwen2.5-7B-Instruct，但你想让客户端通过模型名qwen25-7b来访问，就可以设置：

vllm serve /data/models/Qwen2.5-7B-Instruct --served-model-name qwen25-7b

这个参数在同时部署多个模型、做模型网关时特别有用。你可以把不同厂商、不同路径的模型统一命名成同一套规范，上层调用方就不需要关心底层模型到底存在哪个路径了。

3.2 并行策略参数：单机多卡的核心控制项

--tensor-parallel-size是单机多卡部署时最重要的参数，没有之一。它决定用几张GPU做张量并行。比如你有4张A100，想把模型切到4张卡上运行：

vllm serve /data/models/Qwen2.5-7B-Instruct --tensor-parallel-size 4

这里需要重点解释一下张量并行的原理，因为理解了这个，你才能明白为什么不是并行度越高越好。张量并行把模型每一层的权重按行或者按列切分到多张GPU上，每张卡只保存一部分权重。前向计算时，每张卡的计算结果需要互相通信合并，这就会产生通信开销。用一张图来想象，就是4张卡像4个工人协同组装一台机器，虽然每个人只干一部分活，但零件在传递过程中的交接时间也是成本。

所以，张量并行度提升带来的收益并不是线性的。我实测过一个70B模型在不同并行度下的表现：从单卡不可行（显存不够），到2卡可以跑，到4卡吞吐量有明显提升，但提升幅度远小于2倍。如果你问"我应该用2卡还是4卡"，我的建议是：先把显存作为第一约束条件，在显存够用的前提下，用尽量小的并行度。并行度越小，卡间通信开销越少，单请求延迟通常也越低。

--pipeline-parallel-size是流水线并行的参数，它和张量并行一起，组成了vLLM多卡部署的两种主要并行方式。流水线并行是把模型的不同层放在不同的GPU上。比如一个24层的模型，--pipeline-parallel-size 2就表示前12层在卡0上，后12层在卡1上。相比张量并行，流水线并行的通信量更小，但会引入流水线气泡问题——就是某张卡在等前一层的输出时，自己是空闲的。

从实际部署角度讲，--pipeline-parallel-size用得远比--tensor-parallel-size少，因为大多数场景下单机多卡用张量并行就够了，流水线并行更多用在多机场景，用来跨越机器边界减少通信量。如果你只在单机上部署，我建议优先调--tensor-parallel-size。

--max-parallel-loading-workers这个参数可能很少人注意到，但它和模型加载速度直接相关。它控制加载模型权重时开多少个并行进程。默认情况下，加载一个大模型的权重需要经过：读取文件 -> 反序列化 -> 分配到各GPU worker。这个过程如果串行做，一个70B模型可能要花好几分钟。把workers调大，加载速度会明显加快：

vllm serve /data/models/Qwen2.5-7B-Instruct --tensor-parallel-size 4 --max-parallel-loading-workers 4

但这个参数也不是越大越好，太大会导致磁盘IO打满、内存峰值升高，反而拖慢速度。一般来说，和--tensor-parallel-size保持一致或者略大于它即可。

3.3 KV Cache与显存管理参数

--max-model-len是控制vLLM接受的最大序列长度（输入+输出）。这个参数跟KV Cache的显存占用直接挂钩。理解起来很简单：KV Cache的大小跟序列长度成正比，序列越长，KV Cache占用显存越多。如果不设置，vLLM会尝试从模型配置中推断一个值，但推断出来的值有时候不是你想要的。比如你只想跑短文本任务，但模型默认支持32K上下文，那KV Cache会为这32K预留大量显存，反而限制了并发数。这种情况下可以主动限制：

vllm serve /data/models/Qwen2.5-7B-Instruct --max-model-len 8192

这样显存分配就会按8K上下文来规划，同样的显存量能服务更多并发请求。但注意，设置太小会导致超长输入直接报错。这个参数本质上是在"上下文长度"和"并发能力"之间做取舍。

--gpu-memory-utilization是控制vLLM可以使用多少比例的GPU显存，取值范围是0到1之间的小数。默认是0.9，也就是最多使用90%的显存。剩下那10%是给CUDA context、PyTorch运行时、以及其他零碎开销留的余量。如果你显存比较紧张，想压榨一下：

vllm serve /data/models/Qwen2.5-7B-Instruct --gpu-memory-utilization 0.95

但这里有个教训我必须说一下：这个值不要设成1.0，也不建议超过0.95。因为一旦CUDA运行时的临时显存需求超过预留部分，进程会直接OOM崩溃，而且这种崩溃往往发生在服务运行一段时间后，不太好排查。我见过不止一次有人为了追求极限，把gpu_memory_utilization设成0.99，结果服务跑了几小时，突然在某个高并发请求下崩了。为了多挤那5%的显存去冒这个风险，非常不值。

--kv-cache-dtype是KV Cache的数据类型参数，可选值包括auto和fp8。如果你用的是H100、H200这类支持FP8的GPU，可以试一下：

vllm serve /data/models/Qwen2.5-7B-Instruct --kv-cache-dtype fp8

FP8的KV Cache可以将显存占用减半，但会带来一定的精度损失。我实测下来，在大多数任务上精度损失可以接受，但如果你做的是需要高精度的任务，比如某些代码生成或者数学推理场景，建议先用auto跑一遍基线，再对比FP8的结果，确认影响在可接受范围内。

3.4 请求调度与推理行为参数

--max-num-seqs是单个迭代步最多处理的序列数量，说白了就是最大并发序列数。这个参数直接决定KV Cache的分块数量，因为vLLM的KV Cache是按请求预分配的。比如你设了64，意味着最多同时有64个请求的KV Cache常驻显存。默认值通常是256，但256并不意味着真正能同时处理256个请求，还要看每个请求的实际长度和显存剩余量。

调这个参数时，我建议配合监控来看。vLLM的启动日志会显示KV Cache总的可用空间和每个序列的平均KV Cache显存占用。如果启动日志里显示KV Cache利用已经接近100%，你调高--max-num-seqs也没用，因为显存已经不够分了。

--max-num-batched-tokens是控制一次前向传播最多处理多少个token。这个参数与吞吐量直接相关。简单理解：如果设成4096，意思是一次前向过程最多塞进4096个token的输入。并发请求多、长度长的时候，这个值越大，单次前向能处理的token越多，吞吐量越高，但显存峰值也会更高。默认值通常是--max-model-len的数值。实际调优时，可以把max-num-batched-tokens设成一个不大不小的值，比如8192或16384，观察吞吐量变化。

--enforce-eager是一个很有意思的参数。默认情况下，vLLM会使用CUDA Graph来加速模型推理，CUDA Graph可以把一系列内核启动合并成一次图启动，显著减少kernel launch开销。但这个优化在模型首次运行时会有一个捕获和构建的过程，需要额外的显存。如果你只是想在CPU上跑一下、做个小功能验证，或者你遇到了CUDA Graph捕获时显存不足的问题，可以加：

vllm serve /data/models/Qwen2.5-7B-Instruct --enforce-eager

代价是推理性能会有所下降，尤其是小batch、短请求的场景下，性能差距更明显。所以这个参数只在必要的调试场景下用，生产环境不要加。

--trust-remote-code是加载模型时是否信任远程代码的标志。现在HuggingFace上不少模型在加载时需要执行仓库内的自定义Python代码，比如特定的modeling文件。出于安全考虑，vLLM默认不执行这些远程代码，只有当你明确加上这个参数时才执行:

vllm serve /data/models/Some-Custom-Model --trust-remote-code

这里面的安全风险需要你自己评估。从不可信的来源下载模型并加上--trust-remote-code，相当于直接在机器上执行了一段你不了解来源的代码。我的建议是：非必要不加；如果必须加，尽量从可信渠道下载模型，并且把模型下载到本地后再加载，避免每次启动都去远程拉取。

3.5 与OpenAI API兼容相关的参数

vLLM对外提供的接口高度兼容OpenAI的API格式，这也让很多基于OpenAI API开发的代码可以无缝切换过来。但有几个参数值得注意。

--api-key或环境变量VLLM_API_KEY用来设置API访问密钥。如果你的服务部署在多台机器可以访问的网络中，建议一定要设置密钥，否则任何人都能向你的推理服务发送请求，消耗你的GPU资源。

--enable-auto-tool-choice是跟工具调用相关的参数。如果你要让模型支持function calling或者tool use，需要打开这个开关。还要配合--tool-call-parser参数，指定解析器。不同的模型有不同的工具调用格式，比如Qwen、Llama的解析器各有不同。实际使用时，先查一下vLLM文档中你这个模型支持哪些Parser，别直接套用。

4. 实际部署中的参数组合：几个高频场景的参考配置

参数单独讲是一回事，放在实际场景里组合起来又是另一回事。我挑三个最常见的部署场景，分别给出我实际用过的参考配置，并解释为什么这么配。

4.1 单卡部署7B~8B模型

这是最常见的入门场景，也是很多人第一次用vLLM的场景。单张24G显存的卡（比如RTX 3090、4090或A10），跑Qwen2.5-7B或Llama-3.1-8B，配置相对简单：

vllm serve /data/models/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 32 \ --max-num-batched-tokens 4096

为什么max-num-seqs只设32？因为7B模型本身权重就要占14G左右的显存，单卡24G显存，留给KV Cache的空间大概只有6-8G。在8K上下文下，每个请求的KV Cache大约要占几十MB到一百多MB（取决于具体实现和精度），32个并发序列已经能让KV Cache占用比较饱和了。设大了反而可能OOM。

4.2 单机双卡部署14B~32B模型

当你需要跑更大的模型时，单卡放不下，就用张量并行。以两张24G卡跑Qwen2.5-14B或32B为例：

vllm serve /data/models/Qwen2.5-32B-Instruct \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 \ --max-num-seqs 64 \ --max-num-batched-tokens 8192

这里我把max-num-seqs和max-num-batched-tokens适当调高了，因为两张卡合并后，KV Cache总容量变大了。但注意，tensor-parallel-size 2意味着每张卡只保存一半的权重和一半的KV Cache，通信开销会占用一定的卡间带宽。如果模型在单卡能放下，不要轻易上双卡。

4.3 多模型共存部署

再举一个有意思的场景：同一台机器上部署多个模型服务。比如4卡机器上，一个服务用2卡跑70B模型，另一个服务用剩余2卡跑7B模型。这里要配合环境变量和启动参数一起用：

# 第一个服务：用2号卡和3号卡跑70B模型 CUDA_VISIBLE_DEVICES=2,3 vllm serve /data/models/Qwen2.5-70B-Instruct \ --tensor-parallel-size 2 \ --served-model-name qwen70b \ --port 8001 # 第二个服务：用0号卡和1号卡跑7B模型 CUDA_VISIBLE_DEVICES=0,1 vllm serve /data/models/Qwen2.5-7B-Instruct \ --tensor-parallel-size 2 \ --served-model-name qwen7b \ --port 8002

注意到我特意把两个服务的GPU物理卡分开了，这样两个进程互不干扰。这里的关键是：每个服务必须通过CUDA_VISIBLE_DEVICES限制可见GPU，否则每个vLLM进程都会默认使用所有GPU，两个服务就打起来了。

我见过不止一次有人犯这个错误：启动两个vLLM服务，没有设置CUDA_VISIBLE_DEVICES，结果两个服务都试图占用全部4卡。轻则出现CUDA OOM，重则整个机器卡死。记住：多实例部署时，环境变量隔离是第一件要做的事。

5. 参数排错实战：启动报错信息的定位思路

参数设错了，vLLM启动时通常会给出比较明确的报错信息。但报错信息有时候很长，新手容易被吓到。这里我说几个最常见的报错场景和排查思路。

5.1 "CUDA out of memory" 在启动阶段出现

如果启动时就OOM，通常说明模型权重加KV Cache的显存需求已经超过了卡的总显存。第一步不是去调gpu-memory-utilization，而是先算一笔账：模型权重大概占多少显存，剩下多少给KV Cache。比如7B模型，fp16精度下权重约占14G。一张24G的卡，留给KV Cache的只有10G左右。如果你的max-model-len设得很大，比如32K，KV Cache的规划就会吃掉大部分可用显存，甚至可能导致启动时直接OOM。

排查链路是：先看启动日志里GPU Memory Usage相关的信息，再逐步降低max-model-len和gpu-memory-utilization，直到能启动为止。

5.2 "ValueError: Model class xxx not found"

这个报错在加载一些比较新的模型时会出现，意思是vLLM不认识这个模型架构。常见的解决办法是加--trust-remote-code，但前面说过，有安全风险。更好的做法是先检查一下vLLM版本是不是太旧，很多模型架构是在新版才加入支持的。我建议定期升级vLLM到最新稳定版，很多"模型加载不上"的问题都能通过升级解决。

5.3 令牌生成速度很慢，但GPU利用率不高

这是一个困扰很多人的问题。服务能跑，但速度远低于预期。这种情况通常不是某个参数设错了，而是Attention后端选错了。先检查启动日志里Using XXX backend这一行，看当前用的是哪个后端。如果是xformers但你的GPU支持flash-attn，那就优先安装flash-attn并手动指定：

export VLLM_ATTENTION_BACKEND=FLASH_ATTN

另一个常见原因是模型权重碎片化导致显存带宽利用不充分，但这种情况通常对速度影响没有后端那么大。优先排查后端，再排查其他。

我在多次部署实践中总结了一个经验：遇到vLLM性能或稳定性问题，先把日志里的warning全部看一遍，再去找error。很多潜在问题在warning阶段就已经暴露了，比如某个算子不支持、某个后端缺失、某个特性自动回退到CPU实现，这些都会在warning里提前告诉你。

6. 再分享一份适合生产环境的启动检查清单

写到最后，我把这几年积累的vLLM部署配置经验浓缩成一份检查清单。每次你在生产环境启动服务之前，按这个清单过一遍，能省掉不少事后排查的时间。

第一，确认GPU可见范围。在启动脚本里执行nvidia-smi，核对物理GPU数量和编号，再确认CUDA_VISIBLE_DEVICES设置正确。多实例部署时，这个尤其重要。

第二，确认模型路径存在且文件完整。用ls查看模型目录，确认至少包含config.json、tokenizer.json或tokenizer.model、以及权重文件。模型文件损坏或不完整，vLLM启动时会报错或者运行后行为异常。

第三，确认端口没有被占用。通过ss -lntp或netstat -lntp查看端口占用情况，如果端口被占用，vLLM启动会直接失败。

第四，确认显存规划合理。启动前先用nvidia-smi查看当前显存占用，确保没有其他进程占用了大量显存。vLLM默认按90%的利用率去规划KV Cache，如果你机器上还有别的任务在跑，就会造成显存竞争。

第五，启动后做一个快速验证。用curl发一个最简单的请求，确认服务能正常返回：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "qwen25-7b", "messages": [{"role": "user", "content": "你好"}]}'

如果返回结果里包含choices字段，说明基本链路通了。再进一步，可以用一个小脚本连续发一批请求，观察吞吐量和延迟，确认性能符合预期。

最后说一个每次版本升级后的必做动作：跑一遍vllm serve --help，把输出保存下来，跟你之前用的参数列表对比一下。vLLM版本更新很快，有些参数会改名、废弃或者变更默认值。你旧脚本里的参数在新版本可能已经不生效了，但vLLM不一定会报错，它可能只是静默忽略，然后按新默认值运行。这类"静默变化"最坑人，不对比你根本不知道行为已经变了。