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_DEVICES2,4设置完之后程序里看到的GPU编号就变成了0和1分别对应物理上的第3和第5张卡。这个映射关系特别容易把人绕晕尤其是在做多卡并行的时候。我的建议是设置完这个变量后在代码里先打印一下torch.cuda.device_count()和torch.cuda.get_device_name()确认你看到的卡号和物理卡号对得上再往下走。还有个经常被忽略的细节CUDA_VISIBLE_DEVICES的顺序是有意义的。CUDA_VISIBLE_DEVICES4,2和CUDA_VISIBLE_DEVICES2,4不是一回事因为前者会把物理4号卡映射成逻辑0号卡物理2号卡映射成逻辑1号卡。如果你用--tensor-parallel-size 2做张量并行GPU通信的拓扑结构可能会因为这个顺序不同而产生性能差异。理想情况下你应该把NVLink带宽最高的卡排在相邻位置这个在单机8卡的机器上通常就是物理相邻的那几张。VLLM_WORKER_MULTIPROC_METHOD这个变量算是vLLM自己的一个重要配置它控制多进程启动方式。vLLM在做张量并行时会为每张卡启动一个worker进程这些worker进程之间的通信方式可以通过这个变量来调整可选值包括fork和spawn。默认情况下用的是fork因为启动速度快。但如果你发现多卡启动时出现异常、卡死或者某个worker进程报出奇怪的问题可以试试改成spawnexport VLLM_WORKER_MULTIPROC_METHODspawnspawn方式更安全它会重新导入模块、初始化环境但启动速度会慢一些。我在实际部署中遇到过一次情况用默认的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_WARNING1这样日志会干净不少。但我的建议是在开发调试阶段不要设置等确认没有重要警告后再关掉别为了日志干净错过了关键信息。VLLM_USE_V1这个变量就比较有时代特色了。vLLM在架构迭代过程中V1引擎逐渐成为主流官方为了保证兼容性允许用户通过环境变量强制切换或强制回退export VLLM_USE_V11 # 强制使用V1引擎 export VLLM_USE_V10 # 强制使用旧版引擎如果你遇到新版本引擎在某些模型或某些算子上行为异常而旧版本是好的可以通过这个变量先应急再等待官方修复。我在一次部署Qwen系列模型时就遇到过V1引擎下某个版本的bug导致输出概率分布异常回退到旧引擎后问题消失。这类问题在大型项目中其实不罕见知道这个开关就多了一条退路。2.3 日志与调试相关环境变量日志这块我单独拎出来说因为排查问题的时候日志的详细程度往往决定了你要花多少时间才能定位到问题。vLLM内部很多模块支持通过环境变量开启debug级别的日志输出。比较常用的是VLLM_LOGGING_LEVEL可以设置成DEBUG、INFO、WARNING、ERROR。默认是INFO在排查调度器行为、KV Cache分配细节时可以临时设为DEBUGexport VLLM_LOGGING_LEVELDEBUG但注意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_BACKENDFLASH_ATTN这个变量在排查为什么我的模型推理速度比别人慢这类问题时非常有用。我有一次在A100上跑长序列推理速度明显异常后来发现是因为环境里没装flash-attnvLLM回退到了xformers后端长序列下性能差了好几倍。装上flash-attn并手动指定后速度瞬间正常了。还有像VLLM_TARGET_DEVICE这个变量可以设置成cuda或cpu用于强制指定运行设备。在做纯CPU推理验证时这个很有用但说句实在话CPU模式下vLLM的速度真的很慢只适合做功能验证和教学演示不适合生产推理。你可以试试看跑个7B模型然后用curl发个请求等待响应时间基本就能理解为什么大家都要用GPU了。我把上面提到的常用环境变量整理成了一张速查表方便你部署时快速对照环境变量作用常用取值实际使用建议CUDA_VISIBLE_DEVICES控制可见GPU范围及顺序GPU物理ID列表多卡部署前必设注意顺序影响并行效率VLLM_WORKER_MULTIPROC_METHOD多进程worker启动方式fork/spawn默认fork出现多卡异常时改spawnVLLM_USE_V1强制使用V1引擎1/0新版本异常时可临时回退旧引擎VLLM_ATTENTION_BACKEND指定Attention实现后端FLASH_ATTN/XFORMERS等默认自动选择性能异常时手动指定VLLM_LOGGING_LEVEL日志级别DEBUG/INFO/WARNING/ERROR调试用DEBUG生产保持INFOVLLM_TARGET_DEVICE运行设备类型cuda/cpuCPU仅适合功能验证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 fp8FP8的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_DEVICES2,3 vllm serve /data/models/Qwen2.5-70B-Instruct \ --tensor-parallel-size 2 \ --served-model-name qwen70b \ --port 8001 # 第二个服务用0号卡和1号卡跑7B模型 CUDA_VISIBLE_DEVICES0,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设得很大比如32KKV 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_BACKENDFLASH_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不一定会报错它可能只是静默忽略然后按新默认值运行。这类静默变化最坑人不对比你根本不知道行为已经变了。 vLLM部署指南：环境变量与启动参数完全解读
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_DEVICES2,4设置完之后程序里看到的GPU编号就变成了0和1分别对应物理上的第3和第5张卡。这个映射关系特别容易把人绕晕尤其是在做多卡并行的时候。我的建议是设置完这个变量后在代码里先打印一下torch.cuda.device_count()和torch.cuda.get_device_name()确认你看到的卡号和物理卡号对得上再往下走。还有个经常被忽略的细节CUDA_VISIBLE_DEVICES的顺序是有意义的。CUDA_VISIBLE_DEVICES4,2和CUDA_VISIBLE_DEVICES2,4不是一回事因为前者会把物理4号卡映射成逻辑0号卡物理2号卡映射成逻辑1号卡。如果你用--tensor-parallel-size 2做张量并行GPU通信的拓扑结构可能会因为这个顺序不同而产生性能差异。理想情况下你应该把NVLink带宽最高的卡排在相邻位置这个在单机8卡的机器上通常就是物理相邻的那几张。VLLM_WORKER_MULTIPROC_METHOD这个变量算是vLLM自己的一个重要配置它控制多进程启动方式。vLLM在做张量并行时会为每张卡启动一个worker进程这些worker进程之间的通信方式可以通过这个变量来调整可选值包括fork和spawn。默认情况下用的是fork因为启动速度快。但如果你发现多卡启动时出现异常、卡死或者某个worker进程报出奇怪的问题可以试试改成spawnexport VLLM_WORKER_MULTIPROC_METHODspawnspawn方式更安全它会重新导入模块、初始化环境但启动速度会慢一些。我在实际部署中遇到过一次情况用默认的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_WARNING1这样日志会干净不少。但我的建议是在开发调试阶段不要设置等确认没有重要警告后再关掉别为了日志干净错过了关键信息。VLLM_USE_V1这个变量就比较有时代特色了。vLLM在架构迭代过程中V1引擎逐渐成为主流官方为了保证兼容性允许用户通过环境变量强制切换或强制回退export VLLM_USE_V11 # 强制使用V1引擎 export VLLM_USE_V10 # 强制使用旧版引擎如果你遇到新版本引擎在某些模型或某些算子上行为异常而旧版本是好的可以通过这个变量先应急再等待官方修复。我在一次部署Qwen系列模型时就遇到过V1引擎下某个版本的bug导致输出概率分布异常回退到旧引擎后问题消失。这类问题在大型项目中其实不罕见知道这个开关就多了一条退路。2.3 日志与调试相关环境变量日志这块我单独拎出来说因为排查问题的时候日志的详细程度往往决定了你要花多少时间才能定位到问题。vLLM内部很多模块支持通过环境变量开启debug级别的日志输出。比较常用的是VLLM_LOGGING_LEVEL可以设置成DEBUG、INFO、WARNING、ERROR。默认是INFO在排查调度器行为、KV Cache分配细节时可以临时设为DEBUGexport VLLM_LOGGING_LEVELDEBUG但注意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_BACKENDFLASH_ATTN这个变量在排查为什么我的模型推理速度比别人慢这类问题时非常有用。我有一次在A100上跑长序列推理速度明显异常后来发现是因为环境里没装flash-attnvLLM回退到了xformers后端长序列下性能差了好几倍。装上flash-attn并手动指定后速度瞬间正常了。还有像VLLM_TARGET_DEVICE这个变量可以设置成cuda或cpu用于强制指定运行设备。在做纯CPU推理验证时这个很有用但说句实在话CPU模式下vLLM的速度真的很慢只适合做功能验证和教学演示不适合生产推理。你可以试试看跑个7B模型然后用curl发个请求等待响应时间基本就能理解为什么大家都要用GPU了。我把上面提到的常用环境变量整理成了一张速查表方便你部署时快速对照环境变量作用常用取值实际使用建议CUDA_VISIBLE_DEVICES控制可见GPU范围及顺序GPU物理ID列表多卡部署前必设注意顺序影响并行效率VLLM_WORKER_MULTIPROC_METHOD多进程worker启动方式fork/spawn默认fork出现多卡异常时改spawnVLLM_USE_V1强制使用V1引擎1/0新版本异常时可临时回退旧引擎VLLM_ATTENTION_BACKEND指定Attention实现后端FLASH_ATTN/XFORMERS等默认自动选择性能异常时手动指定VLLM_LOGGING_LEVEL日志级别DEBUG/INFO/WARNING/ERROR调试用DEBUG生产保持INFOVLLM_TARGET_DEVICE运行设备类型cuda/cpuCPU仅适合功能验证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 fp8FP8的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_DEVICES2,3 vllm serve /data/models/Qwen2.5-70B-Instruct \ --tensor-parallel-size 2 \ --served-model-name qwen70b \ --port 8001 # 第二个服务用0号卡和1号卡跑7B模型 CUDA_VISIBLE_DEVICES0,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设得很大比如32KKV 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_BACKENDFLASH_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不一定会报错它可能只是静默忽略然后按新默认值运行。这类静默变化最坑人不对比你根本不知道行为已经变了。