vLLM Linux 服务器部署教程：从环境准备到后台运行完整流程

一、vLLM适合解决什么问题

vLLM是一类面向大语言模型推理的高性能框架，核心优势在于显存管理效率高、并发吞吐能力强，并提供兼容OpenAI接口的服务模式。对于需要在Linux服务器上部署本地模型、给业务系统提供文本生成接口、做私有化推理验证或搭建团队内部AI能力平台的场景，vLLM通常比手写推理脚本更容易维护，也更适合长期运行。

它比较适合A10、A100、H100、L20、4090等具备CUDA能力的GPU服务器。若只是CPU机器，或显存低于模型需求，部署体验会明显下降。开始之前要先明确三件事：准备运行多大参数量的模型、预计同时服务多少请求、接口是否只在内网使用。模型越大、上下文越长、并发越高，对显存和算力要求越高。

二、部署前的环境准备

建议使用Ubuntu 20.04/22.04、Debian 11/12、Rocky Linux 8/9等常见服务器发行版。先登录服务器，执行nvidia-smi确认GPU能被系统识别，并记录驱动版本、显存大小和CUDA版本。若命令不存在或无法显示GPU信息，应先安装或修复显卡驱动，不要急于安装vLLM。

Python建议使用3.10或3.11。为了避免污染系统环境，推荐创建独立虚拟环境，例如使用conda create -n vllm python=3.10 -y，然后执行conda activate vllm。没有conda时，也可以使用python3 -m venv vllm-env，再通过source vllm-env/bin/activate启用环境。

基础工具建议提前安装：git、curl、wget、gcc、g++、python3-dev等。Ubuntu可执行apt update后安装相关依赖；Red Hat系系统可使用dnf安装。服务器磁盘空间也要预留充足，7B模型常见占用十几GB，较大模型可能需要数十GB甚至更多，缓存目录所在分区不要太小。

三、安装vLLM与依赖

进入虚拟环境后，可以先升级安装工具：python -m pip install -U pip setuptools wheel。随后安装vLLM：pip install vllm。一般情况下，pip会自动处理PyTorch等依赖，但GPU驱动与CUDA运行时仍需匹配。如果安装后启动报CUDA相关错误，优先检查PyTorch版本、驱动版本和vLLM版本是否兼容。

安装完成后执行python -c "import vllm; print(vllm.__version__)"进行验证。若能输出版本号，说明Python层面的安装已成功。若出现找不到动态库、CUDA不可用、torch无法调用GPU等报错，应先用python -c "import torch; print(torch.cuda.is_a vailable())"确认PyTorch是否可使用GPU。

模型来源可选择本地目录或模型仓库缓存目录。生产环境更推荐提前下载模型文件，再从本地路径加载，这样启动更稳定，也便于版本固定。模型目录一般应包含config.json、tokenizer相关文件以及权重文件。不要在多人共用服务器上随意覆盖模型目录，避免服务启动后加载到错误版本。

四、启动一个OpenAI兼容接口

最常见的启动方式是使用vLLM内置API服务。示例命令为：python -m vllm.entrypoints.openai.api_server --model /data/models/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8000。这里的--model可以是本地模型目录，也可以是受支持的模型名称；--host 0.0.0.0表示监听服务器所有网卡；--port用于指定服务端口。

如果显存紧张，可结合实际情况调整参数。例如--max-model-len限制上下文长度，--gpu-memory-utilization 0.85控制显存使用比例，--tensor-parallel-size 2用于多卡张量并行。参数不是越大越好，过高的显存占用可能导致服务在高并发时崩溃，建议先用小并发压测，再逐步提高。

服务启动后，可在另一终端使用curl访问接口，例如请求/v1/models查看模型列表，或向/v1/chat/completions发送测试请求。若本机可访问但其他机器不可访问，常见原因是防火墙、安全组、监听地址或端口策略未放行。若服务只供内部系统使用，不建议直接暴露到公网。

五、后台运行的三种方式

临时测试可使用tmux。先执行tmux new -s vllm，进入会话后启动vLLM服务，确认日志正常后按Ctrl+b再按d退出会话。之后可用tmux attach -t vllm重新进入。tmux的优点是直观，适合调试；缺点是服务器重启后不会自动恢复。

简单后台任务可使用nohup，例如：nohup python -m vllm.entrypoints.openai.api_server --model /data/models/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8000 > /data/logs/vllm.log 2>&1 &。启动后可用tail -f /data/logs/vllm.log查看日志。停止时需要通过ps -ef | grep vllm找到进程号，再执行kill。nohup适合轻量场景，但进程守护能力有限。

长期服务更建议使用systemd。可创建/etc/systemd/system/vllm.service，内容包括Unit、Service和Install三部分：Description填写服务说明；WorkingDirectory指定工作目录；ExecStart写完整的Python路径和启动参数；Restart=always表示异常退出后自动重启；User建议使用普通服务账号。保存后执行systemctl daemon-reload，systemctl enable vllm，systemctl start vllm。查看状态使用systemctl status vllm，查看日志使用journalctl -u vllm -f。

六、常见问题与排查思路

第一类问题是显存不足。表现为启动时报CUDA out of memory，或并发稍高就退出。解决思路包括换更小模型、降低--max-model-len、降低并发、调整显存利用率、使用量化模型或多卡并行。不要只看模型权重大小，还要考虑KV缓存和运行时开销。

第二类问题是版本不匹配。安装成功不代表一定能运行，驱动、CUDA、PyTorch、vLLM之间存在兼容关系。排查时先确认nvidia-smi正常，再确认torch.cuda.is_a vailable()为True，最后看vLLM启动日志。生产环境中不要频繁执行无版本限制的升级命令，建议记录pip freeze，必要时可回到旧环境。

第三类问题是接口响应慢。原因可能是模型过大、上下文过长、请求排队、磁盘读取慢或GPU利用率不足。可以通过nvidia-smi观察显存和GPU利用率，通过日志观察请求耗时。若面向多个业务方提供服务，应设置合理的最大输入长度和并发策略，避免单个超长请求拖慢整体服务。

七、安全边界与实用建议

部署推理服务时，应把访问控制放在第一位。vLLM本身主要负责推理，不应被当作完整网关使用。正式环境建议放在内网，前面接入Nginx、API网关或业务后端，由上层处理鉴权、限流、审计和日志脱敏。若必须跨机器访问，至少限制来源地址，并设置访问密钥。

模型使用也要注意授权范围。不同模型对商用、再分发、微调产物可能有不同要求，部署前应阅读模型许可说明。业务数据不要直接写入公开日志，尤其是用户输入、内部文档、合同内容、代码片段等敏感信息。日志只保留排错必要字段，并设置轮转策略，防止磁盘被写满。

稳定运行方面，建议为模型文件、运行环境、启动参数建立清单。每次升级vLLM或更换模型前，先在测试端口验证，再切换正式流量。重要服务可使用systemd自动重启，并配合监控GPU显存、进程状态、接口延迟和错误率。这样即使出现异常，也能快速定位是环境问题、模型问题还是请求压力问题。

总体来看，Linux服务器部署vLLM的关键不只是“装上能跑”，而是让环境可复现、参数可解释、服务可监控、风险可控制。按照环境检查、独立安装、接口启动、后台守护、日志排查和访问控制的顺序推进，能显著降低后续维护成本。